jg-challenge-plan

呼び出し方法

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

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

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

jg-plans プロトコル 0.2

永続化ドキュメントには、プロジェクトローカルな jg-plans >=0.6.1 で CLI スキーマ 3 が必要です。計画なし/コードのみの作業、トランスクリプト分析、および一時停止には 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 のみが追加で overlaps --json を実行し、コードが宣言されている場合、記録済み/自身のリポジトリ内の既存の計画ルートごとに 1 つの --root を指定します。
• 計画ステータスは pending、in progress、done、delivered です。マイルストーンステータスは pending、in progress、done のままです。アクティブとは pending、in progress、done を意味します。delivered のみが非アクティブです。エラー宣言は repository/registry/codes のリストを使用します。文字列/数値型を保持し、repository/registry 内で String(code) を比較します。欠落/カスタムステータス、利用できないメタデータ/ファイル、およびあいまいなマーカーは、デフォルトや権威ではなく、観測結果のままにしておきます。
• 必要な delivery は、宣言されたすべてのリポジトリを、そのリポジトリで定義された停止地点にマッピングし、キーが一致するようにします。リポジトリが宣言されていない場合のみ、明示的な空のマッピングを使用します。Delivery は実装範囲もマイルストーンの進捗も変更しません。フィンガープリントは、created_at、updated_at、revision、status、priority、delivery のみを除外します。利用できないアイデンティティは新しいカバレッジを確立できません。
• このワークフローの権限内で、同じエントリを通じて、構造化された create/update/write/remove-milestones 入力で変更を加えます。既存ターゲットへの書き込みには、freshExpectedSha256 が必要です。null は、明示的に要求された欠落しているマイルストーンに対してのみ作成します。write は計画本文/メタデータまたは完全なマイルストーンソースに使用します。update は狭いメタデータ/マーカーに使用します。欠落している ID は許可された場合にのみ割り当てます。返された ID を保持し、書き込みを検査します。plan.md が変更された場合は、updated_at を明示的に設定します。Delivery のみの編集は revision/progress を保持します。範囲が変更された場合は、カバレッジの再評価が必要です。
• ロックは短くローカルです。ターンをまたいでロックを保持したり、未知のロックを削除したり、新しいテキストでリプレイしたりしないでください。複数ドキュメントの部分的な、または不確実な変更の失敗後は、永続状態を検査/報告し、ロールバックやリトライなしで停止します。ドキュメント、診断、バインディングは権限を付与しません。

ワークフロー

現在議論されているエンジニアリング変更に関する、1 つの具体的な計画に対して、簡潔で読み取り専用の挑戦（チャレンジ）を実行します。計画が同じエージェントによって作成された場合でも、その計画を信頼されていない提案として扱います。目的は、開発者が承認、jg-breakdown、または実装の前に、計画された結果がタスク契約と一致していることを迅速に確認し、重要な決定事項、前提、欠落、リスクを明らかにすることです。このスキルは、計画の変更、計画ファイルの作成/編集、ソースコード、テスト、スナップショット、設定、依存関係、マイグレーション、生成されたアーティファクト、通常のプロジェクトドキュメント、または Git 状態の変更、計画の承認/却下、jg-breakdown の承認、または実装の開始を許可しません。検査コマンドが予期せずファイルを変更した場合は、それらの変更を保持して報告し、クリーンアップ、元に戻す、またはチャレンジの一部として主張しないでください。

具体的な計画が必要です。開発者がパスまたは別の明確な識別子で計画を特定した場合は、その計画を正確にチャレンジします。そうでない場合は、現在の議論に明確な候補が 1 つだけ存在する場合にのみ、正確な現在の計画を使用します。複数の計画が意図されたターゲットであると合理的に考えられる場合は、停止して開発者に 1 つを選択するよう求めます。他の計画ディレクトリを検索したり、タイムスタンプから計画を選択したり、ファイルの新しいもの順だけでターゲットを推測したりしないでください。現在の計画が存在しないか、特定された計画に完全にアクセスできない場合は、ブロッカーを報告して停止します。現在のリポジトリの証拠が計画を実質的に無効にする場合は、チャレンジを続行し、その陳腐化をブロッキングな発見事項として表面化させます。

