teamwork-parent

teamwork-parent スキル

このセッションは以後「チームワークセッション」として、sub-issueの分担・進行管理に徹する。実際のコード実装は各sub-issue用の子ワークツリーに委ね、このセッション自身はコードを書かない。

Step 1: 計画とユーザー承認

1. まず自分自身のワークツリーのトレイ通知をオフにする(承認を待つ必要はない。自分のノイズを止めるだけで他ワークツリーの通知には影響しないため):

   oretachi_set_tray_notification(project_dir: <自分の作業ディレクトリ絶対パス>, enabled: false)
   

2. 対象issueの本文・既存コメント・既存sub-issue(あればgh issue list等で確認)から、タスク分担と依存関係を洗い出す。sub-issueがまだ存在しない場合は、分割案を作成し「sub-issueを新規作成するか」を後続の承認要求に含める(この時点では作成しない)。
3. 各sub-issueに決定的なブランチ名を採番する(例: issue-<番号>)。検証sub-issue等、完了前にユーザー確認が必要なものを識別する。
4. 3章の手順で計画フロー図をartifactとして作成する(状態はすべてnot_startedでよい)。この計画フローartifactが以後の唯一の進捗管理データになる(別途マークダウン等は作らない)。
5. ユーザーに承認を求める。承認内容には次を含める:
   • sub-issue新規作成の要否(対象がある場合)
   • 計画フロー(依存関係・検証ポイント・ユーザーが介入するタイミング) 承認が得られるまでStep2(oretachi_add_taskの呼び出し)を行わない。

Step 2: 子ワークツリー作成(承認不要、開始・完了トリガーで自動)

依存が無い、または既に解消済みのnot_startedのsub-issueについて、承認後は都度ユーザーに確認せず以下を実行する:

1. oretachi_add_taskを呼ぶ。promptの冒頭に必ずteamwork-childスキルの読み込み指示を入れ、本文はsub-issueのURL参照のみに留める(issue本文を転記しない):

   oretachi_add_task(prompt: "teamwork-child スキルを読み込んでから対応してください。\nSub-issue: <URL>")
   

2. oretachi_add_taskは非同期発火のため、ターン境界を挟んでoretachi_get_worktree_status(query: <採番したブランチ名>)をポーリングし、実際に作成されたワークツリー名を確認する。
3. oretachi_subscribe_worktree(target: <確認したワークツリー名>, event_kinds: ["worktree.closed", "worktree.created", "worktree.message"])で購読する。
4. 4章の手順で計画フローartifactのdata/flowモジュールを更新し、対象タスクのstatusをin_progressにし、branchが実際の値と一致していることを確認する。

Step 3: 子ワークツリーイベントへの対応

• worktree.closed: 対応するsub-issueのstatusをdata/flow更新でdoneにする。依存が解消されて着手可能になったnot_startedのsub-issueがあれば、Step2の手順で次の子ワークツリーを承認を求めず自動作成する。
• worktree.message: oretachi_poll_inboxで内容を確認し、oretachi_ack_messageで既読化する。
  • issueコメントのURLのみの場合は必要に応じて参照し、ユーザーの判断が必要な内容かどうかを見極める。
  • ユーザー判断が必要な内容だけを提示し、それ以外は自動で流れを継続する。
• ユーザーの判断・操作が必要になったときは必ずnotify_worktreeを呼ぶ。 Step 1 でトレイ通知をオフにしているため、テキストを出力するだけではユーザーは気付けない。notify_worktreeはトレイ通知オフでも常に通る唯一の呼び戻し経路。
• すべてのイベントを4章の手順でdata/flowのMESSAGESに追記する(新しい順に先頭へ追加)。
• 状態に迷ったらoretachi_list_subscriptionsで購読状態を確認してよい。