Brownfield/onboarding

[binduwavell]

Which document?

Other

If a SKILL.md — which skill?

No response

Which section?

No response

Type of issue

Missing information — a gap that leaves a reader without an answer

What is wrong or missing?

This is a very elegant coding assistant system, kudos!

I would hover created this as a discussion topic but that is not working in this project.

I have a bunch of existing projects with PRDs, often broken down into more formal specs.

Before this project I had not heard of “Clean Architecture”. From context, I assume it is formal system rather than just a judgement call :) To that end, I think it would be beneficial to link to resources on this.

Similarly this project talks about domains and layers, but assumes the reader has a nuanced understanding of these terms. Of course you can’t explain everything, but referencing the models you are working from can be inviting and help people align quickly.

So back to my existing projects, I see how this can be configured to fit in with my project standards very cleanly. However, I’m unclear how I could migrate my existing collection of PRDs, specs and tests to create context files in this system.

Q1: I’m curious how you would perform a context migration to lattice?

I suspect my specs are the right thing to convert to context, however these are organized by category rather than feature. My categories have variable levels of decomposition, I tend to focus on a spec for a category being less than about 300 lines, so when they get larger I tend to split them along natural (to me) areas of focus. If I’m adding a feature that affects several categories, I might just add a new feature that is cross cutting or I might reorganize existing specs to accommodate the new complexity.

Q2: I’m curious how lattice handles (or should handle) both the inherent complexity when a feature (or enhancement) affects multiple contexts?

Q3: And, how lattice handles (or should handle) tasks related to maintenance (reorganizzation) of the context store?

What should it say instead?

No response

[techygarg]

@binduwavell : Thanks for the kind words, and for articulating these precisely — real gaps worth addressing.

On Clean Architecture and terminology: Fair point. We'll add links to the canonical references (Clean Architecture, DDD) in the relevant docs rather than assuming familiarity.

Q1: Context migration from existing PRDs and specs
No migration needed. Drop your PRDs and specs into a requirements folder as-is. Run /lattice-init (or /knowledge-priming-refiner) to establish the base context. From there, invoke /design-blueprint and point it directly at your existing documents — just mention "this is my requirement doc, this is my PRD" and the molecule works from what you have. Lattice doesn't require a specific format; it reads what you give it.

Coming soon: This discussion surfaced a good idea — a dedicated molecule that takes your existing PRDs and specs and produces well-structured Lattice requirement docs from them. That's on the roadmap. In the meantime, the above approach works as a manual path.

Q2: Features that span multiple contexts
A few options, roughly in order of effort:

1. Put it in the knowledge base. Add the common context directly to .lattice/standards/knowledge-base.md, or add a reference to your common context document there with a note on what it contains. The knowledge-priming atom loads this file into every workflow, so anything there is automatically active.
2. Use refiners to set it up. /knowledge-priming-refiner, /language-idioms-refiner, and the other refiners are designed to capture exactly this — shared standards, conventions, and context that should apply everywhere. Run the relevant ones and let them write into .lattice/standards/. If your cross-cutting concern fits a refiner's domain, that's the cleanest path.
3. Pass it explicitly to the molecule. If the above doesn't cover it, pass your common context document as additional input when invoking /design-blueprint or /code-forge — just reference the path and tell the molecule what it contains.

We'd love to hear what works — try these in order and share what does or doesn't hold up.

Q3: Maintenance and reorganization of the context store
.lattice/context/ is plain markdown files — rename, split, or merge by hand when your spec structure evolves. When you split a doc, copy the relevant decisions and constraints into the new files. No tooling exists for this today; it's a known gap.

[binduwavell]

@techygarg, thank you very much for taking the time to share this valuable detail. I hope to give migration to Lattice a shot on one of my repos this weekend.

Very interested to see how completely it will be able to process my PRD and specs in one pass. So far I've struggled to get even a basic consistency validation report to complete without a lot of my direction and a lot of tokens.

I have high hopes for this more formal and compact approach :)

[techygarg]

@binduwavell I added a new molecule, requirement-forge, this can help you to process your existing PRDs and specs into a more Epic -Feature style. Post that you can run design-blueprint to initiate design phase.
Give it a try and let me know your feedback. Please take a look at docs too.
If you are using, claude code plugin, update it as a new version is pushed.

TBH, the whole e2e journey is more fit for green-field projects: requirement-forge → design-blueprint → code-forge → review but individuals molecule can be used in isolation too. Lets see how lattice evolve overtime.

[apnea]

Interesting scenario, thanks for sharing. @binduwavell you could probably also get your model to help with any migration tasks. After /lattice-init the model is able to reason about the framework and suggest or act