agent-teams-simplify-and-harden

Name: agent-teams-simplify-and-harden
Author: pskoett

github.com/pskoettエージェントワークフロー327513 回インストール1 日前に更新

リポジトリ

agent-teams-simplify-and-harden について

agent-teams-simplify-and-harden は、エージェントチーム用ツールが使える開発環境向けのチームスキルです。並行実装、観点別監査、修正と再監査のサイクルを調整し、監査回数と差分の増加に上限を設けます。

主な機能

01実装作業を並行タスクに分割
02簡素化、安全性、仕様の監査を分担
03監査結果から修正タスクを作成
04修正と再監査を反復
05監査回数と差分増加に上限を設定

活用シーン

01仕様に基づく複数機能の並行実装
02複数変更後のコードベースの堅牢化
03レビュー指摘への対応と修正の再監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/pskoett/pskoett-ai-skills --skill agent-teams-simplify-and-harden

インストール後、Claude Code で/agent-teams-simplify-and-hardenを入力して読み込まれたか確認します。

同梱ファイルreferences/auditor-prompts.md

詳細

エージェントチームで簡素化・堅牢化

インストール

gh skill install pskoett/pskoett-skills agent-teams-simplify-and-harden

Agent Skills CLI を使ったフォールバック：

npx skills add pskoett/pskoett-skills/skills/agent-teams-simplify-and-harden

本番品質のコードを作成する、2段階のチームループです。実装し、簡素化＋堅牢化のパスで監査し、監査で見つかった問題を修正してから、コードベースが堅牢になるか、ループ上限に達するまで再監査を繰り返します。

使用する場面

仕様や計画に基づいて複数の機能を実装する場合
一連の変更後にコードベースを堅牢化する場合
レビューで特定された問題や不足点のリストを修正する場合
品質ゲートが重要となる、5つ以上のファイルに関わるタスク

環境要件

以下の手順では、複数エージェントのチームツール（TeamCreate、TaskCreate、TaskUpdate、SendMessage、TeamDelete）と、サブエージェントの起動（general-purpose および Explore エージェントタイプ）を使用します。これらは、エージェントチームが有効になっている Claude Code スタイルの環境で利用できます。環境にチームツールはないものの、サブエージェントを起動できる場合は、チーム／タスク管理ツールを使わずに同じフェーズを直接オーケストレーションしてください。実装サブエージェントを起動し、続いて監査サブエージェントを起動し、タスクは Markdown のチェックリストで管理します。サブエージェントをまったく起動できない環境（例：GitHub Copilot chat）では、このスキルは使わず、代わりに逐次実行の simplify-and-harden スキルを実行し、各フェーズの指摘事項をチャットで確認してください。

パイプラインとの統合

このスキルは、標準パイプラインのステージ2～4（実行、レビュー、学習）を、チームベースのループに置き換えます。plan-interview の後に実行することも、単独で実行することもできます。上流の成果物はすべて任意です。

[plan-interview] → [agent-teams-simplify-and-harden] → [self-improvement]
                    ├─ intent frame (team lead)
                    ├─ implement (parallel agents)
                    ├─ audit (parallel agents)
                    ├─ drift check (team lead, between rounds)
                    └─ learning loop output → self-improvement

plan-interview の計画ファイルがある場合、このスキルはそこからタスクを抽出します。計画がない場合は、チームリーダーが簡単なインライン計画フェーズを実施します。コンテキストサーフィングはループラウンド間の軽量なドリフト確認としてチームリーダーが実行します。サブエージェントは短時間だけ起動するため、コンテキストサーフィングは必要ありません。

パターン

┌──────────────────────────────────────────────────────────┐
│                  TEAM LEAD (you)                          │
│                                                           │
│  Phase 1: IMPLEMENT (+ document pass on fix rounds)       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ impl-1   │ │ impl-2   │ │ impl-3   │  ...            │
│  │ (general │ │ (general │ │ (general │                 │
│  │ purpose) │ │ purpose) │ │ purpose) │                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  ┌─────────────────────────────────────┐                 │
│  │  Verify: compile + tests            │                 │
│  └─────────────────────────────────────┘                 │
│       │                                                   │
│  Phase 2: SIMPLIFY & HARDEN AUDIT                         │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                 │
│  │ simplify │ │ harden   │ │ spec     │  ...            │
│  │ auditor  │ │ auditor  │ │ auditor  │                 │
│  │ (Explore)│ │ (Explore)│ │ (Explore)│                 │
│  └──────────┘ └──────────┘ └──────────┘                 │
│       │             │            │                        │
│       ▼             ▼            ▼                        │
│  Exit conditions met?                                     │
│    YES → Produce summary. Ship it.                        │
│    NO  → back to Phase 1 with findings as tasks           │
│          (max 3 audit rounds)                             │
└──────────────────────────────────────────────────────────┘

