woostack-init

woostack-init

ユーザーが、正確で、リポジトリ固有の、意思決定に役立つ、簡潔で保守しやすいルート README とプロジェクトガイダンスを作成または改善できるよう支援します。質問する前に調査し、書き始める前に相談し、機能している部分を維持し、依頼者が許可した変更のみを適用してください。再実行しても変更がない場合があります。

コマンドと対象範囲

/woostack-init [path]

デフォルトの目的は、ルートの ARCHITECTURE.md を含む、ガイド付きのドキュメント作成です。1つのドキュメントに限定した依頼や、レビュー、計画、草稿の依頼にも対応してください。アーキテクチャのみの依頼では、ほかのルートドキュメントを編集しないでください。Doctor によるサポート不足の案内を含め、ローカルサポートのセットアップまたは修復が明示的に依頼された場合は、ドキュメントに関する相談を行わず、ローカルサポートに直接進んでください。両方の目的が依頼された場合は、それぞれの許可と検証を分けてください。

ドキュメント作業に .woostack/、GitHub ポリシーの検証、Doctor、GitHub へのアクセス、依存関係のインストールは必要ありません。サポートの不足や、無関係な設定の形式不備によって草稿の作成を妨げてはいけません。関連するサポート作業でのみ、サポートヘルパーとコントラクトを読み込んでください。

ガイド付きの作成

