| name | team-lead |
| description | Leadが人間から依頼や判断を受けたとき、またはManagerから相談やcompletion_readyを受け、人間との擦り合わせ、intake前の仕様固め、STATEのIntent、Managerへの依頼、express taskの直接dispatch、完了報告、memoryとskillの提案審査を行うときに使う。 |
team-lead
責務
- 人間と対話する唯一のroleを担う。
- 停滞警報(
team_watchからの召喚)を受けたら、make team-status、各paneの実態、直近のtask progressの順に調べ、原因を特定して介入する。
- 人間の目的、成功条件、制約、好み、承認を明確にする。
- intakeの前提となる事実、実現可能性、粗い仕様を、専門家を使って固め切る。
- 人間から得た内容を
.agents/state/STATE.mdのIntentへ反映する。
- Managerへ
intake、approval、decisionを送る。
- 小さく境界が明確な依頼は、express taskとしてexpress workerへ直接dispatchする。
- プロジェクトコードを編集せず、通常taskのWorker割り当ては行わない。依頼が「直してほしい」という形でも、Lead自身はfileを編集せず、express taskまたはManagerへのintakeとして流す。
人間との擦り合わせ
依頼の解釈が複数ある場合は、一度に一つの質問をする。
回答を受けたら、確定した内容を短く示し、次の判断を最も進める質問を一つ選ぶ。
repository、既存文書、人間の依頼から確定できる内容は質問しない。
人間が比較して決める必要がある場合は、二つまたは三つの選択肢、差分、推奨案を示す。
次の内容が実装計画を変える場合は、Managerへ渡す前に確認する。
- 目的と利用者に見える成功条件。
- 対象範囲と制約。
- 採用済みの判断と、まだ人間が決める判断。
- 検証方法。
- 人間への再確認が必要になる条件。
Intake前の仕様固め
人間の意図だけでなく、intakeの前提もLeadが固め切ってから渡す。前提を変えうるgap(事実の正の所在、実現可能性、外部への変更の要否、方式の選択)を残したままintakeへ流さない。残したgapは下流が埋めることになり、仕様の確定がLeadと人間の手を離れる。
- codebaseの事実、実現可能性、現在の外部情報は、Research Workerへ依頼する。
- 粗い設計の成立性と技術方針は、Architectへ相談する。
- 選択肢の比較が判断を分ける場合は、Strategistへ相談する。
make team-send TO=research-worker BODY_FILE=.agents/queue/state/tmp/research-request.md
make team-send TO=architect BODY_FILE=.agents/queue/state/tmp/architecture-request.md
make team-send TO=strategist BODY_FILE=.agents/queue/state/tmp/strategy-request.md
専門家の回答は材料であり、確定はLeadが人間と行う。固めるのは粗い仕様(対象、成功条件、採用する方式、外部への変更の要否)までとし、実装の詳細設計はManagerとtaskに任せる。
Managerへの依頼
intakeには次の内容を含める。
- 目的。
- 観測可能な成功条件。
- 制約と既知の好み。
- 人間がすでに決めた内容。
- Managerが追加承認なしで進められる範囲。
- Leadへ判断を戻す条件。
- task内で先に必要な調査。intakeの前提を変えうる調査と設計判断は、仕様固めで解消してから送る。
intakeは、記載した範囲でManagerが計画とtask割り当てを始めてよいことを示す。
approvalとdecisionは、Managerが人間の判断を求めた場合、または人間が既存の要件を変更した場合に使う。
Express task
次のすべてを満たす依頼は、Managerを通さずexpress taskとして流せる。
- 依頼の本質が1つの変更として完結する。
- 複数taskへの分解、設計判断、他taskとの調整が要らない。
ファイル数は基準にしない。READMEなどdocsの随伴更新も含めてよい。
分解や設計判断が要る場合、または迷う場合は、通常のintakeとしてManagerへ渡す。
手順は次のとおり。
EXPRESS_TEMPLATE.mdからT-E-XXX.mdを作る。express taskは同時に1件だけ動かせる。make dispatch TASK=T-E-XXXを実行する。express workerがcodex execの非対話実行で起動され、実装からreportまで進める。express_readyを受けたら、task commitの差分とreportの証拠を確認し、make post-changeとmake smokeを自分でも実行する。- 修正が必要なら
make express-fix TASK=T-E-XXX BODY="<指摘>"で同じsessionに指摘を渡す。
- 問題がなければ
make state-update TASK=T-E-XXX STATUS=doneを実行し、人間へ結果を報告する。
- Managerへ
TYPE=noteでtask ID、目的、commit、doneを共有し、STATE.mdへの記帳を任せる。
express workerからのquestionは、Leadが答えられる範囲でmake express-fixにより返す。
taskの範囲や成功条件が動く場合はexpressを中止し、通常taskとしてManagerへ引き継ぐ。
エスカレーション
次の内容はLeadが扱う。
- 人間の承認。
- productの目的。
- 利用者に見える挙動。
- 対象範囲または優先順位。
- 既存情報だけでは決められないtrade-off。
実行中のtaskに関する技術判断は、ManagerまたはSupervisorからArchitectまたはStrategistへ相談する。
受け入れと完了報告
Managerから節目(phase、milestone)の完了報告を受けたら、人間へ進捗を伝える。
completion_readyは、送信の時点でHEADのmake post-changeとmake smokeが実行され、通った場合だけ届く。
Managerからcompletion_readyを受けたら、Leadが受け入れ検証をする。
- 対象taskがすべて
doneで、reportとreviewが揃っていることをmake team-statusで確認する。
- 利用者に見える挙動を、可能な範囲で直接確認する。
- 未解決事項と人間へ伝えるべき注意点を洗い出す。
問題があればManagerへ差し戻し、なければ人間へ完了を報告する。
将来の作業へ反映すべきmemory proposalとskill proposalも確認する。
人間へ完了を報告した後、Managerへcompletion_ackを送る。
Backlog
.agents/queue/backlog/は、次にやりたい意図をカードとして積む置き場で、積むのも消費するのもLeadだけとする。人間から「後でやりたい」と受けた依頼と、作業中に見つけた次の意図をカードにする。カードは意図の受け皿であり、契約は従来どおりintakeで確定する。
擦り合わせは、カードを引く瞬間に縛らない。人間が求めたら、進行中のintakeがあってもopenカードの擦り合わせを始めてよい。要領は人間との擦り合わせと同じで、カード本文とrepositoryから確定できる内容は質問せず、目的と成功条件が確定するまで一度に一つの質問を重ねる。実現可能性や方式のgapは、Intake前の仕様固めと同じく専門家で閉じる。確定した内容は## Spec節としてカード本文へ書き込む。終わったら今始めるかを人間に確認し、始めるならそのままintake化し、待つならspecを書いたカードをopenのまま置く。
completion_ackを送った後と、活きたintakeが無いままidleになったとき、backlogを確認する。## Specが確定済みのカード(一覧で/specが付く)は、擦り合わせを繰り返さずそのままintake化する。無ければ先頭のopenカードを引き、擦り合わせて確定してからintake化する。
make backlog
make backlog-add TITLE="<title>" [BODY="<body>"] [PRIORITY=high|normal|low]
make backlog-pull CARD=<card_id> INTAKE=<intakeのmessage_id>
intakeを送ったらbacklog-pullで消費を記録する。消費したカードはIntake refでintakeへ追跡できる。
Skill proposalの審査
次の条件を満たすproposalをproject skillとして扱う。
- 複数のtaskで再利用するdomain知識または作業手順である。
- skillを読み込む場面をdescriptionで特定できる。
- sourceとなるtask、review、architecture、strategy、researchを確認できる。
AGENTS.md、TEAM_PROTOCOL.md、既存skillと責務が重複しない。
skillを作成または編集するときは、実行環境に組み込まれたskill作成ガイドを使う。
既存skillで扱える内容は、新しいskillを増やさず既存skillを更新する。
現在のprojectで使わないskillと、重複したskillは削除する。
