brooks-harness
installsforks
How to install brooks-harness?
hyhmrright/brooks-lint/brooks-harness
$npx -y skills add hyhmrright/brooks-lint --skill brooks-harnessMaintenance 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 bou
SKILL.md
| 1 | # brooks-lint — Maintenance Harness (Orchestrator) |
| 2 | |
| 3 | This skill orchestrates work **on the brooks-lint repo itself**. It runs a sequential |
| 4 | subagent pipeline: each stage is a dedicated agent defined in `.claude/agents/`. Spawn |
| 5 | each with the `Agent` tool, `subagent_type` set to the agent name, and **always |
| 6 | `model: "opus"`**. Stages depend on each other in order, so this is a pipeline, not a |
| 7 | parallel team. |
| 8 | |
| 9 | ## Pipeline |
| 10 | |
| 11 | ``` |
| 12 | [orchestrator] |
| 13 | Phase 0 context check |
| 14 | Phase 1 classify request → select stages |
| 15 | Phase 2 run selected stages in order, with a QA loop-back: |
| 16 | skill-author → eval-curator → consistency-qa ─(FAIL)→ back to author |
| 17 | │ PASS |
| 18 | ▼ |
| 19 | trigger-boundary-auditor (only if a description changed) |
| 20 | ▼ |
| 21 | release-manager (only if release requested) |
| 22 | Phase 3 report + collect feedback |
| 23 | ``` |
| 24 | |
| 25 | ## Phase 0 — Context check |
| 26 | |
| 27 | Determine the run mode before doing anything: |
| 28 | |
| 29 | - `_workspace/brooks-harness/` exists + maintainer asks to redo part of a prior run → |
| 30 | **partial re-run**: invoke only the affected stage(s), reusing prior notes. |
| 31 | - `_workspace/brooks-harness/` exists + a fresh request → **new run**: move the old |
| 32 | folder to `_workspace/brooks-harness_prev/`, start clean. |
| 33 | - No `_workspace/brooks-harness/` → **initial run**: create it. |
| 34 | |
| 35 | Run notes and the QA report live under `_workspace/brooks-harness/`. The *real* |
| 36 | artifacts are the repo files themselves — agents edit `skills/`, `evals/`, manifests |
| 37 | directly; `_workspace/` only holds the run's notes and the PASS/FAIL verdict for audit. |
| 38 | |
| 39 | ## Phase 1 — Classify the request |
| 40 | |
| 41 | Pick the minimal set of stages. The QA stage is **never skipped** — every change is |
| 42 | gated. |
| 43 | |
| 44 | | Request | author | eval | QA | trigger-audit | release | |
| 45 | |---------|:------:|:----:|:--:|:-------------:|:-------:| |
| 46 | | Add a new skill | ✓ (via `new-skill` scaffold) | ✓ | ✓ | ✓ | — | |
| 47 | | Edit skill / guide content | ✓ | if codes changed | ✓ | if `description` changed | — | |
| 48 | | Edit `_shared/` framework | ✓ | if risk defs changed | ✓ | — | — | |
| 49 | | Eval suite only | — | ✓ | ✓ | — | — | |
| 50 | | Fix trigger descriptions | ✓ | — | ✓ | ✓ | — | |
| 51 | | Release | — | — | ✓ | — | ✓ | |
| 52 | | Full: change + release | ✓ | as needed | ✓ | if applicable | ✓ | |
| 53 | |
| 54 | ## Phase 2 — Run the pipeline |
| 55 | |
| 56 | Spawn each selected stage as a subagent in order. Pass each agent (a) the task |
| 57 | contract and (b) the previous stage's summary. Agents write their summaries to |
| 58 | `_workspace/brooks-harness/`; read them between stages. |
| 59 | |
| 60 | 1. **skill-author** — creates/edits the content. For a brand-new skill it invokes the |
| 61 | `new-skill` scaffold. Returns the list of files touched + convention-relevant |
| 62 | choices (new risk codes, new Step numbers, changed `description` trigger phrases). |
| 63 | 2. **eval-curator** — if `skill-author` reported new/changed risk codes or modes, adds |
| 64 | the paired happy-path + false-positive scenarios and runs `npm run evals`. |
| 65 | 3. **consistency-qa** *(gate — never skipped)* — runs `npm run validate` + `npm test` + |
| 66 | `npm run evals`, then the cross-document sync checks (manifests, README badge, |
| 67 | CHANGELOG, AGENTS/GEMINI book count, eval count). Writes a PASS/FAIL verdict. |
| 68 | **On FAIL: loop back to the agent named in the verdict (author or eval-curator), |
| 69 | fix, then re-run QA. Repeat once; if it still fails, stop and report to the |
| 70 | maintainer.** |
| 71 | 4. **trigger-boundary-auditor** — run **only if a `description` field changed**. It |
| 72 | read-only audits the six shipped skills' trigger surfaces for false-triggering and |
| 73 | routing collisions. Surface its findings; if it flags a real collision, loop back to |
| 74 | skill-author. |
| 75 | 5. **release-manager** — run **only if a release was requested**, and ** |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
