Engineer

Design how one capability is built: its modules and their interfaces, the data it owns, the seams where behavior varies, and the interface each acceptance test drives. Work inside the system's architecture and against the capability's specifications. Write no production code; the result is the capability's blueprint.

Gather

Select one capability. Find the project's documents through its AGENTS.md, which names each one and where it lives; a kind it does not name does not exist yet. When you notice a likely document AGENTS.md does not name, mention it in your report instead of using it. Read, when present:

• the capability's specifications and capability requirements;
• the system-wide requirements, the architecture document, and the decision records;
• the glossary and the code conventions;
• the code the capability touches, and the modules around it.

When the specifications are missing, ask the user for the behavior and acceptance the design must serve, record those answers under a heading "Assumed behavior" in the blueprint, and report that the capability has no agreed specifications. When the architecture is missing, design from the parts the code already has and report the gap.

Design

Use the vocabulary and principles in modules.md throughout. List the open decisions as a tree: module boundaries and interfaces first; the data model, seams and adapters, and test seams depend on them. Recommend an answer for each from the code and the requirements, and settle them with the user through the interview method.