EvolveHQ/docflow

ブートストラップ

あなたは現在のリポジトリにドキュメント主導の規約セットをインストール（または後付け）しています。最終状態は、人間とコーディングエージェントの両方が少数の標準ファイルを使って駆動できるリポジトリです。ここで説明されているメカニズムを引き継いでください。他のプロジェクトについては何も引き継がないでください。

ステップ1 — 状況を検出する

質問する前にリポジトリを検査してください。このセッションですでに提供されている明示的な回答と承認を再利用し、それらをプロファイルのデフォルト値に置き換えたり、再度質問したりしないでください。書き込む前に、解決されたアーティファクトルート、深さ、キュー、ゲート、調整/統合モードをそれらの回答に対して要約してください。ホストが選択したフォルダをサンドボックスにミラーリングする場合は、実際のターゲットパスと、検証済みの出力が選択されたフォルダにどのように到達するかを特定し、スクラッチミラーが通過したという理由だけで、未タッチのターゲットが完了したと呼んではいけません。

• フレッシュリポジトリ（ソースもドキュメントもなし）：ゼロから構築します。

• 既存リポジトリ：後付けします。

  • 変更を提案する前に、現在の README.md、CONTRIBUTING.md、AGENTS.md、CLAUDE.md、docs/、adr/、.github/ をすべて読み込んでください。
  • 既存のコンテンツを保持してください。上書きではなくマージします。既存の規約が以下の規約と競合する場合は、評価サマリーで競合を明らかにしてください。
  • ADRが別の形式ですでに存在する場合は、並列ツリーを作成するのではなく、移行計画（番号の振り直し、保持、変換）を提案してください。

