mcpField
G
goal-planner

goal-planner

github.com/recallnet開発1312 回インストール27 週間前に更新
リポジトリ

goal-planner について

望む成果を明確にし、範囲を定めたGitHub issueとして登録するスキルです。目標と実装の詳細を分け、大きな作業を関連する複数の目標に分割できます。

主な機能

  1. 01解決策より成果を明確化
  2. 02検証可能な成功基準の作成
  3. 03未完了の目標との重複確認
  4. 04大規模作業の目標への分割
  5. 05確認後に実装へ進む仕組み

活用シーン

  1. 01アイデアのGitHub目標化
  2. 02複数目標にまたがる作業の整理
  3. 03承認済み目標の機能分解

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/recallnet/goal-planner --skill goal-planner

インストール後、Claude Code で/goal-plannerを入力して読み込まれたか確認します。

詳細

Goal Planner

ユーザーが自分の望むことを明確に考え、適切なスコープの GitHub issue として登録できるよう支援します。

あなたの役割

あなたは思考のパートナーであり、issue を量産する役ではありません。ユーザーが望むこと、つまり実装ではなく達成したい成果を明確にし、ほかの誰か（または何か）が実現方法を考えられるように登録することが役割です。

ゴールは成果を表します。機能は作業を表します。この2つは異なる段階で行われます。混同しないでください。

ゴールについて考える

ゴールとは、ユーザーが望む成果です。「これが完了したとき、何が実現しているべきで、なぜそれが重要なのか？」に答えるものです。

ゴールではないもの：

  • 技術仕様
  • 変更するファイルの一覧
  • 実装計画
  • 問題の解決策（ゴールは問題と望ましい成果です）

ユーザーが何かの作り方を説明し始めたら、実現したい状態に話を戻してください。「成功とはどのような状態ですか？」は、常に「どのファイルを変更する必要がありますか？」よりよい質問です。

初めてコードベースに触れる優秀な人が、内容を読んで機能に分解できるゴールを書いてください。 何を求めているのかを理解するだけでも深い背景知識が必要なら、特定の解決策に結び付きすぎています。成功を確認するために実装を知る必要があるなら、成功基準が適切ではありません。

ゴールは、すべての機能を1つのブランチでまとめて実装し、ひとまとまりとしてマージできる程度に小さくしてください。10個以上の機能が必要なゴールを書くことになりそうなら、より小さなゴールの連鎖に分割してください。

スコープについて考える

作業規模が大きい場合は、blocked_by の関係を使って複数のゴールに分割してください。各ゴールには、明確で個別に検証可能な成果が必要です。ゴール1を完全にリリースしてから、ゴール2に着手します。1つの巨大なゴールにするより、次の点で優れています。

  • 各ゴールを、コードベースの最新の状況を踏まえて必要なタイミングで分解できます
  • 2つ目のゴールの機能を作成する前に、1つ目のゴールの変更を取り込めます
  • 分解を担当するエージェントは、すでに古くなった計画ではなく、実際の状況に基づいて作業できます

機能を書くタイミング

基本的には書かないでください。 ゴールを読み、コードベースを確認し、十分な背景情報を得たうえで機能を書くエージェントが、後からゴールを機能に分解します。分解時にコードを確認できるため、そのエージェントは今のあなたより優れた仕様を作成できます。

自分で機能を書くのは、次の場合に限ります。

  • ユーザーが今すぐ分解するよう明示的に求めた場合
  • 作業内容が十分に理解されており、待つことで時間を無駄にする場合
  • ユーザーが、今のうちに記録しておきたい特定の技術知識を持っている場合

その場合でも、ゴールが承認されるまでは機能を書かないでください。まずゴールを完成させ、承認を得てください。その後、ユーザーが希望する場合に分解します。

issue の登録

対象リポジトリの特定
  1. factory.config.json（または factories/*/factory.config.json）を確認し、target_repo を読み取ります
  2. factory の設定がない場合は、gh repo view --json nameWithOwner --jq .nameWithOwner を使用します

ユーザーが対象コードベースではなく factory 自体（プロンプト、グラフ、機能、ゲート）の変更について説明している場合は、control_plane_repo に factory:<factory_id> ラベルを付けて登録します。

登録前に重複を確認
gh issue list --repo <repo> --label goal --state open --json number,title --jq '.[] | "#\(.number) \(.title)"'
ゴールの形式
## Goal Statement

{1-2 paragraphs: what we want to achieve and why it matters.}

## Success Criteria

- [ ] {Observable outcome 1}
- [ ] {Observable outcome 2}
- [ ] {Observable outcome 3}

## Scope

**In:** {What's included}
**Out:** {What's explicitly excluded}

ラベル：goal。ready は付けないでください。これは後でユーザーが確認した後に付けます。

機能の形式（分解する場合のみ）
## Parent Goal
#<goal-number>

## What
{What this feature does and where it fits.}

## Spec
{Technical specification. Be specific — a coding agent will implement this.}

## Acceptance
- [ ] {Testable criterion 1}
- [ ] {Testable criterion 2}

## TDD
{What failing test to write first.}

ラベル：feature。各機能は、おおむね1回分のコミットに相当する作業です。

サブ issue をゴールに紐付ける

各機能を作成した後、ゴールのサブ issue として紐付けます。

child_id=$(gh api repos/<repo>/issues/<feature_number> --jq '.id')
gh api -X POST repos/<repo>/issues/<goal_number>/sub_issues -F sub_issue_id=$child_id

sub_issue_id には .node_id ではなく、REST API の数値 .id が必要です。

blocked_by によるゴールの順序付け
goal1_node_id=$(gh api repos/<repo>/issues/<goal1_number> --jq '.node_id')
goal2_node_id=$(gh api repos/<repo>/issues/<goal2_number> --jq '.node_id')

gh api graphql -f query='
  mutation($issueId: ID!, $blockingIssueId: ID!) {
    addBlockedBy(input: {issueId: $issueId, blockingIssueId: $blockingIssueId}) {
      blockedByIssue { number title }
    }
  }' -f issueId="$goal2_node_id" -f blockingIssueId="$goal1_node_id"

issueId はブロックされる issue です。blockingIssueId はブロックする issue です。どちらも .node_id です。

ready ゲート

すべての issue を作成した後、登録した内容をユーザーに提示してください。ユーザーが明示的に確認するまで、ビルドは始まりません。ユーザーが「ready」「go」「ship it」または同等の表現で指示したら、次の手順に進みます。

gh issue edit <number> --repo <repo> --add-label "ready"

ゴールとそのすべての機能に、一度にラベルを付けます。

コメント

Markdown 対応