/architect-implement

name: architect-implement
description: Use when accepted ADRs exist and AD.md must be produced or updated as unified architecture documentation.
disable-model-invocation: true

architect-implement

What this skill does

Generate a full Architecture Description (AD.md) from Architecture Decision Records (ADRs) using a **multi-agent DAG orchestration** approach:

1. **Plan Agent**: Analyze ADRs, detect sub-systems, generate a customized DAG, and get user approval. 2. **Execute Agent**: Generate architecture views per sub-system following the DAG, with dependency context passing. 3. **Summarize Agent**: Aggregate all views, resolve cross-subsystem conflicts, and generate a unified AD.md.

**Key Insight**: ADRs capture **why** decisions were made; the Architecture Description captures **what** the system looks like as a result of those decisions.

When to use

• **After `/architect-specify` or `/architect-clarify`**: Generate AD from discussed and accepted ADRs.
• **After `/architect-init`**: Document brownfield architecture.
• **ADR Updates**: Regenerate AD.md after new decisions.
• **Documentation Sprint**: Create comprehensive architecture docs.

When NOT to use

• **No ADRs exist**: Use `/architect-specify` or `/architect-init` first.
• **Feature-level**: Feature AD is generated during the feature's plan phase, not by this skill.
• **Minor updates**: Use direct editing for small changes.

Process

User Input

$ARGUMENTS

You **MUST** consider the user input before proceeding (if not empty).

**Examples of User Input**:

• `"Focus on deployment and operational views - we need infrastructure docs"`
• `"Generate all views with emphasis on security perspective"`
• `"Update existing AD.md with new ADRs from recent decisions"`
• Empty input: Generate complete Architecture Description from all ADRs

Flags

• `--views VIEWS`: Architecture views to generate
• `core` (default): Context, Functional, Information, Development, Deployment (5 core views)
• `all`: All 7 views including Concurrency and Operational
• Custom: comma-separated (e.g., `concurrency,operational`) - always includes core views

• `--sequential` (default): Execute views sequentially for maximum quality
• Recommended: Allows checkpoint after Functional view
• `--parallel`: Allow parallel execution where dependency chains permit
• Warning: May reduce cross-view consistency - use only when time-constrained

• `--no-checkpoint`: Skip Functional view checkpoint (not recommended)
• Warning: Functional view is the "cornerstone" that shapes all others

• `--force`: Bypass workflow state validation (emergency use only)
• **WARNING**: Use only when you understand the risks
• Skips clarify Phase 5.5 completion check
• Skips pre-flight ADR status validation
• May result in incomplete or inconsistent architecture

**Important**: When `--views` is `core` (default), **skip** Concurrency View (3.4) and Operational View (3.7) entirely. Only generate them when explicitly requested via `--views all` or `--views concurrency,operational`.

Rozanski & Woods Methodology Alignment

This command implements the **Viewpoints and Perspectives** framework from *Software Systems Architecture* (2nd Edition) by Nick Rozanski and Eoin Woods.

Core Principles

1. **Functional View is the Cornerstone** > "The Functional view is the cornerstone of most ADs... It usually drives > the shape of other system structures such as the information structure, > concurrency structure, deployment structure, and so on." > — Rozanski & Woods

2. **Views are Interrelated, Not Independent** > "The decisions taken in one view can have a considerable impact on the > others, and it is a big part of the architect's job to make sure that > these implications are understood."

3. **Perspectives Apply to Views** > "You never work with perspectives in isolation but instead use them with > each view to analyze and validate the qualities of your architecture."

4. **Quality Over Speed** Architecture mistakes are expensive to fix. Sequential execution with checkpoints is the default to ensure quality.

Viewpoint Dependency Graph

                    ┌──────────┐
                    │ Context  │  (System boundaries)
                    └────┬─────┘
                         │
                         ▼
                 ┌───────────────┐
                 │  FUNCTIONAL   │  ★ CORNERSTONE ★
                 │  (Drives all  │  USER CHECKPOINT
                 │   other views)│  REQUIRED HERE
                 └───────┬───────┘
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         ▼               ▼               ▼
   ┌───────────┐   ┌───────────┐   ┌───────────┐
   │Information│   │Concurrency│   │Development│
   │           │   │(optional) │   │           │
   └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
         │               │               │
         └───────────────┼───────────────┘
                         │
                         ▼
                  ┌────────────┐
                  │ Deployment │
                  └──────┬─────┘
                         │
                         ▼
                  ┌────────────┐
                  │ Operational│  (optional)
                  └────────────┘

Dynamic Viewpoint & Perspective Selection

Viewpoints and perspectives are selected dynamically based on system characteristics:

| Category | Always Included | Auto-Detected (Optional) | |----------|-----------------|--------------------------| | Viewpoints | Context, Functional | Information, Concurrency, Development, Deployment, Operational | | Perspectives | Security, Performance | Accessibility, Availability, Evolution, Internationalization, Location, Regulation, Usability, Development Resource |

**Reference**: https://www.viewpoints-and-perspectives.info/

Goal

Transform Architecture Decisio