ループの上限と終了条件

以下のいずれかを満たすと、ループは終了します。

監査で問題なし：すべての監査担当者が、指摘事項がゼロであると報告する
低のみのラウンド：あるラウンドの指摘事項がすべて重大度 low の場合、その場で修正し（チームリーダーまたは単独の実装エージェントが対応）、再監査せずに終了する
ループ上限に到達：監査ラウンドを3回完了した場合。3回目のラウンド後、残っている重大／高の指摘事項をその場で修正して終了します。未解決の中／低の指摘事項は、最終サマリーに記録します。

**予算に関する指針：**各ラウンドで増えた差分の累積を追跡してください。修正ラウンドで追加された差分が、元の実装差分の30%を超えた場合は、対象範囲を絞ります。簡素化に関する中／低の指摘事項はスキップし、堅牢化パッチと仕様上の不足点のみに集中してください。

手順

0. 計画と前提の明確化

計画ファイルがある場合（plan-interview が作成した docs/plans/plan-NNN-<slug>.md、またはユーザー提供のもの）：ファイルを読み、実装チェックリストを抽出して、ステップ2のタスクリストとして使用します。

計画がない場合は、簡単なインライン計画ヒアリングを実施します。

何を構築、修正、または堅牢化する必要がありますか？（機能、バグ、対象）
仕様または信頼できる情報源は何ですか？（ドキュメント、Issue、PR、または口頭での説明）
受け入れ基準は何ですか？

回答を具体的なタスクリストにまとめます。これは完全な plan-interview ではなく、作業を並列化できる単位に分解するために必要な範囲だけ行います。

**意図の確認：**チームを作成する前に、チームリーダーは次を提示します。

## Intent Frame #1

**Outcome:** [What the team session will deliver]
**Approach:** [Team structure, number of agents, audit dimensions]
**Constraints:** [Scope boundaries, loop cap, budget limits]
**Success criteria:** [Clean audit or loop cap with all critical/high resolved]
**Estimated complexity:** [Small / Medium / Large — based on task count and file count]

続行する前にユーザーの確認を取ります。これにより、その後のドリフト確認の基準が定まります。

1. チームを作成する

TeamCreate:
  team_name: "<project>-harden"
  description: "Implement and harden <description>"

2. タスクを作成する

作業を、明確に分けられ、並列実行できるタスクに分解します。各タスクは、他の作業の完了を待たずに1人のエージェントが完了できる程度に独立させます。

TaskCreate for each unit of work:
  subject: "Implement <specific thing>"
  description: "Detailed requirements, file paths, acceptance criteria"
  activeForm: "Implementing <thing>"

必要に応じて依存関係を設定します。

TaskUpdate: { taskId: "2", addBlockedBy: ["1"] }

3. 実装エージェントを起動する

general-purpose エージェントを起動します（ファイルの読み取り、書き込み、編集が可能です）。タスクごとに1つ、または論理的なグループごとに1つ起動します。並列で実行します。

Task tool (spawn teammate):
  subagent_type: general-purpose
  team_name: "<project>-harden"
  name: "impl-<area>"
  mode: bypassPermissions
  prompt: |
    You are an implementation agent on the <project>-harden team.
    Your name is impl-<area>.

    Check TaskList for your assigned tasks and complete them.
    After completing each task, mark it completed and check for more.

    Quality gates:
    - Code must compile cleanly (substitute your project's compile
      command, e.g. bunx tsc --noEmit, cargo build, go build ./...)
    - Tests must pass (substitute your project's test command,
      e.g. bun test, pytest, go test ./...)
    - Follow existing code patterns and conventions

    When all your tasks are done, notify the team lead.

4. 実装の完了を待つ

