factory

factory

トラッカー、PR、チェック、レビュー、デプロイの証拠から状態と次のスキルを導きます。レポートはステートレスです。実行ではチェックポイントが保持されます。

入力

• モード — 最初の引数で指定する report（デフォルト）または run です。run に入るのは、ユーザー自身の依頼にそう明記されている場合だけです。状況を尋ねる質問では run に入りません。
• 参照先 — 次のいずれかです。仕様（PRD）のイシュー（PRWL-100、GitHub のイシュー URL または番号）、チケット、PR 番号または URL、あるいはまだ仕様のないアイデアを表す start です。run ではラベル名（/factory run automate）も指定でき、そのラベルが付いた未解決のイシューすべてが対象です。指定がない場合は確認します。現在のブランチから推測してはいけません。無人で開始するときにレビュアーに関する質問に答える場合は、任意で reviewer=<harness>/<provider>/<model> を指定できます。
• 正とするトラッカー — Linear（Linear MCP 経由）または GitHub（gh 経由）です。ワークスペースの AGENTS.md から確認します。不明な場合は確認します。
• ステージングブランチ — デフォルトは staging です。このブランチに依存する状態を確認する前に、git ls-remote --heads origin <branch> で存在を確認します。

ルール

• レポートモードは読み取り専用です。 トラッカー、gh、git を読み取ります。リモートには何も書き込まず、ファイルも編集しません。状態の変更は、指定されたスキルに任せます。
• レポートモードは提案するだけで、自動的に連続実行しません。 次のスキルを正確な呼び出し方法とともに示したら、そこで停止します。ユーザーが実行します。ユーザーが開始した run モードだけは、提案を実行に移します。
• ゲートの判定にはステータスの文言ではなく証拠が必要です。 references/states.md にある観測可能なシグナルを満たした場合にのみ、ゲートを通過します。必要な場合は、head に対する CI の証拠（または、必須のローカル証明を伴う、該当する CI がないことを示す正式なポリシー）、head に紐づく QA／リスクの証拠、マージコミットに対するデプロイ監視の証明が必要です。ラベル、チャットでの主張、「CI は問題ありません」という発言ではゲートを通過できません。
• すべての証拠は head SHA に紐づきます。 レビュー、QA、リスクの証拠として認められるのは、PR の現在の headRefOid に対するものだけです。承認が有効なのは、レビューの commit.oid が head と一致する場合だけです。新たに push すると、PR は CI の段階に戻ります。
• ステージングが上限です。 READY_FOR_OWNER は最終状態です。本番デプロイ、本番 PR／マージ、フラグのロールアウトを提案してはいけません。デフォルトブランチへの変更は、明示的に許可された非本番の local 配信を除き、オーナーのみが行えます。それ以外の場合はオーナーを明記します。
• シグナルを読み取れない場合は停止します。 表で必要なシグナルを読み取れない場合（トラッカーへのアクセス拒否、デプロイワークフローが見つからないなど）は、不足している情報を示して UNKNOWN と報告します。より進んだ状態を推測してはいけません。gh クエリが失敗またはエラーになった場合は不明として扱います。空の結果、合格、または正常と判断してはいけません。コマンドとそのエラーを報告します。
• 帰属情報は一切付けません。 references/records.md の レビュアーの出所情報 を除き、すべての出力で共同作成者、AI、ツールへの帰属を示してはいけません。
• フェーズの移行時は、references/session-handoff.md にある、移植可能なステータスと待機の契約に従います。

ワークフロー

1. 作業単位を特定する

参照先をもとに、配置対象となる作業単位のリストを作成します。仕様の場合は、すべてのサブイシュー（未解決・解決済みの両方）に展開し、件数を明記します。チケットまたは PR の場合は、それぞれが 1 つの単位です。各チケットについて、次のコマンドまたはトラッカーのリンク済み PR フィールドを使って PR を探します。gh pr list --search "<issue-id>" --state all --json number,headRefName,baseRefName,state クローズ済みやマージ済みのチケットもリストに残します。STAGING の状態である可能性があるためです。qa-escape マーカーが not-deployed 以外の場合、そのチケットは、それより新しい PR のうち最も新しいものを使って配置します。

