woostack-plan

woostack-plan

woostack-plan は、計画ワークフロー全体を担い、GitHub のイシューを直接公開する唯一のスキルです。利用可能であれば関連するソースを使用し、新しいプロジェクトでは提示された目標、制約、調査結果を使用して、重要な未回答の決定事項だけを確定し、レビュー可能な段階に分けて成果をまとめます。依頼された場合に限り、その計画をイシューとして登録します。計画には、チェックアウト、テンプレート、前のフェーズ、追加の承認イベントは必要ありません。読み取り専用の制限については境界を参照してください。

コマンド

/woostack-plan <goal-or-partial-issue>
/woostack-plan <goal-or-partial-issue> --project <exact canonical GitHub Project URL>

--project は、既存の Project で追跡する計画について指定できる唯一の明示的な送信先セレクターです。指定しない場合、送信先は依頼と実際のコンテキストに基づいて決まります。

ワークフロー

1. 依頼と関連するコンテキストを確認します。 目標または部分的なイシューと、提示された制約を読みます。チェックアウトやリモートが存在し、依頼に関係する場合はそれらを調査し、ユーザーが指定したイシューまたは Project も確認します。計画のみを行う場合、ソースも GitHub の送信先も必要ありません。公開する前に、認可されたリポジトリと送信先をそれぞれ1つだけ確定します。タイトル、アクティビティ、慣例、未選択のデフォルトから推測してはいけません。この確定と機能の事前確認は、GitHub 公開手順に従います。
2. 関連する根拠を調査します。 ソースが存在する場合は、対象を絞ってファイル、テスト、設定、ドキュメント、関連する既知のイシューを読みます。そうでない場合は、提示された要件と、重要な技術選択に関する信頼できる調査結果を使用します。計画のためにチェックアウトを作成してはいけません。確認済みのスキーマ、インターフェース、コマンド、慣例と、提案する内容を区別します。最小コードの原則に照らして、再利用または安全な削除で依頼に対応できないか確認します。
3. 意味のある未解決の決定事項を特定します。 結果を左右する決定事項についてのみ質問します。対象となるのは、プロダクトの動作、互換性を破る変更、セキュリティまたはデータの境界、取り消せない影響、コスト、スコープです。依頼された結果に沿う通常の技術的詳細は補い、補った内容を明記します。承認の儀式を作り上げたり、ユーザーがすでに決めたことを再度尋ねたり、明示されたユーザーの選択を黙って覆したりしてはいけません。 技術選択が未確定の場合は、実行環境、レイテンシ、オフライン要件、ホスティングと運用の責任、データの一貫性と復旧、プライバシーと認証、統合、予算、チームの知識といった、実行可能な選択肢を見分ける要件だけを考慮します。現在の信頼できる情報源を調査し、適合性、互換性、重要なコストやロックインのトレードオフを確認します。提示された実行可能な技術スタックを再利用します。デフォルトの技術スタック、質問票、完全な設計を必須とする条件は設けません。
4. 一貫性のある計画を作成します。 成果全体と実際の依存関係を、小さく一貫性があり検証可能な段階に分けて示します。各段階では、観察可能な動作を1つ実現するか、重要な不確実性を1つ解消し、スコープと対象外事項を限定したうえで、関連する既存の根拠または具体的に正当化された根拠を示します。大幅に小さい段階では不十分である理由は、重要なものだけを残します。実装のチェックポイント、担当割り当て、イシュー、PR、リリースはそれぞれ異なる境界です。チェックポイントは、新たな作業者や公開用のオブジェクトを作成せずに、1つのイシューまたは計画内にとどめることができます。分離できない変更、求められる互換性の要件、アトミックな切り替えは維持します。納品を分割するためだけに一時的な橋渡しを作り上げてはいけません。計画を会話内で報告し、次に何をするかはユーザーが決めます。
5. 依頼された場合はイシューを登録します。 「イシューを登録して」「GitHub のイシューを作成して」「この計画を公開して」という依頼自体が公開の認可です。別途承認イベントを求めてはいけません。計画のみを求める依頼では何も書き込まず、計画を返します。