エージェントからのメッセージを監視します。すべての実装エージェントが完了を報告したら、次の手順を実行します。

コンパイル／型チェックを実行し、ビルドに問題がないことを確認します
テストを実行し、すべて成功することを確認します
どちらかが失敗した場合は、先に進む前に修正するか、修正を割り当てます

任意：場当たり的なコマンドを実行する代わりに、このコンパイル／テストの手順を verify-gate スキルに委任すると、内部ループのパイプラインと一貫性を保てます。verify-gate はプロジェクトのコンパイル／テスト／lint を実行し、診断情報とともに合格／不合格の結果を返します。

監査担当を起動する前に、このセッションで変更されたファイルの一覧を取得します。

git diff --name-only <base-branch>  # or: git diff --name-only HEAD~N

このファイル一覧を各監査担当に渡します。

5. 監査エージェントを起動する

Explore エージェントを起動します（読み取り専用のため、ファイルを編集できず、問題を黙って「修正」することはできません）。各監査担当は、Simplify & Harden の方法論に基づき、それぞれ異なる観点を担当します。

推奨する監査の観点：

監査担当	注目する点	考え方
simplify-auditor	コードの明瞭さと不要な複雑さ	「もっと簡潔な表現方法はないか？」
harden-auditor	セキュリティと堅牢性の不足	「悪意のある人物がこれを見たら、何を試すだろうか？」
spec-auditor	仕様／計画に対する実装の完全性	「コードは依頼された内容に合っているか？」

各監査担当向けのプロンプトテンプレートは references/auditor-prompts.md にあります。各プロンプトでは、読み取り専用の範囲、先入観のない状態からの開始、構造化された指摘形式、指摘がない場合にその旨を明示することを必須としています。

Simplify Auditor

Explore エージェントとして起動します。デッドコード、命名、制御フロー、API の表面、過剰な抽象化、統合を確認します。指摘を cosmetic または refactor に分類します（refactor の基準：「不完全なだけではなく、明らかに間違っている」）。ファイル、行、カテゴリ、修正方法、重大度を報告します。

Harden Auditor

Explore エージェントとして起動します。入力検証、エラー処理、インジェクションの危険性、認証／認可、シークレット、データ漏えい、依存関係のリスク、競合状態を確認します。指摘を patch または security refactor に分類します。ファイル、行、カテゴリ、重大度、攻撃経路、修正方法を報告します。

Spec Auditor

Explore エージェントとして起動します。機能の不足、誤った動作、不完全な実装、契約違反、テスト範囲、受け入れ条件の不足を確認します。指摘を missing、incorrect、incomplete、untested に分類します。ファイル、行、カテゴリ、仕様の参照先、重大度を報告します。

6. 監査結果に対応する

すべての監査担当から指摘を収集します。指摘ごとに、次のように対応します。

Critical/High：タスクを作成し、実装エージェントに割り当てます
Medium：タスクを作成し、次の実装ラウンドに含めます
Low/Cosmetic：簡単に修正できる場合のみ次のラウンドに含めます。それ以外は最終サマリーに記載し、対応を見送ります

リファクタリングの判定基準： 指摘が refactor または security refactor に分類された場合は、タスクを作成する前に、そのリファクタリングが本当に必要かを評価します。基準は「シニアエンジニアが、現在の状態は不完全なだけでなく明らかに間違っていると言うだろうか？」です。スタイルの好みやわずかな改善にすぎないリファクタリングの提案は却下します。

終了判定： このラウンドのすべての指摘の重大度が low の場合は、その場で修正し、再監査は省略します（ループの上限を参照）。

修正タスクを作成する際は、各実装エージェントの作業にドキュメントの確認も含めます。

割り当てられた問題を修正した後、変更したファイルに、判断の背景がすぐには分からない箇所を説明する1行コメントを最大5つ追加してください。

「なぜこれが存在するのか？」を考えるのに5秒以上かかるロジック

背景と削除条件を示す TODO を添えた回避策やハック

現在の方法を選んだ理由を含むパフォーマンス上の選択

監査で見つかった問題の修正そのものにはコメントを付けないでください。説明が不足している、元の実装での判断に限ってコメントしてください。

これにより、ドキュメントの確認を軽量かつ限定的に行えます。以降のラウンドの監査担当は、これらのコメントを指摘事項として挙げないでください。

