teamwork-child

teamwork-child スキル

このワークツリーは親issueのsub-issueとして作成された。実際の作業内容・進め方は、通常どおり他のスキル・エージェント設定・ユーザー指示に従ってよい。このスキルはそれらを一切上書きせず、実行フローも規定しない(義務1のdescriptionセットのタイミングだけが唯一の例外)。以下の4つの義務のみを追加で負う。

最初の1手はoretachi_set_description。 sub-issueの内容を把握したら、調査・設計・実装のどれに入るよりも先にこれを呼ぶ(義務1)。ここを飛ばしたまま先へ進むことは、このスキルでは認められていない。

義務1: 対応開始前のdescriptionセット

このsub-issueへの対応を開始する前に、必ずoretachi_set_descriptionでこのワークツリーの1行説明をセットする。 descriptionが空だとメインウィンドウのカード一覧でこのワークツリーが何をしているのか分からなくなる。

oretachi_set_description(project_dir: <このワークツリーのルート絶対パス>,
  description: "<このsub-issueで進める作業全体の目的を1行で>")

呼ぶタイミングは「sub-issueの内容を把握した直後」。 gh issue viewで本文を読んだ、あるいは最初から本文がプロンプトに入っていた —— どちらであれ、内容が分かった時点で次のツール呼び出しがこれになる。把握したあとに別の調査へ進んではいけない。

• plan modeかどうかを問わない。 auto modeなどプランを挟まずいきなり実装へ入る場合は、最初のファイル変更より前にセットする。plan modeの場合はプラン承認直後(実装の最初の1手)にセットする。承認前に呼ぶ必要はない —— このツールはreadOnlyHintを持たないため、plan mode中は許可プロンプトで自動進行が止まる。
• 既にdescriptionが入っていても、今回のsub-issueの内容と食い違っていれば上書きする(前の作業の使い回しワークツリーや、親が仮の値を入れている場合がある)。oretachiはユーザー入力のたびに現在のdescriptionをリマインダで示してくる。「未設定です」と出ていれば未実施のサインなので必ず従う。何か入っている場合も、それが今回の目的とずれていないかを確かめる(内容が入っていること自体は正しさの保証にならない)。
• sub-issueのタイトルをそのまま流用してよいが、15〜40文字程度の1行に収める。
• セットするのは作業全体の目的であり、サブタスクの進行やレビュー対応では更新しない。目的そのものが変わったときだけ更新する。
• セルフチェック(保険): 最初のコミットを作る前と、義務2で親へ報告する前に、「自分はoretachi_set_descriptionを呼んだか?」を確認する。呼んでいなければその場で呼ぶ。ただしこれは取りこぼしを拾うためのものであり、この時点で初めて呼ぶのは義務1違反である。

義務2: 報告

親issueまたは現在のissueへの報告事項が発生したら、通常の報告作業(issueコメント投稿等)に加えてnotify_worktreeで親ワークツリーへ通知する。

• issueへコメントした場合: 本文は省略し、コメントのURLのみをbodyに入れる。

  notify_worktree(worktree_name: <自分のワークツリー名>, kind: "worktree.message",
    body: "<コメントURL>")
  

  • kind: "worktree.message"を指定することで、親issueワークツリーが購読している場合に配送される(宛先は購読側=親issueワークツリーが決めるため、worktree_nameは表示用であり配送先には無関係)。
  • 自分のワークツリー名が分からない場合はoretachi_get_worktree_status(query: <git branch --show-current の結果>)で確認する。
• ユーザーが購読機能を認識しており、issueコメントを介さず直接ワークツリーへの報告を指示された場合に限り、notify_worktreeの通知のみでよい(issueコメント投稿は不要)。

義務3: 停止条件