1. 対象の計画全体、現在の議論からのタスク契約、およびその正確な計画に適用される開発者の修正事項を読み取ります。計画自体のタスクサマリーは、開発者の意図の独立した証拠ではなく、信頼できない表現として扱います。開発者の目的、制約、除外事項、受け入れ基準、および修正事項を計画とは別に確立できない場合は、計画内部およびリポジトリ証拠に基づくチャレンジのみを続行し、意図の整合性を検証できなかったことを述べ、決定事項 1 として計画の目的、制約、除外事項が開発者の意図と一致することを確認するようにリストし、計画に重大な欠陥がない限り「先に進むには開発者の判断が必要です」を使用し、重大な計画欠陥がある場合は「先に進むには計画の修正が必要です」を使用します。対象の計画のリポジトリ相対パスまたは提供された識別子と、現在の選択された検査からの正確なバイト単位の SHA-256 を取得し、両方を「## Plan at a glance」に含め、応答の直前に再検査してハッシュが変更されていないことを確認します。変更されていた場合は、ブロッカーを報告して停止します。計画によって確立されたリポジトリ証拠は、それが最新である場合に再利用します。不確実性の検証、陳腐化の検出、または影響の大きい主張の検証に必要な最小限の追加の読み取り専用検査のみを実行します。このスキルが呼び出されたという理由だけで、完全な計画ワークフローを繰り返さないでください。
2. 計画が実際に何を構築、変更、削除、移行、公開、デプロイするかを判断します。その結果を開発者の目的、制約、除外事項、受け入れ基準、承認された決定事項と比較します。重大な範囲の拡大、必要な作業の欠落、動作の変更、サポートされていない前提、および提案された結果が開発者の意図と異なる可能性のある箇所を特定します。 delivery が宣言されたすべてのリポジトリをカバーしていること、ターゲットがデリバリードキュメントに存在すること、オペレーター/前提条件が明示されていること、承認がエージェント操作のステップをカバーしていることを確認します。計画全体の delivery は実装とレビューに従わなければなりません。開発者が操作する残りのステップは delivered とは呼べません。
3. 該当する場合、計画の重要な決定事項とリスク管理をチャレンジします。これには、アーキテクチャとモジュールの所有権、データフローと統合境界、データベーススキーマ、永続化データ、マイグレーションとロールバック、公開 API、エクスポート、イベント、キュー、Webhook、キャッシュキー、設定、互換性、セキュリティ、プライバシー、認証、認可、所有権、課金、その他の価値関連の動作、並行性、リトライ、冪等性、障害回復、依存関係、インフラストラクチャ、デプロイメント、運用要件、置き換えられたパスまたは並列パスの削除、テストと検証戦略が現実的に重要な欠陥を明らかにできるかどうかが含まれます。
4. 特に、不必要な複雑さ、投機的な抽象化、重複した所有権、正当な移行ニーズのない一時的または並列的な実装、不完全な互換性またはロールバックパス、隠れた影響範囲の大きい変更、および重要な動作が正しくないままテストに合格する可能性がある検証を探します。このスキルの名前が jg-challenge-plan であるという理由だけで批判をでっち上げないでください。「重大な懸念事項なし」は有効な結果です。フォローアップでは、以前の発見事項、変更された意図または計画マテリアル、および影響を受ける相互作用を再評価し、変更されていないレビュー済み領域には現在の証拠を再利用します。未解決の重大な懸念事項は保持します。明示的な新しい完全なチャレンジ、以前のカバレッジの欠落、古い証拠、新しい障害、または変更された重大なリスクがある場合にのみ範囲を広げます。
5. 開発者が承認決定を行うのに役立つ情報のみを報告します。影響の少ない実装の詳細、網羅的なファイルリスト、ステップバイステップの実装シーケンス、完全なテストマトリックス、検証コマンドリストは、特定の項目が重大な懸念事項を明らかにする場合を除き、結果に含めないでください。すべてのチャレンジについて、具体的な不一致、欠落、サポートされていない前提、またはリスクを述べます。なぜそれが重要か、そして最も小さな適切な修正方法を述べてください。計画を書き換えたり、そのアーキテクチャを黙って置き換えたり、代替実装をあたかもすでに受け入れられたかのように提示したりしないでください。
6. 結果を正確に以下のセクションを使用して提示します。
   • 「## Plan at a glance」：意図された最終的な成果、主要な実装境界、および重要な明示的除外事項を要約します。
   • 「## Material impact」：開発者の注意を引くべきアーキテクチャ上の決定、データベースまたは永続化データの変更、公開または統合契約の変更、セキュリティに敏感な動作、依存関係またはインフラストラクチャの変更、およびマイグレーション、互換性、デプロイメント、ロールバックの影響のみを表面化させます。無関係なカテゴリは省略するか、その欠如自体が重要な場合は「変更なし」と記載します。
   • 「## Challenges」：重大な発見事項を影響の大きい順にリストします。存在しない場合は「重大な懸念事項は見つかりませんでした」と記載します。
   • 「## Developer decisions required」：動作、範囲、契約、安全性、データ、アーキテクチャ、または運用に実質的に影響を与える未解決の選択のみを含めます。リストされたすべての決定に、開発者が対処すべき順に番号を付けます。各決定について、行うべき正確な選択を述べ、少なくとも 1 つの推奨事項を提供し、その推奨事項を受け入れること、意味のある代替案を選択すること、または決定を未解決のままにすることの重大な結果とトレードオフを説明します。そのような決定が残っていない場合は「なし」と記載します。このセクションを埋めるためだけに決定をでっち上げないでください。
   • 「## Recommendation」：最初の行に、「重大な懸念事項なし」、「先に進むには計画の修正が必要です」、または「先に進むには開発者の判断が必要です」のいずれかを正確に 1 つ配置します。重大な計画欠陥が存在する場合は、開発者の入力も必要な場合でも、「先に進むには計画の修正が必要です」を使用します。計画はそれ以外は問題ないが、重要な開発者の決定なしには安全に進めない場合にのみ、「先に進むには開発者の判断が必要です」を使用します。判定の下に正確に 1 行の「次のステップ:」を配置します。
     • 「重大な懸念事項なし」の後：計画に、それぞれ完了、検証、レビューが可能な少なくとも 2 つの部分（別々のパッケージ、リポジトリ、リリースなど）がある場合は、開発者に jg-breakdown を実行するよう指示します。それ以外の場合は、計画を承認するか jg-execute を呼び出すよう指示します。計画自体のレビューチェックポイントはブレークダウンを不要にしません。milestones.md がなければ、jg-execute は計画全体を 1 つのユニットとして実行し、それらのチェックポイントで停止しません。
     • 「先に進むには計画の修正が必要です」の後：開発者に、番号付きの決定に回答し、jg-plan を呼び出して（必要な修正をそれらの回答とともに適用します）、修正された計画が提示されたら jg-challenge-plan を再度呼び出すよう指示します。
     • 「先に進むには開発者の判断が必要です」の後：開発者に、番号付きの決定に回答し、計画を変更する回答がある場合は jg-plan を呼び出し、修正された計画が提示されたら jg-challenge-plan を再度呼び出すよう指示します。
7. 完全なチャレンジは 1,000 語以下に抑えます。密接に関連する懸念事項を統合し、最も判断価値の高い情報を優先します。制限を満たすためだけにブロッキングな懸念事項を省略したり、利用可能なスペースを消費するためだけに計画の内容を複製したりしないでください。
8. 推奨事項は助言として扱います。これは計画を承認したり、以前の承認を取り消したり、jg-breakdown を承認したり、実装を承認したり、jg-challenge-plan を別のワークフローの前提条件にしたりするものではありません。チャレンジは評価された正確な計画バージョンにのみ適用されます。計画の改訂は以前のチャレンジを陳腐化させ、改訂された計画に関する証拠として再利用してはなりません。## Recommendation の「次のステップ:」行の後で終了します。このスキルの出力契約は、一般的な完了サマリー要件を置き換えます。