brooks-audit

Featured

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 how the codebase is organized, or asks "does this follow clean architecture?" or "why does everything depend on everything?". Also triggers for onboarding requests: "explain this codebase to a new developer" or "give me a codebase tour" (use onboarding mode). Do NOT trigger for: PR-level code review (use brooks-review) or line-level refactoring questions — this skill analyzes structural/module-level concerns, not individual functions.

Code & Development 1,469 stars 66 forks Updated 4 days ago MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
100
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
66
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Brooks-Lint — Architecture Audit ## Setup Read in order: 1. `../_shared/common.md` — Iron Law, Project Config, Report Template, Health Score 2. `../_shared/source-coverage.md` — book coverage, exceptions, tradeoffs 3. `../_shared/decay-risks.md` — symptom definitions and source attributions 4. `architecture-guide.md` (this directory) — 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. **Scope:** if the user did not specify files or a directory, apply Auto Scope Detection (`../_shared/common.md`) first. 1. Gather codebase context and draw the module dependency graph as Mermaid (Steps 0–1 of the guide) 2. Scan for each decay risk in the order specified (Steps 2–4 of the guide) 3. Assign node colors in the Mermaid diagram based on findings (red/yellow/green) — after Step 4 4. Run the Testability Seam Assessment (Step 5 of the guide) 5. Run the Conway's Law check (Step 6 of the guide) 6. Output using the Report Template from common.md — Mermaid graph FIRST, then Findings **Mode line in report:** `Architecture Audit`

Details

Author
hyhmrright
Repository
hyhmrright/brooks-lint
Created
5 months ago
Last Updated
4 days ago
Language
JavaScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

brooks-health

Combined codebase health dashboard that scores a project across all four quality dimensions — PR quality, architecture, tech debt, and test quality — in a single pass, drawing on twelve classic engineering books. Triggers when: user wants an overall quality assessment, asks "how healthy is this codebase?", "run all the checks", "I need a health score before the release", or wants to onboard a new team with a quality overview. Do NOT trigger for: server health checks, HTTP health endpoints, Kubernetes liveness/readiness probes, database health, or application uptime. Also do not trigger when the user specifically requests only one dimension — use the corresponding focused skill instead (brooks-review / brooks-audit / brooks-debt / brooks-test).

1,469 Updated 4 days ago
hyhmrright
Code & Development Featured

brooks-review

PR code review that surfaces decay risks, design smells, and maintainability issues with concrete Symptom → Source → Consequence → Remedy findings, drawing on twelve classic engineering books. Triggers when: user asks to review code, check a PR, shares a diff or pastes code asking "does this look right?" / "any issues here?" / "ready to merge?", or asks for feedback on a function, class, or file. Also triggers when user mentions: code smells / refactoring / clean architecture / DDD / SOLID principles / Hyrum's Law / deep modules / tactical programming / conceptual integrity / Brooks's Law / Mythical Man-Month / second system effect. Do NOT trigger for: questions about how to write code from scratch, language syntax questions, or framework/tool questions where no existing code is shared.

1,469 Updated 4 days ago
hyhmrright
Code & Development Listed

awesome-architecture-audit

Read-only whole-project audit of design: module boundaries and dependency direction, docs-vs-code fidelity, YAGNI/KISS/SOLID, and extensibility (build from source, add a provider), producing a prioritized report with a SHIP / FIX / BLOCK verdict. Language-agnostic. Use when asked to audit the architecture of a whole codebase, check whether the docs still match the code, judge how hard it is to extend, or 'оцени архитектуру'. Do not use for one diff (awesome-code-review), a vulnerability (awesome-security-audit), runtime latency (awesome-performance-audit), or comment cleanup (awesome-code-cleanup).

8 Updated today
khasky