devil-team-adder

devil-team-adder

任意の Skill（既存 / 新規）に Devil-only Agent Teams を動的策定して scaffold するメタスキル。対象 Skill ごとに Devil 観点を毎回見極め、プリセットは使わない。

責務分離

本 skill は Skill 内 Devil の観点策定 + scaffold 専用。runtime での起動判断・並列実行は別 skill が担当する:

skill	責務	対象
devil-team-adder (本 skill)	観点策定 + scaffold	単一 Skill
devil-team-orchestrator	runtime 起動判断 + Layer 2 並列実行 (Codex Devil 主役 / Claude Devil fallback、案 A)	プロジェクト全体 (タスク受領時に自動)

本 skill は「この Skill に Devil 入れて」と明示依頼された時のみ起動。タスク受領時の常駐 Devil 起動は orchestrator の責務。

背景と原則

• 同一モデルでも観点を分離した Devil を複数体並列起動すれば、重複指摘 < 7 割の独立性を保ったまま批判層を構成できる（実プロジェクトでの検証事例あり）
• この運用を任意の Skill に資産化する
• プリセットを押し付けない: Skill ごとに「作るもの / 読者 / 既存ロール / 過去失敗」が全部違うので一般解なし。観点は毎回策定する

Hard rules

• プリセットを提示して選ばせる運用はしない（対象 Skill ごとに観点を策定）
• 対象 Skill の既存 Devil があれば削除・置換せず、共存する（役割分担マーカーを scaffold 時に明記）
• ユーザー承認なしに対象 Skill のファイル（SKILL.md / roles/ 等）を変更しない
• Skill tool / Agent tool の公式仕様に従う
• scaffold は idempotent（同じ Skill に再実行しても安全に更新できる）
• 初回 scaffold と 2 回目以降の再 scaffold を区別する（mode: initial / update）
• Phase 4 で系統 A / 系統 B を判定する（対象 Skill が Agent tool を使うなら系統 B、使わないなら系統 A）。詳細は references/coexistence-guide.md 「Phase 4 開始前の系統判定」節
• 系統 B の claude -p サブプロセスは必ず --model opus を指定する（sonnet / haiku への変更禁止）

入力

• target_skill (必須): 追加先の Skill 名
• mode (省略可、既定 initial): initial (初回策定) / update (既存 scaffold の再策定)
• custom_focus (省略可): ユーザーが特に強調したい観点ヒント（例: "時間軸重視", "AI 臭に集中"）

実行手順（5 Phase）

Phase 1: 対象 Skill の精読

目的: 対象 Skill の構造・アウトプット・既存ロール・依存を把握する。

1. target_skill のディレクトリ .claude/skills/<target-skill-name>/ を走査
2. 以下を全て読む:
   • SKILL.md 全文
   • references/ 配下（あれば全ファイル）
   • roles/ 配下（あれば全ファイル）
   • templates/ 配下（あれば全ファイル）
   • その他 .md / .sh / .py ファイル
3. 対象 Skill が依存すると見られる他ファイル（自プロジェクトの failure-patterns 台帳、関連 reflection 等）を列挙
4. 精読サマリをユーザーに提示（アウトプット / 既存ロール / 既存 Devil 有無 / 関連失敗パターン）

Phase 2: 観点策定インタビュー（6 軸の問い）

目的: 対象 Skill 固有の Devil 観点を、ユーザー対話で動的に策定する。

references/perspective-discovery.md のフレームワークに従い、以下 6 軸をユーザーと対話:

1. 軸 1: この Skill は何を作るか？（アウトプットの粒度 / 種類）
2. 軸 2: 誰が読む / 使うか？（1 次読者、2 次判断者、3 次保守者）
3. 軸 3: 過去の失敗パターン（自プロジェクトの failure-patterns 台帳 + 対象 Skill 関連 reflection 照合）
4. 軸 4: 時間軸観点（直後 / 中期 / 長期のリスク）
5. 軸 5: 視点軸（内部 / 外部 / メタ）
6. 軸 6: 既存 Devil の担当範囲と、追加 Devil-only Team がカバーすべき補完領域