1. 根拠を確認します。 対象と依頼された範囲を特定し、変更しないでください。関連する会話上の決定事項、既存のルートおよび対象範囲別のエージェント指示、README／コントリビューター向けガイダンス、プロダクト／デザイン／アーキテクチャ文書とその正本、代表的なソースコード、エントリーポイント、マニフェスト、設定、スクリプト、CI を確認します。 現在の理解、対象範囲内で作成・更新・維持する必要がある文書、および現状を保つべきものについて、簡潔な冒頭の要約を用意します。実装として確認できたこと、文書に記された意図、提案する方向性を区別し、矛盾があれば、黙って一方を選ぶのではなく明示します。既存の指示の権限と適用範囲を尊重してください。 検証ガイダンスが対象範囲に関係する場合は、リポジトリで実際に使われているツール、コマンド、指示、CI、テストスイート、利用可能な所要時間の根拠を確認し、実証されたボトルネックと未測定の懸念を区別します。十分な検証環境であれば、何も変更しない判断も妥当です。
2. 草稿作成の前に相談します。 冒頭の要約を提示して話し合いを始め、リポジトリの情報に基づいた質問をして、文書の草稿作成や書き込みに着手する前にユーザーの回答を待ちます。既存のリポジトリが十分に整っているように見える場合でも同様です。文書の初期作成や更新を一般的に依頼されても、この相談を省略する許可にはなりません。また、通常の編集許可によって、この相談が暗黙のうちに免除されることもありません。一般的な依頼の場合は、対象文書に関係する以下の項目について話し合います。意図（リポジトリの存在理由、対象ユーザー、解決すべき問題、望ましい成果、対象外とすること）、全体構成（主要なアプリ、パッケージ、モジュール、文書の意図された編成と責任、意図的に維持すべき既存の構成）、方向性（短期的な優先事項、長期的な目標、プロダクトおよびデザインの原則、制約、トレードオフ）、アーキテクチャ（意図された境界、依存関係、重要なやり取りとデータフロー、およびソースコードだけでは確認できない根拠）です。これらは話し合う項目であり、固定された質問集ではありません。リポジトリから事実を確認し、それらの事実の背後にある意図や理由について質問してください。対象を絞った更新では、関連する決定事項のみを相談し、無関係なリポジトリ全体の聞き取りに広げません。 AGENTS.md が対象範囲に含まれる場合は、プロジェクトの段階と実際の利用者、互換性に関する約束（「なし」と確認された場合も明示）、変更後も保持すべきデータや環境、または明確に破棄可能なデータや環境を確認します。これらはそれぞれ別の決定事項です。未リリースであることやバージョンが 0.x であることだけでは、利用者がいないことも、データを破棄可能であることも確認できません。ユーザーが明示的に変更しない限り、既存の約束を維持し、未解決の回答は未解決のまま扱います。確認済みの決定事項を実務的な指示に落とし込むには、AGENTS.md のガイダンスを参照してください。 最初は対応可能な範囲の質問を提示して、回答を待ちます。回答ごとに理解を更新し、先行する回答（既存コードから推測した前提と矛盾する回答も含む）に応じた追加質問を選びます。固定のチェックリストを機械的に進めるのではなく、影響、矛盾、重要な未決事項を明確にします。すでに得られた回答は再利用してください。過去の回答で関連する決定事項が確認済みの場合は、そこから導かれる理解を提示し、変更したい点があるかどうかを尋ね、聞き取りをやり直さないでください。必要に応じて推奨事項やトレードオフを提示し、重要な決定事項は、確定したかのように扱わず、明示的に保留します。未回答の質問と同じターンで文書を作成・変更してはいけません。質問なしで進めるよう明示的に求められた場合は、その依頼に従ってください。エージェント自身の確信度が高いことは例外の理由になりません。回答がない場合は、確認できた根拠に基づいてのみ草稿を作成し、未確認の事項は決めつけず未解決として示します。 検証に関する推奨事項は、テストの原則に従います。まず重複作業をなくし、標準機能を設定して活用することを優先してください。必要性がある場合に限り、現時点で信頼できるエコシステムの情報源を調べます。妥当な既存の選択を尊重し、互換性、正確性、実行コスト、移行の手間、保守性を比較します。現在の設定、合意済みの方向性、未実施の推奨事項を区別し、トレードオフと検証方法を示します。測定されていない高速化を事実のように主張してはいけません。
3. 対象を絞ったガイダンスを作成します。 合意された理解に基づいて草稿を作成し、現在の実装、合意済みの将来的な方向性、保留中の決定事項を区別します。提案中または保留中のアーキテクチャを、すでに実装済みであるかのように記述してはいけません。プロダクト→デザイン→エージェント指示の順で草稿を作成する方法は有用ですが、必須ではありません。各文書の責任範囲と、該当する文書スキーマを使用してください。欠けているガイダンスを作成し、空またはプレースホルダーだけの内容を根拠のあるガイダンスに置き換えるか、有用なプロジェクト固有の記述を維持しながら対象を絞って修正します。 古くなった内容、矛盾する内容、重複する内容を特定し、生成された内容をさらに追加するのではなく、削除の対象として扱います。正本となる仕様、アーキテクチャ上の決定、デザインシステム、コントリビューター向けガイダンスを複製せず、リンクしてください。確立済みの文書を置き換える前に、統合を提案します。コマンド、メトリクス、アーキテクチャ上の根拠、確定した決定事項を捏造してはいけません。導入済みのツールについては、リポジトリのマニフェストと CI 設定を正本とします。コマンドの存在、作業ディレクトリ、実行条件を確認して記録し、現在のコマンドと提案中のコマンドを文書スキーマに従って区別します。対象範囲別の指示を維持してください。
4. 重要な変更をレビューし、許可された編集を行います。 プロダクトの方向性、デザインやアーキテクチャ上の制約、エージェントの権限に関する変更を明示し、提案内容を提示します。すでに与えられた許可を再利用し、見出しや段落ごとに承認を求める手続きを追加しないでください。レビューのみ、草稿作成のみ、または計画のみの依頼では、何も書き込みません。承認されていない対象範囲の拡大は、提案にとどめます。 ツールおよび検証に関する推奨事項は、境界に従い、助言として扱います。無関係な作業、ファイルの所有者、既存のファイル／シンボリックリンクの関係を維持してください。リンクされた対象を編集する前に、その対象の実体と編集許可を確認し、リンク自体を置き換えたり、安全性が確認できないパスや曖昧なパスを通じて書き込んだりしてはいけません。書き込みが阻まれても、草稿の提示は可能です。
5. 対象範囲内で検証します。 該当するスキーマ、影響を受ける文書間の整合性、参照先のパス／リンク、技術的な記述を、現在のリポジトリの根拠と照合します。形式バージョンを追加する前に、その形式であることを確認します。適用できる範囲の制約と、未解決の変換を報告してください。依頼とプロジェクトの規則で許可された、安全で関連性のあるチェックを行い、調査したコマンドと実際に実行したコマンドを区別します。 説明文の検証のために、無関係なセットアップ、ネットワーク操作、副作用のあるコマンドを実行してはいけません。
6. 結果を報告します。 作成、更新、意図的に維持、または変更を阻まれた内容、検証の根拠、未解決の決定事項を示します。未実施の推奨事項、トレードオフ、検証方法は、現在の設定や合意済みの方向性とは分けて報告します。文体の目新しさを理由に書き換えるのではなく、適切なガイダンスはそのまま維持してください。

