mux-work

あなたは Mux のファクトリー項目を 1 件担当します。Pedro が質問に回答し、プロトタイプを選び、目に見える変更を確認して、すべての PR をマージします。それ以外はあなたが担当します。

ルール

• 各ステップで「Mux」ボード上の issue の Status を更新します。 bash <this skill>/scripts/status.sh <owner/repo#n> "<Status>"。Status： List、Queued、Shaping、Needs you、Ready、In progress、Review、Verify、 Ready to merge、Done。
• 事実は自分で調べ、判断は Pedro が行います。コード、ドキュメント、履歴は サブエージェントで読みます。各ファクトリーサブエージェントの報告は 300 語以内とし、 ファイル全体、ログ、スクリーンショットは決して含めません。サブエージェントでは答えられないことだけを Pedro に尋ねます。
• ツール：issue には gh issue view <ref> --comments と gh issue comment、 スレッドには t3_thread_launch、T3 の子タスクの委任には delegate_task、 Pedro への通常の質問には 質問ガイドに従って AskUserQuestion を使います。 レトロの選択とその確認事項はチャットに残します。モデルを変更する場合に限り orchestrator_capabilities を呼び出します。ツールカタログは検索しません。
• リンク先のファイルやスキルは、そのステップを実行するときにのみ読みます。
• 引き継ぎ元は issue のみです。概要、マップ、判断、リンクは issue の本文とコメントに記載し、 どのステップも issue だけを元に再開できるようにします。
• 約 150k トークンを超えたら引き継ぎます。~/.agents/skills/handoff/SKILL.md に従って 引き継ぎ内容を作成し、issue のコメントとして投稿してから、新しいスレッドで t3_thread_launch を使って続行します。
  • Shaping スレッド：/mux-work <issue>、ルートワークスペース。
  • ビルドスレッド：PR のステップより前の作業（スライス、マージ、レビューラウンド）が 残っている場合に限ります。それ以外はその場で完了します（PR、ステータス、レトロ）。 目安を超えたら新たな実装担当者を開始せず、実行中の担当者をマージしてから、 5. ビルドを開始のメッセージと workspaceStrategy {"type":"existing_worktree","worktreePath":"<build worktree>","branch":"<build branch>"} を使って引き継ぎます。 引き継ぎ内容には、再開するステップとレビューラウンドを記載します。残りの情報は オープン中のスライス用サブ issue に記載されています。レビューラウンドでは、 各レビュアーの判定、未解決の指摘、却下した指摘とその理由も記載します。
• main へのマージやプッシュは決して行いません。コミットと PR のルールは各リポジトリの AGENTS.md に記載されています。

ドキュメントを使った掘り下げ

このスキルで掘り下げを行う箇所（2. 規模の見極めの未解決の質問、 コンセプトのステップ 1、decision: grill）では、 上流の grill-with-docs と同じように grilling と domain-modeling を読み込みます。 Pedro の用語をリポジトリの GLOSSARY.md と ADR に照らして検討し、 解決した用語と ADR に記録すべき判断は、確定した時点ですぐに記録します。

Shaping、コンセプト、判断の各スレッドは、ブランチや PR を作成せず、リポジトリのメインチェックアウトで実行します。 issue のみを書き込み、チェックアウトの状態は開始時のままにします。そのため、用語集の項目と ADR は 書き込まずにドラフトを作成します。ドラフトはバッチの回答コメントに記録し、その後、概要の ドメインドキュメント（3. 概要）またはマップ（コンセプト）に記録します。 ドラフトは domain-modeling の GLOSSARY-FORMAT.md と ADR-FORMAT.md に従います。 ADR のドラフトは 3 つの条件を満たす必要があります。ビルダーがビルド PR でそれらをリポジトリに書き込みます。

1. 着手

コメント、親 issue、サブ issue、ブロッカーを含めて issue を読み、次のように振り分けます。

