build-dark-factory

ダークファクトリーを構築する

ユーザーが入力した内容： $ARGUMENTS

この行から PRD のパスとリポジトリのパスを自分で特定し、確認していない解析結果を表示しないでください。 位置は空白で区切られるため、「build a dark factory for my repo at C:\code\thing」のような文を入力した人に対して、最初の 2 つの 単語 が 2 つのパスとして扱われます。実際に、3 回の別々のテスト実行で PRD: Build と Repo: a が開かれました。スキルがその後ひっそりと解析を修正したにもかかわらず、最初のやり取りは壊れているように見えます。

そのため、行を読み、.md の PRD らしきものとディレクトリらしきものを見つけて、フェーズ 0 の前に 1 文で両方をユーザーに確認してください。片方だけが指定されている場合は、拡張子からどちらかを判断し、もう片方を尋ねてください。PRD のパスが存在しない場合は、そのことを伝えて停止してください。これは早い段階で到達するフェーズ 0a です。

ダークファクトリーとは、一方の端から作業が入り、もう一方の端から出荷可能なコードが出てくるリポジトリで、その間に人間がいません。作業は Issue として届きます。ワークフローが計画し、構築し、検証し、マージします。デプロイによって実際のユーザーに届けられます。誰も差分をレビューしません。

最後の一文が、困難のすべてです。それ以外は配管作業です。

設計ドキュメントを渡すのではなく、ユーザーのリポジトリにファクトリーを構築してください。 以下の各フェーズでは、コミット済みのファイルと、実際に動作することを実証できるものが必ず残ります。

システム全体を1ページにまとめた図です。 5つの要素、3つのガバナンスファイル、そして独立性の境界を示しています。手順に進む前に全体像を確認したい場合は、dark-factory-diagram.png をフルサイズで開いてください。

---

出力のルール — ユーザーに一言でも伝える前にお読みください

このドキュメントが長いのは、完全でなければならないからです。ユーザーに伝える内容は、そうではありません。 これを使ったユーザーは、「とてもイライラするし、処理するのが難しく、控えめに言っても圧倒される」と体験を語りました。スキル自体は正しく動作し、各ステップで自分の説明をしていたにもかかわらずです。ファイルに書くべき推論をチャットウィンドウに表示するのはノイズです。

厳格な上限です。好みの問題ではありません。

場面	上限
質問と次の質問の間	何もなし。 質問してください。前置きも、前の回答の要約もしないでください。
フェーズの終了時	2行。 今あるものと、次の質問。
概念の説明	聞かれたときだけ、その場合もまず簡潔に説明してください。
作成したファイルの報告	1行。 パスと、内容を決めるもの。
コマンドの出力	貼り付けないでください。判定と数値を伝えてください。

次のことは絶対にしないでください。

• フェーズを始める前に計画を発表すること。実行してから、何ができたかを伝えてください。
• ユーザーの回答を段落で言い直すこと。選択ツールにすでに表示されています。
• スキルがこのように動作する理由を説明すること。その推論は、ユーザー向けではなくあなた向けに references/ にあります。必要ならユーザーから尋ねられます。
• これから構築するものをすべて一覧にした表を表示すること。
• フェーズの開始時に伝えた内容を、終了時に要約すること。
• 書いたばかりのファイルを貼り付けること。ユーザーは自分で開けます。

言葉を費やす価値がある唯一のことは、実際の判断を伴う質問です。そのような質問は質問ツールを通じて行い、選択肢の中に内容を記してください。質問の前に段落を添えてはいけません。

メッセージを送る前に、役に立つ確認方法があります。その内容を削除しても、なお成り立ちますか？ ディスク上のファイルにその事実が記されているなら、削除してください。

---

これは何か、そして何ではないか

ダークファクトリーは、AI を使ったコーディングの別のやり方ではありません。すでに AI を使って行っているコーディングから、人間によるチェックポイントを取り除いたものです。

現在実行しているプロセスを、そのままファクトリーに組み込みます。GitHub Spec Kit、BMAD、PRP フレームワーク、独自の「計画してから実装する」ループ、あるいは慣れ親しんだ習慣でも構いません。手順は変わりません。スキルも変わりません。MCP サーバー、ルールファイル、サブエージェント、すでに信頼しているコマンドも、すべてそのままです。

変わることはひとつです。計画を承認する人も、出荷前に差分を読む人もいません。

ですから、ここでの仕事はプロセスを考案することではありません。ユーザーがすでに使っているプロセスを書き起こし、それが安全に任せられるようにする部分を構築することです。**早い段階で、現在どのような AI コーディングのワークフローを使っているかを尋ね、それを形にしてください。**サンプルのファクトリーの形を押し付けないでください。

**このスキルでは PRD を作成しません。**これは意図的なものです。製品の最上位の計画を作る部分は、ほとんどの人が独自の方法を持っており、それを維持する価値があります。一般的な聞き取りに置き換えるのは、むしろ後退です。まだ方法がない場合は、同じリポジトリにある plan-create-prd スキルを案内し、ファイルが用意できたら戻ってきてもらってください。

以下のあらゆる判断を形作る二つのこと

• **キャッシュされた読み取りのコストは、出力のコストを桁違いに上回ります。**コンテキストのサイズは、エージェントがどれだけ書くかよりも、請求額に大きく影響します。そのため、プレミアムモデルを計画の段階に使い、それ以外では安価なモデルを使います。
• **断るコストは小さく、構築するコストは大きいです。**フェーズ 0 の判断が微妙なら、断ってください。間違ったファクトリーを構築したことに気づくのは 2 か月目で、その問題はプロンプトを改善しても修正できません。

ユーザーが最初のコミットメントを小さくしたい場合は、ガイダンス層までで止めることを提案してください。cron を有効にしなくても、十分に役立ちます。

まず最初に：3 つのハーネス

これらを混同すると、デバッグできなくなります。早い段階で、一度、はっきりとそれぞれの名前を伝えてください。

ハーネス	その内容	誰が構築するか
エージェントハーネス	Claude Code、Codex、Pi。プロンプトを編集内容に変換するループです	ベンダーです。あなたの担当ではありません。
ファクトリーハーネス	作業の計画、実装、レビュー、ゲート判定、マージを行う仕組みです	**templates/runner/。**コンポーネント 1～4 で、ほとんどをコピーします。
検証ハーネス	エージェントがユーザーと同じ方法で作業を確認するためのツールです	**あなたが構築します。これが作業の大半です。**コンポーネント 5 です。