各軸の回答は 簡潔で構わない（対話コスト < 実装価値）。ユーザー回答がユルい場合は、メタスキルが推論で補完した案をユーザー確認に回す。

Phase 3: Devil セット候補の生成 → ユーザー承認

references/perspective-derivation.md の変換ルールで、Phase 2 の回答から Devil 観点候補を導出:

• 各 Devil に 明確な名前（Phase 3 で対象 Skill の文脈に合わせて命名する）
• 各 Devil の 担当軸（300 字以内の説明）
• 既存 Devil との重複チェック（軸 6 でフィルタ）

提案数は 2-6 体（ユーザーが対話で決定）。Trio / Quintet / Duo のような事前定義ではなく、対象ごとに最適数を対話で決める。

ユーザー承認 → Phase 4。修正指示があれば Phase 3 を反復。

Phase 4: Scaffold の実行

1. templates/skill-md-insertion-block.md を読み、Phase 3 の Devil セットを埋めて対象 SKILL.md に追記（既存 Devil 共存マーカー付き）
2. 対象 Skill 配下に roles/ ディレクトリがなければ作成
3. 各 Devil について templates/role-file-template.md を埋めて roles/devil-<name>.md を生成
4. 対象 SKILL.md に 自然言語起動例（「/devil-team-adder を再起動すると更新できます」）を 1 行追記
5. 【系統 B のみ・必須】scaffold 後の実機 dry-run 検証:
   • 系統 B（claude -p サブプロセス方式）採用時は、scaffold 完了直後に 本環境で系統 B が動くか実機検証する
   • 検証コマンド（2 種類とも実行）:

     # 試行 1: dangerously-skip-permissions あり
     claude -p --dangerously-skip-permissions --output-format text --model opus "exit 0" 2>&1 | head -3
     # 試行 2: --bare -p（dangerously-skip-permissions なし）
     claude --bare -p --output-format text --model opus "exit 0" 2>&1 | head -3
     

   • 両方とも成功（exit 0 / マーカー出力など）→ scaffold 確定、devils/system-choice.md に「[YYYY-MM-DD] 本環境で系統 B 動作確認」を追記
   • どちらかでも "Tier 1 blocked behavior" / "autonomous agent loop" / "Create Unsafe Agents" 系の permission denied → 系統 B が 本環境では動かない。次のいずれかの代替方式をユーザーに提示して選択を仰ぐ:
     1. B 案（推奨 / 唯一の確実な道）: 既存 Reviewer プロンプトに Devil N 観点を統合し、サブプロセスを使わない設計に変更（subprocess 不要 / 判定自体が起きない / Q3 ネスト不可制約も同時回避）
     2. C 案: Devil 起動コマンドを「ユーザー手動 Bash」に切り出し、SKILL.md には起動コマンドだけ書いて Updater は Devil なしで完了
     3. D 案: Devil 起動条件を撤廃（軽量化 / LLM バイアス対策は Reviewer + Codex のみに依存）
     4. A 案（非推奨）: ユーザーが settings.json で Bash(claude -p:*) 許可。エラーメッセージに「To allow this type of action in the future, the user can add a Bash permission rule to their settings」とあるので一部のケースで通る可能性はあるが、判定が permission レイヤーより上位で行われている可能性もあり、settings 許可しても通らないケースも実機確認必要。スコープ拡大リスクも大きい
     5. 未検証案 (Agent SDK 経由): claude_agent_sdk.query() (Python) / @anthropic-ai/claude-agent-sdk (TS) での autonomous loop 起動が Tier 1 を通過するか実機検証。Anthropic 公式の Agent SDK permissions ドキュメントに subagent inheritance ノートがあり親プロセス検出の存在が示唆されているため、期待値は低いが要検証
   • 不採用確定: claude --bare -p 単独 = Tier 1 ブロック対象（試行 2 でも同じくブロック確認済み）
   • 未検証 → ユーザーに「動作確認 skip 状態」と明示してから scaffold 確定（非推奨）
   • 失敗時は devils/system-choice.md に「[YYYY-MM-DD] 本環境で系統 B Tier 1 ブロック / 採用代替方式: {B/C/D/A/未検証}」を必ず追記
   • 「Tier 1」用語の補足: 「Tier 1 blocked behavior」は Claude Code エラーメッセージに登場する 内部実装の用語。Anthropic 公式 permissions ドキュメントの "tiered permission system"（Read-only / Bash / File modification の 3 階層）とは別概念。公式 docs に「Tier 1」名称の明示記載なし
   • 論理整合だけで完了報告しない: 「論理仕様で系統 B が正しい」と「実機で動く」は別問題