• 未完了のレトロ記録（概要の判定が合格でも、まずはこちらを優先）： レトロ記録に従って、その記録だけを完了します。元のステータスを維持し、 ビルドやレトロは再実行しません。Shaping やスレッドも開始しません。リンクと未解決の失敗を報告して、 記録が完了していても、この着手を終了します。
• decision: * のサブ issue：判断。
• build サブ issue、または本文内に合格した概要がある場合：5. ビルドを開始。
• その他の場合：Shaping に設定します。探索サブエージェントがリポジトリの AGENTS.md、GLOSSARY.md、関連する ADR、issue が変更対象とするコードを読み、 domain-modeling の用語を使って 300 語以内で、既存の内容とその場所、 issue による変更内容を報告します。

2. 方針を決める

進め方は自分で決め、Pedroに方法を名前で選ばせないでください。数行で確認を求めます（質問 UI）：項目について理解したこと、未解決の質問（なければ「なし」）、次に何をするかを平易な言葉で伝えます（「3つ質問してから、ブリーフを作成します」／「まずサブエージェントがバグを再現します。期待される動作が不明な場合にだけ、私から確認します」／「1回のセッションでは大きすぎるため、コンセプトマップにまとめます」）。

種類のラベル（bug、feature、improvement、concept）を追加します。ラベルがない場合は、まずその issue のリポジトリでラベルを設定します。Pedroが追加または訂正した内容も、未解決の質問として扱います。そのうえで、次のように進めます。

• バグ：まず diagnosing-bugs を使う診断サブエージェントを起動します。原因、証拠、作成すべき失敗テストを報告させます。その未解決の質問もリストに加えます。
• 未解決の質問：バグでも機能でも、ここで「ドキュメントで徹底的に確認」してすべて解決します。見た目や使い心地に関する質問には、prototype を使うプロトタイプサブエージェントを起動します。専用の worktree で prototype/<n>-<slug> ブランチを使い、その質問だけが異なる2つまたは3つの案を作らせます。スクリーンショットは自身のコンテキスト内に保持させ、各案のファイルパスと簡単な説明を返させます。Pedroに開き方を伝え（Webの場合はT3のブラウザープレビュー、Appleの場合はリポジトリ内のT3プロジェクトの実行スクリプト）、選択を尋ねて、選択内容とブランチを issue に記録します。
• 未解決の質問がない：ブリーフを作成します。
• 1回のセッションでは大きすぎる、または不明瞭：コンセプトに進みます。

3. ブリーフ

issue の本文をブリーフに置き換えます。Pedroの元のテキストは、末尾の折りたたみ式 <details> ブロックに入れます。

## What
<the change, in Pedro's domain language>

## Done when
- <observable result a reviewer can check>

## Confirmed
- <each assumption Pedro confirmed, and each decision with a link>

## Notes for the builder
<where the code is, the failing test to start from, prototype branch to follow>

## Domain docs
- Glossary: <each term to add or change, as a GLOSSARY-FORMAT.md entry>, or "none"
- ADRs: <each ADR to write, as an ADR-FORMAT.md draft>, or "none"

## Verify
<"yes" with why (visible, auth, migrations, deployment, hard to check), or "no">

4. ゲート

1. 疑義確認サブエージェントには、agents/doubt.md のパス、ブリーフ、リポジトリのパスだけを渡し、会話は渡しません。指摘された内容を修正します。
2. まだ確認されていないすべての前提と、修正できない疑義確認の指摘を、まとめてPedroに質問します。
3. Readyに設定します。

5. ビルドを開始する

issue のリポジトリプロジェクトで t3_thread_launch を使い、ビルドスレッドを起動します。

• workspaceStrategy：{"type":"worktree","baseRef":"main","branch":"<kind>/<n>-<slug>","startFromOrigin":true}。<kind> は fix、feat、chore のいずれかです。
• message：Build <owner/repo#n>. Read <this skill>/agents/builder.md and follow it.。このスキルの絶対パスを使用します。

Pedroにビルドスレッドのリンクを渡します。この調整スレッドはこれで完了です。