MCAF: Architecture Overview
Trigger On
- create the first repo-wide architecture map
- modules, boundaries, interfaces, or ownership changed
- onboarding is slow because there is no short "start here" system map
Value
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
- reduce ambiguity through explicit planning, verification, and final validation skills
- leave reusable project context so future tasks are faster and safer
Do Not Use For
- recording a single architecture decision with alternatives
- writing feature-level behaviour details
Inputs
- current solution layout and entry points
- the in-repository backend, frontend, contract, test, infrastructure, and docs roots plus the canonical slice convention required by
MCAF-ARCH-001
- existing ADRs, feature docs, and boundary docs
- feature
REQ-*/AC-* and ADR implementation links required by MCAF-REQ-001
- the nearest
AGENTS.md files
Quick Start
- Read the nearest
AGENTS.md and confirm scope and constraints.
- Run this skill's
Workflow through the Ralph Loop until outcomes are acceptable.
- Return the
Required Result Format with concrete artifacts and verification evidence.
Workflow
- Start from the current
docs/Architecture.md; if it is missing, scaffold it from references/overview-template.md.
- Build a short navigational overview:
- the single repository boundary and every solution-owned surface
- a repo-wide vertical-slice map using one canonical name per feature across backend, frontend, contracts, tests, and docs
- system or module map
- key boundaries and contracts
- scoping hints
- links to ADRs, feature docs, and high-signal code paths
- traceability from each non-trivial slice to its feature requirements and architecture-affecting ADR implementation contracts
- Use only real names from the repo. No placeholders like "Module A".
- Prefer Mermaid diagrams plus a tiny link index over long prose.
- Split diagrams by boundary if the map becomes noisy.
Deliver
docs/Architecture.md
- a short architecture map that routes the reader to deeper docs
- explicit evidence that
MCAF-ARCH-001 is applied to the real repository topology
Validate
- diagram nodes use real repo names
- every important box or boundary links to deeper material
- the file stays navigational instead of becoming an inventory dump
- the overview lets a new agent scope work without reading the whole repo
- no solution-owned surface points to another repository
- slice names and internal conventions match across every applicable technical root; non-applicable surfaces are explained
- non-trivial slices link to stable requirements and acceptance criteria, and architecture-affecting decisions link to ADRs whose status and implementation contract match reality
Ralph Loop
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
- Brainstorm first (mandatory):
- analyze current state
- define the problem, target outcome, constraints, and risks
- generate options and think through trade-offs before committing
- capture the recommended direction and open questions
- Plan second (mandatory):
- write a detailed execution plan from the chosen direction
- list final validation skills to run at the end, with order and reason
- Execute one planned step and produce a concrete delta.
- Review the result and capture findings with actionable next fixes.
- Apply fixes in small batches and rerun the relevant checks or review steps.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable or only explicit exceptions remain.
- If a dependency is missing, bootstrap it or return
status: not_applicable with explicit reason and fallback path.
Required Result Format
status: complete | clean | improved | configured | not_applicable | blocked
plan: concise plan and current iteration step
actions_taken: concrete changes made
validation_skills: final skills run, or skipped with reasons
verification: commands, checks, or review evidence summary
remaining: top unresolved items or none
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
- use
references/overview-template.md only when scaffolding the file
Example Requests
- "Create an architecture overview for this repo."
- "Update the overview after splitting the API and worker."
- "Make onboarding easier by adding a real module map."
1---2name: mcaf-architecture-overview-33description: Create or update `docs/Architecture.md` as the global architecture map for a solution. Use when bootstrapping a repo, onboarding, or changing modules, boundaries, or contracts. Keep it navigational and use `references/overview-template.md` for scaffolding.4---56# MCAF: Architecture Overview78## Trigger On910- create the first repo-wide architecture map11- modules, boundaries, interfaces, or ownership changed12- onboarding is slow because there is no short "start here" system map1314## Value1516- produce a concrete project delta: code, docs, config, tests, CI, or review artifact17- reduce ambiguity through explicit planning, verification, and final validation skills18- leave reusable project context so future tasks are faster and safer1920## Do Not Use For2122- recording a single architecture decision with alternatives23- writing feature-level behaviour details2425## Inputs2627- current solution layout and entry points28- the in-repository backend, frontend, contract, test, infrastructure, and docs roots plus the canonical slice convention required by `MCAF-ARCH-001`29- existing ADRs, feature docs, and boundary docs30- feature `REQ-*`/`AC-*` and ADR implementation links required by `MCAF-REQ-001`31- the nearest `AGENTS.md` files3233## Quick Start34351. Read the nearest `AGENTS.md` and confirm scope and constraints.362. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.373. Return the `Required Result Format` with concrete artifacts and verification evidence.3839## Workflow40411. Start from the current `docs/Architecture.md`; if it is missing, scaffold it from `references/overview-template.md`.422. Build a short navigational overview:43 - the single repository boundary and every solution-owned surface44 - a repo-wide vertical-slice map using one canonical name per feature across backend, frontend, contracts, tests, and docs45 - system or module map46 - key boundaries and contracts47 - scoping hints48 - links to ADRs, feature docs, and high-signal code paths49 - traceability from each non-trivial slice to its feature requirements and architecture-affecting ADR implementation contracts503. Use only real names from the repo. No placeholders like "Module A".514. Prefer Mermaid diagrams plus a tiny link index over long prose.525. Split diagrams by boundary if the map becomes noisy.5354## Deliver5556- `docs/Architecture.md`57- a short architecture map that routes the reader to deeper docs58- explicit evidence that `MCAF-ARCH-001` is applied to the real repository topology5960## Validate6162- diagram nodes use real repo names63- every important box or boundary links to deeper material64- the file stays navigational instead of becoming an inventory dump65- the overview lets a new agent scope work without reading the whole repo66- no solution-owned surface points to another repository67- slice names and internal conventions match across every applicable technical root; non-applicable surfaces are explained68- non-trivial slices link to stable requirements and acceptance criteria, and architecture-affecting decisions link to ADRs whose status and implementation contract match reality6970## Ralph Loop7172Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.73741. Brainstorm first (mandatory):75 - analyze current state76 - define the problem, target outcome, constraints, and risks77 - generate options and think through trade-offs before committing78 - capture the recommended direction and open questions792. Plan second (mandatory):80 - write a detailed execution plan from the chosen direction81 - list final validation skills to run at the end, with order and reason823. Execute one planned step and produce a concrete delta.834. Review the result and capture findings with actionable next fixes.845. Apply fixes in small batches and rerun the relevant checks or review steps.856. Update the plan after each iteration.867. Repeat until outcomes are acceptable or only explicit exceptions remain.878. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.8889### Required Result Format9091- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`92- `plan`: concise plan and current iteration step93- `actions_taken`: concrete changes made94- `validation_skills`: final skills run, or skipped with reasons95- `verification`: commands, checks, or review evidence summary96- `remaining`: top unresolved items or `none`9798For setup-only requests with no execution, return `status: configured` and exact next commands.99100## Load References101102- use `references/overview-template.md` only when scaffolding the file103104## Example Requests105106- "Create an architecture overview for this repo."107- "Update the overview after splitting the API and worker."108- "Make onboarding easier by adding a real module map."