2. シグナルを読み取る

ユニットごとに、状態テーブルが必要とする情報だけを読み取ります。チェックを解釈する前に、references/ci-policy.md を適用します。このファイルでは、既知の CI なしのポリシーと、保留中、失敗、必須チェックの欠落、ポリシーを読み取れない場合を区別しています。

gh pr view <pr> --json state,isDraft,baseRefName,headRefOid,mergeCommit,mergedAt,reviewDecision,reviews,statusCheckRollup,autoMergeRequest,body,comments,commits
gh pr diff <pr> --name-only
gh run list --workflow <deploy-workflow> --branch <staging-branch> --json headSha,status,conclusion,url
gh issue view <issue> --json state,comments

未解決のレビューコメントスレッドは、ページネーション対応の GraphQL reviewThreads クエリで読み取ります。マージ前にスレッドの状態を読み取れない場合は UNKNOWN です。

PR と issue の記録から、QA／リスク／デプロイのエビデンスを references/records.md を使って読み取ります。Linear のコメントは、読みやすい見出しとフィールドを使います。従来の記録も引き続き読み取れます。必要なリビジョンについては、最も新しい有効なエビデンスを採用します。BUILDING を解除する Acceptance criteria の判定には、head を明記する必要があります。まず本文を読み、本文にない場合は、Change: の SHA が head と一致する最新の ## QA handoff を読み取ります。古い head の受け入れ判定は対象になりません。

3. 各ユニットを分類する

シグナルを references/states.md のテーブルに上から順に照らし合わせます。条件を満たす最初の行が状態になります。状態の順序は、OUTCOME、TICKETS、QA_RETURNED、BUILDING、CI_STUCK、CI、QA_STUCK、CHANGES、QA、REVIEW、HUMAN_REVIEW、MERGE、READY_FOR_OWNER、DEPLOY_FAILED、STAGING、そして UNKNOWN です。

4. ゲートを確認して、次のスキルを1つ選ぶ

各ユニットについて、現在の状態から抜けるためのゲートと、そのエビデンスがあるかどうかを示します。テーブルの next 列から、ユニットごとに次のスキルを1つだけ選びます。そのスキルの実行時またはコード変更時に使うワークツリーを明記します。PR の場合は <project-repo>/.worktrees/pr-<n>、エスケープの場合は .worktrees/qa-escape-<issue> です。複数のユニットを含む仕様では、ブロック中のユニット（QA_RETURNED、DEPLOY_FAILED、CI_STUCK、QA_STUCK、CHANGES、UNKNOWN）を、順調なユニットの進行より先に提案します。順調なユニットは Since が最も古いものから並べます。1つの状態に3日を超えてとどまっているユニットには stalled とフラグを付けます。ゲートとスキルが同じユニットは、1つの提案にまとめます。

5. 報告して終了する

以下の出力を表示します。報告モードはここで終了します。ユーザーが不在でも、提案したスキルを実行しないでください。次の対応はユーザーに委ねられます。

実行モード

