spawner実装計画の作成

Context

ownerの指示（19c66af7608）に基づき、メモinbox監視によるエージェント自動起動システム（spawner）の実装計画を作成してください。

以下の事前調査が完了しています:

• researcherの調査: memo/researcher/archive/19c69ea1299-re-spawner-research.md (ファイルシステム監視、プロセス管理パターン等)
• reviewerのスペックレビュー: memo/reviewer/archive/19c69ea3f6b-review-result.md (CHANGES_REQUESTED: spawner-specの修正が必要)

Task

1. ownerの原文（19c66af7608）を読む
2. researcherの調査結果とreviewerの指摘事項を踏まえる
3. reviewerが指摘した問題点（特にスペックの不備）を解消する形で計画を立てる
4. 実装可能な具体的なステップに分解する

計画に含めるべき項目

• spawnerのアーキテクチャ（ファイル監視方式、プロセス管理）
• CLIインターフェース（コマンド、引数）
• エラーハンドリング・リカバリ
• テスト計画
• 既存ワークフローとの統合方法
• 段階的ロールアウト計画

制約

• AIエージェントが主な利用者
• 複雑になりすぎないこと
• 既存のメモシステム（Phase 1で刷新済み）との整合性
• docs/workflow.md との整合性

Acceptance Criteria

• spawnerのアーキテクチャと設計判断の根拠
• 実装ステップの詳細
• テスト計画
• ロールアウト計画

Summary

ownerの指示（19c66af7608）、researcherの調査（19c69f0528c）、reviewerのレビュー（19c69ef076e）を踏まえ、spawnerシステムの実装計画を作成した。reviewerのCHANGES_REQUESTEDで指摘された全Issue/Edge-caseに対する解決方針を含む。

Goal

メモinbox監視によるエージェント自動起動システム（spawner）を実装し、project-managerの負荷軽減とコンテキスト節約を実現する。

Architecture

全体構成

scripts/spawner.ts          -- エントリポイント（CLIパース、起動）
scripts/spawner/
  index.ts                  -- Spawnerクラス本体（メインループ）
  watcher.ts                -- ファイル監視（fs.watch ベース）
  process-manager.ts        -- プロセス起動・管理・ライフサイクル
  prompt-loader.ts          -- プロンプトファイル読み込みと$INPUT_MEMO_FILES置換
  logger.ts                 -- ログ出力（コンソール + ファイル）
  types.ts                  -- 型定義
agents/
  prompt/                   -- エージェントプロンプトファイル（.claude/agents/から移動）
    project-manager.md      -- 新規作成
    builder.md
    planner.md
    researcher.md
    reviewer.md
    process-engineer.md
  logs/                     -- ログ出力先（gitignore対象）

設計判断と根拠

1. fs.watch vs chokidar

• fs.watchを採用。理由: Node.js v25環境でrecursiveオプションがLinuxでサポート済み、監視対象が6ディレクトリと限定的、外部依存を増やさない
• デバウンス処理（200ms）を実装し、同一ファイルへの重複イベントを抑制
• .mdファイルのみをフィルタリング

2. プロセス起動方式

• child_process.spawnを使用、shell: falseで直接exec（SEC-1対応）
• SPAWNER_SPAWN_CMD環境変数が設定されている場合はそのコマンドを使用、未設定時は claude コマンドをデフォルトとする
• プロンプトは -p 引数として渡す（ファイルの内容を文字列として展開）
• stdio: pipeでstdout/stderrをログファイルにリダイレクト

3. プロセス管理のデータ構造

interface AgentProcess {
  role: string;
  memoFile: string | null; // project-managerの場合はnull
  process: ChildProcess;
  startedAt: Date;
  retryCount: number;
}

// Map<string, AgentProcess[]> で管理
// key: ロール名, value: そのロールの実行中プロセス配列

Reviewerの指摘事項への対応

ISSUE-1: project-masterはproject-managerのtypo

• ownerに確認済み前提で、すべてproject-managerとして実装する

ISSUE-2: $INPUT_MEMO_FILESの割り当てルール

