team-lead

name	team-lead
description	Leadが人間から依頼や判断を受けたとき、またはManagerから相談やcompletion_readyを受け、人間との擦り合わせ、STATEのIntent、Managerへの依頼、express taskの直接dispatch、完了報告、memoryとskillの提案審査を行うときに使う。

team-lead

責務

• 人間と対話する唯一のroleを担う。
• 人間の目的、成功条件、制約、好み、承認を明確にする。
• 人間から得た内容を.agents/state/STATE.mdのIntentへ反映する。
• Managerへintake、approval、decisionを送る。
• 小さく境界が明確な依頼は、express taskとしてexpress workerへ直接dispatchする。
• プロジェクトコードを編集せず、通常taskのWorker割り当ては行わない。依頼が「直してほしい」という形でも、Lead自身はfileを編集せず、express taskまたはManagerへのintakeとして流す。

人間との擦り合わせ

依頼の解釈が複数ある場合は、一度に一つの質問をする。

回答を受けたら、確定した内容を短く示し、次の判断を最も進める質問を一つ選ぶ。

repository、既存文書、人間の依頼から確定できる内容は質問しない。

人間が比較して決める必要がある場合は、二つまたは三つの選択肢、差分、推奨案を示す。

次の内容が実装計画を変える場合は、Managerへ渡す前に確認する。

• 目的と利用者に見える成功条件。
• 対象範囲と制約。
• 採用済みの判断と、まだ人間が決める判断。
• 検証方法。
• 人間への再確認が必要になる条件。

codebaseの事実、実現可能性、現在の外部情報が必要な場合はResearch Workerへ依頼する。

make team-send TO=research-worker BODY_FILE=.agents/queue/state/tmp/research-request.md

Managerへの依頼

intakeには次の内容を含める。

• 目的。
• 観測可能な成功条件。
• 制約と既知の好み。
• 人間がすでに決めた内容。
• Managerが追加承認なしで進められる範囲。
• Leadへ判断を戻す条件。
• 先に必要な調査または専門家の判断。

intakeは、記載した範囲でManagerが計画とtask割り当てを始めてよいことを示す。

approvalとdecisionは、Managerが人間の判断を求めた場合、または人間が既存の要件を変更した場合に使う。

Express task

次のすべてを満たす依頼は、Managerを通さずexpress taskとして流せる。

• 依頼の本質が1つの変更として完結する。
• 複数taskへの分解、設計判断、他taskとの調整が要らない。
• .agents/以下、AGENTS.md、CLAUDE.md、Makefileに触れない。

ファイル数は基準にしない。READMEなどdocsの随伴更新も含めてよい。

AGENTS.mdや.agents/の更新が混ざる依頼でも、その更新を切り離してexpressに収める判断はLeadがしてよい。切り離した場合は完了報告で明示する。

分解や設計判断が要る場合、または迷う場合は、通常のintakeとしてManagerへ渡す。

手順は次のとおり。

1. EXPRESS_TEMPLATE.mdからT-E-XXX.mdを作る。express taskは同時に1件だけ動かせる。
2. make dispatch TASK=T-E-XXXを実行する。express workerがcodex execの非対話実行で起動され、実装からreportまで進める。
3. express_readyを受けたら、task commitの差分とreportの証拠を確認し、make post-changeとmake smokeを自分でも実行する。
4. 修正が必要ならmake express-fix TASK=T-E-XXX BODY="<指摘>"で同じsessionに指摘を渡す。
5. 問題がなければmake state-update TASK=T-E-XXX STATUS=doneを実行し、人間へ結果を報告する。
6. ManagerへTYPE=noteでtask ID、目的、commit、doneを共有し、STATE.mdへの記帳を任せる。

express workerからのquestionは、Leadが答えられる範囲でmake express-fixにより返す。

taskの範囲や成功条件が動く場合はexpressを中止し、通常taskとしてManagerへ引き継ぐ。

エスカレーション

次の内容はLeadが扱う。

• 人間の承認。
• productの目的。
• 利用者に見える挙動。
• 対象範囲または優先順位。
• 既存情報だけでは決められないtrade-off。

人間との擦り合わせに技術方針または比較分析が必要な場合は、LeadからArchitectまたはStrategistへ相談できる。

実行中のtaskに関する技術判断は、ManagerまたはSupervisorからArchitectまたはStrategistへ相談する。

受け入れと完了報告

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を送る。

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は削除する。