📦 deps(skills): sync thirdparty skills
This commit is contained in:
ci[bot]
Vendored
+19
-10
@@ -55,6 +55,11 @@ maturity stages. One of:
|
||||
|
||||
See **Health Score Calculation** below for the per-preset deduction weights.
|
||||
|
||||
**`sweep`** — Full Sweep only. `max_iterations` (default 3) caps how many
|
||||
non-critical re-scan rounds the sweep pipeline runs before it stops and reports
|
||||
the remainder as unresolved. Critical findings are exempt from the cap — they
|
||||
iterate until resolved or retired. Ignored by every other mode.
|
||||
|
||||
**Minimal example:**
|
||||
```yaml
|
||||
version: 1
|
||||
@@ -65,6 +70,8 @@ severity:
|
||||
R1: suggestion
|
||||
ignore:
|
||||
- "**/*.generated.*"
|
||||
sweep:
|
||||
max_iterations: 3
|
||||
```
|
||||
|
||||
If `.brooks-lint.yaml` contains a `custom_risks` map, read `custom-risks-guide.md`
|
||||
@@ -109,10 +116,9 @@ When no files or code are specified, detect scope automatically:
|
||||
|
||||
## The Six Decay Risks
|
||||
|
||||
Navigation index only — canonical definitions (symptoms, severity guides, sources, "What Not
|
||||
to Flag" guards) live in `decay-risks.md`. Do not duplicate or edit diagnostic questions here;
|
||||
update `decay-risks.md` directly. Book-level coverage, exceptions, and tradeoffs are in
|
||||
`source-coverage.md`.
|
||||
Navigation index only. Canonical definitions — symptoms, severity guides, sources, "What Not
|
||||
to Flag" guards — live in `decay-risks.md`; edit them there, not here. Book-level coverage,
|
||||
exceptions, and tradeoffs are in `source-coverage.md`.
|
||||
|
||||
| Code | Risk | Diagnostic Question |
|
||||
|------|------|---------------------|
|
||||
@@ -137,7 +143,7 @@ and fixed structural headers from the template below (`Findings`, `Summary`,
|
||||
````
|
||||
# Brooks-Lint Review
|
||||
|
||||
**Mode:** [PR Review / Architecture Audit / Tech Debt Assessment / Test Quality Review]
|
||||
**Mode:** [PR Review / Architecture Audit / Tech Debt Assessment / Test Quality Review / Health Dashboard / Full Sweep]
|
||||
**Scope:** [file(s), directory, or description of what was reviewed]
|
||||
**Health Score:** XX/100
|
||||
|
||||
@@ -196,7 +202,10 @@ Remedy: ...
|
||||
## Remedy Mode
|
||||
|
||||
When the user passes `--fix` or asks to "fix the findings", read
|
||||
`remedy-guide.md` from the `_shared/` directory before writing the report.
|
||||
`remedy-guide.md` from the `_shared/` directory before writing the report. It
|
||||
sharpens each Remedy into a concrete action — the diagnostic modes still do not
|
||||
edit files. Full Sweep is the mode that applies fixes, and it follows
|
||||
`brooks-sweep/sweep-guide.md` instead.
|
||||
|
||||
## Health Score Calculation
|
||||
|
||||
@@ -209,9 +218,7 @@ Base score: 100. Per-finding deductions depend on the `strictness` preset
|
||||
| `balanced` (default) | −15 | −5 | −1 |
|
||||
| `legacy-friendly` | −8 | −3 | −1 |
|
||||
|
||||
Floor: 0 (score cannot go below 0). The preset changes only the score weighting and
|
||||
framing — every finding is still reported in full. Under `legacy-friendly`, lead the
|
||||
**Summary** with the three highest-leverage fixes so a first run is not a wall of Criticals.
|
||||
Floor: 0 (score cannot go below 0).
|
||||
|
||||
## History Tracking
|
||||
|
||||
@@ -240,7 +247,9 @@ After reporting Warning or Suggestion findings, offer:
|
||||
|
||||
For each finding one at a time (lowest severity first): show title, ask `[a]ccept / [d]ismiss / [f]defer / [s]kip`; wait for reply before moving to the next.
|
||||
|
||||
**Dismiss:** ask one-line reason → append to `.brooks-lint.yaml` under `suppress:` → downgraded to info in future runs.
|
||||
**Dismiss:** ask one-line reason → append to `.brooks-lint.yaml` under `suppress:` →
|
||||
downgraded to info in future runs. Entry fields: `risk` (code), `pattern` (file glob),
|
||||
`reason` (required), `date` (when it was dismissed).
|
||||
|
||||
**Defer:** same as dismiss, add `expires: YYYY-MM-DD` (default 90 days) → resurfaces at original severity after expiry.
|
||||
|
||||
|
||||
+3
-4
@@ -42,7 +42,6 @@ process:
|
||||
|
||||
## Config Validation additions
|
||||
|
||||
The following codes are valid in `disable`, `focus`, and `severity`:
|
||||
- Standard: `R1`–`R6`, `T1`–`T6`
|
||||
- Custom: any `Cx` code defined in `custom_risks`
|
||||
- Any other code: skip it and emit `"Config warning: X is not a valid risk code"`
|
||||
Extends the Config Validation rules in `common.md`: alongside `R1`–`R6` and `T1`–`T6`,
|
||||
any `Cx` code defined in `custom_risks` is a valid target for `disable`, `focus`, and
|
||||
`severity`. Anything else is still skipped with a config warning.
|
||||
|
||||
+37
-60
@@ -30,18 +30,12 @@ Cognitive load beyond working memory causes mistakes, avoidance, and blocks the
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Long Method | Fowler — Refactoring | Long Method |
|
||||
| Long Parameter List | Fowler — Refactoring | Long Parameter List |
|
||||
| Message Chains | Fowler — Refactoring | Message Chains |
|
||||
| Flag Arguments | Fowler — Refactoring | Flag Arguments |
|
||||
| Primitive Obsession | Fowler — Refactoring | Primitive Obsession |
|
||||
| Function length and nesting | McConnell — Code Complete | Ch. 7: High-Quality Routines |
|
||||
| Variable naming | McConnell — Code Complete | Ch. 11: The Power of Variable Names |
|
||||
| Magic numbers | McConnell — Code Complete | Ch. 12: Fundamental Data Types |
|
||||
| Domain name mismatch | Evans — Domain-Driven Design | Ubiquitous Language |
|
||||
| Shallow Module | Ousterhout — A Philosophy of Software Design | Ch. 4: Modules Should Be Deep |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Fowler — Refactoring | Long Method · Long Parameter List · Message Chains · Flag Arguments · Primitive Obsession |
|
||||
| McConnell — Code Complete | Ch. 7: High-Quality Routines (length, nesting) · Ch. 11: The Power of Variable Names · Ch. 12: Fundamental Data Types (magic numbers) |
|
||||
| Evans — Domain-Driven Design | Ubiquitous Language (domain name mismatch) |
|
||||
| Ousterhout — A Philosophy of Software Design | Ch. 4: Modules Should Be Deep (Shallow Module) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -84,17 +78,14 @@ Each change ripples to unrelated modules, slowing velocity and multiplying regre
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Shotgun Surgery | Fowler — Refactoring | Shotgun Surgery |
|
||||
| Divergent Change | Fowler — Refactoring | Divergent Change |
|
||||
| Feature Envy | Fowler — Refactoring | Feature Envy |
|
||||
| Inappropriate Intimacy | Fowler — Refactoring | Inappropriate Intimacy |
|
||||
| Orthogonality violation | Hunt & Thomas — The Pragmatic Programmer | Ch. 2: Orthogonality |
|
||||
| DIP violation | Martin — Clean Architecture | Dependency Inversion Principle |
|
||||
| High change propagation radius | Brooks — The Mythical Man-Month | Ch. 2: Brooks's Law (communication overhead) |
|
||||
| Hyrum's Law | Winters et al. — Software Engineering at Google | Ch. 1: Hyrum's Law |
|
||||
| Information Leakage | Ousterhout — A Philosophy of Software Design | Ch. 5: Information Hiding and Leakage |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Fowler — Refactoring | Shotgun Surgery · Divergent Change · Feature Envy · Inappropriate Intimacy |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | Ch. 2: Orthogonality |
|
||||
| Martin — Clean Architecture | Dependency Inversion Principle |
|
||||
| Brooks — The Mythical Man-Month | Ch. 2: Brooks's Law (communication overhead, propagation radius) |
|
||||
| Winters et al. — Software Engineering at Google | Ch. 1: Hyrum's Law |
|
||||
| Ousterhout — A Philosophy of Software Design | Ch. 5: Information Hiding and Leakage |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -128,13 +119,11 @@ Multiple copies drift apart silently. DRY is about decisions, not code lines.
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Code duplication | Fowler — Refactoring | Duplicate Code |
|
||||
| Parallel Inheritance | Fowler — Refactoring | Parallel Inheritance Hierarchies |
|
||||
| DRY violation | Hunt & Thomas — The Pragmatic Programmer | DRY: Don't Repeat Yourself |
|
||||
| Inconsistent naming | Evans — Domain-Driven Design | Ubiquitous Language |
|
||||
| Alternative Classes | Fowler — Refactoring | Alternative Classes with Different Interfaces |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Fowler — Refactoring | Duplicate Code · Parallel Inheritance Hierarchies · Alternative Classes with Different Interfaces |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | DRY: Don't Repeat Yourself |
|
||||
| Evans — Domain-Driven Design | Ubiquitous Language (inconsistent naming) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -172,16 +161,13 @@ Accidental complexity accumulates addition by addition until developers fight sc
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Speculative Generality | Fowler — Refactoring | Speculative Generality |
|
||||
| Lazy Class | Fowler — Refactoring | Lazy Class |
|
||||
| Middle Man | Fowler — Refactoring | Middle Man |
|
||||
| Switch Statements | Fowler — Refactoring | Switch Statements |
|
||||
| Second System Effect | Brooks — The Mythical Man-Month | Ch. 5: The Second-System Effect |
|
||||
| YAGNI violations | McConnell — Code Complete | Ch. 5: Design in Construction |
|
||||
| Over-engineering | Hunt & Thomas — The Pragmatic Programmer | Topic 4: Good-Enough Software |
|
||||
| Tactical programming debt | Ousterhout — A Philosophy of Software Design | Ch. 3: Strategic vs. Tactical Programming |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Fowler — Refactoring | Speculative Generality · Lazy Class · Middle Man · Switch Statements |
|
||||
| Brooks — The Mythical Man-Month | Ch. 5: The Second-System Effect |
|
||||
| McConnell — Code Complete | Ch. 5: Design in Construction (YAGNI) |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | Topic 4: Good-Enough Software (over-engineering) |
|
||||
| Ousterhout — A Philosophy of Software Design | Ch. 3: Strategic vs. Tactical Programming |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -222,17 +208,12 @@ When business logic depends on infrastructure, infrastructure changes cascade in
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Dependency cycles | Martin — Clean Architecture | Acyclic Dependencies Principle (ADP) |
|
||||
| DIP violation | Martin — Clean Architecture | Dependency Inversion Principle (DIP) |
|
||||
| Instability direction | Martin — Clean Architecture | Stable Dependencies Principle (SDP) |
|
||||
| Abstraction mismatch | Martin — Clean Architecture | Stable Abstractions Principle (SAP) |
|
||||
| ISP violation | Martin — Clean Architecture | Interface Segregation Principle (ISP) |
|
||||
| Conceptual integrity | Brooks — The Mythical Man-Month | Ch. 4: Conceptual Integrity |
|
||||
| Law of Demeter | Hunt & Thomas — The Pragmatic Programmer | Ch. 5: Decoupling and the Law of Demeter |
|
||||
| SOLID violations | Martin — Clean Architecture | Single Responsibility, Open/Closed Principles |
|
||||
| Diamond dependency / upgrade blockage | Winters et al. — Software Engineering at Google | Ch. 21: Dependency Management |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Martin — Clean Architecture | Acyclic Dependencies (ADP, cycles) · Dependency Inversion (DIP) · Stable Dependencies (SDP, instability direction) · Stable Abstractions (SAP) · Interface Segregation (ISP) · Single Responsibility · Open/Closed |
|
||||
| Brooks — The Mythical Man-Month | Ch. 4: Conceptual Integrity |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | Ch. 5: Decoupling and the Law of Demeter |
|
||||
| Winters et al. — Software Engineering at Google | Ch. 21: Dependency Management (diamond dependency, upgrade blockage) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -271,15 +252,11 @@ Code that mismatches business language forces mental translation. Over time it m
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Anemic Domain Model | Evans — Domain-Driven Design | Domain Model pattern |
|
||||
| Ubiquitous Language drift | Evans — Domain-Driven Design | Ubiquitous Language |
|
||||
| Bounded context violation | Evans — Domain-Driven Design | Bounded Context |
|
||||
| Data Class | Fowler — Refactoring | Data Class |
|
||||
| Refused Bequest | Fowler — Refactoring | Refused Bequest |
|
||||
| Feature Envy | Fowler — Refactoring | Feature Envy |
|
||||
| LSP violation | Martin — Clean Architecture | Liskov Substitution Principle (LSP) |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Evans — Domain-Driven Design | Domain Model pattern (Anemic Domain Model) · Ubiquitous Language · Bounded Context |
|
||||
| Fowler — Refactoring | Data Class · Refused Bequest · Feature Envy |
|
||||
| Martin — Clean Architecture | Liskov Substitution Principle (LSP) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
|
||||
+7
-1
@@ -1,5 +1,11 @@
|
||||
# Remedy Guide — Actionable Fix Mode
|
||||
|
||||
**Applies to the diagnostic modes only** (PR Review, Architecture Audit, Tech Debt,
|
||||
Test Quality, Health Dashboard). They never write to the codebase — `--fix` there
|
||||
means "make the Remedy specific enough to act on", not "apply it". Full Sweep
|
||||
(`/brooks-sweep`) is the one mode that edits files; it follows
|
||||
`brooks-sweep/sweep-guide.md`, which owns its own fix-classification and revert rules.
|
||||
|
||||
When `--fix` is active, enhance every finding's Remedy field to be directly actionable:
|
||||
|
||||
## Remedy Enhancement Rules
|
||||
@@ -32,6 +38,6 @@ After the standard report, add a **Fix Summary** section:
|
||||
| R5 — Circular dep | manual | src/models/ ↔ src/services/ | Introduce interface boundary |
|
||||
|
||||
## What NOT to do
|
||||
- Do NOT modify any files. Phase 1 is diagnosis + actionable plan only.
|
||||
- Do NOT modify any files. Diagnosis + actionable plan is the whole deliverable.
|
||||
- Do NOT generate diffs or code blocks. The Remedy text IS the deliverable.
|
||||
- Do NOT re-score. The Health Score reflects current state, not projected state.
|
||||
|
||||
+28
-35
@@ -24,12 +24,10 @@ Unclear test intent breeds distrust, missed failures, and duplicates — one ste
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Assertion Roulette | Meszaros — xUnit Test Patterns | Assertion Roulette (p.224) |
|
||||
| Mystery Guest | Meszaros — xUnit Test Patterns | Mystery Guest (p.411) |
|
||||
| General Fixture | Meszaros — xUnit Test Patterns | General Fixture (p.316) |
|
||||
| Test naming | Osherove — The Art of Unit Testing | method_scenario_expected naming convention |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Meszaros — xUnit Test Patterns | Assertion Roulette (p.224) · Mystery Guest (p.411) · General Fixture (p.316) |
|
||||
| Osherove — The Art of Unit Testing | method_scenario_expected naming convention |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -66,12 +64,11 @@ Brittle tests punish refactoring — eventually developers stop refactoring and
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Eager Test | Meszaros — xUnit Test Patterns | Eager Test (p.228) |
|
||||
| Erratic Test | Meszaros — xUnit Test Patterns | Erratic Test |
|
||||
| Implementation coupling | Osherove — The Art of Unit Testing | Test isolation principle |
|
||||
| Orthogonality violation | Hunt & Thomas — The Pragmatic Programmer | Ch. 2: Orthogonality |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Meszaros — xUnit Test Patterns | Eager Test (p.228) · Erratic Test |
|
||||
| Osherove — The Art of Unit Testing | Test isolation principle (implementation coupling) |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | Ch. 2: Orthogonality |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -105,11 +102,10 @@ Duplicated tests must change in multiple places and create false confidence with
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Test Code Duplication | Meszaros — xUnit Test Patterns | Test Code Duplication (p.213) |
|
||||
| Lazy Test | Meszaros — xUnit Test Patterns | Lazy Test (p.232) |
|
||||
| DRY violation in tests | Hunt & Thomas — The Pragmatic Programmer | DRY: Don't Repeat Yourself |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Meszaros — xUnit Test Patterns | Test Code Duplication (p.213) · Lazy Test (p.232) |
|
||||
| Hunt & Thomas — The Pragmatic Programmer | DRY: Don't Repeat Yourself |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -144,13 +140,11 @@ Mock abuse produces tests that pass while verifying nothing — production code
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Mock count > 3 | Osherove — The Art of Unit Testing | Mock usage guidelines |
|
||||
| Testing mock behavior | Meszaros — xUnit Test Patterns | Behavior Verification (p.544) |
|
||||
| Test-only production methods | Feathers — Working Effectively with Legacy Code | Ch. 3: Sensing and Separation |
|
||||
| Hard-Coded Test Data | Meszaros — xUnit Test Patterns | Hard-Coded Test Data (p.534) |
|
||||
| Incomplete Mock | Osherove — The Art of Unit Testing | Mock completeness requirement |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Meszaros — xUnit Test Patterns | Behavior Verification (p.544) · Hard-Coded Test Data (p.534) |
|
||||
| Osherove — The Art of Unit Testing | Mock usage guidelines (count > 3) · Mock completeness requirement (Incomplete Mock) |
|
||||
| Feathers — Working Effectively with Legacy Code | Ch. 3: Sensing and Separation (test-only production methods) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -185,11 +179,11 @@ Coverage measures execution, not verification. 90% line coverage can still miss
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Legacy code = no tests | Feathers — Working Effectively with Legacy Code | Ch. 1: "Legacy code is code without tests" |
|
||||
| Change coverage vs line coverage | Google — How Google Tests Software | Ch. 11: Testing at Google Scale |
|
||||
| Happy-path only | Osherove — The Art of Unit Testing | Test completeness principle |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Feathers — Working Effectively with Legacy Code | Ch. 1: "Legacy code is code without tests" |
|
||||
| Google — How Google Tests Software | Ch. 11: Testing at Google Scale (change vs line coverage) |
|
||||
| Osherove — The Art of Unit Testing | Test completeness principle (happy-path only) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
@@ -226,12 +220,11 @@ Wrong suite shape is slow and expensive — not from bad tests, but from using t
|
||||
|
||||
### Sources
|
||||
|
||||
| Symptom | Book | Principle / Smell |
|
||||
|---------|------|-------------------|
|
||||
| Inverted pyramid | Google — How Google Tests Software | 70:20:10 unit:integration:E2E ratio |
|
||||
| No seam points | Feathers — Working Effectively with Legacy Code | Ch. 4: Seam Model |
|
||||
| Missing Characterization Tests | Feathers — Working Effectively with Legacy Code | Ch. 13: Characterization Tests |
|
||||
| Suite execution time | Meszaros — xUnit Test Patterns | Slow Tests (p. 253) |
|
||||
| Book | Principle / Smell |
|
||||
|------|-------------------|
|
||||
| Google — How Google Tests Software | 70:20:10 unit:integration:E2E ratio (inverted pyramid) |
|
||||
| Feathers — Working Effectively with Legacy Code | Ch. 4: Seam Model · Ch. 13: Characterization Tests |
|
||||
| Meszaros — xUnit Test Patterns | Slow Tests (p. 253, suite execution time) |
|
||||
|
||||
### Severity Guide
|
||||
|
||||
|
||||
Reference in New Issue
Block a user