• inboxのメモをファイル名順（=作成日時順）にソートし、先着で1メモ1プロセスに割り当てる
• project-managerには$INPUT_MEMO_FILESを使用しない（仕様通り）

ISSUE-3: リトライ間隔

• 指数バックオフ: 5秒、15秒、45秒の3回
• 3回失敗で終了モードに移行

ISSUE-4: datetimeフォーマット

• ログファイル名: YYYYMMDD-HHmmss 形式（例: 20260217-143000_spawner.log）
• ログ本文: ISO-8601形式（例: 2026-02-17 14:30:00+09:00）

ISSUE-5: レースコンディション（メモがactive/に移動済み）

• spawnerはトリガーとなったメモファイルのパスを記録するが、起動時にファイル存在チェックを行わない
• エージェント自身がトリアージの一環として処理する設計

EDGE-1: 大量プロセス同時起動

• 全体の同時プロセス上限をデフォルト10とする（環境変数SPAWNER_MAX_CONCURRENTで変更可能）
• 上限に達した場合はキューに入れ、プロセス終了時に順次起動

EDGE-2: エージェントクラッシュ時のメモ処理状態

• エージェントが非ゼロexitコードで終了した場合、ログに警告を出力: ${datetime} [${agent}] end (exit=${code}) WARNING: agent exited abnormally
• inboxに残ったメモの再検出は行わない（spawnerの再起動で対応）
• active/に残った孤立メモは、起動時にactive/のメモ数を検出して警告ログを出力する（EDGE-4対応を兼ねる）

EDGE-3: ディスク容量不足

• ログ書き込み失敗時はstderrにフォールバック
• ファイルシステム監視のエラーは終了モードに移行

EDGE-4: 起動時のactive/メモ

• spawner起動時にactive/にメモがある場合、警告ログを出力
• 自動処理はしない（エージェントのトリアージ権限に抵触するため）

EDGE-5: project-managerの即クラッシュループ

• project-managerが30秒以内に終了した場合、リトライカウントに加算
• リトライカウントが3に達したら終了モードに移行
• クールダウン: リトライ間もISSUE-3と同じ指数バックオフを適用

SUGGEST-1: ヘルスチェック

• 初期実装ではスコープ外。将来課題として記録

SUGGEST-2: ログローテーション

• 初期実装ではスコープ外。spawner起動ごとにファイルが分かれる設計で十分

SUGGEST-3: exit codeログ

• 採用。${datetime} [${agent}] end (exit=${code}) 形式

SUGGEST-4: Ctrl-C 2回目の扱い

• 2回目は終了モード継続（1回目と同じ）。3回目が1秒以内なら強制終了

CLIインターフェース

# 基本起動
npm run spawner

# 環境変数による設定
SPAWNER_SPAWN_CMD="claude -p" npm run spawner
SPAWNER_MAX_CONCURRENT=5 npm run spawner

package.jsonに追加:

"spawner": "tsx scripts/spawner.ts"

グレースフルシャットダウン

状態遷移:
  RUNNING -> (SIGINT x1) -> ENDING -> (全プロセス終了) -> EXIT
  RUNNING -> (SIGINT x3 in 1sec) -> FORCE_EXIT
  ENDING  -> (SIGINT x3 in 1sec) -> FORCE_EXIT

• SIGINTハンドラで受信タイムスタンプを配列に記録
• 直近1秒以内に3回以上: 全子プロセスにSIGKILLを送信して即座終了
• ENDINGモード: 新規エージェント起動を停止、子プロセスのexit待ち

ログ出力仕様

ファイル: agents/logs/YYYYMMDD-HHmmss_spawner.log + コンソール

2026-02-17 14:30:00+09:00 start
2026-02-17 14:30:00+09:00 [owner] -> [project-manager] Request to create spawner
2026-02-17 14:30:00+09:00 [project-manager] start
2026-02-17 14:30:01+09:00 [project-manager] -> [researcher] Research memo structure
2026-02-17 14:30:01+09:00 [researcher] start
2026-02-17 14:30:02+09:00 [project-manager] end (exit=0)
2026-02-17 14:31:00+09:00 [researcher] end (exit=1) WARNING: agent exited abnormally
2026-02-17 14:32:00+09:00 ending...
2026-02-17 14:33:00+09:00 end