ドキュメントの役割

網羅的なテンプレートや、すべてのプロジェクトに同じ質問票を使うのではなく、現在適用されるドキュメント形式を使用してください。関係のないセクションは省略してください。DESIGN.mdで確立されているアーキテクチャ重視の意味は維持してください。ビジュアル形式はその意味に取って代わるものではありません。

ドキュメント	目的	役立つ内容
README.md	このプロジェクトとは何か、使い始めるにはどうすればよいか。	README の要件：根拠に裏付けられたプロジェクトの概要、検証済みの最短の初回利用手順、代表的な使用例、正式なドキュメントやポリシーへの案内。
PRODUCT.md	何を、誰のために、なぜ作るのか。	プロダクトの記録：ユーザー、目的、運用環境、機能、制約、確認済みの原則。現在の対象範囲と将来の方向性は分けてください。
DESIGN.md	プロダクトはどのように機能し、どのような印象を与えるべきか。	該当する場合はビジュアル形式：確認済み、または合意済みのアイデンティティ、トークン、コンポーネント、使用方法。ドキュメントがすでにシステム設計上の決定を正式に扱っている場合は、それらを維持してください。
ARCHITECTURE.md	変更はどこに置くべきか、各部分はどのように連携するか、どの境界を維持すべきか。	技術的な概要：主要な責務と経路、重要な関係とフロー、制約、裏付けのある意思決定へのリンク。
AGENTS.md	エージェントはこのリポジトリでどのように効率よく作業すべきか。	バージョン管理対象外の運用 Markdown：実際のコマンドと作業ディレクトリ、条件付きの検証、境界、注意点、詳細なドキュメントへのリンク。

AGENTS.mdは運用に関する内容に限定してください。プロダクト仕様の複製、網羅的なファイル一覧、一般的なコーディングのアドバイス、重複する Woostack のワークフローは記載しないでください。AGENTS.mdも許可された対象範囲に含まれる場合は、該当する箇所でPRODUCT.md、DESIGN.md、ARCHITECTURE.mdへの短い条件付き案内を追加するか、内容を改善してください。たとえば、コンポーネントの境界やコンポーネント間のフローを変更する前など、アーキテクチャに関するガイダンスを読むべきタイミングを説明してください。内容を複製したり、自動的に読み込まれると想定したりせず、リンクしてください。Woostack の導入時にAGENTS.mdを作成または更新する場合は、以下の文言をもとに、利用可能性を考慮した簡潔な案内文をローカルに作成し、Woostack の無条件の利用要件やインストール要件を置き換えてください。

Use woostack skills when available. At the start of work, `using-woostack` may load
project rules and route `/woostack-*` requests to the matching installed skill when it
is installed; it is an optional navigation aid, not a conduit. Each installed skill
carries its own activation, authority, approval, and completion behavior, so a missing
router or sibling skill must not block ordinary repository work. If woostack skills
are unavailable, follow this file and continue ordinary work with the host's available
capabilities; installation is not required. For an explicit `/woostack-*` command whose
skill is unavailable, name the missing skill and ask whether to install it or proceed
without it before continuing.

