What problem does it solve? Writing a whole-system architecture document from an approved PRD often produces boilerplate outlines, unjustified technology picks, and decisions buried inline. This Skill supplies the method for producing a grounded architecture document: scoping the boundary first, naming one responsibility per component, justifying each significant technology choice, realizing every NFR target with a mechanism, and recording each key decision as a standalone, linked ADR file. ## Core Features & Use Cases - Method-driven authoring: Fills an architecture-doc template's sections with judgment — boundary and stakeholder concerns first, protocol per topology arrow, failure semantics per integration boundary, and diagram-narrative sync. - Standalone ADR mechanism: Records each significant decision as its own immutable ADR file (one decision per file, with driver and real alternative), keeping only a linked decisions index in the document; changes supersede rather than rewrite. - NFR realization and amend path: Gives every PRD quality target a documented mechanism (measurable quality-attribute scenarios where load-bearing) and supports delta-based amendment with supersede conventions and downstream ripple analysis to dependent technical-design docs. - Use Case: Given an approved PRD for a new product, produce the system architecture document — context, components, topology, tech-choice rationale, NFR realizations — plus a set of linked ADR files that a reviewing skill can gate against a 10-condition bar. ## Quick Start Use authoring-architecture-doc to write the system architecture document from the approved PRD in docs/specs/auth-v2.md, with each key decision recorded as a linked ADR file.
