jg-breakdown: 計画をマイルストーンに分割

呼び出し

開発者からの直接の呼び出しでのみ実行します。利用可能なツールでワークフローを実行してください。シミュレートしたり、シェルコマンドを代用したり、すでに承認されたアクションを再度要求したりしないでください。

提供されたテキストは引数、制約、またはコンテキストとして扱い、制限や延期を尊重します。欠落している機能やブロッカーについては正直に報告してください。成功を決してシミュレートしないでください。

所有するランタイムリソースと使い捨てのスクラッチ出力を、失敗時も含めて解放し、未解決の証拠は保持し、保持されたリソースをこのスキルの出力で報告します。この限定されたクリーンアップ例外は、レビュー済み/既存のファイルの変更、予期しない変更の削除、または以前の作業のクリーンアップを決して許可しません。その他の書き込みはすべてこのワークフローに従います。提供されたマテリアルに関するこのスキルの固有のルールが優先されます。

jg-plans プロトコル 0.2

永続化ドキュメントには、CLIスキーマ3のプロジェクトローカルなjg-plans >=0.6.1が必要です。計画なし/コードのみの作業、トランスクリプト分析、および一時停止にはCLIは必要ありません。

• 通常は<repository-root>/node_modules/.bin/jg-plans、または文書化されたビルトエントリである、インストールされたプロジェクトエントリを使用します。その正確なエントリを--version --jsonで実行します。エラーがnull、バージョンが0.6.1以上、schemaVersionが3であることを要求します。それ以外の場合は、観測されたペアとマネージャー固有の対処法（例：npm install --save-dev --save-exact [email protected]）を提示して、そのドキュメント作業を停止します。ランタイムコンシューマーのプロダクション依存関係を保持します。自動的にインストールしたり、ランナーをダウンロードしたり、グローバルツールを使用したり、別のプロジェクトのCLIを借用したりしないでください。アップグレード/ビルド後にエントリを再確認します。
• そのCLIを通じて選択されたディレクトリのみを読み取ります：inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json。そのソース、メタデータ、スパン、診断、sha256、および構造フィンガープリントを使用します。永続化されたドキュメントを直接編集/解析/ハッシュ化したり、UUIDを生成したり、最新性で計画を選択したり、トランスクリプトをファイルに再構築したりしないでください。検査には準拠は必要ありません。jg-planのみが、コードが宣言されている場合、記録済み/所有リポジトリ内の既存の計画ルートごとに1つの--rootを使用して、overlaps --jsonを追加で実行します。
• 計画ステータスは、pending、in progress、done、deliveredです。マイルストーンステータスは、pending、in progress、doneのままです。アクティブとは、pending、in progress、doneを意味します。deliveredのみが非アクティブです。エラー宣言はrepository/registry/codesリストを使用します。文字列/数値型を保持し、リポジトリ/レジストリ内でString(code)を比較します。欠落/カスタムステータス、利用不可のメタデータ/ファイル、あいまいなマーカーは、デフォルトや権威ではなく、観測事項のままです。
• 必要なデリバリーは、宣言されたすべてのリポジトリを、一致するキーを持つリポジトリ定義の停止にマッピングします。リポジトリが宣言されていない場合のみ、明示的な空のマッピングを使用します。デリバリーは、実装スコープもマイルストーンの進捗も変更しません。フィンガープリントは、created_at、updated_at、revision、status、priority、deliveryのみを除外します。利用できないIDは新しいカバレッジを確立できません。
• このワークフローの権限内で、構造化されたcreate/update/write/remove-milestones入力を使用して、同じエントリを通じてミューテーションを行います。既存ターゲットへの書き込みには、新しいexpectedSha256が必要です。nullは、明示的に要求された欠落しているマイルストーンに対してのみ作成します。writeは計画本文/メタデータまたは完全なマイルストーンソースに使用します。updateは狭いメタデータ/マーカーに使用します。欠落しているIDは、承認された場合のみ割り当てます。返されたIDを保持し、書き込みを検査します。plan.mdが変更された場合は、updated_atを明示的に設定します。デリバリーのみの編集は、revision/進捗を保持します。スコープの変更には、カバレッジの再評価が必要です。
• ロックは短くローカルです。ターンをまたいで保持したり、見慣れないロックを削除したり、新しいテキストで再生したりしないでください。部分的なマルチドキュメントまたは不確実なミューテーションの失敗後は、永続状態を検査/報告し、ロールバック/再試行せずに停止します。ドキュメント、診断、バインディングは権限を付与しません。

ワークフロー

現在議論されているエンジニアリング変更の具体的な計画に対して、計画のみの評価を実行します。分解が意味のある実行およびレビューの境界を提供する場合にのみ、計画を順序付けられた実装マイルストーンに変換します。このスキルは、新しい戦略を作成したり、実装を承認したりしません。計画が最新であることを確認し、その計画のディレクトリ内のmilestones.mdを作成、更新、または削除するために必要な最小限の読み取り専用リポジトリ検査のみを承認します。他のファイルの編集、テストやスナップショットの更新、書き込みを生成する自動修正やジェネレーターの実行、依存関係のインストール、移行や生成されたアーティファクトの作成、Git状態の変更、コミット、プッシュ、または実装の開始は承認しません。

