Brooks-Lint — Architecture Audit
When to Use
Use this skill when you need architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books. Triggers when: user asks to audit architecture, review folder/module structure, check for circular imports, understand...
Setup
- Read
../_shared/common.md for the Iron Law, Project Config, Report Template, and Health Score rules
- Read
../_shared/source-coverage.md for book-level coverage, exceptions, and tradeoffs
- Read
../_shared/decay-risks.md for symptom definitions and source attributions
- Read
architecture-guide.md in this directory for the audit framework
Process
Onboarding mode: If the user asks for an onboarding report, codebase tour, or
"explain this codebase to a new developer", read onboarding-guide.md from this
directory and follow it instead of architecture-guide.md. This mode explains rather
than diagnoses — no Health Score, no Iron Law findings.
If the user has not specified files or a directory to audit: apply Auto Scope
Detection from ../_shared/common.md to determine the audit scope before proceeding.
- Gather codebase context and draw the module dependency graph as Mermaid (Steps 0–1 of the guide)
- Scan for each decay risk in the order specified (Steps 2–4 of the guide)
- Assign node colors in the Mermaid diagram based on findings (red/yellow/green) — after Step 4
- Run the Testability Seam Assessment (Step 5 of the guide)
- Run the Conway's Law check (Step 6 of the guide)
- Output using the Report Template from common.md — Mermaid graph FIRST, then Findings
Mode line in report: Architecture Audit
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
1---2name: brooks-audit3description: Architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books.4license: MIT5---6
7# Brooks-Lint — Architecture Audit
8## When to Use
9
10Use this skill when you need architecture audit that maps module dependencies, checks layering integrity, and flags structural decay across a codebase, drawing on twelve classic engineering books. Triggers when: user asks to audit architecture, review folder/module structure, check for circular imports, understand...
11
12
13## Setup
14
151. Read `../_shared/common.md` for the Iron Law, Project Config, Report Template, and Health Score rules
162. Read `../_shared/source-coverage.md` for book-level coverage, exceptions, and tradeoffs
173. Read `../_shared/decay-risks.md` for symptom definitions and source attributions
184. Read `architecture-guide.md` in this directory for the audit framework
19
20## Process
21
22**Onboarding mode:** If the user asks for an onboarding report, codebase tour, or
23"explain this codebase to a new developer", read `onboarding-guide.md` from this
24directory and follow it instead of `architecture-guide.md`. This mode explains rather
25than diagnoses — no Health Score, no Iron Law findings.
26
27**If the user has not specified files or a directory to audit:** apply Auto Scope
28Detection from `../_shared/common.md` to determine the audit scope before proceeding.
29
301. Gather codebase context and draw the module dependency graph as Mermaid (Steps 0–1 of the guide)
312. Scan for each decay risk in the order specified (Steps 2–4 of the guide)
323. Assign node colors in the Mermaid diagram based on findings (red/yellow/green) — after Step 4
334. Run the Testability Seam Assessment (Step 5 of the guide)
345. Run the Conway's Law check (Step 6 of the guide)
356. Output using the Report Template from common.md — Mermaid graph FIRST, then Findings
36
37**Mode line in report:** `Architecture Audit`
38
39## Limitations
40
41- Use this skill only when the task clearly matches its upstream source and local project context.
42- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
43- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
hyhmrright