Phase 5: 検証と次アクション提示

1. 対象 Skill の実際のアウトプット（既存ファイル）があれば、策定した Devil Team を並列で試し起動（option、ユーザー確認後）
2. Devil 結果を整形して報告し、観点の過不足を対話で修正（Phase 3 に戻る）
3. 完了時の次アクション提示:
   • scaffold 済み Devil を実タスクで使うコマンド例
   • 再策定が必要な場合の mode: update 起動方法

共通リソース

• 観点策定フレームワーク: references/perspective-discovery.md
• 変換ルール: references/perspective-derivation.md
• 既存 Devil 共存ガイド: references/coexistence-guide.md
• 自然言語 Skill 起動パターン集: references/launch-pattern-catalog.md
• SKILL.md 挿入ブロック雛形: templates/skill-md-insertion-block.md
• ロールファイル雛形: templates/role-file-template.md
• Devil プロンプト骨格: templates/devil-prompt-skeleton.md
• idempotent 挿入スクリプト: scripts/inject-devil-team.sh

出力フォーマット

Phase 2 完了時

OBSERVED PERSPECTIVES (6 軸サマリ):
- 軸 1: ...
- 軸 2: ...
- 軸 3: ...
- 軸 4: ...
- 軸 5: ...
- 軸 6: ...

Phase 3 完了時

DEVIL SET PROPOSAL ({N} 体):
- Devil α "{NAME}": {責務}
- Devil β "{NAME}": {責務}
...

EXISTING DEVIL COEXISTENCE:
- 既存 Devil ({有 / 無}): {既存責務 if 有}
- 補完関係: {どう役割分担するか}

[ユーザー確認]: この構成で scaffold しますか？

Phase 4 完了時

SCAFFOLD COMPLETE:
- 対象 SKILL.md: {path} に Devil-only セクション追加
- roles/devil-{name}.md: {N} ファイル生成
- 再策定方法: /devil-team-adder + mode: update

想定使用例

• 例 A: 既存 Devil 不在の Skill に初回策定 → 5 Phase 完走
• 例 B: 既存 Devil ありの Skill に補完 Devil-only Team を追加 → Phase 3 で共存マーカー明記
• 例 C: 新規 Skill 作成時に skill-creator の post-step として devil-team-adder を呼ぶ → Phase 1 で新規 Skill を精読

制約と既知の不確定要素

• Skill → Skill の自然言語起動: 公式記法ではないが運用実証あり。発火率は書き方に依存する（launch-pattern-catalog.md に発火高確率パターン蓄積）
• Agent Teams のネスト: 対象 Skill が既に Agent tool で並列起動中の状態に Devil-only Team を起動できるかは環境依存 → 必要なら実機検証
• Phase 間 context 保持: Phase 2 で集めた 6 軸回答が Phase 3-4 で失われないか → 現状は 1 ターン内で完遂する前提。複数ターンにまたがる場合は明示的にユーザーに 6 軸回答を復唱してもらう