• すでに docflow リポジトリ（AGENTS.md + CONVENTIONS.md + ADRカタログを保持している）：構築ではなく、既存のセットアップに追加しています。コアを再構築したり、解決済みの質問を再度尋ねたりしないでください。CONVENTIONS.md/AGENTS.md から記録された選択（ADR形状、ステータスライフサイクル、アーティファクトルート、マルチエージェントモード、およびすでに存在するオプションレイヤー）を読み取ってください。次に、まだ存在しないオプトアウトしたオプションレイヤーのいずれか（plan/、_agent/、GLOSSARY.md、domains/、または2番目のADR形状（テクノロジーテンプレート））を有効にすることを提案し、選択されたものだけを、記録されたアーティファクトルートの下にマージで書き込み、他のものはすべてそのままにしてください。新しいレイヤーに必要な質問のみを行ってください（例： _agent/ を有効にする場合の調整に関する質問 — 記録された検証ゲートとプランキューの両方を持たない単一のライターは、正しく _agent/ がまったくなくなり、そのレイヤーは単に不要になります）。これは、最初のブートストラップで延期したレイヤーを追加するためのエントリポイントです。以前のスキャフォールドによって調整ファイルがまだ残っているリポジトリは、それらをそのままにしておいてください。監査スキルがレイアウトを報告します。

  GLOSSARY.md を有効にすると、標準のシェルが書き込まれますが、決して書き換えられません。 レイヤーが選択され、ファイルが存在しない場合、templates/GLOSSARY.md から書き込みます（オプションの見出しと散文、次に生成された CONVENTIONS.md §用語集に記録されている1つの 用語 | 定義 テーブル）。ファイルがすでに存在する場合は、そのままにしておきます。レイヤーを有効にしても何も追加されず、add-convention は標準形状で既存のファイルを拡張するか、audit が同意された移行を提供します。

  2番目のADR形状の有効化はファイルコピーではなく、スキームの切り替えです。 これは、すでに記録されている選択を変更する唯一の延期されたレイヤーであるため、すべてを1回のパスで書き込むか、まったく書き込まないでください。CONVENTIONS.md の §ADR形状を2形状テキストに置き換え、テクノロジーのセクション順序と形状の箇条書きを AGENTS.md に追加し、adr/0000-template-technology.md を書き込み、形状列を含む INDEX.md を再生成します。既存のADRは番号を維持し、機能のままです。shape: フィールドがない場合はすでに機能を意味するため、ADRは書き換えられず、番号も振り直されません。切り替えの半分は、リポジトリをステップ4.5のクロスチェックが矛盾と呼ぶ状態、つまり単一形状スキームが決して選択しないテクノロジーテンプレートがある状態に置き去りにします。

  すでにレガシー範囲エンコーディングを使用しているリポジトリは、代わりに移行オファーを受け取ります。 一部の2形状リポジトリは、形状が宣言フィールドになる前にスキャフォールドされ、それを番号にエンコードしています。§ADR形状はカットオフ（機能はその下、テクノロジーはその上）を記録し、adr/ には 0000 以外の番号が付けられたテンプレート（例： adr/0100-template.md）があります。どちらかのシグナルだけでそれを識別できます。このようなリポジトリはレイヤーが欠落しているわけではありません。すでに両方の形状を持っています。そのため、上記のスキーム切り替えを提供しないでください。それを行うと、2つの競合するエンコーディングで行き詰まります。代わりに、監査スキルが使用するものと同じ条件で、宣言フィールドへの移行を提供してください。

  • まず、新旧番号マップをドライランとして表示します。機能ADRは番号を保持します。テクノロジーADRは、元の相対順序で、最も高い番号の機能ADRに続く番号を取得します。それと一緒に、それに続く参照（depends-on、supersedes / superseded-by、相対 adr/NNNN-*.md リンク、INDEX.md、ドメイン README.md リスト、plan/todo/ 所有ADR行）と、履歴として残るもの（plan/done/ フッター、コミットメッセージ、タグ）をリストしてください。
  • そのマップの明示的な確認なしには何も書き込まないでください。 拒否も有効な結果です。リポジトリは範囲エンコーディングを保持し、独自のルールに合格し続けます。
  • 確認後、監査スキルの移行ステップで指定されているとおりに移行を適用します — 番号を振り直し、すべてのADRに shape: をスタンプし、カタログ内のすべての参照を書き換え、境界テンプレートを adr/0000-template-technology.md に置き換え、§ADR形状を宣言フィールドに書き換えてシードADR例外条項を削除し、形状列を含む INDEX.md を再生成します — そして、メッセージにすべての新旧ペアをリストした1つのコミットとして着地させます。その手順が唯一の信頼できる情報源です。ここでその別のバリエーションを言い換えないでください。
  • 次に、本当に存在しないレイヤー（plan/、_agent/、GLOSSARY.md、domains/）について、通常どおり再実行を続行します。

評価質問をする前に、該当する状況を1行で述べてください。

ステップ2 — ターゲットレイアウト

<repo>/
  AGENTS.md              # コーディングエージェントのハードルール — エントリポイント
  CLAUDE.md              # ワンライナー: @AGENTS.md
  README.md              # 人間向けプロジェクトサマリー（存在すれば保持）
  CONVENTIONS.md         # 作成ルール: ADR、命名、ステータス、監査、git
  INDEX.md               # すべてのADRの生成テーブル
  GLOSSARY.md            # 共有用語（オプション — Q7参照）
  adr/
    0000-template.md     # 機能ADRテンプレート（常に）
    0000-template-technology.md  # テクノロジーADRテンプレート（2形状の場合のみ — Q2参照）
    NNNN-<kebab-slug>.md # 決定ごとに1つのADR、連続番号
  domains/<slug>/README.md   # オプション（Q7参照）
  plan/
    README.md
    todo/NNNN-<slug>.md
    done/<YYYY-MM-DD>-<slug>.md
  _agent/                # エージェント運用契約（Q5参照） — オプション
    ROLES.md             # 誰が何を書くか（複数ライターのみ）
    LOCKS.md             # ファイルクレームミューテックス（共有チェックアウトのみ）
    prompts/autonomous.md  # 無人実行の動作方法（検証ゲート — Q8 — とプランキュー — Q4a の両方がある場合のみ）
  federation.md          # マルチリポジトリのみ（Q11）: このリポジトリのバックポインタ
  federation-index.md    # マルチリポジトリのみ（Q11）: メンバーインデックス — ホームリポジトリのみ