Follow this file first when it conflicts with generic agent defaults.

導入時の成果物では、別のスキル、ソースのチェックアウト、共有ランタイムを必須にしないでください。ワークフローのカタログを複製したり、スコープ別の指示を統合したりしないでください。

ローカルサポート

この補助パスは、明示的なサポートの初期化／修復に限って使用します。ローカルのみで完結し、プロバイダーを使用せず、製品や設計に関する判断やドキュメントの編集も必要ありません。

1. 正規の対象リポジトリを変更せずに特定します。リポジトリのルート、ブランチ、作業状態、既存の .woostack/ ファイル、競合／シンボリックリンク／パスの安全性を確認します。

2. scripts/config/resolve-config.sh を使用して、適用されるローカルポリシーを特定します。追跡対象の .woostack/config.json と、オプションのプライマリチェックアウトにある .woostack/config.local.json を統合し、オプションの正規 github オブジェクトを検証して、ユーザーが所有する無関係な設定を保持します。成果物の仕様で、設定フィールド、優先順位、検証、および保持されるレガシー設定の保護を規定しています。

3. 選択したサポート範囲内で、不足しているサポートパスのみを作成します。

   • templates/config.json を元にした .woostack/config.json。
   • Doctor、監査、QA 用のローカル診断レポートルート。
   • ワークツリーの仕様で宣言されたワークツリー／復旧サポート。

   既存のサポートへの修復を提案する場合は、許可された変更セット内に限ります。ユーザーが所有する設定を上書きしないでください。委任にはホストが公開するエージェントを使用します。Init はプロジェクトのエージェント定義を作成、検証、修復しません。同梱の OMP ホストに関する注意事項で、以前のリリースが生成した変更のない定義に対する任意のクリーンアップ方法を規定しています。

4. サポートの作成または修復後に、同梱の変更を加えないサポートチェッカーを --check <target> で実行します。これはローカル手順であり、Doctor ワークフローではありません。この実行で作成または修復したパスについて、権限、レポートルート、相互リンクも検証します。危険なパス、権限、競合、不正な正規設定、不完全なチェック、または対象のサポート操作に関する不完全な復旧証拠がある場合は、安全側に停止します。無関係なドキュメントの作成は停止対象ではありません。

5. 作成、修復、保持、スキップ、ブロックされたサポートパスと、正確な検証結果を報告します。GitHub のオーナー、Project、Status フィールド、Issue、公開先を推測したり、プロバイダーに連絡したり、リモート永続化を選択したりしないでください。

既存の .woostack/tmp/runs/、レガシーの下書き、マニフェスト、ロック、レポート、リモート記録は、過去からのユーザーデータです。これらからインポート、書き換え、削除したり、ラッパーを再作成したりしないでください。成果物の仕様で、これらの保護と、オプションの読み取り専用履歴リーダーを規定しています。不明または不完全な結果の場合は、最後に個別確認できた境界で停止します。

境界

Init が作成するのは、許可されたプロジェクトガイダンスと明示的なローカルサポートであり、アプリケーションのソースコードやスキャフォールドではありません。ツールに関する推奨は助言にとどまります。Init はパッケージをインストールせず、パッケージマニフェスト、ロックファイル、CI ワークフローを書き込んだり更新したりせず、実装の引き継ぎも予定しません。それらの実装には別途許可が必要です。Issue、Project、ブランチ、コミット、プルリクエスト、ライフサイクル状態を作成しません。また、プッシュ、マージ、認証情報の読み書き、保持データの移行、破壊的なクリーンアップも行いません。セッション名付け用のホスト拡張機能や .omp/ も作成しません。ユーザーが所有するファイル、レガシー設定、保持された記録、変更のあるワークツリー、レポートはすべて保持します。