opencode-skills-collection 3.1.12 → 3.1.13

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.

package/bundled-skills/brooks-review/pr-review-guide.md

@@ -0,0 +1,163 @@
+# PR Review Guide — Mode 1
+
+**Purpose:** Analyze a code diff or specific files for decay risks that are directly visible
+in the changed code. Every finding must follow the Iron Law: Symptom → Source → Consequence → Remedy.
+
+---
+
+## Before You Start
+
+**Auto-generated files:** If the diff contains generated files (protobuf stubs, OpenAPI clients,
+ORM migrations, lock files, minified bundles), skip those files entirely. Generated code reflects
+tool choices, not developer decisions. Note in the report which files were skipped and why.
+
+**Scope calibration:** Adjust analysis depth based on PR size before starting.
+
+| PR Size | Approach |
+|---------|----------|
+| < 50 lines | Focus on Steps 1–3 only; run Step 6a only if imports changed; run Step 6b if any class, method, or variable was renamed or introduced |
+| 50–300 lines | Full process, all steps |
+| > 300 lines | Full process; note in the Scope line that review is sampled — cover the highest-risk areas rather than every file |
+
+For PRs > 500 lines: flag in the Summary that a PR this size is itself a Change Propagation signal. A change that cannot be reviewed in one pass suggests tangled responsibilities.
+
+---
+
+## Analysis Process
+
+Work through these seven steps in order. Do not skip steps.
+
+### Step 1: Understand the scope
+
+Read the diff or files and answer:
+- What is the stated purpose of this change?
+- Which files were modified?
+- Flag immediately if the PR changes more than 10 unrelated files — that itself is a
+  🟡 Warning: Change Propagation (a PR that touches many unrelated things is a sign
+  that responsibilities are tangled).
+
+### Step 2: Scan for Change Propagation
+
+*Scan this first — it is the most visible risk in a diff.*
+
+Look for:
+- Does this change touch files in modules that have no conceptual connection to the stated purpose?
+- Does any modified class change for more than one business reason in this diff?
+- Does any method use more data from another class than from its own?
+
+If the diff shows no cross-module changes beyond what the feature requires → skip, no finding.
+
+### Step 3: Scan for Cognitive Overload
+
+Look for:
+- Are any new or modified functions longer than 20 lines?
+- Is there nesting deeper than 3 levels in new or modified code?
+- Are there more than 4 parameters in any new function signature?
+- Are there magic numbers or unexplained constants in new code?
+- Do new variable or function names require reading the implementation to understand?
+- Are there train-wreck chains (3+ method calls chained)?
+
+### Step 4: Scan for Knowledge Duplication
+
+Look for:
+- Does this change introduce logic that already exists elsewhere in the codebase?
+- Does this change introduce a new name for a concept that already has a name?
+- Does this change add a class to a hierarchy that has a parallel in another module?
+
+### Step 5: Scan for Accidental Complexity
+
+Look for:
+- Does this change add an abstraction with only one concrete use?
+- Does this change add a class that only wraps another class or delegates everything?
+- Does this change add configuration options or extension points that serve no current requirement?
+
+### Step 6a: Scan for Dependency Disorder
+
+- Do any new imports create a dependency from a high-level module to a low-level one?
+  (e.g., domain service now imports a database driver or HTTP client)
+- Do any new imports introduce a cycle between modules?
+- Does any new interface force callers to depend on methods they do not use?
+
+If no new imports and no structural changes → skip, no finding.
+
+### Step 6b: Scan for Domain Model Distortion
+
+- Do new class or variable names match the language the business uses for the same concept?
+- Does any new class hold only data with no behavior (pure data bag), where behavior was expected?
+- Does any new method put logic that belongs to the domain in a service or utility layer?
+
+---
+
+## Severity Calibration
+
+Apply the Iron Law format from `../_shared/common.md`. Each risk in `../_shared/decay-risks.md` has its own Severity
+Guide with numeric thresholds — use those as the primary reference. When a finding sits
+on the boundary between two tiers, use this as a tiebreaker:
+- 🔴 Critical — actively breaking velocity or creating production risk *today*
+- 🟡 Warning — will if left unaddressed through the next few features
+- 🟢 Suggestion — worth fixing when nearby, not urgent
+
+When multiple findings exist, list Critical items first. If there are more than 5 findings,
+add a one-line "Recommended fix order" at the end of the Findings section.
+
+---
+
+## Step 7: Quick Test Check
+
+*Run this last. Three signals only — this is not a full Mode 4 review.*
+
+If the diff contains only generated files, configuration, or documentation with no
+production logic changes → skip Step 7 entirely.
+
+**Signal 1: Do tests exist for the changed behavior?**
+
+- Does the diff modify production code?
+- Are corresponding test file changes included in the diff?
+- If new public behavior was added with no new tests:
+  → 🟡 Warning: Coverage Illusion — new behavior is untested
+  → Source: Feathers — Working Effectively with Legacy Code, Ch. 1
+- If the change is a pure refactor and existing tests cover the behavior → no finding.
+
+**Signal 2: Quick Mock Abuse sniff**
+
+Only check if the diff includes test file changes.
+
+- Is mock setup code in new/modified tests obviously longer than the test logic?
+- Are the primary assertions `expect(mock).toHaveBeenCalledWith(...)` with no behavior verification?
+- Does the diff add any methods to production classes that are only called from test files?
+
+If any of these are true:
+  → 🟡 Warning: Mock Abuse — test complexity exceeds behavior complexity
+  → Source: Osherove — The Art of Unit Testing, mock usage guidelines
+
+**Signal 3: Quick Test Obscurity sniff**
+
+Only check if the diff includes test file changes.
+
+- Do new test names express scenario and expected outcome?
+  (Pattern: `methodName_scenario_expectedResult` or equivalent)
+- Are there new tests with multiple assertions and no message strings on any of them?
+
+If test names are vague or assertions lack messages:
+  → 🟢 Suggestion: Test Obscurity — test intent is unclear from the test name or assertions
+  → Source: Meszaros — xUnit Test Patterns, Assertion Roulette (p.224)
+
+**Output rule:**
+
+If all three signals are clean → write no Test findings. Proceed directly to the report.
+
+If findings exist → add them to the Findings section using the standard Iron Law format.
+Label the risk as the test decay risk name (e.g., "Coverage Illusion", "Mock Abuse",
+"Test Obscurity").
+
+> **Note:** Step 7 is a fast check, not a full test audit. When systemic test problems
+> are found, note in the Summary: "Consider running `/brooks-lint:brooks-test` for a
+> complete test quality diagnosis."
+
+---
+
+## Output
+
+Use the standard Report Template from `../_shared/common.md`.
+Mode: PR Review
+Scope: list the files reviewed (excluding skipped generated files).

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

