architecture-design

Architecture design

Design a target architecture. The architect writes design artifacts; it does not edit production source or implement the design.

When to use

Use when the user wants a new or revised architecture from functional requirements, product requirements, an ADR brief, or a known redesign goal. Use also when an existing system needs target-state module docs, integration contracts, or module test specifications before implementation.

If the user asks whether the existing implementation is healthy, start with architecture-review instead. If the user has an architecture report with findings but no approved target design, continue here before planning. If the user already has an approved architecture design and wants execution steps, use architecture-plan instead.

Skill navigation

• Missing or untrusted picture of the existing implementation: run architecture-review first. Architecture docs may describe original intent; code, deploy files, and tests may have drifted.
• Current skill: use architecture-design to turn requirements, validated context, or review findings into target architecture artifacts.
• Next skill after design approval: recommend exactly one primary next step: architecture-plan when implementation sequencing is requested, or stop when the user only asked for design.
• Next skill after plan implementation: run architecture-review with comparable scope to verify actual code matches the design.
• If design questions expose unclear requirements, pause design and get the missing requirement clarified before continuing.

Task list discipline

Maintain a visible task list for the design flow. Track at least:

1. Requirements and scope confirmed.
2. Existing docs/code drift checked when code exists.
3. Domain and volatility map approved.
4. Module map and integration contracts approved.
5. Design artifacts written.
6. Test specifications and fitness checks written.
7. Self-review complete.
8. Next skill recommendation made.