イシューに記載する内容

各イシューには、実現する成果、重要な制約、対象外の事項、完了を定義する受け入れ基準と検証要件、実際の前提条件を記載します。これは最低限の要件であり、固定テンプレートではありません。タスクキー、序数、マーカーブロック、親イシューの選択方針、必須のセクション順はありません。利用できる場合は既存のファイル、シンボル、インターフェースを、またはイシューの成果によって作成される予定のインターフェースを明記し、初めて読む人が作業箇所を見つけられるようにしてください。すでに担当者がいる制約は、内容をコピーせずリンクしてください。それらの参照を読んでも実装ワークフローは開始されず、実装も承認されません。

• アプリケーション境界をまたぐ成果は、 アプリケーション境界アダプターのルールに従います。
• 新たに作成する検証要件は、同梱の テストガイダンスに従います。包括的なテストスイートや割り当て件数ではなく、観察可能な契約と個別の不足点を記載します。十分な既存チェックがある場合はそれを優先します。明示された要件や、名前を挙げた重大なリスクに対して追加の証拠を提案してください。完了基準と、ドラフトの公開および利用者へのリリースに関するゲートを区別し、新たな検証インフラは提案するスコープとして明記してください。既存の無関係なイシューの受け入れ基準を書き換えないでください。

イシューに記載するコマンドやパスは、記載前に存在を確認してください。リポジトリ内に存在するか、そのイシューまたは前提となるイシューによって作成される必要があります。計画は期待事項を記録するものであり、検証を実行したり、検証に合格したと主張したりするものではありません。

公開と読み戻し

公開では実装のチェックポイントを、既存のイシューを再利用しながら一貫性のある成果単位にまとめます。チェックポイントごとにイシューを作成したり、イシューごとに PR を1つ作成するよう指定したりはしません。依頼された関係だけを、 GitHub プロファイルに記載されたホストの許可済み GitHub 機能を通じて記録してください。認証情報を読み取ったり、トークンを転送したり、独自のトランスポートを追加したりしてはいけません。変更対象となったすべてのイシューと関係を個別に読み戻してください。変更への応答だけでは、何も証明されません。

公開手順では、公開先の解決、機能の事前確認、既存イシューの再利用、応答が失われた場合に重複作成せず復旧するために保持する作成 ID、およびホストが書き込めないネイティブな関係の代わりとなる閲覧可能なインデックスを扱います。必須のネイティブなグラフを作成できなかった場合は未完了のままとし、Plan は公開済みとせず、その旨を明記します。Project の選択が明示されている場合は、公開したイシューをメンバーとして追加します。Project 自体を作成することはありません。また、個別の依頼がない限り、Status、ライフサイクル、受け入れに関する変更は行いません。

境界

計画は、依頼で承認されたイシューの公開を除き、読み取り専用のままです。Plan は実装ソースを編集せず、ブランチ、ワークツリー、コミット、PR を作成せず、実装作業やオーケストレーション作業を指示せず、マージもしません。人が作成した内容、既存のイシュー ID、無関係なイシュー、ラベル、履歴を維持します。つまり、計画を記載するイシューの部分だけを編集し、それ以外には手を加えません。何かをクローズ、再オープン、再割り当てすることはなく、実装、デリバリー、チェックの合格、製品としての受け入れ、マージを主張することもありません。

返却内容

計画として、段階、成果、制約、受け入れ基準、実際の前提条件を返します。また、解決済みの場合はリポジトリと公開先、確認したソースや調査内容、決定事項、未解決の質問も含めてください。公開後は、実際のイシュー URL、再利用したものと新規作成したもの、読み戻しの結果、記録した関係、未解決の事項を追加します。ユーザーが希望する場合、オーケストレーションのヒントは別の提案として提示します。

/woostack-orchestrate --issue <verified canonical issue or tracker URL>
/woostack-orchestrate --project <verified canonical Project URL>

このヒントは作業の指示ではありません。Orchestrate は、見つけたイシューを自ら読み取り、順序を決定します。