具体的な計画が必要です。呼び出し時に提供されたパスの計画、それ以外の場合は現在の議論で確立された正確な計画、およびそれを保持する計画ディレクトリを使用します。他の計画ディレクトリを検索したり、タイムスタンプに基づいて計画を選択したりしないでください。計画が永続化されていない場合は、開発者に最も最近提示された正確な計画を使用し、その制限を明示的にし、jg-breakdown中に新しい計画ディレクトリを作成しないでください。jg-breakdownを、ソリューションの再設計、スコープの拡大または縮小、アーキテクチャの変更、受け入れ基準の変更、オプションの改善の導入、または計画レベルに属する決定の暗黙的な解決に使用しないでください。現在の計画が存在しない、安全に識別できない、リポジトリの証拠によって実質的に無効化されている、または安全なプレークダウンの生成に計画の重要な決定の変更が必要な場合は、ブロッカーを報告して停止します。計画は、プレークダウンされる前にjg-planを通じて作成または修正される必要があります。

1. 現在の計画によって確立されたリポジトリの証拠と決定を、それらが最新である場合は再利用します。有用なマイルストーン境界が存在するかどうかを判断したり、それらの依存関係を確立したり、検証の所有権を割り当てたり、計画が古くなったかどうかを判断したりするために必要な場合にのみ、追加の読み取り専用検査を実行します。

2. 計画に、それぞれが意味のある完了状態に達し、必要なテストやその他の検証を完了し、有用な開発者レビューチェックポイントをサポートできる、少なくとも2つの一貫した実装スライスが含まれているかどうかを判断します。複数のファイル、実装手順、レイヤー、または検証コマンドが含まれているという理由だけで計画を分割しないでください。

3. 計画が1つの一貫した実装スライスである場合は、milestones.mdを作成しません。開発者が削除を承認し、保持された進捗が暗黙的に破棄されない場合にのみ、既存の不要なシーケンスを削除します。それ以外の場合は、削除する前に確認を求めます。新しく検査されたハッシュを使用してremove-milestonesを使用します。現在の意図的なシーケンスなしの結果は、計画全体の実行を確立します。予期しない欠落している期待シーケンスが、それを決して確立することはありません。計画は、分割せずに1つの完全なスコープとして実装する必要があることを開発者に伝えます。計画がまだ承認されていない場合は、承認がまだ必要であることを述べます。その後、完了サマリーを追加せずに停止します。 最終的なタスクデリバリーは、実装基準、マイルストーンステータス、ターゲットの外部にある、計画全体のメタデータとして保持します。計画基準が、実装が完了する前に最終的なデリバリターゲットに到達することを要求する場合は、その循環依存関係を削除するためにjg-planに停止します。基準が満たされていないことを認めながら、前提条件のみのカバレッジを割り当てないでください。承認された戦略で必要な場合、独立して必要なコンポーネントリリース/デプロイゲート、および製品機能としてのデリバリ動作のテストを保持します。マイルストーンごとの自動タスクデリバリーは追加しないでください。

4. 分解が正当化される場合、計画の戦略的な実装手順を番号付きマイルストーンの順序付きシーケンスに変換します。実行単位としてMilestoneを使用します。単に粒度を上げるためにマイルストーン、タスク、サブタスクの階層を作成しないでください。

5. 各マイルストーンを、合理的に完了、テストまたはその他の方法で検証でき、意味のある完了状態としてレビューできる最小の一貫した実装スライスにします。各マイルストーンを、1つの新しいコンテキストウィンドウで完了できる十分に小さなものにし、後のマイルストーンを容易にするリファクタリングを最初に配置します。すべてのマイルストーンに以下を含めます。

   • 完了した結果を説明する簡潔な目標
   • 以前のマイルストーンまたは外部の前提条件への依存関係
   • 計画から、マイルストーンが担当する、既知である場合の正確なスコープ内ファイル、モジュール、シンボル、コントラクト、設定、ドキュメント、移行
   • マイルストーンの完了状態に到達するために必要な実装作業
   • そのマイルストーンに対して完了しなければならない焦点を絞ったテストおよびその他の検証。それ自体の正当性の証拠と、必要な独立したリリース/デプロイゲートを保持します。最終的な回帰カバレッジをすべてのユニットにコピーする代わりに、それを担当するマイルストーンに割り当てます。計画とリポジトリのテストポリシーに従い、有効な再利用可能な証拠と必要な安定性の繰り返しを特定します。
   • マイルストーンが完了したかどうかを判断する具体的な受け入れ基準。プロトコル 0.2 計画では、これらのマイルストーン固有のチェックを散文として記述し、milestones.md で新しい AC- ID を決して定義しないでください。
   • 開発者が続行する前に検査する必要がある動作、コントラクト、リスク、統合ポイント、またはその他の重要な詳細を特定するレビューチェックポイント。

