goal-crafter について
Goal Crafterは、曖昧なタスクを検証可能な完了条件付きのAIエージェント向け目標に変換します。質問を一つずつ行う方法と、確定済みの判断を蒸し返さず承認済み資料をまとめる方法があります。
主な機能
- 01一問ずつ質問してタスクを明確化
- 02確認可能な完了条件を定義
- 03対応ハーネス向けに目標を整形
- 04承認済み計画資料を取りまとめ
- 05目標の範囲と準備状況を検証
活用シーン
- 01不明確な依頼をエージェントタスクに変換
- 02Claude CodeまたはCodex向けの目標を準備
- 03承認済み仕様を実行引き継ぎに変換
- 04提出前に目標の検証可能性を確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tt-a1i/ matt-skills-with-to-goal --skill goal-crafterインストール後、Claude Code で/goal-crafterを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.gitignoreREADME.mdagents/openai.yaml詳細
ゴールクラフター
曖昧なタスクを、AI エージェントが人の付き添いなしで実行できる検証可能なゴールに変換します。
基本原則:確認可能な完了条件のないゴールは、単なる願いにすぎません。エージェントは人に尋ねずに「完了したか」を判断できなければなりません。
呼び出しモード
プロセスに従う前に、モードを選択してください。
- スタンドアロンモード:ユーザーが曖昧なタスクを提示するか、直接ゴールを求めます。フェーズ 1 を実行し、一度に 1 つずつ質問してタスクを明確にします。
- コンパイル済みハンドオフモード:承認済みの計画情報からすでに回答を得られています。**ユーザーに再度質問してはいけません。**このスキルの検証可能性ルールと、対象ハーネスの書式のみを適用してください。情報の出所は、会話、仕様書、課題、ドキュメント、または別のスキルの場合があります。
コンパイル済みハンドオフモードで、必須のプロダクト上の決定事項または完了条件が情報源に本当に存在しない場合は、その情報源ではエージェントが実行できる状態にないことを報告し、不足している情報を明示してください。ゴールをコンパイルする際に、計画に関する質問を最初からやり直してはいけません。
プロセス
フェーズ 1 — タスクを明確にする
このフェーズはスタンドアロンモードでのみ実行します。コンパイル済みハンドオフモードでは、質問せずに上流の情報から 5 つの回答を抽出してください。
ユーザーには、一度に 1 つずつ、次の形式で質問してください(スタンドアロンの聞き取り時のみ。コンパイル済みハンドオフモードでは絵文字を使わないでください)。
❓ **QN** - **<short title>**
<body>
💡 <your recommended answer, when you have one>
次の 5 項目を順番に確認してください。
-
エージェントには具体的に何をしてほしいですか? タスクを 1 文で示してもらいます。曖昧な場合(「コードを最適化する」「UI を改善する」など)は、具体化を促してください。
-
どこで実行しますか? どのプロジェクト/リポジトリ/ワークスペースですか?特定のブランチやファイル領域はありますか?
-
完了とはどのような状態ですか? これは最も重要な質問です。観測可能で、機械的に確認できる条件を尋ねてください。
❌ 曖昧(悪い例) ✅ 検証可能(良い例) 「コード品質の向上」 " tsc --noEmitエラー 0 件 +eslint警告 0 件"「UI をもっと見栄えよくする」 "375px / 768px / 1440px の 3 つのブレークポイントで、ページの見た目が一貫しており、はみ出しがない" 「すべてのバグを修正する」 " npm testがすべて成功し、git diffに修正に関係する変更のみが含まれる"「ドキュメントをきちんと書く」 "README.md にインストール/使用方法/API の 3 つのセクションがあり、各セクションにコード例が含まれる" 「パフォーマンスを最適化する」 "Lighthouse の Performance スコアが 90 以上で、LCP が 2.5s 未満" -
制約はありますか? 変更してはいけないファイル、使用必須のツール、予算や時間の上限はありますか?
-
どのエージェント/ハーネスを使いますか? Claude Code(
/goal)、Codex(Automations)、Pi、または汎用ですか?
**フェーズ 1 は、5 つすべての質問への回答が得られた時点で完了です。**ユーザーが #3 に回答できない場合は、検証可能な条件を一緒に考えてください。ここが最もよくつまずくポイントです。
フェーズ 2 — ゴールを作成する
対象エージェントの形式でゴールを記述してください。次のルールに従います。
以下の 3 つの形式は、このスキルが主に対象とするハーネス向けに維持しているものです。これらは一時点の形式であり、標準ではありません。対象ハーネスのドキュメントに異なる形式が記載されている場合は、そちらに従い、ここに示すブロックはフォールバックとして扱ってください。記載のないハーネスには、汎用ブロックを使用します。
Claude Code /goal の場合:
Goal: [one-line task description]
Completion criteria:
- [ ] [checkable condition 1]
- [ ] [checkable condition 2]
- [ ] [checkable condition 3]
Constraints:
- [file/area restrictions]
- [tool/approach restrictions]
- [budget/time limits]
Context:
- [key files to read first]
- [relevant docs/specs]
- [related issues/PRs]
Codex Automations の場合:
Task: [one-line description]
Frequency: [once / on push / on schedule]
Verification: [checkable condition]
Workspace: [project path]
Pi/汎用の場合:
任务:[一句话]
完成标准:
- [ ] [可验证条件 1]
- [ ] [可验证条件 2]
限制:[约束条件]
フェーズ 3 — ゴールを検証する
最終的なゴールを提示する前に、自己チェックしてください。
- エージェントは完了条件を読んで、「完了」と「未完了」を明確に判断できますか?
- すべての条件は、人の判断なしに観測可能ですか?(「見栄えがよい」「しっくりくる」などは不可)
- 制約は、スコープの拡大を防げるほど具体的ですか?
- エージェントが「どこで」または「どのように」と尋ねずに作業を始めるのに十分なコンテキストがありますか?
チェックに 1 つでも失敗した場合、スタンドアロンモードではフェーズ 1 に戻り、その点についてユーザーに確認してください。コンパイル済みハンドオフモードでは、新たに計画に関する質問をするのではなく、情報源がエージェント実行可能な状態にないことを報告し、不足している情報を明示してください。
フェーズ 4 — 提示する
スタンドアロンモードでは、最終的なゴールを提示し、次の文で締めくくってください。
🎯 この goal を [エージェント名] に貼り付ければ、自動で完了まで実行します。途中で止まった場合は、どの完了基準を満たせなかったか教えてください。調整をお手伝いします。
コンパイル済みハンドオフモードでは、提示時の形式は上流のスキルが担当します。スタンドアロン用の締めくくりを追加せず、指定されたハーネス形式でゴールを返してください。
例
以下2つの例にあるリポジトリ名、ディレクトリ構造、ファイルパスはすべてプレースホルダーであり、実際のプロジェクトで採用されている規約を示すものではありません。実際に作成する goal には、対象リポジトリの現在の実際のパスを記載し、ここにある形式をそのまま使わないでください。
例1:コードレビューの自動化
ユーザー:「PRを自動でレビューする goal を書いて」
確認済み:
- タスク:現在のブランチと main の差分をすべてレビューする
- 対象:現在の作業リポジトリ
- 完了条件:レビュー報告を出力し、すべての P0/P1 の問題を列挙する。各問題にはファイルと行番号を記載する
- 制約:読み取り専用。ファイルを変更しない
- エージェント:Claude Code
出力:
Goal: 审查当前分支相对于 origin/main 的 diff
Completion criteria:
- [ ] 已读取完整的 git diff
- [ ] 已检查安全漏洞(SQL 注入、XSS、密钥泄露)
- [ ] 已检查逻辑错误(空指针、竞态条件、边界条件)
- [ ] 已检查代码规范(命名、结构、重复代码)
- [ ] 输出审查报告,每个问题标注:严重度 + 文件:行号 + 问题描述 + 修复建议
Constraints:
- 只读,不修改任何文件
- 只关注当前分支的改动,不审查已有代码
Context:
- 项目背景:<一句话说明这个仓库是什么>
- 设计 spec:<仓库内的设计文档>
例2:UI の再設計
ユーザー:「このページを作り直す goal を書いて」
確認済み:
- タスク:shadcn コンポーネントライブラリを使って対象のページを作り直す
- 完了条件:3つのブレークポイントでページの見た目に一貫性があり、すべてのインタラクションに hover/focus/active の状態があり、tsc の型チェックに合格する
- 制約:既存の API インターフェースを変更しない。プロジェクトで既に使用している Tailwind の設定を使う
- エージェント:Claude Code
出力:
Goal: 用 shadcn/ui 组件库重做目标页面
Completion criteria:
- [ ] 所有组件替换为 shadcn/ui 等价组件
- [ ] 页面在 375px / 768px / 1440px 断点下无溢出、无错位
- [ ] 所有可交互元素有 hover、focus、active 状态
- [ ] `tsc --noEmit` 0 errors
- [ ] 页面加载后无 console error
Constraints:
- 不修改 API 客户端目录下的任何文件
- 使用项目已有的 Tailwind 主题配置
- 不引入新的 npm 依赖(shadcn 除外)
Context:
- 当前页面:<页面组件文件>
- UI 组件:<组件库入口文件>
- 样式:<全局样式入口>
特別ルール
- スタンドアロンモードでは、フェーズ1の質問3を省略しないでください。 ユーザーが「完了」を定義できない場合、goal は失敗します。一緒に案を考えてください。
- コンパイル済みハンドオフモードでは、再度ヒアリングしないでください。 承認済みのエビデンスによって、すでに確認とプロダクト上の決定が行われています。エビデンスが不足している場合、ソースはエージェントが実行できる状態ではありません。
- チェックボックス1つにつき、検証可能な条件を1つにしてください。 複数の条件を1行にまとめないでください。
- 制約は重要です。 エージェントが無関係なファイルを「最適化」したり、互換性を損なう変更を加えたりするのを防ぎます。
- タスクが1つの goal で対応するには大きすぎる場合、明確な引き継ぎを含む2~3個の小さな goal に分けることを提案してください。
- 調査/分析の goal(コード変更を伴わないもの)では、完了条件を「特定のセクションを含むレポートを出力する」としてください。