ユーザーの /factory run <reference> により、チェーン全体が承認されます。まず references/run.md を読みます。そこにある Stage map には、ユニットが初めて該当状態に達したときに読む後半工程のファイル（references/review-and-delivery.md、[references/returned-by-qa.md](references/returned-by-qa.md）が記載されています。

ディスパッチ前にブリーフを読み、続行時には受領記録を読み、QA 中にはドラフトを読みます。

1. 受付。 ステップ 1 のとおりにユニットを特定し、ビルダー／ランタイム作業の前に Triage を適用します。要件が完全に定義されたチケットには、実行権限のもとで対象を限定した適格性遷移を適用できます。不明瞭な作業は保留します。不足している基準を投稿するのは、既存の成果を言い換える場合に限ります。Start を適用してビルダーを引き継ぎます。すでに回答済みでない限り、レビュアーへの質問だけをします。

   レビュアーから回答がない場合 → セットアップと再開用プロンプトを提示して停止します。再開時には選択内容を維持します。この受付の後、実行中に質問することはありません。

2. ループ。 アクティブな子プロセスを待ち、自動的に続行します。ワーカーのターン終了は、ファクトリーの停止を意味しません。Dependency-aware scheduling に従います。独立したユニットは、容量の範囲内で並行して進められます。統合は親が順次行います。準備が整った各ユニットについて、配置し（ステップ 2〜4）、Stage map に従ってその Next を実行し、再度配置します。記録を残し、Lessons を適用します。ユニットごとに、ステータスを In Progress にし、専用のワークツリーと Task stack を用意し、選択したバックエンドでビルダーワーカーを実行し、QA ワーカーでエージェント型 QA を実施し、PR と CI を用意し、レビュアーとビルダーの間で Review loop を行い、リスクレビュー、Merge、ステータスを In Review とした Handover、Cleanup、Promotion、Staging を実施します。セットアップまたはローカルランタイムのブロッカーについては、references/readiness-and-recovery.md を読みます。Loading a stage skill に復旧と停止に関する規則があります。

3. 保留。 高リスクレビュー、上限到達、報告者のみが把握する事実など、人による対応を待つユニットは、根拠を添えて保留し、実行を続けます。追跡対象の Compose ファイルも Issue 本文も編集せず、Issue もクローズしません。

4. 実行レポート。 自動で行える作業がなくなったら、出力テーブル、保留中のユニットに関する標準ハンドオフ、作成した基準、Production readiness、Lessons を出力します。

出力

Factory — <reference>  (<n> units)

| Unit | PR | State | Since | Gate evidence | Next |
| ---- | -- | ----- | ----- | ------------- | ---- |
| #418 | #87 | CI | 2026-10-02 14:10 | run 9912 failed on a1b2c3d (unit-tests) | /ci-loop 87 |
| #419 | #88 | HUMAN_REVIEW | 2026-09-28 09:02 (stalled) | risk-review tier=high on 4e5f6a7 (migration) | engineer review — no skill |
| #420 | #85 | READY_FOR_OWNER | 2026-10-01 17:45 | deploy run 9890 success on merge 7c8d9e0, smoke passed | owner promotes — factory ends |

Escapes: 2 qa-escape on this spec — 1 after agentic-qa verified (honesty gap: #418 missed-empty-state)
Next: /ci-loop 87

ユニットごとのテーブル行は最大 1 行です。Gate evidence には実行 ID、SHA、またはコメントを記載します。「pass」だけを記載してはいけません。Since はユニットを配置したシグナル（ヘッドへのプッシュ、マーカー、実行）のタイムスタンプです。この実行の記録を読み取ってください。締めくくりの Next: 行には、最も緊急性の高い提案を 1 つだけ記載します。ユニットが UNKNOWN の場合、その行に不足しているシグナルを記載します。Escapes: 行には、仕様内で再現された qa-escape マーカーの数（クラス not-a-regression は除外）と、そのうち PR（pr=）を示すものの数を記載します。ここで数える PR は、最終ヘッドに verified の agentic-qa マーカーが付いているものです。この件数が誠実性のギャップを示します。該当するものをすべて列挙してください。

完了条件

• 仕様内のすべてのユニットがテーブルに含まれ、出力したユニット数が、トラッカーから読み取ったオープンとクローズ済みを合わせたサブ Issue 数と一致している
• すべての Gate evidence セルに、この実行中に実際に読み取った実行 ID、SHA、またはコメントマーカーが記載されている
• レポートモード：git status と PR にこの実行で行った変更がなく、次のスキルも呼び出されていない
• 実行モード：準備状況／修復の根拠に、チェックアウト／ランタイム、原因、変更した条件、すべての上限内で行った再チェックが記載されている
• 実行モード：すべてのユニットが、配信記録を読み戻したうえでマージ済み、または理由を明示して保留されている。クリーンアップの読み戻しには、タスクのランタイムリソースも /tmp/<task-id>/ も残っていないことを示すか、残っているものをすべて列挙している。Issue はクローズされておらず、追跡対象の Compose ファイルも変更されていない