abd-architecture-outline
abd-architecture-outline
Purpose
A team that cannot draw its system on one page also cannot agree on what to build next. Outlines fix that. This skill produces the first architecture artifact for a system — short on prose, heavy on diagrams — so engineers, product, and stakeholders share a single picture of the platform, the layers, the neighbours, the deployment topology, and the principles in force. When the outline is in place, deeper architecture work (blueprint, reference, mechanisms) can start without re-litigating what the system is.
When to use this skill
Load this skill when any of the following apply:
- A new project is kicking off and there is no architecture document at all — start with the outline before deeper work.
- An existing project has no canonical picture of itself and onboarding new people takes weeks because everyone redraws the system from memory.
- A team is choosing a platform or major technology and needs a single page that names the candidate stack and the principles that drove the choice.
- Stakeholders keep asking "which system owns that?" and the answer changes depending on who is in the room — the major-systems catalogue settles it.
- An architecture review is about to happen and there is no outline-level artifact to anchor the conversation.
What is an architecture outline?
An architecture outline is the one-page answer to "what is this system?". It is built around a small set of diagrams — platform, layered architecture, system context, deployment topology — supplemented by a consolidated list of guiding principles, the technology stack, and a one-line description of every major system or subsystem. It is deliberately shallow: it shows the system's silhouette and neighbours but explicitly defers internal mechanisms, component contracts, data models, and patterns to the blueprint and reference skills that come after it.