7. ループ

修正すべき指摘事項がある場合：

指摘事項からタスクを作成します（ドキュメントのパスに関する指示を含めます）
実装エージェントを起動します（または、アイドル状態のエージェントを SendMessage で再利用します）
修正を待ちます
コンパイルとテストの検証を実行します
スコープの逸脱を確認（チームリーダー）： 次の監査ラウンドの前に、意図のフレームと計画／タスクの内訳を読み直します。作業の現在の状態を元のスコープと比較します。監査の指摘事項によってチームが無関係な領域に引き込まれていたり、設定した範囲を超えてスコープが広がっていたりする場合は、スコープを再設定するか、ループを早めに終了して概要を作成します。
ループの上限を確認します（「ループの上限と終了条件」を参照）。
終了しない場合は、監査エージェントを再度起動します（再利用ではなく、新しいエージェントを使用します。コンテキストをクリアするためです）。
繰り返します

8. 最終検証と概要

終了条件を満たしたら：

コンパイル／型チェックを行います。エラーがあってはなりません
テストがすべて成功することを確認します
対応するタスクがない状態で、新たに // TODO または // FIXME コメントを追加していないことを確認します

セッションの最終概要を作成します：

## Hardening Summary

**Audit rounds completed:** 2 of 3 max
**Exit reason:** Clean audit (all auditors reported zero findings)

### Findings by round

Round 1:
- simplify-auditor: 4 cosmetic, 1 refactor (rejected -- style preference)
- harden-auditor: 2 patches, 1 security refactor (approved)
- spec-auditor: 1 missing feature

Round 2:
- simplify-auditor: 0 findings
- harden-auditor: 0 findings
- spec-auditor: 0 findings

### Actions taken
- Fixed: 6 findings (4 cosmetic, 2 patches, 1 security refactor, 1 missing feature -- rejected refactor excluded)
- Skipped: 1 refactor proposal (reason: style preference, not a defect)
- Document pass: 3 comments added across 2 files

### Unresolved
- None

### Out-of-scope observations
- <any out-of-scope items auditors flagged, for future reference>

### Learning loop
learning_loop:
  target_skill: "self-improvement"
  candidates:
    - pattern_key: "harden.input_validation"
      auditor: "harden-auditor"
      rounds_to_resolve: 1
      severity: "high"
      suggested_rule: "Validate and bound-check external inputs before use."
    - pattern_key: "simplify.dead_code"
      auditor: "simplify-auditor"
      rounds_to_resolve: 1
      severity: "low"
      suggested_rule: "Remove dead code and unused imports before finalizing."

複数のラウンドで繰り返し見つかった監査指摘事項を、simplify-and-harden と同じ形式の pattern_key エントリーにまとめます。これにより、タスクをまたいだパターンの追跡と昇格に関する self-improvement に情報を提供します。

状況に合わせて形式を調整してください。見つかったこと、修正したこと、スキップしたこととその理由、残っていることを明確に記録するのが目的です。

9. クリーンアップ

すべてのエージェントにシャットダウンをリクエストしてから、チームを削除します：

SendMessage type: shutdown_request to each agent
TeamDelete

エージェントの規模の目安

コードベース／タスクの規模	実装エージェント	監査エージェント
小（10 ファイル未満）	1-2	2（簡素化＋強化）
中（10-30 ファイル）	2-3	2-3
大（30 ファイル以上）	3-5	3（簡素化＋強化＋仕様）

エージェントを増やすと並列性は高まりますが、調整のオーバーヘッドも増えます。ほとんどのタスクでは、実装エージェント 2-3 個と監査エージェント 2-3 個が最適です。

ヒント

