opencode-skills-collection 3.1.12 → 3.1.14

package/bundled-skills/brooks-audit/architecture-guide.md

@@ -0,0 +1,195 @@
+# Architecture Audit Guide — Mode 2
+
+**Purpose:** Analyze the module and dependency structure of a system for decay risks that
+operate at the architectural level. Every finding must follow the Iron Law:
+Symptom → Source → Consequence → Remedy.
+
+**Monorepo note:** Treat each deployable service or library as a top-level module. Draw
+dependencies between services, not between their internal packages. Apply the Conway's Law
+check at the service ownership level. Within a single service, apply standard module-level analysis.
+
+---
+
+## Analysis Process
+
+Work through these six steps in order.
+
+### Step 0: Gather Codebase Context
+
+Before drawing anything, establish what you can see.
+
+**If the user provided a full directory tree or pasted relevant file contents:** skip the
+proactive reading below and proceed to Step 1.
+
+**Otherwise, proactively read the project using these tools:**
+
+1. **Top-level structure** — glob top two levels to identify module boundaries:
+   ```
+   Glob: **/*(depth 2, directories only)
+   ```
+2. **Entry points** — read the package manifest or main config file (e.g., `package.json`,
+   `go.mod`, `pom.xml`, `Cargo.toml`, `pyproject.toml`) to confirm language, framework,
+   and declared dependencies.
+3. **Dependency edges** — grep import statements to discover inter-module calls. Run once
+   per language present; limit to the first 200 matches to avoid token overrun:
+   ```
+   Grep: "^\s*(import|from|require\(|use )" across *.ts|*.py|*.go|*.rs|*.java
+   ```
+4. **Large modules** — for any top-level directory with > 10 files, read the file matching
+   `index.*`, `main.*`, or `__init__.*` to understand its stated responsibility.
+
+**Stop when you can answer all three:**
+- What are the top-level modules (names and count)?
+- Which modules import from which other modules?
+- Which module has the highest fan-in or fan-out?
+
+If the project has > 100 top-level files or > 4 levels of nesting, note which areas were
+sampled vs. inferred, and flag this in the report scope line.
+
+### Step 1: Draw the Module Dependency Graph (Mermaid)
+
+Before evaluating any risk, map the dependencies as a Mermaid diagram. Use this format:
+
+````mermaid
+graph TD
+  subgraph UI
+    WebApp
+    MobileApp
+  end
+
+  subgraph Domain
+    AuthService
+    OrderService
+    PaymentService
+  end
+
+  subgraph Infrastructure
+    Database
+    MessageQueue
+  end
+
+  WebApp --> AuthService
+  WebApp --> OrderService
+  MobileApp --> AuthService
+  MobileApp --> OrderService
+  OrderService --> PaymentService
+  OrderService --> Database
+  OrderService --> MessageQueue
+  PaymentService --> Database
+  AuthService -.->|circular| OrderService
+
+  classDef critical fill:#ff6b6b,stroke:#c92a2a,color:#fff
+  classDef warning fill:#ffd43b,stroke:#e67700
+  classDef clean fill:#51cf66,stroke:#2b8a3e,color:#fff
+
+  class PaymentService critical
+  class OrderService warning
+  class Database,MessageQueue,AuthService,WebApp,MobileApp clean
+````
+
+Draw the graph structure first — nodes, subgraphs, and edges — without any `classDef` or
+`class` lines. You cannot assign colors until you have completed the risk scan in Steps 2–4.
+
+**After completing Step 4**, return to this graph and add the `classDef` and `class` lines
+based on findings. The example above shows the final colored output.
+
+Rules:
+1. **Nodes** — Use top-level directories or services as nodes, not individual files
+2. **Grouping** — One `subgraph` per architectural layer or top-level directory (e.g., UI, Domain, Infrastructure)
+3. **Edges** — Solid arrows (`-->`) point FROM the depending module TO the dependency; use dotted arrows with label (`-.->|circular|`) for circular dependencies. If no circular dependencies exist, use only solid arrows
+4. **Node limit** — Keep the graph to ~50 nodes maximum; collapse low-risk leaf modules into their parent if needed
+5. **Fan-out** — For any node with fan-out > 5, use a descriptive label: `HighFanOutModule["ModuleName (fan-out: 7)"]`
+6. **Colors** — Apply `classDef` colors AFTER completing Steps 2-4: `critical` (red `#ff6b6b`) for nodes with Critical findings, `warning` (yellow `#ffd43b`) for Warning findings, `clean` (green `#51cf66`) for nodes with no findings or only Suggestions. If no findings at all, classify all nodes as `clean`
+7. **Direction** — Default to `graph TD` (top-down); use `graph LR` only if the architecture is clearly a left-to-right pipeline
+
+### Step 2: Scan for Dependency Disorder
+
+*The most architecturally consequential risk — scan this first.*
+
+Look for:
+- Circular dependencies (any `-.->|circular|` edge in the map above)
+- Arrows flowing upward (high-level domain depending on low-level infrastructure)
+- Stable, widely-depended-on modules that import from frequently-changing modules
+- Modules with fan-out > 5
+- Absence of a clear layering rule (no consistent answer to "what depends on what?")
+
+### Step 3: Scan for Domain Model Distortion
+
+Look for:
+- Do module names match the business domain vocabulary?
+- Is there a layer called "services" that contains all the business logic while domain objects
+  are pure data structures?
+- Are there modules that cross bounded context boundaries (e.g., billing logic in the user module)?
+- Is there an anti-corruption layer where external systems interface with the domain?
+
+### Step 4: Scan for Remaining Four Risks
+
+Check each in turn:
+
+**Knowledge Duplication:**
+- Are there multiple modules implementing the same concept independently?
+- Does the same domain concept appear under different names in different modules?
+
+**Accidental Complexity:**
+- Are there entire layers in the architecture that do not add value?
+- Are there modules whose responsibility cannot be stated in one sentence?
+
+**Change Propagation:**
+- Which modules are "blast radius hotspots"? (A change here requires changes in many other modules)
+- Does the dependency map reveal why certain features are slow to develop?
+
+**Cognitive Overload:**
+- Can the module responsibility of each module be stated in one sentence from its name alone?
+- Would a new developer know which module to add a new feature to?
+
+### Step 5: Testability Seam Assessment
+
+A *seam* is a place in the architecture where behavior can be altered without editing source
+code — typically an interface, a configuration point, or a dependency injection boundary.
+Seam density is a proxy for testability and evolvability.
+
+Scan for:
+- **No seam at the infrastructure boundary**: can you replace a real database, file system,
+  or HTTP client with a test double without editing the module under test? If not, the
+  architecture forces integration tests where unit tests would suffice.
+- **Seam collapse**: a module that was once testable in isolation has had its seams removed
+  (e.g., direct constructor instantiation replaced a dependency injection point, or a global
+  singleton replaced an injected collaborator).
+- **Missing seam in legacy areas**: modules without an obvious injection point or interface
+  boundary — any change requires touching the entire call stack to substitute behavior.
+
+If all modules have clear seams at their infrastructure boundaries → no finding.
+
+If seams are absent or collapsed: flag as 🟡 Warning with a Remedy pointing to the specific
+module and the injection point that needs to be restored or introduced.
+
+Source: Feathers — Working Effectively with Legacy Code, Ch. 4: The Seam Model
+
+### Step 6: Conway's Law Check
+
+After the six-risk scan, assess the relationship between architecture and team structure:
+
+- Does the module/service structure reflect the team structure?
+  (Conway's Law: "Organizations design systems that mirror their communication structure")
+- If yes: is this intentional design or accidental coupling?
+- A mismatch that causes cross-team coordination overhead for every feature is 🔴 Critical.
+- A mismatch that is theoretical but not yet causing pain is 🟡 Warning.
+- If team structure is unknown, note this as context missing and skip the check.
+
+**Calibration examples:**
+- 🔴 Critical: the Payments module is owned by Team A but contains auth logic owned by Team B —
+  every Payments change requires a sync meeting with Team B
+- 🟡 Warning: two separate teams own the `utils/` and `helpers/` directories which do the same
+  things — theoretically painful but not yet causing release coordination issues
+- Not a finding: a single team owns a monorepo with multiple logical modules — Conway's Law
+  misalignment requires *separate teams* to be meaningful
+
+---
+
+## Output
+
+Use the standard Report Template from `../_shared/common.md`. Mode: Architecture Audit.
+
+Place the Mermaid dependency graph FIRST under "Module Dependency Graph". Reference
+relevant node names in findings. Add `classDef` color assignments LAST, after all
+findings are identified.

package/bundled-skills/brooks-audit/onboarding-guide.md

@@ -0,0 +1,89 @@
+# Codebase Onboarding Guide
+
+**Purpose:** Produce a newcomer-friendly tour of the codebase. This is NOT a diagnostic
+report — no Health Score, no Iron Law findings. Focus on explanation and orientation.
+
+---
+
+## Process
+
+### Step 1: Map the Territory
+
+- Read top-level structure (same as architecture-guide Step 0)
+- Output: a plain-language overview of what each top-level module does (one sentence each)
+- Group into layers: "Things users interact with", "Business logic", "Infrastructure"
+
+### Step 2: Draw the Dependency Map
+
+Draw the same Mermaid dependency graph as architecture audit Step 1, but color nodes by
+**recommended reading order** using a DISTINCT palette from the severity palette
+(which uses red/yellow/green). This avoids confusing "red = danger" with "red = read last":
+
+- 🔵 Blue (`#339af0`): start here — entry points, core domain
+- 🟣 Purple (`#9775fa`): read next — supporting modules
+- ⚪ Gray (`#ced4da`): read last — infrastructure, generated code, utilities
+
+Add numbered labels: `CoreModule["1. CoreModule"]`
+
+```
+classDef start fill:#339af0,color:#fff
+classDef next fill:#9775fa,color:#fff
+classDef last fill:#ced4da
+```
+
+### Step 3: Highlight Key Conventions
+
+Identify and document patterns the codebase follows:
+- Naming conventions (file naming, class naming, variable naming)
+- Directory organization pattern (feature-based? layer-based? hybrid?)
+- Error handling pattern (exceptions? result types? error codes?)
+- Testing convention (co-located? separate directory? naming pattern?)
+- Dependency injection pattern (if any)
+
+### Step 4: Mark Danger Zones
+
+For each module with known complexity or coupling issues, add a brief warning:
+- "OrderService: high complexity, only modify with full test suite running"
+- "legacy/: no tests, use Characterization Tests before changing"
+
+Do NOT use Iron Law format — use plain warnings. This is orientation, not diagnosis.
+
+### Step 5: Build a Domain Glossary
+
+Extract 10-15 key domain terms from code (class names, method names, constants) and map
+them to plain-language definitions. This applies Evans's Ubiquitous Language as documentation.
+
+### Step 6: Suggest First Tasks
+
+Based on the dependency map, suggest 2-3 low-risk areas where a new developer could make
+their first contribution: modules with good test coverage, clear boundaries, low coupling.
+
+---
+
+## Output Template
+
+```
+# Codebase Tour: [Project Name]
+
+## Overview
+[2-3 sentence summary of what the project does and its tech stack]
+
+## Module Map
+[Mermaid graph with reading-order colors]
+
+## Module Guide
+[One paragraph per top-level module: what it does, what it depends on, key files to read]
+
+## Conventions
+[Bullet list of patterns this codebase follows]
+
+## Danger Zones
+[Bullet list of areas to be careful with, or "None identified" if the codebase is clean]
+
+## Domain Glossary
+| Term | Meaning |
+|------|---------|
+
+## Suggested First Tasks
+[2-3 concrete suggestions for a new developer's first PR]
+```

package/bundled-skills/brooks-debt/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: brooks-debt
+description: 'Tech debt assessment that identifies, classifies, and prioritizes maintainability problems — helping teams build a refactoring roadmap — drawing on twelve classic engineering books. Triggers when: user asks about tech debt, refactoring priorities, what to clean up first, or asks "why...'
+risk: unknown
+source: https://github.com/hyhmrright/brooks-lint/tree/main/skills/brooks-debt
+source_repo: hyhmrright/brooks-lint
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/brooks-lint/blob/main/LICENSE
+---
+
+# Brooks-Lint — Tech Debt Assessment
+## When to Use
+
+Use this skill when you need tech debt assessment that identifies, classifies, and prioritizes maintainability problems — helping teams build a refactoring roadmap — drawing on twelve classic engineering books. Triggers when: user asks about tech debt, refactoring priorities, what to clean up first, or asks "why...
+
+
+## Setup
+
+1. Read `../_shared/common.md` for the Iron Law, Project Config, Report Template, and Health Score rules
+2. Read `../_shared/source-coverage.md` for book-level coverage, exceptions, and tradeoffs
+3. Read `../_shared/decay-risks.md` for symptom definitions and source attributions
+4. Read `debt-guide.md` in this directory for the debt classification framework
+
+## Process
+
+**If the user has not described the codebase or pointed to specific areas:** apply Auto
+Scope Detection from `../_shared/common.md` to determine the assessment scope before proceeding.
+
+1. Scan for all six decay risks (Step 1 of the guide); list every finding before scoring
+2. Apply the Pain × Spread priority formula and classify debt intent (Steps 2–3 of the guide)
+3. Group findings by decay risk (Step 4 of the guide)
+4. Output using the Report Template from common.md, plus the Debt Summary Table
+
+**Mode line in report:** `Tech Debt Assessment`
+
+## 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.

package/bundled-skills/brooks-debt/debt-guide.md

@@ -0,0 +1,125 @@
+# Tech Debt Assessment Guide — Mode 3
+
+**Purpose:** Identify, classify, and prioritize technical debt across the entire codebase.
+Every finding must follow the Iron Law: Symptom → Source → Consequence → Remedy.
+
+---
+
+## Evidence Gathering
+
+If you have insufficient evidence to assess the codebase, ask the user ONE question —
+choose the single question most relevant to what you already know:
+
+1. "Which part of the codebase takes the longest to modify for a typical feature?"
+2. "Which module do developers avoid touching, and why?"
+3. "Which parts of the system have the fewest tests and the most bugs?"
+4. "Is there a module that only one person fully understands?"
+
+After one answer, proceed. Do not ask more than one question.
+If the user declines or says they don't know, proceed with available evidence and note
+which areas could not be assessed.
+
+---
+
+## Analysis Process
+
+Work through these four steps in order.
+
+### Step 1: Full Decay Risk Scan
+
+Scan for all six decay risks across the entire codebase. List every finding before scoring
+any of them. This prevents anchoring on early findings and missing systemic patterns.
+
+For each risk, look for:
+
+**Cognitive Overload:** Are there widespread naming problems, deeply nested logic, or
+excessively long functions spread across many modules?
+
+**Change Propagation:** Which modules cause the most ripple effects when changed?
+Are there modules that everyone must modify when adding a new feature?
+
+**Knowledge Duplication:** How many times is the same concept implemented independently?
+Is the domain vocabulary consistent across the codebase?
+
+**Accidental Complexity:** Are there architectural layers or abstractions that add no value?
+Is the infrastructure overhead proportional to the problem being solved?
+
+**Dependency Disorder:** Are there dependency cycles? Does domain logic depend on infrastructure?
+Are there modules with no clear layering position?
+
+**Domain Model Distortion:** Is business logic in the right layer?
+Do code names match business names? Are domain objects anemic?
+
+### Step 2: Score Each Finding with Pain × Spread
+
+After listing all findings, score each one:
+
+**Pain score (1–3):** How much does this slow down development today?
+- 3: Developers actively avoid touching this area; it causes bugs on most changes
+  *(e.g., "nobody wants to touch the billing module because it always breaks something")*
+- 2: This area is noticeably slower to work in than the rest of the codebase
+  *(e.g., "adding a field takes 2–3x longer here than elsewhere")*
+- 1: This is a quality issue but not currently causing active pain
+  *(e.g., "inconsistent naming, but we always know what we mean")*
+
+**Spread score (1–3):** How many files, modules, or developers does this affect?
+- 3: Affects 5+ modules or all developers on the team
+  *(e.g., "every new feature touches the God class in core/")*
+- 2: Affects 2–4 modules or a subset of the team
+  *(e.g., "the auth and notification modules are tightly coupled")*
+- 1: Isolated to one module or one developer's area
+  *(e.g., "legacy parser that only one person maintains")*
+
+**Priority = Pain × Spread** (max 9)
+
+| Priority | Classification | Action |
+|----------|---------------|--------|
+| 7–9 | Critical debt | Address in next sprint |
+| 4–6 | Scheduled debt | Plan within quarter |
+| 1–3 | Monitored debt | Log and watch |
+
+### Step 3: Classify Debt Intent
+
+After scoring, classify each finding as intentional or accidental:
+
+**Intentional debt** — a conscious shortcut taken to meet a deadline, with the expectation
+of paying it back. The team knows about it. It may be legitimate (a strategic prototype,
+a known temporary workaround during a migration).
+
+**Accidental debt** — degradation that accumulated without a deliberate decision: the team
+did not choose it and may not even know it exists. This is the kind Ward Cunningham's
+original definition warned against — not a tactical trade-off, but structural erosion.
+
+Mark each finding with `[intentional]` or `[accidental]` in the Debt Summary Table.
+Intentional debt with no visible payback plan — no linked ticket, no code comment, no
+documented decision — should be treated as accidental for prioritization purposes.
+Focus remediation energy on accidental debt first; intentional debt at least has an owner.
+
+### Step 4: Group by Decay Risk
+
+Report findings grouped by risk type, not by file or module.
+Grouping by risk reveals systemic patterns:
+- "Change Propagation is systemic" → architectural intervention needed
+- "Cognitive Overload is isolated" → localized refactoring sufficient
+
+---
+
+## Output
+
+Use the standard Report Template from `../_shared/common.md`. Mode: Tech Debt Assessment.
+
+After Findings, append a Debt Summary Table:
+
+```
+## Debt Summary
+| Risk | Findings | Avg Priority | Classification | Intent |
+|------|----------|-------------|----------------|--------|
+| Cognitive Overload      | N | X.X | Monitored/Scheduled/Critical | intentional/accidental |
+| Change Propagation      | N | X.X | ... | ... |
+| Knowledge Duplication   | N | X.X | ... | ... |
+| Accidental Complexity   | N | X.X | ... | ... |
+| Dependency Disorder     | N | X.X | ... | ... |
+| Domain Model Distortion | N | X.X | ... | ... |
+
+**Recommended focus:** [risks with highest average priority]
+```

package/bundled-skills/brooks-harness/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: brooks-harness
+description: Maintenance orchestrator for the brooks-lint plugin itself. Runs a sequential subagent pipeline — author → eval → QA → trigger-audit → release — to add or edit a skill, refresh the eval suite, keep the four manifests + README + CHANGELOG + AGENTS/GEMINI in sync, audit trigger...
+risk: unknown
+source: https://github.com/hyhmrright/brooks-lint/tree/main/.claude/skills/brooks-harness
+source_repo: hyhmrright/brooks-lint
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/brooks-lint/blob/main/LICENSE
+---
+
+# brooks-lint — Maintenance Harness (Orchestrator)
+## When to Use
+
+Use this skill when you need maintenance orchestrator for the brooks-lint plugin itself. Runs a sequential subagent pipeline — author → eval → QA → trigger-audit → release — to add or edit a skill, refresh the eval suite, keep the four manifests + README + CHANGELOG + AGENTS/GEMINI in sync, audit trigger...
+
+
+This skill orchestrates work **on the brooks-lint repo itself**. It runs a sequential
+subagent pipeline: each stage is a dedicated agent defined in `.claude/agents/`. Spawn
+each with the `Agent` tool, `subagent_type` set to the agent name, and **always
+`model: "opus"`**. Stages depend on each other in order, so this is a pipeline, not a
+parallel team.
+
+## Pipeline
+
+```
+[orchestrator]
+   Phase 0  context check
+   Phase 1  classify request → select stages
+   Phase 2  run selected stages in order, with a QA loop-back:
+            skill-author → eval-curator → consistency-qa ─(FAIL)→ back to author
+                                              │ PASS
+                                              ▼
+                            trigger-boundary-auditor   (only if a description changed)
+                                              ▼
+                                      release-manager  (only if release requested)
+   Phase 3  report + collect feedback
+```
+
+## Phase 0 — Context check
+
+Determine the run mode before doing anything:
+
+- `_workspace/brooks-harness/` exists + maintainer asks to redo part of a prior run →
+  **partial re-run**: invoke only the affected stage(s), reusing prior notes.
+- `_workspace/brooks-harness/` exists + a fresh request → **new run**: move the old
+  folder to `_workspace/brooks-harness_prev/`, start clean.
+- No `_workspace/brooks-harness/` → **initial run**: create it.
+
+Run notes and the QA report live under `_workspace/brooks-harness/`. The *real*
+artifacts are the repo files themselves — agents edit `skills/`, `evals/`, manifests
+directly; `_workspace/` only holds the run's notes and the PASS/FAIL verdict for audit.
+
+## Phase 1 — Classify the request
+
+Pick the minimal set of stages. The QA stage is **never skipped** — every change is
+gated.
+
+| Request | author | eval | QA | trigger-audit | release |
+|---------|:------:|:----:|:--:|:-------------:|:-------:|
+| Add a new skill | ✓ (via `new-skill` scaffold) | ✓ | ✓ | ✓ | — |
+| Edit skill / guide content | ✓ | if codes changed | ✓ | if `description` changed | — |
+| Edit `_shared/` framework | ✓ | if risk defs changed | ✓ | — | — |
+| Eval suite only | — | ✓ | ✓ | — | — |
+| Fix trigger descriptions | ✓ | — | ✓ | ✓ | — |
+| Release | — | — | ✓ | — | ✓ |
+| Full: change + release | ✓ | as needed | ✓ | if applicable | ✓ |
+
+## Phase 2 — Run the pipeline
+
+Spawn each selected stage as a subagent in order. Pass each agent (a) the task
+contract and (b) the previous stage's summary. Agents write their summaries to
+`_workspace/brooks-harness/`; read them between stages.
+
+1. **skill-author** — creates/edits the content. For a brand-new skill it invokes the
+   `new-skill` scaffold. Returns the list of files touched + convention-relevant
+   choices (new risk codes, new Step numbers, changed `description` trigger phrases).
+2. **eval-curator** — if `skill-author` reported new/changed risk codes or modes, adds
+   the paired happy-path + false-positive scenarios and runs `npm run evals`.
+3. **consistency-qa** *(gate — never skipped)* — runs `npm run validate` + `npm test` +
+   `npm run evals`, then the cross-document sync checks (manifests, README badge,
+   CHANGELOG, AGENTS/GEMINI book count, eval count). Writes a PASS/FAIL verdict.
+   **On FAIL: loop back to the agent named in the verdict (author or eval-curator),
+   fix, then re-run QA. Repeat once; if it still fails, stop and report to the
+   maintainer.**
+4. **trigger-boundary-auditor** — run **only if a `description` field changed**. It
+   read-only audits the six shipped skills' trigger surfaces for false-triggering and
+   routing collisions. Surface its findings; if it flags a real collision, loop back to
+   skill-author.
+5. **release-manager** — run **only if a release was requested**, and **only after QA
+   PASS**. Cuts the release via the `release` skill.
+
+## Phase 3 — Report & feedback
+
+Report: stages run, files changed, QA verdict, trigger-audit findings (if any), and the
+release URL (if any). Then offer the maintainer a feedback opening: "Anything to adjust
+in the result, the agent roles, or the pipeline order?" Record accepted changes in the
+CLAUDE.md harness change-log table.
+
+## Conventions this harness enforces
+
+- **All `Agent` calls use `model: "opus"`** — harness quality tracks agent reasoning.
+- **consistency-qa must be `general-purpose`** (it runs npm scripts); the
+  trigger-boundary-auditor is read-only.
+- **No slash commands are created** — short forms are auto-installed by the
+  session-start hook.
+- **Direct-to-main**: changes push to `main` without a PR (per repo CLAUDE.md); the
+  global simplify→review→commit gate still applies to non-doc edits, but skill/guide
+  content is markdown and follows the validate gate instead.
+
+## Error handling
+
+- A stage that fails once is retried once with its error as input; a second failure
+  stops the pipeline and reports to the maintainer (no silent skip).
+- QA FAIL never proceeds to release.
+- Conflicting data is reported with provenance, not deleted.
+- High-risk git ops (`--no-verify`, `--force`, history rewrites) require explicit
+  maintainer authorization — release-manager stops and asks.
+
+## Test scenarios
+
+**Normal flow — "add a brooks-security skill":** Phase 1 selects author+eval+QA+audit.
+skill-author runs `new-skill brooks-security`, creates SKILL.md (with a sibling-carving
+"Do NOT trigger for:" clause) + guide; eval-curator adds an S-code happy-path + a
+false-positive scenario; consistency-qa runs the gate → PASS; trigger-boundary-auditor
+confirms no collision with brooks-review/audit. Report lists files + PASS.
+
+**Error flow — QA FAIL on book-count drift:** maintainer adds a thirteenth book but
+edits only `source-coverage.md`. consistency-qa's cross-doc check finds README still
+says "twelve" → FAIL, attributed to skill-author. Orchestrator loops back; skill-author
+updates README/AGENTS/GEMINI wording; QA re-runs → PASS. No release was requested, so
+the pipeline ends at Phase 3.
+
+## 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.

package/bundled-skills/brooks-review/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: brooks-review
+description: "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..."
+risk: unknown
+source: https://github.com/hyhmrright/brooks-lint/tree/main/skills/brooks-review
+source_repo: hyhmrright/brooks-lint
+source_type: community
+date_added: 2026-07-01
+license: MIT
+license_source: https://github.com/hyhmrright/brooks-lint/blob/main/LICENSE
+---
+
+# Brooks-Lint — PR Review
+## When to Use
+
+Use this skill when you need 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...
+
+
+## Setup
+
+1. Read `../_shared/common.md` for the Iron Law, Project Config, Report Template, and Health Score rules
+2. Read `../_shared/source-coverage.md` for book-level coverage, exceptions, and tradeoffs
+3. Read `../_shared/decay-risks.md` for symptom definitions and source attributions
+4. Read `pr-review-guide.md` in this directory for the analysis process
+
+## Process
+
+**If the user has not specified files or pasted code:** apply Auto Scope Detection
+from `../_shared/common.md` to determine the review scope before proceeding.
+
+1. Understand the review scope, then scan for each decay risk in the order specified (Steps 1–6 of the guide)
+2. Run the Quick Test Check (Step 7 of the guide) — skip for docs-only or non-production changes
+3. Apply the Iron Law to every finding
+4. Output using the Report Template from common.md
+
+**Mode line in report:** `PR Review`
+
+## 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.