ファクトリーハーネスは何を実行するかを決めます。検証ハーネスは、実行したものを残す価値があったかどうかを決めます。この二つを混同するからこそ、立派な DAG を構築しても、壊れたソフトウェアを予定どおりに出荷してしまうのです。

この区別によって、どの部分をテンプレートとして提供できるかも決まります。

ファクトリーハーネスはテンプレート化できます。検証ハーネスはできません。

ディスパッチャー、ランナー、ゲート、ガード、マージ、ステートマシンは、どのファクトリーでも同じです。そのため、苦労の跡も残したまま templates/runner/ に置いてあります。このアプリにとって「動作する」とは何を意味するのか。それだけは誰にも事前に書けないため、コンポーネント 5 はあなたが作るものです。そして、この構築で本当に手間がかかるのも、そこです。

---

構築順序と、1-2-3-4-5 の順ではない理由

5 つのコンポーネントは構造の順、つまりシステムを説明する順に番号が付けられています。この順番で構築するわけではありません。代わりに、次の順番で構築します。

構築順	コンポーネント	この順番の理由
0 番目	(PRD)	コンポーネントではありません。入力です。以降のすべてがこれを読み、これなしでは以降のどれも正直に書けません。
1 番目	ガイダンスレイヤー (#4)	Markdown であり、ほかのすべてのコンポーネントが読み取ります。ここで最も低コストで、最大の効果が得られるものです。
1.5 番目	(歩く骨格)	グリーンフィールドの場合のみ。ガイダンスレイヤーの後であり、前ではありません。スライスはミッションの範囲内で構築すべきで、Markdown の作成にコードは必要ありません。コンポーネントではなく、意図的にごく小さくした、1 つのアサート可能な動作が得られる最小のスライスです。存在しないソフトウェアを前提にコンポーネント 5 は書けません。Phase 0c を参照してください。ここで MVP を構築してしまうのが危険です。
2 番目	検証ハーネス (#5)	最も時間がかかる部分です。必要になる前に着手してください。これについては 2 回は間違えることになるからです。
3 番目	ワークフロー駆動のリポジトリ (#1)	これで、ワークフローには従うべきルールと通過すべきチェックができます。
4 番目	デプロイ (#3)	無人運転にする前に、実際のユーザーまでの一連の流れを完成させます。
最後	トリガー (#2)	cron はスイッチです。1〜4 が実証された後にのみオンにします。

トリガーを意図的に最後に構築します。 スケジューラーを有効にする瞬間に、リポジトリは自律的になります。それまではすべて手動で実行して、確認できます。ディスパッチャーを最初に構築したファクトリーは、誰にも一度もチェックされていない、無監督のコードジェネレーターです。

開始前に、これをユーザーに伝えてください。これによって、プロジェクト全体の捉え方が「エージェントをつなぐ」から「離れてもよいと認められるだけの実績を積む」へと変わります。

---

Phase 0. 入力、拒否する 2 つの方法、そしてグリーンフィールドの道筋

0a. PRD が必要です

このスキルへの入力は PRD です。何を、なぜ作るのかを、プロダクトマネージャーが書くレベルで記述したものです。課題、ユーザー、スコープ、そして何よりも対象外事項を含めます。仕様書、概要書、プロダクト文書、エピックなど、名称は重要ではありません。重要なのは内容です。

意図的に、技術スタック、アーキテクチャ、データモデル、ファイル構成は含めません。これらはエンジニアリング上の判断であり、後から決めるものです。ファクトリーでは、通常、最初の本格的な実行時に決めるか、既存のコードベースですでに決まっています。これらをここで尋ねると、変更できない仕様書に PRD が変わってしまいます。

PRD にこれらが含まれている場合、そしてたいてい含まれていますが、スコープではなく決定済みとして扱い、そのように扱っていることを明言してください。 エンジニアではない人は、自分が確信を持てる部分として技術スタックを書きます。キャリアチェンジを目指す人の概要書には、対象外事項がひとつも書かれる前に、フレームワーク、ホスト、テーブルの概略が記されていることもあります。それを覆すよう議論しても得るものはなく、場の時間を浪費します。

つまり、すでに決まった判断として受け入れ、MISSION.md には記載せず（スコープではなく、ファクトリーが擁護すべきものでもありません）、それが暗黙の前提ではなく選択であることを一言で明示してください。声に出して確認すべき点は、到達可能性です。レンダリングされたページ経由でしか操作できない技術スタックの場合、E2E テストから呼び出せるものの背後にロジックを分離する必要があります。0c を参照してください。

質問をひとつでもする前に、$prd にある PRD を最後まで読んでください。そのうえで、内容を対応づけます。

PRD に記載されている内容	ファクトリーがそれをもとに構築するもの
課題と、それを解決する価値がある理由	MISSION.md 冒頭の説明
ユーザー	E2E の手順を実行する人
MVP のスコープ、機能領域	トリアージで受け入れ可能なもの
対象外事項	MISSION.md の永久にスコープ外とする項目。ビルド全体で最も重要なリストです
成功指標	検証ハーネスが最終的に評価するもの
未解決の質問、TBD と記された項目	提案すべき判断。ファクトリーが妥当な値を選んで記録し、マージは人間の確認まで保留します。エスカレーションするのは FACTORY_RULES.md §7.2 にある限定された項目だけです。「未解決」は「まだ決めていない」と読み、「提案してはならない」と読まないでください

また、PRD に記載されていない内容を、ユーザーにはっきり伝えてください。まさにこれらを明らかにするために、インタビューを行います。

• 観測可能な手順として説明した E2E のハッピーパス
• 保護対象リスト
• プロンプトではなくコードで実装しなければならない 2 つのゲート
• 目標とする自律性のレベル
• 停止ボタン
• 作業の到着方法と、ファクトリーの実行場所

PRD がない場合は拒否してください。その理由を伝えてください。書面によるスコープがなければ、MISSION.md に対象外リストを設けられず、そのリストがなければ、もっともらしい機能リクエストはどれもスコープ内と見なされる可能性があります。ファクトリーはそのすべてを構築します。これは自律型リポジトリが失敗する最も一般的な原因であり、後からプロンプトを改善しても修正できません。

このリポジトリの plan-create-prd スキルを案内して、そこで止めてください。20 分後に実際の PRD を用意して戻ってくるのが、最短の道であり、遠回りではありません。

0b. リポジトリを観察可能な状態にする必要があります

質問する前に調べてください。テストコマンドが実行できるか、アプリの起動方法、既存の CI、gh が認証済みか、リポジトリが公開されているか、すでにある AI コーディング環境（CLAUDE.md、AGENTS.md、.claude/、.cursor/、既存のスキル、コマンド、MCP 設定）を確認します。最後の項目こそ、プロセスとして組み込むものです。たいていの場合、すでにそこにあります。

実際に見て、どちらのリポジトリか判断してください。今しがた確認したところです。質問しないでください。 以下の拒否条件は一方のリポジトリ向けに書かれており、もう一方に当てはめると大きく誤ります。違いはファイル一覧を見ればわかります。

• ブラウンフィールド - 足場となるものではないソースファイルがあります。拒否条件は記載どおり適用されます。
• グリーンフィールド - PRD と、おそらく .gitignore、.claude/、README はあるものの、実行できるものが何もありません。どちらの拒否条件も自明に当てはまり、どちらにも判断材料がありません。 0c に進み、拒否しないでください。

判断したリポジトリの種類と、その理由を一行で伝えてください。ユーザーが訂正できます。例："docs/ と .claude/ 以外にソースファイルがないため、グリーンフィールドとして扱います。" 判断が間違っていても修正は簡単ですし、質問しても、すでにわかっている答えをもう一度尋ねることになります。

次の場合は、理由を伝えて断ってください。

• ソフトウェアの動作を観察する方法がない - 起動するものも、呼び出せるものも、インポート可能なものもありません。コンポーネント 5 は何にも依拠できません。

  これは観察できないソフトウェアに関する条件であり、まだ存在しないソフトウェアに関する条件ではありません。 グリーンフィールドのリポジトリは定義上、この条件と次の条件に当てはまります。そこで拒否すれば、欠陥ではなく前提そのものを拒否することになります。0c を参照してください。

  ライブラリはこのケースには該当しません。 ハーネスには 3 つのドライバーが付属しています。http（サーバー）、cli（コマンド）、library（プロセスを起動せず、E2E がライブラリをインポートして呼び出します）です。APP_STARTED driver=library はインポートの成功を意味し、サーバーが応答するのと同じことを示します。この条件は以前、「ライブラリ」という言葉から始まっていましたが、純粋な Python ライブラリに対するテスト実行では、標準でサポートされているリポジトリまでほとんど拒否されてしまいました。観察可能かどうかを判断する前に、templates/harness/appproc.py を読んでください。

• リポジトリに CI もテストコマンドもない。 まずテストスイートから始めてください。チェックが一つもないまま稼働するダークファクトリーは、もっともらしいコードをマージするための機械にすぎません。

• ユーザーが、認証、支払い、または許容できないほど大きな影響範囲を伴うものにエージェントを関与させようとしている。 それらは保護対象リストに含めるべきで、ファクトリーに持ち込むものではありません。

この段階で断るほうが、2か月後に断るよりも低コストです。いずれかに当てはまる場合は、より小規模な案を提案してください。今すぐガイダンスレイヤーとハーネスを構築し、自律化に進む前に止めます。

0c. グリーンフィールド：ウォーキングスケルトンは小規模です

これは例外ではなく、よくあるケースです。 プロジェクトの初期段階でダークファクトリーを求める人がほとんどです。構築を始める最適なタイミングでもあります。まだ矛盾するものがないときにガイダンスレイヤーを書くのがもっとも低コストであり、以下で説明するシミュレーションとプレゼンテーションの分離も、コードがないうちは簡単ですが、後から行うとコストがかかります。

グリーンフィールドは拒否の理由ではありません。ただし、現時点ではコンポーネント 5 が何にも依拠できず、フェーズの順序を変えても解決しません。まず何かが存在する必要があります。

スケルトンは最も薄い垂直スライスであり、MVP ではありません

ここがグリーンフィールドの構築がうまくいかなくなるポイントであり、しかも毎回同じ方向に失敗します。エージェントはハーネスがテストできるようにプロダクトのコアを構築しようと提案し、ユーザーはそれが必須に思えるので同意し、その結果、面白くリスクのある作業は手作業で行われ、ファクトリーには残り物だけが残されます。それは本末転倒です。

端から端まで観察可能で検証可能な 1 つの振る舞いを生み出す、最小のスライスを構築してください。 ゲームであれば、敵 1 体、ヒット 1 回、ダメージ数値 1 つ、再起動後も保持されるセーブ。サービスであれば、1 行を書き込んで読み戻す 1 つのエンドポイント。CLI であれば、出力の 1 行を変える 1 つのフラグを持つ 1 つのコマンド。

基準は「これは役に立つか」ではなく、**「ユーザーが気づくようなことを E2E が検証できるか」**です。もしできるなら、構築をやめてファクトリーの構築を始めてください。MVP の他のすべてはイシューであり、それをファクトリーが構築することこそが、あなたがここにいる理由です。

開始前にサイズを明示し、意図的に除外するものを述べてください。「私は 1 つのホーンレベル、1 つのウェーブ、1 つのダメージ数値、そしてセーブファイルを構築します。報酬カーブも、元素相互作用も、ウェーブ構成も作りません。それらはイシュー 1、2、3 です。」

到達可能性の制約を、今決める

ハーネスがソフトウェアに到達する方法はちょうど 3 つ - http（サーバー）、cli（コマンド）、library（インポートして呼び出す）です。templates/harness/appproc.py を読んでください。レンダリングされたウィンドウ、ゲームループ、キャンバス、ネイティブ UI はそのどれでもありません。

したがってグリーンフィールドでは、これはアーキテクチャの好みではなくなり、厳格な要件になります。ロジックは、E2E が駆動できるヘッドレスでスクリプト可能なサーフェスの背後に存在しなければなりません。 シミュレーションはレンダリングから分離します。ドメインはビューから分離します。ルールがエンジンノードとレンダリングループの中にしか存在しないなら、検証できるものがなく、ファクトリーをレベル 3 で構築することはできません。それはスキルが限られているからではなく、作業をチェックできるものが何もないからです。

これはコードを書く前に述べてください。今ならほぼ無料で、後になれば書き直しになります。

ファクトリーのスコープは MVP よりも厳密に小さい

一部の MVP 項目は機械的に検証できず、今後も決してできません。「戦闘の感触が良い」、「エスカレーションが視覚的にも聴覚的にも明らかに異なる」、「初めてのプレイヤーが理解できる」。これらはフィール、プレゼンテーション、可読性です。

それらを声に出して名付け、MISSION.md と FACTORY_RULES.md に恒久的に人間の担当として書き込み、ファクトリーがプロダクトではなくシミュレーション層を所有することを明確にしてください。それでも広く価値のあるサーフェスであり、通常は実際のリスクの大半を占めますが、それが MVP 全体であるかのように装うと、緑のファクトリーが誰も遊びたくないゲームを出荷する羽目になります。

次に、この順序で - そして分岐はインタビューの後に来る

上記の 2 点（スケルトンはスライスである、ロジックは到達可能でなければならない）を今すぐ、フェーズ 0 で述べてください。どちらもユーザーがインタビューで答える内容を変えるからです。その後で:

1. フェーズ 1、インタビュー。 グリーンフィールドでも変わりません。
2. フェーズ 2、ガイダンス層。 Markdown でコードは不要であり、以降のすべてのコンポーネントがこれを読みます。スケルトンも含めてです。スケルトンはミッションのスコープと並行してではなく、その内側で構築すべきです。これはグリーンフィールドのユーザーが望むかもしれない自然な停止点でもあり、スケルトンを先に置くとそれがなくなります。
3. スケルトンを、R1.1 からのジャーニーに対して命名し、サイズを決めます。
4. フェーズ 3 以降は書かれているとおりです。

以下の分岐はここではなく、フェーズ 1 の後に提示されます。 その推奨オプションは、スライスを名付け、何を除外するかを名付けることを要求しますが、R1.1 がジャーニーを教えてくれる前に、どちらも正直にはできません。フェーズ 0 で尋ねると、まだ誰も持っていない情報で決定を下すことになります。フェーズ 0 では選択が来ることを示唆し、インタビューの後に置いてください。

インタビューでジャーニーが得られた後の分岐

既知の答えが 3 つあるので、これは他のすべてと同様に質問ツールの呼び出しであり、 最初のものを推奨します。

1. 今すぐ薄いスケルトンを作り、その上にファクトリーを構築する (推奨) - スライスに名前を付け、 何を除外するかにも名前を付けるので、「推奨」が「あなたの MVP を構築します」と 読まれることはありません。
2. ガイダンス層とスキャフォールドのみ - MISSION.md、FACTORY_RULES.md、CLAUDE.md、 さらに runner/ と harness/ をコピーし、コントラクトを文書化してアサーションは 空のままにします。ユーザーがスケルトンを構築し、あなたはコンポーネント 5 から再開します。これは 慰めではなく実際の選択肢です。MISSION.md/FACTORY_RULES.md のペアは、cron が 一度も有効化されなくても、インタラクティブな作業でその価値を発揮します。
3. 停止 - まずアーキテクチャ - PRD が 0c の到達可能性制約が依存するものを先送りし、 コードが存在する前にそれを決着させたいとユーザーが望む場合。

フェーズ 1. インタビュー

references/interview.md を読み、それに沿って進めます。これはスキル全体を質問形式にしたものです。 各質問が実際に何のためなのか、良い答えはどのように聞こえるか、そしてどの曖昧な答えに 押し返すべきかが書かれています。

これは 3 ラウンドであり、アンケートではありません。 ラウンド 1 は以下の 3 つの質問で、 何よりも先に 1 つずつ尋ねます。ラウンド 2 はユーザーだけが答えられる 6 つの質問です。ラウンド 3 は 単一のメッセージで、残りのすべての設定を既定値があらかじめ入力された状態で列挙し、 何を変更するかを尋ねます。

既定値を提案し、尋問しないでください。 保護パス、ポーリング間隔、並行性、停止ボタン、 PR 上限、モデルルーティング、ホールドアウトの場所にはすべて、config.sh とテンプレートに 同梱された実用的な既定値があります。それらを自由回答で尋ねると、ユーザーがスキルの宿題を することになり、重要な質問が埋もれてしまいます。「これらの 5 つのパスと、あなたの CI 設定を 保護します - 他に何かありますか?」は「エージェントが決して触れてはならないファイルはどれですか?」 よりも良い質問であり、このようなものを一度も構築したことのない人が間違って答えることは できません。

PRD はすでにこの一部に答えています。 それが答えていることを決して再質問しないでください。スコープと 非目標を提案として読み返し - 「つまりトリアージはこれら 4 つの領域のものを受け入れ、これら 6 つを 拒否する、で正しいですか?」 - それが開いたままにしたものに時間を費やしてください。 ユーザーがすでに書き留めたことを再質問することは、インタビューが最初の 2 分で場を失う 方法です。

先に進む前に、各答えを具体的な成果物として反映してください (「つまりマージゲートは X」)。

すべての質問は質問ツールを通します。 Claude Code の AskUserQuestion、または 他の場所での同等のものです。自由回答の質問も含め、すべてです。例外はなく、 散文へのフォールバックもありません。

これは以前は分割されていました - 既知の選択肢にはピッカー、自由回答の質問には散文 - というのは、 *「ユーザーが行う最も価値のあることを説明してください」に選択肢を提示することは、答えをあなたの 推測のメニューに置き換えてしまうという主張でした。その主張はツール自体によって答えられます。 それは常に「その他」の自由記述の逃げ道を備えています。 自分の言葉で答えたいユーザーは、 1 回のキー操作で依然として答えられます。段落をざっと読み流して「あなたが選んで」*と言ったであろう ユーザーは、3 つの具体的な候補のうち最も近いものを修正するようになり、それがあなたに 必要だった答えであり、そうしなければ得られなかったものです。

古い主張から生き残るのは、ツールではなく選択肢に関する制約です。自由回答の質問では、 そのユーザーの PRD とそのリポジトリから選択肢を導き出し、出典を明示してください。 彼ら自身の資料からの草案は彼らの答えを読み返したものであり、彼らは喜んで上書きするでしょう。 でっち上げたものは、彼らをあなたの推測に固定してしまいます。

ラウンド 2 のすべての質問は、彼らにすでに起こったことについて尋ねます - すり抜けたバグ、 何を差し置いてでも直したいもの、変更後に自分自身を納得させるために何をするか。 ユーザーに成果物を設計させないでください。彼らは自分のソフトウェアについて記憶から答えます。 それをシナリオ、欠陥セット、ルールに変えるのがあなたの仕事であり、黙って行われます。 interview.md には正確な文言と、それぞれが何になるかが書かれています。 すべての質問には、次の2つのルールを適用してください。

1. 必ず推奨案を提示します。 最初の選択肢を (Recommended) とし、理由を1行の説明に含めます。空白のままにはしません。推奨案を示すのが誠実でない場合、つまり本当に五分五分の場合は、自信があるふりをして選択肢を作るのではなく、そのことを質問文で伝えます。
2. 回答する前に、難しい用語の説明を申し出ます。 Holdout、mutation set、ratchet、independence line、structural gate は、こうしたものを作ったことがある人にしかすぐには分かりません。holdout を知らないと言いたくないユーザーは、推測で答えてしまいます。「まず説明を聞く」という選択肢を加えてください。interview.md には各用語を一息で説明する文があります。その言葉を使い、講義のような説明はしないでください。

Round 1 の3つの質問でプロジェクトが決まるため、どれも曖昧に済ませないでください。

1. 「最初のクリックから、最終的に目にするものまで、誰かがこれを使って行う最も役立つことを一つ、順を追って説明してください。」 この手順が、変更のたびにチェックする主要な経路になります。説明できなければ、チェックする方法もありません。
2. 「現在、AI を使って機能をどう作っていますか？」 質問を並べず、自由回答式の質問を一つだけします。相手の回答を受け止め、残りは CLAUDE.md、AGENTS.md、.claude/、.cursor/ を確認してください。承認手順を取り除いたうえで、ワークフローが本人たちのプロセスだとはっきり分かるようにします。
3. 「誰も事前にコードを読まずに、ユーザーにコードを届けても構いませんか？」 そのうえで、下のダイヤルを示します。レベル3を推奨してください。 5を選ぶ人はよくいますが、5はミッションに基づいてファクトリーが自らの作業を作成することを意味し、これは別の判断です。

自律性ダイヤル

レベル	自動化されること	引き続き人が行うこと
0	ワークフローが存在する	手動で実行する
1	ラベル付きの issue → PR が開かれる	すべてレビューしてマージする
2	＋バリデーターが実行され、判定を投稿する	すべてマージする
3	＋すべての構造ゲートが成功すると、バリデーターが自動マージする	issue を作成し、リリースを行う
4	＋自ら issue をトリアージし、スケジュールされたテストが自らバグを報告する	重要な issue を作成する
5	＋ミッションに基づいて自ら issue を作成する	何もしない

レベル3をデフォルトにします。レベル3を目指して構築してください。

人がコードを読まずにマージされる最初のレベルであり、これこそが目的です。レベル2で止まるファクトリーは、キュー付きのコードジェネレーターにすぎず、取り除こうとしていたボトルネックは依然として人です。この構築で難しいことはすべてレベル3を実現するためにあります。そのため、それより低いレベルを目指して構築すると、難しい部分を作りながら使わないことになります。

レベル0から2は通過点であり、到達点ではありません。順番にリリースし、それぞれで一巡を実証して、レベル3まで進めてください。ダイヤルは orchestrator.sh で制御され、holdout が存在するまで factory_doctor がレベル3を明示的にブロックするため、「レベル3を目指して構築する」ことが、証拠がそろう前に「レベル3を有効にする」ことにはなりません。

ユーザーに明確な理由がある場合に限り、レベル3未満で止めてください。変更できないレビュー要件、許容できない影響範囲、まだ信頼できないハーネスなどです。それは正当な選択であり、ダイヤルの話が出なかったためにデフォルトで決まるのではなく、本人がはっきりと意思表示したうえで選ぶべきです。

レベル3より上は、さらに先へ進む段階ではなく、別の問いです。レベル4では何を作るかの決定を委ね、レベル5では何を作るかの決定自体を委ねます。マージの自動化を望むからといって、どちらも自動的に含まれるわけではありません。

フェーズ 2．ガイダンスレイヤー（コンポーネント 4）

references/guidance-layer.mdを読み、テンプレートから次の 3 つのファイルを作成します。

• MISSION.md - 何を構築するのか、そして今後も意図的に対象外とするもの
• FACTORY_RULES.md - エージェントが監督なしでどのように動作するか、および保護対象リスト
• CLAUDE.md / AGENTS.md - ファクトリーかどうかにかかわらず、どのプロジェクトにも当てはまる規約 （テンプレートはtemplates/CLAUDE.md。すでにファイルがある場合は、置き換えるのではなく分割します）

MISSION.mdはPRDを圧縮したものであり、新しい文書ではありません。 PRDを直接もとに草案を作成し、ファイルの差分だけでなく、意味上の差分もユーザーに示します。PRDの非目標は、ほぼそのまま対象外リストに含めます。また、インタビューで追加された内容にはその旨を記し、後から見たときに、どの制約がプロダクトに由来し、どの制約が無人運用のために追加されたのかが明確になるようにします。

規約ファイルがすでにある場合は、そのファイルを残し、ファクトリー固有のルールを取り出します。その上から新しいファイルを書くのではありません。この分割は通常、既存リポジトリに対してこのフェーズで行う変更のうち、最も有益なものです。

ルールごとに、次の基準で判断します。

人間が作業する場合にもこのルールを書くか？ → 規約ファイル。 誰も監視していないことを理由に存在するルールか？ → FACTORY_RULES.md。 プロダクトが何であり、何ではないかに関するルールか？ → MISSION.md。

最も重要な性質は、エージェントが評価基準となるルールを改変できないことです。 3 つのファイルすべてを保護対象リストに加え、これらに触れる PR は、ほかの評価を行う前に自動却下します。プロンプトではなく、コードでこれを強制してください。

今すぐscripts/factory_doctor.py --repo <path>を実行します。エラーが表示されますが、それで正しい状態です。これはチェックリストであり、ここから対応を始めます。

フェーズ 3．検証ハーネス（コンポーネント 5）

何かを書く前に、references/validation-harness.md を最初から最後まで読んでください。ここが最も長いリファレンスです。ファクトリーで実際に問題が起きるのはここだからです。冒頭のセクションは、ランナーが期待する契約です。エントリーポイント、マーカー、追記ルール、そして --quick のサブセットが記されています。残りを流し読みする場合でも、ここは読んでください。追記ルールを誤ると、一見コードとは無関係に思える理由で、すべてのマーカーアサーションが失敗するからです。

まずスキャフォールドを使い、それからアサーションを削除してください。

cp -r templates/harness <repo>/harness

templates/harness/ が提供するのは配線部分だけです。Python 専用でも Web 専用でもありません。すべてのコマンドは harness.config.json にあり、ドライバーは http、cli、library のいずれかです。Python の HTTP サービス、Node の CLI（変更したのは設定値 5 つだけで、それ以外は変更なし）、Python のライブラリで実証済みです。

用意されているのは、段階的なテスト、件数付きマーカー、ステップ名付けツール、--quick のサブセット、そして動的ポートをバインドし、ヘルスチェックを待ち、どの経路でもプロセスを終了するアプリケーションプロセスマネージャーです。そのまま実行できます。

この分離は保険ではなく、検証から得られた結論です。2 人が異なる製品を対象に、それぞれ独立して、スキャフォールドなしでこのハーネスを一から作りました。そして、どちらも「テストが 0 件検出された場合は合格ではない」というガードまで含め、同じファイルを書きました。配線部分を決めるのはアプリではなく、マーカーの契約です。

e2e.py にあるアサーションはすべて実装例なので、すべて削除してください。 .factory/holdout/run.py と harness/mutations/defects.json も同様です。それぞれにマーカー行が含まれており、内容を自分のものにする際に削除します。削除するまで factory_doctor は レベル 2 以上でブロックします。テンプレートのサンプル製品についてだけ合格するゲートは、ゲートがないよりも悪いからです。

インタビューからは 3 つすべてが得られます。R1.1 のユーザージャーニー、ビルダーが読み取れない構成済みシナリオである R2.5a、捕捉すべき欠陥である R2.5b です。ユーザーが気づく部分は、誰もあなたの代わりに書けません。それは R1.1 への答えであり、実作業の中心です。スキャフォールドで用意できるのは配線部分までであり、アサーションは用意できません。

以下は要約です。ただし、実際に読むことの代わりにはなりません。

• 段階を進めてください： 静的解析 → 単体テスト → 統合テスト → 実際のユーザーとしての E2E → 視覚的な評価 → ホールドアウトシナリオ → 決定論的なゲート。
• 独立性の境界は統合テストの後に引いてください。 その下のすべてはエージェントの最適化ループ内にあるため、時間を与えると、意図したものではなく、測定したものを満たすようになります。境界より下にテストを増やしても解決にはなりません。
• 少なくとも 2 つのゲートは、モデルが言い逃れできないコードにしてください。 マージそのものと、アプリケーションが実際に起動したことを示す肯定的なアサーションです。それ以外の場所では、「ゲート」はプロンプト内の指示にすぎず、丁寧な提案でしかありません。
• 空は合格ではありません。 失敗した件数だけでなく、実行されたチェックの件数もアサートしてください。スキップされたチェックは何も返しません。何もないことは失敗ではありません。
• バリデーターはコードがどのように書かれたかを学習しません。 求められたことと、現在コードが何をするかだけを検証します。

成果物：ワークフローから呼び出せる validate エントリーポイント。明示的なマーカーを出力し、それを grep する bash のマージゲートも用意してください。

フェーズ 4．ワークフロー駆動型リポジトリ（コンポーネント 1）

各エージェントのヘッドレス実行時の契約とランナーの内容については、references/automation.md を読んでください。

ランナーをコピーしてください。自分で書いてはいけません。 templates/runner/factory/ は、ディスパッチャー、ランナー、構造ゲート、保護パスガード、マージ、デプロイ、ステートマシン、7 つのノードプロンプトを備えた、実際に動作する実行レイヤーです。インストール順序は README.md に記載されています。

cp -r templates/runner/factory <repo>/factory
mkdir -p <repo>/.factory/{locks,holdout,runs}

その後、3 つの編集を行います。3 つ目がこのフェーズの本当の作業です。

1. factory/config.sh - エージェント、モデル、そしてフェーズ 3 のハーネスを指定する FACTORY_VALIDATE_CMD を設定します。プロジェクト固有の値はすべてここに置きます。パスを変更するために別のスクリプトを編集しているなら、それは config.sh に不備があるということです。
2. factory/guard.py - 保護対象の一覧です。面接で返された内容をそのまま受け入れるのではなく、初期値を設定してください。
3. factory/prompts/*.md - ユーザー自身のプロセスとして、これらを書き換えてください。 フェーズ 1 の R1.2 の回答が反映されるのはここです。あるスキルで計画し、別のスキルで実装するなら、それぞれを 2 つのノードにします。今日、特定の手順でルールファイルや MCP サーバーを読み込んでいるなら、ここでもその手順で読み込むようにします。

ファクトリーの興味深い特性は、異なる動作をすることではなく、人が付き添わなくても実行できることです。これらのプロンプトに自分のワークフローを見いだせるユーザーは、ファクトリーを信頼し、保守します。新しいパイプラインを覚えなければならないユーザーは、そうしません。パーソナライズするのはプロンプトです。配管ではありません。 だからこそ、配管はコピーとして提供し、プロンプトは判断すべき箇所を明示したひな型として提供します。

ユーザーがすでに使っているワークフローエンジン（Archon、YAML DAG、GitHub Actions、Agent SDK プログラム）がある場合も、ランナーは引き続き、ノードが行うべきことの手本となります。つまり、フレッシュコンテキストの境界、ツールの許可リスト、ホールドアウトの拒否、コミット手順、ゲートです。これらの特性を移植してください。Bash を移植してはいけません。

フェーズ 5．デプロイ（コンポーネント 3）

references/deployment.md を読んでください。短い内容ですが、他のどんなことよりも多くのファクトリーをひそかに停止させる、たった 1 つの落とし穴が記されています。GitHub は、デフォルトの GITHUB_TOKEN を使って行われたコミットではワークフローを起動しません。 エージェントはコミットしますが、デプロイは実行されず、エラーも発生せず、何も通知されません。

実際のユーザーに届くところまでループが続かないなら、ユーザーが作ったのは PR 生成ツールです。

フェーズ 6。トリガー（コンポーネント 2）

今になって初めてです。references/setup.md を最初から最後まで読み、オートメーションリファレンスのディスパッチャーのセクションも読んでください。

references/setup.md は、華やかさはないものの、誰も書き残さない部分です。前提条件、cron と systemd と Task Scheduler、.gitattributes の改行コード指定、core.longpaths、PYTHONIOENCODING、事前確認の git check-ignore、認証情報の有効期限切れ、そして停止ボタンを意図的にテストする方法が記載されています。そこにある項目は、どれも実際のファクトリーで問題を起こしました。完璧なコンポーネントが 5 つあっても、チェックアウト時に改行コードが書き換えられたせいで、マシンが一度も周回を完了したことがない、ということもあります。

ダイヤル自体は、すでにランナーで制御されています。orchestrator.sh は FACTORY_AUTONOMY を読み取り、そのレベル未満の各アクションを拒否します。そのため、レベルを上げることは、ファイルにメモを残すのではなく、意図的な操作になります。

ほとんどの人が誤った仕組みを想定してやってくるため、これは声に出して言ってください。何かがプッシュするわけではありません。 イシューを登録しても実行はトリガーされません。Webhook はなく、そもそも設ける想定もありません。スケジューラーがタイマーで起動し、状態を読み取り、最大 1 つの処理をディスパッチします。09:01 に登録されたイシューは、次の起動まで待機します。プッシュトリガーが壊れても、何も通知されず、ファクトリーに処理することがない場合とまったく同じように見えます。一方、ポーリングが壊れれば、ポーリングが動いていないことを確認できます。

ここではなく、最初の周回が終わった後にインストールしてください。 install-trigger.sh はダイヤルが 1 未満だと拒否し、フェーズ 7 で手動の周回が実証されるまでダイヤルは 0 から変わりません。そのため、番号どおりにフェーズ 6 を実行することはできません。今はトリガーの設定を作成し、ダイヤルが動くフェーズ 7 の手順 3 でインストーラーを実行してください。コードは正しく、実行順序が間違っていました。

手作業ではなくインストーラーでトリガーを有効にしてください。また、ダイヤルが 0 の間は拒否されることに注意してください。レベル 0 のスケジューラーはいつまでも起動しますが、正しく何もしません。これを見て、周回を一度も完了したことがないのにファクトリーが稼働していると思い込む人がいます。

bash factory/install-trigger.sh --status     # what is armed right now
bash factory/install-trigger.sh --install    # cron, systemd timer, or Task Scheduler
bash factory/install-trigger.sh --remove

その後、factory_doctor をもう一度実行してください。スケジューラーが実際に有効になっているかを確認するようになります。予定が何もない、完全に構築済みのファクトリーも、稼働中のファクトリーも、監査結果が同じになってしまうためです。

ディスパッチャーは、システム内でもっとも単純で、もっとも決定論的なものでなければなりません。 何を実行するかを LLM に判断させてはいけません。存在しない作業をでっち上げてディスパッチしてしまいます。Bash と、固定の優先順位と、ありふれた場所にある共有状態を使います（GitHub ラベルで十分です。データベースもメッセージバスも必要ありません）。

優先順位は固定であり、次の順序が重要です。

1. 修正が必要な PR を修正する
2. レビュー待ちの PR を検証する
3. 受け入れ済みイシューのうち、最優先のものを実装する
4. 未トリアージのイシューをトリアージする

新しい作業を始める前に、進行中の作業を完了させてください。 逆にすると、ファクトリーはいつまでもトリアージを続け、自分の PR は放置されたままになります。

フェーズ 7。実証してからレベル 3 に進みます

目標は 3 です。ダイヤルがそこに達するまで、作業は完了ではありません。 以下の手順は、 そこに到達するための証拠であり、途中で止めるための階段ではありません。

1. ウォーキングスケルトンを手動で実行します。実際の課題を 1 件、最後まで進めて、 自分でマージする PR まで完了させます。一度も完走したことのないファクトリーを先に進めてはいけません。
2. python scripts/factory_doctor.py --repo <path> --audit を、問題がなくなるまで実行します。ホールドアウトがない場合、 レベル 3 への移行は拒否されます。これが、残りの作業が本当に行われたかどうかを判定するチェックです。 2b. python scripts/_test_runner.py --repo <path> と python scripts/_audit_runner.py --repo <path> を実行します。ドクターはリポジトリが 正しくセットアップされているかを確認し、これらはその下で動く仕組みが今も機能するかを確認します。無料で、 約 2 分で完了します。これらに失敗するファクトリーは、ひっそりと失敗します。 誰にも知らされずに作業を保留したり、失敗するしかないワークフローを再実行したりします。factory/ 以下を 手動で編集した場合はいつでも、また、しばらく停止していたファクトリーを再起動する前にも、 両方を再実行してください。ランナーはリポジトリにコピーされ、リンクはされないため、上流での修正は あなたのリポジトリには反映されていません。
3. ダイヤルを 1、次に 2 へ上げ、それぞれの段階で 1 サイクルを最後まで見届けてから、3 まで上げます。 2 で止めると、人がすべての PR をマージし続けることになります。それこそ、この仕組み全体を構築した目的に対するボトルネックです。 ユーザーが 3 未満で止めることを選んだ場合は、さらに進むには何が満たされている必要があるかを FACTORY.md に書き留めてください。そうすれば、誰も再び触れないダイヤルではなく、 次に進む道筋のある判断になります。
4. テンプレートから FACTORY.md を作成します。何を構築したか、現在どのレベルで動いているか、 次の段階へ進む前に何が満たされている必要があるかを記載します。元になった PRD へのリンクを記載してください。 製品が変わればミッションもそれに合わせて変える必要があり、誰かが気づくまで ファクトリーは古いスコープを忠実に構築し続けるからです。

---

運用上の事実 — 読み上げる説明ではありません

このセクションをそのまま読み上げないでください。 導入時の説明のように読めてしまい、実際にそうした結果、 ユーザーが何もする前に、密度の高い説明が 6 段落続いてしまいました。これらは、正しく構築するために あなたが知っておくべき事実です。それぞれ、実際に役立つタイミングで 1 つずつ伝えてください。 トリガーを設定するときのトークンに関する箇条書き、最初のコミットを行うワークフローを書くときの git check-ignore に関する箇条書き、各 1 行です。ユーザーから注意点を尋ねられた場合は、 ここから短いものを優先して答えてください。

• PRD は、もはや着手時の成果物ではなく、常に更新される文書です。 通常の開発では PRD が古くなり、人がひそかに補います。ここでは補う人はいません。ファクトリーは、スコープが編集されるまで、 与えられたスコープを構築し続けます。製品の内容を変えるには、意図的に、人間がコミットを作成して MISSION.md を編集します。
• 初日、最初の無人実行の前に、トークンを計測できるようにしてください。 警告としてではなく、 後から復元できない、記録しておきたい測定値としてです。「課題を 1 件修正する」実行では、 外から見える以上に多くのエージェントセッションが発生します。自分の環境で何が起きるかを知る唯一の方法は、 最初のサイクルから記録しておくことです。
• 計画用のスロットには高性能なモデルを 1 つ配置し、それ以外にはより安価なモデルを使ってください。 重要な 2 つのスロットのうち 1 つに高性能なモデルを使うだけで、両方に使った場合の品質の大半が得られます。 どのスロットにも高性能なモデルを使わないことこそが、実際にはコストがかかります。
• 編集を行うすべてのノードに、個別の差分の範囲を厳守させてください。 ファイルの範囲を指定せずに 編集できるノードは、6 ファイルの PR を 11 ファイルに増やし、その過程でバグを持ち込むことになります。
• コミットを行う最初のワークフローの前に、すべての設定ファイルに対して git check-ignore -v を実行してください。 PR 作成ステップ内の git add -A は、無視されていないものをすべて公開します。そして公開とは、本当に公開されるということです。
• エージェントは交換可能な部品ですが、配管はそうではありません。 認証情報の有効期限切れ、コストの急増、 デフォルトのセッションタイムアウトがないこと、サンドボックスからの外部通信は、どのエージェントでも同じ問題であり、 どのエージェントも解決してくれません。

リソース

• dark-factory-diagram.png：システム全体を1ページにまとめた図です。5つのコンポーネント、3つのガバナンスファイル、ラダー、独立性ラインが示されています。**このリポジトリを読む人向けであり、エージェント向けではありません。**ビルド中に説明してはいけません。

• references/interview.md：3ラウンドで行うインタビューです。プロジェクトを決める3つの質問、ユーザーがすでに知っているソフトウェアについての7つの質問、デフォルト設定を確認する1回の呼びかけで構成されています。すべての質問は質問ツールを通じて行い、推奨事項を添えます。ユーザーが知る理由のない概念を質問に出さず、専門用語を使う箇所には、それぞれ一息で読める平易な英語の説明を付けます。フェーズ1で読みます。

• references/guidance-layer.md：3ファイルへの分割、配置テスト、保護対象ファイル、実効性のある対象外リストの書き方について説明します。フェーズ2で読みます。

• references/validation-harness.md：ラダー、独立性ライン、ホールドアウト設計、構造的ゲートとプロンプトによるゲート、失敗モードについて説明します。チェックを書く前に、フェーズ3で読みます。

• references/automation.md：8つのコーディングエージェント向けのヘッドレス契約、オーケストレーターの選択肢とトレードオフ、ディスパッチャーのルールについて説明します。フェーズ4と6で読みます。

• references/deployment.md：デプロイ戦略、GITHUB_TOKENの落とし穴、GitHubのスケジュール設定に関する注意点について説明します。フェーズ5で読みます。

• references/setup.md：前提条件、プラットフォームの負担、スケジュール設定、有効化について説明します。早い段階で断るため、フェーズ0bでざっと読みます。フェーズ6では全体を読みます。

• templates/：MISSION.md、FACTORY_RULES.md、FACTORY.mdが含まれています。コピーして内容を埋めてください。テンプレートのプレースホルダーテキストを残したまま出荷してはいけません。別個のorchestrator.shやvalidate-gate.shのスケッチは、もうありません。これらはtemplates/runner/factory/にある実際のものより明らかに劣る重複物であり、パイプラインの定義を二重に出荷することこそ、automation.mdが警告する失敗です。誰も実行しないものこそ、乖離していきます。

• templates/runner/：実行レイヤー本体で、約3,000行あります。フェーズ4でリポジトリにコピーします。インストール順序と重要事項の一覧は、同梱のREADME.mdを読んでください。コメントには実際に起きたインシデントが記録されています。設計だけを頼りにファクトリーを再構築すると、本番環境で、無人のままそれらすべてを再発見することになります。

• templates/harness/：フェーズ3でコピーする、検証ハーネスの配線部分です。コピーすればすぐに実行できますが、含まれるアサーションはすべて削除用の例です。ファクトリーのハーネスも、その配線部分もテンプレート化できます。しかし、テンプレート化できないのは、この製品における「動作する」の定義であり、それがコンポーネント5のすべてです。

• scripts/factory_doctor.py：ファクトリーリポジトリを決定論的に監査します。保護対象ファイル、ホールドアウトの漏えい、ゲートがコードであること、空は合格ではないこと、無視されたシークレット、自律性レベルを確認します。フェーズ2と7で実行してください。ソースコードをコンテキストに読み込んではいけません。出力だけを参照してください。

• scripts/_test_factory_doctor.py：doctor自体のテストです。正常なファクトリーを構築し、一度に1つずつ問題を起こして、doctorがそれを検知できることを要求します。doctorを変更した後に実行してください。一度も失敗したことのないゲートは、誰にもテストされていないゲートです。このスキルのゲートにも同じことが当てはまります。

• scripts/_test_runner.py：runnerの動作テスト一式であり、「このファクトリーは本当に健全か？」への答えです。実際のfactory/を含む実際のGitリポジトリを構築し、エージェントとバリデーターをスタブ化して、完全な実行を無料かつ決定論的に行えるようにしたうえで、実際のシェルスクリプトを動かします。各テストの名前は、そのテストが再発を防ぐ不具合に由来します。

  python scripts/_test_runner.py                    # the shipped template
  python scripts/_test_runner.py --repo <path>      # a factory somebody BUILT
  python scripts/_test_runner.py --mutate           # do the tests catch anything?
  

  **覚えておくべきなのは--repoです。**runnerはリポジトリにコピーされ、リンクされることはありません。そのため、このテンプレートを修正しても、すでに構築済みのものには反映されません。また、手作業で編集されたファクトリーは、監視するものがなければ乖離していきます。無人で再び信頼して実行する前に、ファクトリーに対してテストしてください。 --mutate こそが、このスイートを誠実に保つ仕組みです。 これは各履歴上の欠陥を使い捨てのコピーに復元し、スイートが RED になることを要求します。欠陥を戻してもすべてがグリーンのままであるテストは飾りであり、そのように名付けられます。これは、このスキルがあなたのプロダクトのミューテーションテストについて述べているのと同じ論旨を、自分自身に向けたものです - そしてすでに、ここであるテストが誤った理由でパスしていることを一度捕捉しています。

• scripts/_audit_runner.py: 振る舞いテストでは表現できない構造的不変条件 - config.sh が一度もエクスポートしなかった、子プロセスが読み取るノブ、レンダラーが置換しないプロンプトのプレースホルダー、何もディスパッチしない状態、次の行のエスカレートの前に死ぬガードされていないコマンド。--repo はここでも機能します。factory_doctor があなたのリポジトリを監査するのに対し、これは MACHINERY を監査します。その検出結果はあなたのセットアップのギャップではなくファクトリーのバグであり、壊れた MACHINERY を動かしている正しく構成されたリポジトリは、doctor が持つすべてのチェックにパスします。

なぜこの2つが存在するのか。 同じ4つの故障の形がこの runner で繰り返し現れ、そのそれぞれが手作業で見つけられ、一度きりの修正として直されました。その理由は、このスキルが5つのフェーズをかけてあなたのコードについて述べていることと同じです。すなわち、ハーネスがなかったのです。約4,200行の runner が出荷されましたが、それを実行するものは何もありませんでした。そのため、すべての修正は RED になるものではなく、ドキュメント内の一文でした。このスキルから1つだけアイデアをあなた自身のリポジトリに持ち帰るなら、それを持ち帰ってください - そして、それがあなたが構築するプロダクトに当てはまるのと同じくらい、それらが構築するツールにも当てはまることに気づいてください。