配置。 上のツリーはルートオプションを示しています。AGENTS.md と CLAUDE.md は常にリポジトリルートに配置されます。adr/、plan/、_agent/、INDEX.md、および CONVENTIONS.md は、Q12で選択されたアーティファクトルート（デフォルトは .docflow/、例： .docflow/adr/、.docflow/plan/）の下に配置されます。

検出。 ツールは、CONVENTIONS.md を最初に読まなくてもアーティファクトルートを特定します。リポジトリルートにある .docflow/ディレクトリがルートです。他のルートの場合、ブートストラップはリポジトリルートに .docflowファイル — 1行のポインタ、root: <path>（例： root: docs/、root: .）— を書き込みます。どちらも存在しない場合は、プリコントラクトリポジトリ（ツールは docs/、次にリポジトリルートをプローブして、アーティファクトルートを指定する CONVENTIONS.md を探します）または docflow リポジトリではないことを意味します。

_agent/ はエージェント運用契約です — 誰が何を書くか、1つの実際のミューテックス、および無人実行の動作方法。gitがすでに記録しているものは何も保持しません（重複した出荷記録、進行中のもののダッシュボード、現在の状態のスナップショット、引き継ぎはありません）。上記の3つのファイルのどれが存在するかは、Q5、Q8、Q4aから完全に決定され、_agent/ ディレクトリがまったくないリポジトリも有効な結果です。

コア vs オプションレイヤー。 書き込まれるのはコアのみです。AGENTS.md、CLAUDE.md、CONVENTIONS.md、adr/0000-template.md、および INDEX.md。これらだけのリポジトリは、有効で軽量な docflow リポジトリです — 古典的なADRカタログと規約です。その他はすべてオプトインレイヤーです。plan/ キュー（Q4a）、_agent/ 契約（Q5 + Q8 + Q4a — 検証ゲートとプランキューの両方を持たない単一ライターは何も取得しません）、GLOSSARY.md と domains/（Q7）。オプションのレイヤーを省略することは、エラーではなく有効な状態です。欠落しているレイヤーを必要とするライフサイクルスキルは、きれいに拒否し、何が欠けているかを指定します。

マルチリポジトリ製品（複数のリポジトリにまたがる1つの製品 — Q11参照）の場合、federation.md（すべてのメンバーリポジトリが持つ小さなバックポインタ）と federation-index.md（ホーム/確立リポジトリのみに存在する信頼できるメンバーリスト）の2つの追加ファイルが表示されます。すべてのフェデレーションアーティファクト（federation.md、federation-index.md、および派生ロールアップ ROLLUP.md）は、設定されたアーティファクトルートの下に配置されます。スタンドアロンリポジトリにはこれらはありません。

ステップ3 — インストールする規約

1. ADRが信頼できる情報源です。 決定ごとに1つのADR。分割は、置き換える新しいADRになります。既存の範囲を拡張しないでください。
2. 最大2つのADR形状、フィールドで宣言。 2つを区別するリポジトリは、各ADRの shape: メタデータフィールド（capability または technology。フィールドがない場合は機能を意味します）に区別を記録します。番号範囲で記録することはありません。すべてのADRは、形状に関係なく次の連続番号を取得し、各形状には独自のテンプレートがあり、どちらも 0000 と番号が付けられています。
   • 機能ADR（システムが実行する必要があること）。セクション順序：メタデータ → コンテキスト → 機能ステートメント → ユーザーストーリー/シナリオ → 受け入れ基準 → 範囲外 → 未解決の質問 → 参考文献 → 改訂履歴 → 承認。
   • テクノロジーADR（どのように構築されるか）。セクション順序：メタデータ → コンテキスト → 決定 → 根拠 → 結果 → 受け入れ基準 → 範囲外 → 未解決の質問 → 参考文献 → 改訂履歴 → 承認。根拠は、検討された代替案を挙げ、具体的な拒否理由（「よりシンプル」/「より慣用的」ではありません）を示さなければなりません。
