# Brooks Harness

Maintenance orchestrator for the brooks-lint plugin itself.

- Repository: https://github.com/hyhmrright/brooks-lint (1554 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-26
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add hyhmrright/brooks-lint --skill brooks-harness -g -a claude-code -y`
Codex: `npx skills add hyhmrright/brooks-lint --skill brooks-harness -g -a codex -y`
Cursor: `npx skills add hyhmrright/brooks-lint --skill brooks-harness -g -a cursor -y`
Gemini CLI: `npx skills add hyhmrright/brooks-lint --skill brooks-harness -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add hyhmrright/brooks-lint`

## 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 + all README translations + CHANGELOG + AGENTS/GEMINI in sync, audit trigger boundaries, and cut releases. Drives the five agents in .codex/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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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 `.codex/agents/`.
Use the available Codex collaboration tools with the matching agent role; inherit
the parent model and permissions. If custom roles are not loaded, pass the role's
`developer_instructions` from its TOML file to a standard subagent. Stages run
sequentially. Every editing agent must preserve other contributors' changes and
own only the files assigned by the orchestrator.

## 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

The rest: https://github.com/hyhmrright/brooks-lint/blob/HEAD/.agents/skills/brooks-harness/SKILL.md