@@ -0,0 +1,44 @@
+---
+name: brooks-sweep
+description: "Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic..."
+risk: unknown
+source: https://github.com/hyhmrright/brooks-lint/tree/main/skills/brooks-sweep
+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 — Full Sweep & Auto-Fix
+## When to Use
+
+Use this skill when you need full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic...
+
+
+## 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 production risk symptom definitions
+4. Read `../_shared/test-decay-risks.md` for test risk symptom definitions
+5. Read `sweep-guide.md` in this directory for the unified scan and fix process
+
+## Process
+
+**If the user has not specified a project or directory:** apply Auto Scope Detection
+from `../_shared/common.md` to determine the review scope before proceeding.
+
+1. Show pre-flight consent notice and wait for the user's one-time approval (Step 0 of the guide)
+2. Enumerate scope and initialize the `unresolvable` / `non_critical_rounds` / `fix_log` state (Step 1 of the guide)
+3. Run the four dimensions in sequence — review, test, debt, audit — each scanning, classifying, applying Safe + Extended-Safe fixes, and verifying via the project test command (Steps 2–5 of the guide)
+4. Iterate: re-scan modified files + same-module + static consumers; converge on a clean round, retire 3-retry failures to the `unresolvable` set, cap non-critical rounds at 3 (Step 6 of the guide)
+5. Aggregate residual and unresolvable items and output the Full Sweep Report (Steps 7–8 of the guide)
+
+**Mode line in report:** `Full Sweep`
+
+## 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.