実装エージェントには general-purpose を指定します。書き込みアクセスが必要です
監査エージェントには Explore を指定します。読み取り専用にすることで、監査の目的を損なうような、気付かれない修正を防げます
監査ラウンドごとに新しいエージェントを使用します。前のラウンドの監査エージェントを再利用しないでください。以前のコンテキストに引きずられ、「すでに確認済み」の領域に偏る可能性があります
タスクの説明は具体的にします。ファイルパス、関数名、期待される動作を正確に含めます。曖昧なタスクからは曖昧な実装しか得られません
フェーズの間にコンパイルとテストを実行します。コードが壊れている状態で監査エージェントを起動せず、まずコンパイルエラーとテストエラーを修正します
ループを短く保ちます。監査で見つかったのが重要度の低い見た目上の問題 1-2 件だけなら、実装ラウンドを丸ごと起動するのではなく、自分で修正します
エージェントの起動前にタスクを割り当てます。TaskUpdate でタスクに owner を設定し、エージェントがすぐに作業内容を把握できるようにします
まず簡素化する方針にします。監査の指摘事項に対応するときは、リファクタリングに取り組む前に、ノイズを減らす見た目上の整理を優先します。既定ではクリーンアップを行い、リファクタリングは例外とします
スタイルよりセキュリティを優先します。予算や時間に制約がある場合は、簡素化の指摘事項より強化の指摘事項を優先します
ファイル一覧を渡します。変更したファイルの明示的な一覧を、必ず監査エージェントに渡します。監査エージェントが自力でスコープを把握することを前提にしないでください

例：仕様機能の実装

0.  Plan: Read spec (or run inline interview), break into 8 tasks
0b. Emit Intent Frame #1, confirm with user
1.  TeamCreate: "feature-harden"
2.  TaskCreate x8 (one per feature)
3.  Spawn 3 impl agents, assign ~3 tasks each
4.  Wait → all done → compile clean → tests pass
5.  Collect modified file list (git diff --name-only)
6.  Spawn 3 auditors: simplify-auditor, harden-auditor, spec-auditor
7.  Simplify-auditor finds 4 cosmetic + 1 refactor proposal
8.  Harden-auditor finds 2 patches + 1 security refactor
9.  Spec-auditor finds 1 missing feature
10. Team lead evaluates refactors (approve security refactor,
    reject simplify refactor), creates fix + document tasks
11. Spawn 2 impl agents for fixes
12. Wait → compile clean → tests pass
13. Drift check: re-read intent frame, scope looks good
14. Round 2: Spawn 3 fresh auditors
15. Auditors find 0 issues → exit condition met
16. Produce hardening summary + learning loop output
17. Shutdown agents, TeamDelete

品質ゲート（必須）

ループを終了する前に、以下を満たす必要があります：

コンパイル／型チェックが成功し、エラーがゼロであること
テストの失敗がゼロであること
終了条件を満たしていること（監査で指摘事項がない、重要度の低い指摘のみのラウンド、または重大／高重要度の指摘を解決したうえでループ上限に到達している）
対応するタスクがない状態で、新たに // TODO または // FIXME コメントを追加していないこと

他のスキルとの相互運用性

このスキルが受け取るもの

plan-interview から（任意）： 計画ファイル（docs/plans/plan-NNN-<slug>.md）。利用できる場合は、実装チェックリストからタスクを抽出します。ない場合は、チームリードがインラインで計画フェーズを実施します。
ユーザーから（常に利用可能）： タスクの説明、仕様、または機能リスト。計画ファイルがない場合の信頼できる情報源として使用します。

このスキルが生成するもの

自己改善向け： 繰り返し発生する監査結果から得られる学習ループの候補。simplify-and-harden と同じ pattern_key 形式です。
ユーザー向け： すべてのラウンドにわたる完全な監査履歴を含む、ハードニングの概要。

パイプライン内の位置

このスキルは、標準パイプラインのステージ 2～4 をチームベースのループに置き換えます。

plan-interview（任意 — またはフェーズ 0 でインライン計画を実施）
agent-teams-simplify-and-harden（チームリード + インテントフレーム + 実装 + 監査 + ドリフトチェック + 学習ループ）
self-improvement（学習ループの出力を利用して、タスクをまたいだパターンを追跡）

チームリードは独自のインテントフレームを実施します（intent-framed-agent から受け取るものではありません）。また、ラウンド間では軽量なコンテキストサーフィングによるドリフトチェックを行います（完全な終了／引き継ぎプロトコルではありません）。サブエージェントは短期間のみ稼働し、パイプラインスキルを実行しません。

Markdown 対応

ログインしてコメント

基本情報

作者: pskoett
リポジトリ: pskoett/pskoett-ai-skills
カテゴリ: エージェントワークフロー
インストール数: 513
GitHub スター: 327

問題を報告