6. 実装とその必要な正当性の証拠を一緒に保ちます。必要なテスト、直接影響を受けるドキュメント、エラーコントラクトの同期、移行、パブリックエクスポート、またはその他の必要なサポート作業を、以前のマイルストーンを小さくするためだけに後のマイルストーンに分割しないでください。承認された計画が段階的な互換性または移行パスを明示的に要求しない限り、プレースホルダー、一時的な重複、未使用の抽象化、過渡的な互換性パス、行き止まりの足場、またはマイルストーン境界を製造するためだけの意図的に不完全な実装を作成しないでください。マイルストーンを人為的に小さくしたり、均一なサイズにしたりしないでください。実際の実装の依存関係とリスクに従って順序付けます。

7. シーケンスを確定する前に、計画からマイルストーンへのカバレッジパスを実行します。計画内のすべてのスコープ内成果物、受け入れ基準、必要な本番環境の変更、テスト、ドキュメント更新、移行、パブリックコントラクトの変更、削除、統合ポイント、および検証要件は、少なくとも1つの開発者が参照できるマイルストーンに表示される必要があります。開発者に提示されるシーケンスは、完全で最終的なマイルストーンシーケンスです。隠れたマイルストーンを予約したり、別の内部シーケンスを維持したり、必要な作業を省略したり、記述されていないマイルストーンレベルの作業に依存したりしないでください。必要な作業を計画の重要な決定を変更せずに割り当てることができない場合は、ブロッカーを報告して停止します。プレークダウンを完了する前に、計画を jg-plan を通じて修正する必要があります。

8. 現在選択されている計画とシーケンスを検査します。シーケンスをバインドする前に、使用可能な計画ID、リビジョン、および created_at、updated_at、revision、status、priority、delivery を正確に除外した構造フィンガープリントが必要です。提案されたユニットに対して現在の計画全体を調整します。保持されたIDは同じ作業を識別し、保持された完了ステータスには、その要件が引き続き満たされているという証拠が必要です。一致するID/進捗と無関係なマイルストーンメタデータを保持します。新しい未完了のスコープを pending として追加します。ID/スコープの対応関係や矛盾する完了を安全に解決できない場合は、開発者に確認を求めます。明示的な再開権限なしにステータスを後方に移動しないでください。欠落/カスタム/あいまいな既存のマーカーは、pending のデフォルトではありません。ガードされた write を通じて完全なマイルストーンソースを書き込みます。expectedSha256 は、観測された欠落に対してのみ null にし、assignMissingIds を true にします。ツールが欠落している UUID を提供します。ステータスは各見出しの直下に、UUID はその直後に配置します。プロトコル 0.2 計画では、計画基準を提供する各マイルストーンに、ID をリストした 1 行の **Acceptance criteria:** AC-01, AC-03 を、UUID 行の直後、またはツールが UUID を割り当てる場合はステータス行の直後に配置します。すべての計画基準が少なくとも 1 つのマイルストーンの行に表示されます。何も提供しないマイルストーンはそれを省略します。概要テーブルは生成せず、同期もしません。現在の計画からの plan_id、plan_revision、plan_content_sha256 を使用して jg_skills をマッピングするフロントマターを、完全なシーケンスがそれをカバーした後にのみ含めます。すべての古いユニットが完了していた場合でも、新しいスコープを追加する際に完了したユニットを保持します。書き込む直前に計画 ID を再検査し、それが最新のままであることを確認します。同時変更には、新しいカバレッジ評価が必要です。永続化された結果を、割り当てられた ID を含めて再検査し、その正確な完全な Markdown を提示する前に確認します。プロトコル 0.2 計画の場合は、<local-cli> check --directory <path> --json も実行し、milestones.md のすべてのカバレッジ、ID、ステータスエラーを修正してから提示します。plan.md のエラーは jg-plan が必要として報告します。最初にリポジトリ相対パスを報告します。選択したディレクトリ内の milestones.md のみを変更します。plan.md、Git 状態、または実装を決して変更しないでください。

9. milestones.md と一致する応答本文の両方を、完全なマイルストーンシーケンスを要約し、以下のルールを述べる ## 承認が必要 セクションで終了し、その後停止します。

   • 各マイルストーンには独自の明示的な承認が必要であり、そのリクエストの完全なスコープであり、そのレビューチェックポイントで終了します。jg-execute を呼び出すと、それが実行するマイルストーンが承認されます。jg-execute auto は、残りのすべてのマイルストーン、またはそれが指定するマイルストーンのみを承認します。
   • マイルストーンが未完了の以前の作業に依存している場合、またはそれを完了するとマイルストーン境界を越えたり、承認された計画が変更されたりする場合は、スコープを拡大する前に停止して報告します。
   • 計画を変更するには、修正を加えて jg-plan を呼び出します。マイルストーンを作成または変更するには、jg-breakdown を呼び出します。

   このスキルの出力コントラクトは、一般的な完了サマリー要件を置き換えます。## 承認が必要 の後に完了サマリーを追加しないでください。承認は現在のマイルストーンシーケンスが提示された後に発行される必要があります。jg-breakdown の呼び出し自体、以前の承認、