3. ステータスライフサイクル: Proposed → Accepted → Implemented → (Superseded | Deprecated)。 終端状態は、以前のどの状態からも到達可能です。ステータスはプランフォルダの配置を決定します。Accepted → plan/todo/、Implemented → plan/done/。
4. ファイル名: adr/NNNN-kebab-slug.md、4桁ゼロ埋め、連続、予約済みギャップなし。相互参照は相対パスを使用します。
5. 受け入れ基準はテスト可能で番号が付けられています。 テストは、実用的な範囲でそれらにマッピングされます。
6. 監査規律。 実質的なADR変更は、改訂履歴行を追加します。編集上の変更（タイプミス、フォーマット、リンク修正）は除外されますが、コミットメッセージで editorial としてフラグが付けられます。承認テーブルは、ADRが受け入れられたときに設定され、その後の実質的な改訂ごとに更新されます。
7. INDEX.md は、ADR変更後にADRメタデータから再生成されます。 派生物として扱い、手動編集はしません。
8. plan/ は作業キューです。 作業が出荷されるとき、git mv plan/todo/X plan/done/<date>-X、plan-item ステータスの削除、所有ADRステータスの進行、および INDEX.md の再生成は、完了コミットでグループ化されます。直接メイン統合では、そのコミットは統合ブランチにプッシュされ、移動されたファイルのフッターはHEAD SHA（および該当する場合はデプロイアーティファクトID）を指定します。プルリクエスト統合では、これらの変更はプルリクエストブランチの最後のコミットであり、準備完了とマークされる前に、フッターはプルリクエストを指定し、マージが完了イベントです。
9. 調整は契約であり、ログではありません。 _agent/ は、gitが伝えられないものだけを保持し、各モード（Q5）は正確に独自のファイルを規定します — 他には何も書き込まれません。共有チェックアウトでは、エージェントは編集前に _agent/LOCKS.md に行を追加し（<agent-id> | <path> | <ISO-8601 timestamp>）、コミット時にそれを削除します。その台帳が唯一の実際のミューテックスであり、キューアイテムはアイテム自体でクレームされます。別個のワークツリーでは、キューアイテムは claim/<item-key>（拡張子なしのキューアイテムファイル名）をプッシュし、統合がプルリクエストベースの場合はそれからドラフトプルリクエストを作成することでクレームされます。プッシュが2番目のライターを排除するものであり、台帳は保持されません。単一ライターの場合、シリアル化するものもクレームするものもありません。どのモードも、重複した出荷状態、進行中のもののダッシュボード、または現在の状態のスナップショットを保持しません。git履歴と plan/done/ が記録であり、ライブブランチとプルリクエストが進行中のものです。
10. Git契約。 Conventional Commits。ADRに触れるコミットには必須の Rationale: フッター。ユーザーがオプトアウトしない限り、署名済みコミット。ユーザーが要求しない限り、エージェント作業に対する Co-Authored-By トレーラーはありません。
11. AGENTS.md はハードルールのエントリポイントです。 CLAUDE.md は、それを読む互換性のあるエージェント向けのワンライナー @AGENTS.md です。
12. ADRは内部アーティファクトであり、ユーザーには決して表示されません。 ADR番号、ADRタイトル、およびADRカタログの存在は、ユーザーに到達する製品コードパス（UI文字列、API応答本文、エラーメッセージ、顧客に発行されるログ行、公開ドキュメント、リリースノート、マーケティングコピー、サポートコミュニケーション）に決して表示されてはなりません。ADRはビルダーのためのものであり、ユーザーのためのものではありません。参照は許可されています：コードコメント（// a…

...（準備中、完全な内容は元のSKILL.mdを参照）