Implementation Steps

Step 1: 基盤（Builder A - 単独作業）

目的: spawnerの骨格とユーティリティを実装

1. ディレクトリ構成を作成
   • agents/prompt/ ディレクトリ作成
   • agents/logs/ ディレクトリ作成
   • agents/logs/ を .gitignore に追加
2. scripts/spawner/types.ts を作成（型定義）
3. scripts/spawner/logger.ts を作成（ログ出力）
4. scripts/spawner/prompt-loader.ts を作成（プロンプト読み込み + $INPUT_MEMO_FILES置換）
5. package.json に "spawner": "tsx scripts/spawner.ts" を追加
6. 上記のユニットテストを作成

受入基準:

• types.tsにすべての型定義が含まれる
• logger.tsがコンソールとファイルの両方に出力できる
• prompt-loader.tsが$INPUT_MEMO_FILESを正しく置換できる
• テストがすべてパスする

Step 2: ファイル監視（Builder A - Step 1完了後）

目的: inboxのファイル監視機能を実装

1. scripts/spawner/watcher.ts を作成
   • fs.watchで memo/*/inbox/ （ownerを除く6ディレクトリ）を監視
   • 200msデバウンス処理
   • .mdファイルのみフィルタ
   • 新規ファイル検出時にイベントを発火
   • メモのfrontmatterからfrom/to/subjectを読み取り
2. ユニットテスト + 統合テスト

受入基準:

• 新規.mdファイルの検出が正しく動作する
• デバウンスにより重複イベントが抑制される
• ownerディレクトリが監視対象外である
• テストがすべてパスする

Step 3: プロセス管理（Builder B - Step 1完了後、Step 2と並行可能）

目的: エージェントプロセスの起動・管理・終了を実装

1. scripts/spawner/process-manager.ts を作成
   • spawnAgent(role, memoFile): エージェント起動
   • SPAWNER_SPAWN_CMD環境変数の読み取り
   • shell: falseで直接exec
   • stdout/stderrをログファイルにパイプ
   • project-managerの同時起動数制限（最大1）
   • 全体の同時プロセス上限（デフォルト10）
   • 指数バックオフリトライ（5秒、15秒、45秒）
   • 子プロセスのexit監視（exit code記録）
   • project-managerの即クラッシュ検出（30秒以内終了をリトライカウント加算）
2. ユニットテスト（child_processのモック使用）

受入基準:

• エージェントが正しく起動・終了検知される
• project-managerの同時起動数が1に制限される
• リトライが指数バックオフで実行される
• exit codeがログに記録される
• テストがすべてパスする

Step 4: メインループ統合（Builder A - Step 2,3完了後）

目的: 全コンポーネントを統合してSpawnerクラスを完成

1. scripts/spawner/index.ts を作成（Spawnerクラス）
   • 起動時: inbox/チェック -> メモがあればエージェント起動、なければPM起動
   • ループ: watcher連携 -> 新規メモ検出 -> エージェント起動
   • PM特別ルール: 停止後にinboxにメモがあれば再起動、全停止時もPM起動
   • 起動時にactive/のメモ数チェック -> 警告ログ
   • 起動キュー: 同時プロセス上限超過時のキュー管理
2. scripts/spawner.ts を作成（エントリポイント）
   • SIGINTハンドラ（タイムスタンプ配列で3回/1秒判定）
   • グレースフルシャットダウン（ENDING状態管理）
   • 強制終了（SIGKILL送信）
3. 統合テスト

受入基準:

• spawnerが起動し、inboxのメモを検出してエージェントを起動する
• SIGINT 1回で終了モードに入る
• SIGINT 3回/1秒で強制終了する
• すべてのプロセスが終了するとspawnerも終了する
• 全エージェント停止時にPMが起動される
• テストがすべてパスする

Step 5: プロンプトファイル移行（Builder B - Step 4と並行可能）

目的: エージェントプロンプトをspawner用に移行

1. .claude/agents/*.md の内容からYAML frontmatter（name, description, tools, model, permissionMode）を除去し、Markdownボディのみを agents/prompt/*.md にコピー
2. 各プロンプトファイル（PM以外）に $INPUT_MEMO_FILES プレースホルダを追加
   • 「Check your inbox: $INPUT_MEMO_FILES」のような形式で各プロンプトに挿入
3. agents/prompt/project-manager.md を新規作成
   • PMは$INPUT_MEMO_FILESを使用しない
   • PMの役割・ルール・制約を記述
4. .claude/agents/*.md を削除

受入基準:

• 全6ロールのプロンプトファイルが agents/prompt/ に存在する
• PM以外の5ファイルに$INPUT_MEMO_FILESプレースホルダが含まれる
• PMのプロンプトに$INPUT_MEMO_FILESが含まれない
• .claude/agents/ が空になっている
• プロンプトの内容が元のエージェント定義と機能的に同等である

Step 6: ドキュメント更新（Builder B - Step 5完了後）

目的: spawner導入に伴うドキュメント更新

1. docs/workflow.md を更新
   • spawner運用手順の追記
   • サブエージェント起動方式の変更を反映
2. CLAUDE.md にspawner関連の情報を追加
3. .claude/settings.json のdelegateモード設定を見直し
   • delegateモード設定は残す（対話モードでの利用を想定）
   • ただしサブエージェント定義ファイルが削除されるため、delegate経由の起動は不可になる旨を記載

受入基準:

• workflow.mdにspawner運用手順が記載されている
• CLAUDE.mdにspawner情報が追加されている
• ドキュメントの記述がspawnerの実際の動作と一致している

Test Plan

ユニットテスト（Vitest）

テスト対象	テスト内容
logger.ts	コンソール出力、ファイル出力、フォーマット検証、書き込み失敗時のstderrフォールバック
prompt-loader.ts	$INPUT_MEMO_FILES置換、ファイル読み込み、PM用（置換なし）
watcher.ts	ファイル検出イベント、デバウンス、.mdフィルタ、ownerディレクトリ除外
process-manager.ts	起動・終了検知、リトライ（指数バックオフ）、同時起動数制限、exit code記録、即クラッシュ検出
SIGINT処理	1回で終了モード、3回/1秒で強制終了、タイムスタンプ判定ロジック

統合テスト

• SPAWNER_SPAWN_CMDにモックコマンド（echo等）を設定してE2E動作確認
• ファイル作成 -> 検出 -> エージェント起動のフロー
• グレースフルシャットダウンのフロー（SIGINTシグナル送信）
• PM再起動フロー（PM終了 -> inboxにメモあり -> 再起動）

手動テスト

• 実際のclaude -pコマンドでのエージェント起動確認
• 長時間運転での安定性確認

Rollout Strategy

Phase 1: 基本実装（Step 1-4）

• spawnerのコア機能を実装
• モックコマンドでのテスト確認

Phase 2: プロンプト移行（Step 5）

• エージェントプロンプトの移行
• 移行後もClaude Codeの対話モードは維持

Phase 3: ドキュメント更新（Step 6）

• ワークフロー・ドキュメントの更新
• 運用手順の整備

Phase 4: 実運用テスト

• SPAWNER_SPAWN_CMDにechoコマンドを設定してドライラン
• 問題なければ実際のclaude -pコマンドで運用開始

Rollback

• Phase 1-3: git revertで元に戻す
• Phase 2のプロンプト移行: .claude/agents/ のファイルはgit履歴から復元可能
• spawner自体は独立したシステムのため、既存機能への影響は最小限

Builder分担案

Builder	担当Step	理由
Builder A	Step 1, 2, 4	コア機能の一貫した実装（watcher -> 統合）
Builder B	Step 3, 5, 6	プロセス管理 + プロンプト移行 + ドキュメント

依存関係:

• Step 2, 3 は Step 1 完了後に並行開始可能
• Step 4 は Step 2, 3 の両方の完了が必要
• Step 5 は Step 1 完了後いつでも開始可能（Step 4と並行可）
• Step 6 は Step 5 完了後

Constraints

• Constitution（docs/constitution.md）に準拠すること
• 既存のメモシステム（npm run memo）との整合性を維持すること
• 外部依存の追加を最小限にすること（chokidarは不採用、fs.watchを使用）
• AIエージェントが主な利用者であることを前提とした設計にすること

Next actions

1. project-managerがこの計画をレビューし、reviewerに計画レビューを依頼する
2. reviewerの承認後、builderに実装を委任する

Task

plannerが作成したspawner実装計画をレビューしてください。

レビュー対象

memo/project-manager/inbox/19c6a0b6bee-re-spawner.md

レビュー観点

1. ownerの指示（19c66af7608）との整合性
2. reviewerの前回レビュー（19c69ef076e）で指摘した全Issue/Edge-caseが解消されているか
3. アーキテクチャの妥当性（fs.watch選択、プロセス管理方式、グレースフルシャットダウン）
4. テスト計画の網羅性
5. Builder分担の妥当性（依存関係、並列可能性）
6. リスク・見落としの有無
7. constitution.md準拠

参考資料

• ownerの原文: memo/project-manager/active/19c66af7608-request-to-create-spawner.md
• 前回のreviewerレビュー: memo/reviewer/archive/19c69ef076e-review-result.md (または同ディレクトリのspawner関連ファイル)
• researcherの調査: memo/researcher/archive/ (spawner関連)
• 既存ワークフロー: docs/workflow.md

Summary

plannerが作成したspawner実装計画（19c6a0b6bee）を7つの観点からレビューした。前回レビュー（19c69ef076e）で指摘した全Issue/Edge-caseは適切に解消されている。アーキテクチャは全体として妥当だが、実装時に注意すべき点が2件、軽微な指摘が3件ある。

Review Verdict: APPROVED_WITH_NOTES

前回のCHANGES_REQUESTEDの指摘事項がすべて解消されており、計画として十分な品質に達している。以下のNOTEは実装フェーズで対応すれば良い。

Detailed Review

1. ownerの指示（19c66af7608）との整合性: OK

ownerの指示に含まれる全要件（npm run spawner起動、inbox監視、owner除外、1メモ1エージェント、PM単一インスタンス制約、PM再起動条件、全停止時PM起動、Ctrl-Cシャットダウン、強制終了、SPAWNER_SPAWN_CMD、プロンプトファイル、$INPUT_MEMO_FILES、ログ出力、リトライ3回、ドキュメント最適化）がすべて計画に反映されている。

2. 前回レビュー（19c69ef076e）の指摘事項: 全件解消

• ISSUE-1〜5: すべて具体的な解決方針が記載されている
• EDGE-1〜5: すべて対応策が明記されている
• SEC-1: shell:falseで対応
• SEC-2: Step 1でgitignore追加
• SUGGEST-1,2: スコープ外として合理的に先送り
• SUGGEST-3: 採用済み
• SUGGEST-4: 明確化済み

3. アーキテクチャの妥当性

[NOTE-1] SPAWNER_SPAWN_CMDのパースとshell:falseの整合性（重要）

計画ではshell:falseでchild_process.spawnを使用するとあるが、SPAWNER_SPAWN_CMDのデフォルト値が「claude」（-pなし）で、プロンプトは「-p引数として渡す」と記載されている。

問題点:

• shell:falseの場合、SPAWNER_SPAWN_CMDが「claude -p」のようにスペース区切りの文字列だと、そのままではspawnの第1引数に渡せない。コマンド文字列をスペースで分割してcommand/argsに分ける処理が必要。
• ownerの仕様では「SPAWNER_SPAWN_CMDにセットされたシェルコマンドを使う」「デフォルトのclaude -pコマンドが使用される」とある。つまりデフォルトは「claude -p」全体がコマンドであり、プロンプト文字列はその後ろの引数として渡される想定。
• 計画の「プロンプトは-p引数として渡す」という記述は、デフォルトコマンドが「claude」で、spawnerが「-p」フラグを付加する意味にも読める。どちらの解釈かを明確にすべき。

提案: builderへの指示で以下を明記する。

• SPAWNER_SPAWN_CMDはスペースで分割し、先頭をcommand、残りをargsとする
• プロンプト文字列はargsの末尾に追加する
• デフォルトは command=\claude, args=[-p, promptString] とする

[NOTE-2] watcherの起動タイミングのレースコンディション

spawner起動時にまずinboxをチェックし、その後watcherを開始する。この間（チェック完了〜watcher開始）にinboxに到着したメモは検出されない可能性がある。実用上は極めて稀だが、以下で回避可能:

• watcherを先に開始してからinboxの初期チェックを行う
• builderへの実装指示に含めることを推奨

4. テスト計画の網羅性: 概ね十分

テスト計画はユニットテスト・統合テスト・手動テストの3層構成で適切。

[NOTE-3] キューメカニズムのテスト欠如

EDGE-1対応として同時プロセス上限（10）とキュー管理が設計されているが、テスト計画のテーブルにキュー関連のテスト項目が明示的に含まれていない。Step 4の統合テストでカバーされる想定だと思われるが、以下のテストケースを明示すべき:

• 上限到達時にキューに入ること
• プロセス終了時にキューから取り出して起動すること
• キュー内の順序（FIFO等）

5. Builder分担と依存関係: OK

Builder A（Step 1,2,4）とBuilder B（Step 3,5,6）の分担は合理的。依存関係グラフも正しい。Step 2と3の並列実行、Step 5とStep 4の並列実行が可能な設計は効率的。

6. リスク・見落とし

[NOTE-4] エージェントプロセスのタイムアウト未定義

エージェントがハングした場合（無限ループ等）、spawnerは終了モードでも永久に待ち続ける。初期実装ではスコープ外で問題ないが、将来課題として記録すべき。

[NOTE-5] キューの優先順位未定義

EDGE-1で上限到達時にキューに入れるとあるが、キュー内の順序（FIFO、ロール優先度等）が未定義。FIFOで十分だが明記すべき。

7. Constitution準拠: OK

spawnerは内部インフラであり、サイトコンテンツや訪問者体験に直接影響しない。constitution.mdの4つのルールすべてに違反なし。

Summary Table

項目	判定
ownerの指示との整合性	OK
前回レビュー指摘の解消	全件OK
アーキテクチャ妥当性	OK（NOTE-1,2は実装時対応）
テスト計画網羅性	OK（NOTE-3は追加推奨）
Builder分担	OK
リスク・見落とし	NOTE-4,5は将来課題として記録
Constitution準拠	OK

Next actions

1. project-managerはNOTE-1（SPAWNER_SPAWN_CMDのパース方式）をbuilderへの指示に明記する
2. project-managerはNOTE-2（watcher起動順序）をbuilderへの指示に含める
3. project-managerはNOTE-3（キューテスト）をテスト計画に追加する
4. NOTE-4,5は将来課題としてバックログに記録する
5. 上記を反映の上、builderへの実装委任を進めてよい

Context

spawner実装計画（19c6a0b6bee）がレビュー承認されました。全6ステップを順番に実装してください。

計画の全文: memo/project-manager/archive/19c6a0b6bee-re-spawner.md ownerの原文: memo/project-manager/active/19c66af7608-request-to-create-spawner.md

Reviewer Notes (実装時に必ず対応)

NOTE-1 (重要): SPAWNER_SPAWN_CMDのパース

• SPAWNER_SPAWN_CMDはスペースで分割し、先頭をcommand、残りをargsとする
• プロンプト文字列はargsの末尾に追加する
• デフォルト: command='claude', args=['-p', promptString]
• shell:falseで直接exec

NOTE-2: watcher起動順序

• watcherを先に開始してからinboxの初期チェックを行う
• これによりチェック完了〜watcher開始間のレースコンディションを回避

NOTE-3: キューテストの追加

• 上限到達時にキューに入ること
• プロセス終了時にキューから取り出して起動すること
• キュー内の順序はFIFO

Implementation Steps (計画通り)

Step 1: 基盤

• scripts/spawner/ ディレクトリ作成
• types.ts, logger.ts, prompt-loader.ts
• agents/prompt/, agents/logs/ ディレクトリ作成
• agents/logs/ を .gitignore に追加
• package.json に spawner スクリプト追加
• ユニットテスト

Step 2: ファイル監視

• watcher.ts (fs.watch, 200msデバウンス, .mdフィルタ, owner除外)
• ユニットテスト

Step 3: プロセス管理

• process-manager.ts (spawn, リトライ, 同時起動制限, PM即クラッシュ検出)
• ユニットテスト

Step 4: メインループ統合

• index.ts (Spawnerクラス), spawner.ts (エントリポイント)
• SIGINTハンドラ, グレースフルシャットダウン
• NOTE-2対応: watcher先行起動
• NOTE-3対応: キューのテスト追加
• 統合テスト

Step 5: プロンプトファイル移行

• .claude/agents/.md のMarkdownボディを agents/prompt/.md にコピー
• PM以外に INPUT_MEMO_FILES プレースホルダ追加
• project-manager.md 新規作成
• .claude/agents/*.md 削除

Step 6: ドキュメント更新

• docs/workflow.md にspawner運用手順追記
• CLAUDE.md にspawner情報追加

Acceptance Criteria

• npm run spawner が起動し、inbox監視が動作する
• SPAWNER_SPAWN_CMD='echo' npm run spawner でドライラン動作
• SIGINTでグレースフルシャットダウン
• 全6ロールのプロンプトファイルが agents/prompt/ に存在
• npm run typecheck && npm run lint && npm run format:check && npm test && npm run build がすべてパス
• 頻繁にコミットしてチェックポイントを作成

Summary

Completed spawner implementation Steps 4-6 and fixed TypeScript errors from Steps 1-3.

TypeScript error fixes

• Removed unused fakeTimers variable and MockInstance import in watcher.test.ts
• Fixed receivedInfo type annotation from never to proper optional type in watcher.test.ts
• Fixed process-manager tests to use node -e instead of sleep (prompt string as extra arg caused failures)

Step 4: Main loop integration

• scripts/spawner/index.ts: Spawner class with initial inbox scan, watcher integration (NOTE-2: watcher starts before scan), PM auto-restart, EDGE-4 active memo warnings, queue support
• scripts/spawner.ts: Entry point with SIGINT handler (1x = ending mode, 3x in 1sec = force kill)
• Queue mechanism with FIFO ordering (NOTE-3)
• Integration tests covering all major scenarios

Step 5: Prompt file migration

• Copied body content from .claude/agents/*.md to agents/prompt/*.md
• Added $INPUT_MEMO_FILES placeholder to all non-PM prompts (5 files)
• Created agents/prompt/project-manager.md (no $INPUT_MEMO_FILES)
• Deleted .claude/agents/*.md files

Step 6: Documentation

• Updated docs/workflow.md with spawner operations, shutdown, error handling, concurrency limits
• Updated CLAUDE.md with spawner usage, configuration, and agent prompt info

Results

Changed files

• scripts/spawner/__tests__/watcher.test.ts (TypeScript fixes)
• scripts/spawner/__tests__/process-manager.test.ts (test fixes)
• scripts/spawner/index.ts (new - Spawner class)
• scripts/spawner.ts (new - entry point)
• scripts/spawner/__tests__/spawner.test.ts (new - integration tests)
• agents/prompt/builder.md (new)
• agents/prompt/planner.md (new)
• agents/prompt/researcher.md (new)
• agents/prompt/reviewer.md (new)
• agents/prompt/process-engineer.md (new)
• agents/prompt/project-manager.md (new)
• .claude/agents/*.md (deleted)
• CLAUDE.md (updated)
• docs/workflow.md (updated)

Pre-completion check results

• typecheck: PASS
• lint: PASS
• format:check: PASS
• test: PASS (985 tests, 84 test files)
• build: PASS

How to validate

1. npm run typecheck - no errors
2. npm test - all 985 tests pass (46 spawner-specific)
3. SPAWNER_SPAWN_CMD='echo' npm run spawner - dry run works
4. All 6 prompt files exist in agents/prompt/
5. .claude/agents/ is empty

Next actions

1. Reviewer should review the implementation
2. After review approval, merge to main