Brooks Harness
Maintenance orchestrator for the brooks-lint plugin itself.
Install
npx skills add hyhmrright/brooks-lint --skill brooks-harness -g -a claude-code -y- Repository
- hyhmrright/brooks-lint1.6k
- Category
- Testing
- Updated
- 9d ago
- License
- MIT
- Context cost
- Mediumabout 1,508 tokens
- Runs scripts
- No, instructions only
What it does
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 + all README translations + CHANGELOG + AGENTS/GEMINI in sync, audit trigger boundaries, and cut releases. Drives the five agents in .claude/agents/ (skill-author, eval-curator, consistency-qa, trigger-boundary-auditor, release-manager). Triggers when the maintainer asks to work ON brooks-lint itself: "add a new skill", "edit the brooks-debt guide", "update the eval suite", "fix the trigger descriptions", "make this change and validate it", "release brooks-lint", "bump and publish", and follow-ups: "re-run", "re-validate", "update that skill", "redo the audit", "do the X part again". Do NOT trigger for: USING the brooks-lint analysis skills on some target codebase (that's brooks-review / brooks-audit / brooks-debt / brooks-test / brooks-health / brooks-sweep); generic questions about brooks-lint that don't ask to change it; or maintenance of a different plugin.
brooks-lint, Maintenance Harness (Orchestrator)
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.
