jackin-goal-prompt

jackin-goal-prompt

ロードマップ項目（およびオペレーターから渡された計画ファイル）を、単独で完結する /goal プロンプトにまとめます。事前のコンテキストがまったくない実行エージェントでも、最後まで実行できるプロンプトです。プロンプトそのものが成果物であり、その精度が目標の成否を左右します。

上限は厳密に4000文字です。構成は /improve の計画を参考にしています。自己完結型で、検証ゲートを設け、境界を明確にします。実行に必要な骨組み（目的、スコープ、検証ゲート、完了基準、STOP 条件）は残し、ファイルから読み取れる情報（コード抜粋）や、jackin❯ の自動読み込みルール（AGENTS.md、COMMITS.md、ENGINEERING.md）から得られる情報は、再掲せず参照先を示します。

jackin-research とは異なります。こちらは /goal Follow で実行する複数ページの prompt.mdx ファイルである「調査資料ブリーフ」を作成します。このスキルでは、/goal Implement または /goal Run で実行する、コンパクトな「インライン」プロンプトを作成します。

使用する場面

• オペレーターが目標プロンプトを求めている、またはロードマップ項目を対象に /goal を開始したい場合。
• オペレーターがロードマップ項目と /improve の計画ファイルを持っており、それらを実行可能な1つのプロンプトにまとめたい場合。

使用しない場面

• 調査資料ブリーフの作成 → jackin-research。
• ロードマップ項目自体の設計 → jackin-brainstorm。
• PR の作成 → jackin-create-pr / jackin-propose。

引数

• <slug> — ロードマップ項目（slug、パス、または .mdx）。常に必須です。
• --plan <path|glob> — 取り込む計画の Markdown（フォルダー、ファイル、または glob）。通常は /improve の出力です。

手順

1. 変更内容を把握する。 ロードマップの .mdx を読みます。title: と **Status**: だけを手がかりにします。実際の項目では Problem/Why/Design/Tasks のひな形から外れていることがあるため、見出しの構成には柔軟に対応します。--plan が指定されている場合は、すべての計画ファイルを読み、スコープ、手順、検証コマンド、完了基準、STOP 条件を抽出します。

   完了条件：この変更で何を作り、そのコードがどこにあるかを2文で説明できること。

2. リポジトリの実際の検証ゲートを確認する。 検証コマンドはリポジトリから取得し、決して作り出しません。CONTRIBUTING.md（マージ準備の項目）、.github/workflows/ci.yml、mise.toml から取得します。jackin❯ の場合は、cargo fmt --check、cargo clippy --all-targets --all-features -- -D warnings、cargo nextest run --all-features、e2e プロファイルに加え、docs/ を変更する場合は bun のドキュメントゲートが該当します。

   完了条件：記載するすべてのゲートが、リポジトリで実際に実行され、期待される結果が明確なコマンドであること。

3. プロンプトを作成する — 圧縮した /improve のひな形です。

   • 目的 — 1〜2行で、何を作るのかをロードマップ／計画から記述します。
   • スコープ — 対象パスと対象外の境界（関連して見えても変更してはならないもの）。
   • 検証ゲート — 手順2のコマンドと、それぞれの期待される結果。
   • 完了基準 — 1行につき1項目とし、機械的に確認できるものにします（コマンドと結果、または grep 可能な不在）。「正しく動作する」のような文章は使いません。
   • STOP 条件 — 計画との乖離、維持できないスコープ境界、正直に成功させられないゲート。
   • 規約 — jackin❯ の自動読み込みルールファイルを1行で参照します。内容を転載してはいけません。

4. 4000文字の上限を厳守する。 プロンプトを一時ファイルに書き込み、wc -c で文字数を確認します。上限を超えている場合は、収まるまで次の優先順位で圧縮します。コード抜粋を削除する（コードではなく、ファイル名と契約を示す）。規約を参照先だけにまとめる。目的を簡潔にする。「理由」の説明を削る。完了基準を検証ゲートに統合する。再度カウントします。上限は厳守してください。4000文字を超える出力は決して行いません。

   完了条件：wc -c の結果が4000以下であり、プロンプトに目的、スコープ、検証ゲート、完了基準、STOP 条件が残っていること。

5. 出力して報告する。 /goal Implement <slug> または /goal Run の後に貼り付けられるよう、プロンプトを1つのコードブロックに出力します。文字数を記載します。上限に収めるために圧縮または削除した内容を示し、上限を引き上げたい場合にオペレーターがインラインで追加を求められるようにします。

よくある間違い

• 4000 文字を超えること。これは唯一の絶対的な制約です。
• リポジトリに実在するコマンドを確認せず、検証コマンドを作り出すこと。リポジトリが実行しないゲートはノイズです。
• jackin❯ が自動読み込みするルール（AGENTS.md、COMMITS.md、ENGINEERING.md）を繰り返すこと。実行者が自動読み込みするため、コピーせず参照先を示してください。
• コードの抜粋を埋め込むこと。実行者がファイルを読むため、ファイル名と、満たすべき契約を記載してください。
• チャットの文脈（「前に話したとおり」「選んだ方針」など）に依存するプロンプトを作ること。自己完結しておらず、新しい実行者では機能しません。
• 提供された --plan ファイルを無視すること。これらには対象範囲と完了基準が記載されており、プロンプトに取り込むことが重要です。
• STOP 条件を削除すること。これらは実行者にとって、正直に作業を中断できる唯一の手段です。

ツール

これを担う xtask はありません。このスキルは読み取り（ロードマップ .mdx、計画ファイル、リポジトリの検証コマンド）を調整し、4000 文字以下の文字列を 1 つ生成します。構成は、/improve の計画の構成（自己完結型、検証を通過条件とし、明確な境界を設ける）と、jackin❯ がギャップ解消にすでに使っている /goal Run の概要形式を参考にしています。