brooks-harness

brooks-lint — メンテナンスハーネス（オーケストレーター）

このスキルは、brooks-lint リポジトリ自体に対する作業をオーケストレーションします。順次実行するサブエージェントのパイプラインを実行します。各ステージは .codex/agents/ で定義された専用エージェントです。一致するエージェントロールで利用可能な Codex コラボレーションツールを使用し、親のモデルと権限を引き継いでください。カスタムロールが読み込まれていない場合は、そのロールの TOML ファイルにある developer_instructions を標準のサブエージェントに渡してください。ステージは順次実行します。すべての編集エージェントは、ほかのコントリビューターの変更を保持し、オーケストレーターが割り当てたファイルのみを担当してください。

パイプライン

[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

フェーズ 0 — コンテキストの確認

何かを行う前に、実行モードを判断してください。

• _workspace/brooks-harness/ が存在し、メンテナーが前回の実行の一部をやり直すよう依頼している → 部分的な再実行：影響を受けるステージのみを実行し、以前のメモを再利用します。
• _workspace/brooks-harness/ が存在し、新しい依頼がある → 新規実行：古い フォルダーを _workspace/brooks-harness_prev/ に移動し、クリーンな状態から開始します。
• _workspace/brooks-harness/ が存在しない → 初回実行：作成します。

実行メモと QA レポートは _workspace/brooks-harness/ に保存します。実際の 成果物はリポジトリのファイルそのものです。エージェントは skills/、evals/、マニフェストを直接編集します。_workspace/ に保存するのは、実行メモと監査用の PASS/FAIL 判定のみです。

フェーズ 1 — 依頼の分類

必要最小限のステージを選択してください。QA ステージは決して省略しません。すべての変更に QA を適用します。

依頼	作成	評価	QA	トリガー監査	リリース
新しいスキルの追加	✓（new-skill のスキャフォールドを使用）	✓	✓	✓	—
スキル／ガイドのコンテンツ編集	✓	コードが変更された場合	✓	description が変更された場合	—
_shared/ フレームワークの編集	✓	リスク定義が変更された場合	✓	—	—
Codex／メンテナンス設定	—	—	✓	—	—
評価スイートのみ	—	✓	✓	—	—
トリガーの説明の修正	✓	—	✓	✓	—
リリース	—	—	✓	—	✓
全体：変更＋リリース	✓	必要に応じて	✓	該当する場合	✓

フェーズ 2 — パイプラインの実行

Codex コラボレーションツールを使用して、選択した各ステージをサブエージェントとして順番に起動します。各エージェントに、（a）タスクの契約内容と（b）前のステージの要約を渡してください。エージェントは要約を _workspace/brooks-harness/ に書き込みます。ステージ間で要約を読んでください。

1. skill-author — コンテンツを作成／編集します。新しいスキルの場合は、 new-skill のスキャフォールドを呼び出します。変更したファイルの一覧と、規約に関係する選択（新しいリスクコード、新しい Step 番号、変更した description のトリガーフレーズ）を返します。
2. eval-curator — skill-author が新規または変更されたリスクコードやモードを報告した場合は、対応するハッピーパスと誤検知のシナリオを追加し、npm run evals を実行します。
3. consistency-qa (ゲート — 省略不可) — npm run validate、npm test、npm run evals を実行し、その後、ドキュメント間の同期チェック（マニフェスト、バージョンを含むすべてのテキストファイル、CHANGELOG、AGENTS/GEMINI の項目数、評価数）を行います。PASS/FAIL 判定を書き込みます。 FAIL の場合：判定で指定されたエージェント（author または eval-curator）に戻り、 修正後に QA を再実行します。これをもう一度繰り返します。それでも失敗する場合は、 停止してメンテナーに報告します。
4. trigger-boundary-auditor — description フィールドが変更された場合にのみ実行します。出荷対象の 6 つのスキルのトリガー領域を読み取り専用で監査し、誤トリガーとルーティングの衝突を確認します。調査結果を提示してください。実際に衝突があると指摘された場合は、skill-author に戻ります。
5. release-manager — リリースが依頼された場合にのみ、かつ QA が PASS になった後にのみ実行します。release スキルを使用してリリースを作成します。

フェーズ 3 — 報告とフィードバック

実行したステージ、変更したファイル、QA 判定、トリガー監査の調査結果（該当する場合）、リリース URL（該当する場合）を報告します。その後、メンテナーにフィードバックを求めます：「結果、エージェントロール、パイプラインの順序について、調整したい点はありますか？」承認された変更は AGENTS.md のハーネス変更履歴テーブルに記録します。

このハーネスが適用する規約

• 現在の Codex モデルと権限を引き継ぎます。Claude モデルは選択しません。
• consistency-qa は general-purpose でなければなりません（npm スクリプトを実行するため）。trigger-boundary-auditor は読み取り専用です。
• コマンドラッパーは作成しません — Codex は .agents/skills/ を検出します。
• main への直接リリースは AGENTS.md に従います。依頼があった場合にのみ、コミット、プッシュ、タグ付け、公開を行います。明示された検証／テスト／評価のゲートを実行します。Claude のグローバルルールとフックは Codex では実行されません。

エラー処理

• あるステージが失敗した場合、エラーを入力として一度だけ再試行します。2 回目も失敗した場合はパイプラインを停止し、メンテナーに報告します（黙ってスキップしません）。
• QA が FAIL の場合、リリースには進みません。
• 矛盾するデータは、出典情報とともに報告し、削除しません。
• リスクの高い git 操作（--no-verify、--force、履歴の書き換え）には、メンテナーの明示的な許可が必要です。release-manager は処理を停止して確認を求めます。

テストシナリオ

通常のフロー — 「brooks-security スキルを追加」： フェーズ 1 で author+eval+QA+audit を選択します。 skill-author が new-skill brooks-security を実行し、SKILL.md（兄弟スキルとの棲み分けを示す「Do NOT trigger for:」節を含む）とガイドを作成します。eval-curator は S コードの正常系シナリオと誤検知シナリオを追加します。consistency-qa がゲートを実行 → PASS。trigger-boundary-auditor は brooks-review/audit との衝突がないことを確認します。レポートにはファイルと PASS が記載されます。

エラーフロー — 書籍数の不一致で QA FAIL： メンテナーが 13 冊目の書籍を追加しますが、source-coverage.md のみを編集します。consistency-qa のドキュメント間チェックで、README にはまだ「12」と記載されていることが見つかり → FAIL。原因は skill-author として記録されます。オーケストレーターは前の段階に戻り、skill-author が README/AGENTS/GEMINI の文言を更新します。QA を再実行 → PASS。リリースは依頼されていないため、パイプラインはフェーズ 3 で終了します。