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
- existing ADRs, feature docs, and boundary docs
- the nearest
AGENTS.mdfiles
Quick Start
- Read the nearest
AGENTS.mdand confirm scope and constraints. - Run this skill's
Workflowthrough theRalph Loopuntil outcomes are acceptable. - Return the
Required Result Formatwith concrete artifacts and verification evidence.
Workflow
- Start from the current
docs/Architecture.md; if it is missing, scaffold it fromreferences/overview-template.md. - Build a short navigational overview:
- system or module map
- key boundaries and contracts
- scoping hints
- links to ADRs, feature docs, and high-signal code paths
- 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
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
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_applicablewith explicit reason and fallback path.
Required Result Format
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current iteration stepactions_taken: concrete changes madevalidation_skills: final skills run, or skipped with reasonsverification: commands, checks, or review evidence summaryremaining: top unresolved items ornone
For setup-only requests with no execution, return status: configured and exact next commands.
Load References
- use
references/overview-template.mdonly 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."