Goal

The best, most elegant and effective software systems are ones that are well-informed, well-planned, and verifiable. The final output is a plan/spec that can act as a reference doc, covering the problem/motivation, technical approach, deltas (what properties of the system will change once implemented), and verification criteria. The first step is always understanding the current state. Use gjalla (CLI or MCP) to fetch the relevant parts of the master spec, including the architecture, capabilities, data flows, etc that are relevant to this problem/solution space. Also fetch the gjalla rules so you know what boundaries there are on your final solution. Once you understand the relevant properties and constraints, identify any specific details that you need from the source code and gather them. Now you have everything you can find yourself. Are there any outstanding questions that will affect the specifics of the solution you propose? If so, ask the user for input.

When you have everything you need, go ahead and use gjalla spec new which will scaffold a change spec for you to edit. This is necessary for workflows where spec artifacts are canonical, and the gjalla platform will facilitate verifying and merging changes into the master spec once implementation is complete. Think through the end-goal, the context (architecture, data flows, use case, etc.) and your rules/constraints, then work to design an elegant, maintainable, effective solution to the goal.