help

ヘルプ

現在のリポジトリの状態を読み取り、次のパイプライン手順を提案します。このスキル自体は作業を行いません。観察した状態を根拠として、次に使うべきスキルを案内します。ユーザーは、その提案を別の手順で上書きできます。

このスキルは、しばらく離れていたリポジトリに戻ってきたユーザー、初めて Skill Kit を使うユーザー、またはパイプラインの途中で次に呼び出すスキルがわからなくなったユーザーのための入り口です。

呼び出すタイミング

これはメインパイプラインから分岐するスキルです。診断結果が示すスキルを通じて、メインパイプラインに戻ります。

次の場合に /help を使います。

• Skill Kit をすでに使っているリポジトリでセッションを開始し、パイプラインの現在地を知りたい場合
• しばらく機能開発から離れていて、作業の状態を確認したい場合
• 新しいチームメンバーが references/SYSTEM-OVERVIEW.md をすべて読むのではなく、パイプラインの案内を求めている場合
• ユーザーが「次に何をすればよいですか？」または「今どの段階ですか？」と明示的に尋ねた場合

次の場合は /help を使わないでください。

• 推奨されたスキルを実際に実行する場合。/help は提案のみを行い、次のスキルはユーザー自身が実行します
• ユーザーがすでに次の手順を把握しており、実行だけを希望している場合
• 質問が状態に関するものではなく、概念に関するものであり、references/SYSTEM-OVERVIEW.md の代わりとして使う場合
• 機能開発のパイプラインとは無関係のタスク（上流の成果物を伴わないバグ修正や単発のクリーンアップなど）の場合

プロセス

1. リポジトリの状態を収集する

状態のスナップショットを2つのフェーズに分けて作成します。まずベースブランチを順番に検出し（後続の呼び出しで参照できるようにします）、次に読み取り専用のスナップショットコマンドを並列で実行します。

フェーズ1a — ベースブランチを検出する（最初に、順番に実行）：

# Prefer the remote's HEAD, fall back through common names
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null | sed 's@^origin/@@')
if [ -z "$BASE_BRANCH" ]; then
  for candidate in main master prod develop trunk; do
    if git rev-parse --verify "$candidate" >/dev/null 2>&1; then BASE_BRANCH=$candidate; break; fi
  done
fi
# A name is not a ref. $BASE_BRANCH names the branch (for `--base`, `git switch`);
# $BASE_REF points at it, and is the only thing safe as a range endpoint.
if git rev-parse --verify "origin/$BASE_BRANCH" >/dev/null 2>&1; then
  BASE_REF="origin/$BASE_BRANCH"
else
  BASE_REF="$BASE_BRANCH"
  echo "note: origin/$BASE_BRANCH does not resolve — measuring against the local branch, which may be stale" >&2
fi
echo "base=$BASE_BRANCH ref=$BASE_REF"

main や master をハードコードしないでください。すべてのリポジトリで使われているわけではありません（Skill Kit 自身のリポジトリでは prod を使用しており、ほかにも develop、trunk、チーム固有の名前を使用しているリポジトリが多数あります）。origin/HEAD が設定されておらず、フォールバック候補もどれも存在しない場合は、続行する前にユーザーにベースブランチ名を確認してください。

残る注意点： $BASE_REF の鮮度は最後に git fetch を実行した時点に依存します。また、三角形のフォークでは（または origin という名前ではないリモートでは）、origin/$BASE_BRANCH が存在しないか、上流ではなくフォークを追跡している可能性があります。その場合、else ブランチはローカルブランチにフォールバックしますが、これはこのガードで避けようとしている古い参照の挙動です。もっともらしい誤った結果が何の通知もなく返されることで、この不具合が5か月も放置されていたため、黙ってフォールバックするのではなく、標準エラーにその旨を出力します。カウントが正しくないようであれば、git fetch を実行して再試行するか、BASE_REF を手動で設定してください。

フェーズ1b — スナップショットを収集する（並列で実行し、各呼び出しは独立）：

# Current branch and commits ahead of the detected base branch
git branch --show-current
git log --oneline "$BASE_REF..HEAD"

# Open PR for the current branch, if any
gh pr list --head "$(git branch --show-current)" --state open --json number,title,url

# Research archive entries for this repo (durable, per-user, outside the repo)
REPO_SLUG=$(git config --get remote.origin.url | sed -E 's|.*[:/]([^/]+)/([^/.]+)(\.git)?$|\1-\2|')
ls -t "$HOME/.claude/research/$REPO_SLUG/" 2>/dev/null

# Open issues with PRD or slice labels, or in open milestones
gh issue list --state open --json number,title,labels,milestone --limit 50

# The frontier — which open issues are actually takeable right now.
# `state` is the GraphQL enum here: uppercase OPEN, not REST's lowercase.
# `totalCount` counts blockers in every state, which is what distinguishes
# "blockers all closed" from "never wired" (see the note below).
gh issue list --state open --limit 100 --json number,blockedBy,assignees \
  --jq '.[]
       | {number,
          open_blockers: [.blockedBy.nodes[] | select(.state == "OPEN") | .number],
          ever_wired: .blockedBy.totalCount,
          assignee: (.assignees[0].login // null)}' 2>/dev/null

# Open milestones with remaining feature issues
gh api "repos/{owner}/{repo}/milestones?state=open" --jq '.[] | {title, open_issues, closed_issues}' 2>/dev/null

フロンティアの呼び出しは、このバッチ内のほかの呼び出しすべてと独立しており、推測した参照が原因で失敗することもないため、並列バッチに含めます。ノードを state == "OPEN" に絞り込むと、ブロッカーがすべてクローズしたスライスでは、追加の記録処理なしで open_blockers が空になります。そのため、ブロッカーを再読み込みしなくても、この値は最新の状態として信頼できます。

スライスに含まれる Issue がネイティブな依存関係の接続機能より前のもの（/prd-to-issues §7 を参照）であるリポジトリでは、すべての項目について open_blockers が空として報告されます。ever_wired によって、推測に頼らず、これを本当に依存関係のないグラフと区別できます。いずれかの Issue が ever_wired > 0 を報告していれば、そのリポジトリでは依存関係が接続されており、空のリストは実際の状態です。すべての Issue が ever_wired: 0 で、本文に Blocked by #N という文が含まれている場合は、依存関係のエッジが一度も書き込まれていません。その場合は文中の記述を参照し、バックログ全体に着手できると断言するのではなく、推奨事項でその旨を伝えてください。

並列ツール使用時の注意点。 Claude Code では、並列バッチ内の Bash 呼び出しが1つでもエラーになると、ハーネスが実行中の兄弟呼び出しをキャンセルします。参照先が1つでも誤っていると、スナップショット全体が失敗します。そのため、フェーズ1aは先に単独で実行する必要があります。ベースブランチの検出に失敗すれば、フェーズ1bで $BASE_BRANCH を参照しようとする処理は実行されません。並列バッチ内で推測したブランチ名を使い、「手間を省く」ために &&／|| を連結しないでください。推測が外れたリポジトリでは、エラーが発生します。

gh が認証されていない場合、またはリポジトリが GitHub リポジトリではない場合は、収集できなかったシグナルを明記し、残りの情報をもとに作業してください。シグナルが欠けていても失敗ではなく、推奨できる内容が限られるだけです。

2. 状態を分類する

以下のチェックを優先順位順に確認します。最初に一致したものが推奨事項です。最初に一致した時点で確認を終了してください。ユーザーに選択肢を3つ提示しようとしないでください。

#	シグナル	推奨事項	一言での理由
1	現在のブランチにオープン PR がある	PR をマージしてから、/compound を実行する	"<branch> にオープン PR があります。レビューが済んでいる場合は、マージして教訓を記録してください。"
2	現在のブランチにベースブランチより先行するコミットがあり、オープン PR がない	/pre-merge	"ベースブランチ <base> より先行するコミットが <N> 件ありますが、PR はまだありません。/pre-merge は PR を作成し、アーキテクチャレビューを実行します。"
3	PRD を参照するオープンなスライスイシューがあり、クローズ済みのものがない	open_blockers が空の、最優先スライスに対して /execute	"PRD #<prd> の配下にオープンなスライスイシューが <N> 件あります。/execute で、ブロックされていない最初のスライスに着手してください。"
4	PRD を参照するオープンなスライスイシューがあり、クローズ済みのものもある	open_blockers が空の、次のスライスに対して /execute	"PRD #<prd> の配下にオープンなスライスが <N> 件、クローズ済みのスライスが <M> 件あります。/execute で、次のブロックされていないスライスに着手してください。"
5	スライスイシューのないオープンな PRD イシューがある	PRD #<prd> に対して /prd-to-issues	"PRD #<prd> の形は整っていますが、まだ分解されていません。/prd-to-issues でスライスに分割してください。"
6	このリポジトリに関する最近の調査アーカイブがあり、その機能に一致するオープンな PRD イシューがない	/write-a-prd	"<feature> の最近の調査ファイルはアーカイブされていますが、PRD イシューがありません。/write-a-prd で、形の整った提案にしてください。"
7	計画マイルストーンに research-ready の機能イシューがある	research-ready の機能に対して /research	"マイルストーン <name> に research-ready の機能があります。その機能に対して /research を実行してください。"
8	計画マイルストーンに roadmap bet の機能しかない	機能を1つ選んで research-ready に昇格させてから、/research	"マイルストーン <name> には roadmap bet の機能しかありません。1つ選んで昇格させてから、/research を実行してください。"
9	作業をリリース済みだが、最後のマージ以降 docs/solutions/ にエントリーがない	/compound	"最後のマージでリリースされた作業は、まだ教訓として記録されていません。/compound を実行してください。"
10	QA バグがオープンで、進行中の機能作業がない	最優先の QA バグに対して /execute	"オープンな QA バグイシューが <N> 件あります。/execute で対応してください。"
11	上記のいずれにも該当しない — クリーンな状態で、進行中の機能がない	/shape（または、何をしようとしているのかユーザーに尋ねる）	"進行中の機能作業はありません。通常は /shape から始めます。"

シグナル #3 と #4 の「ブロックされていない」とは、Phase 1b のフロンティア呼び出しで open_blockers が空であることを意味します。これを読み取り、イシュー本文の Blocked by の記述から推測しないでください。これは /prd-to-issues §9 および Ralph ループのプロンプトでも使用される同じルールです。そのため、3つの選択箇所すべてで、偶然ではなく仕様上同じ選択になります。

3. 推奨事項を提示する

一言での理由と、それを引き起こした状態シグナルを添えて、推奨事項を1つ提示します。次の形式を使用してください。

## Where you are

<one paragraph: the state signals you observed, stated as facts>

## Next step

**`/<recommended-skill>`** — <one-line reason>

## Why this skill

<one short paragraph: what the skill produces and how it connects to the observed state>

## If this is wrong

<2-3 alternative next steps for common cases where the heuristic might have missed>

出力例（シグナル #6 の場合。最近の調査アーカイブがあり、一致する PRD イシューがないケース）：

## Where you are

Current branch: main. No open PRs. Research archive has `~/.claude/research/owner-repo/nextjs-middleware-migration-2026-04-05.md`, dated 2026-04-05 and pointing at a Next.js 16 middleware migration. No open PRD issue matches it (I searched open issues for "middleware" and "Next.js" and found nothing). No open slice issues. No active milestone.

## Next step

**`/write-a-prd`** — a recent research file is present but there is no PRD issue for the work it covers.

## Why this skill

`/write-a-prd` takes a completed research document and turns it into a shaped PRD filed as a GitHub issue. It consults the archived research automatically, so the recommendations in the research will flow into the pitch without you re-summarizing them. Expect 10–15 minutes of interview, then a PRD issue ready for `/prd-to-issues`.

## If this is wrong

- If the archived research is stale and no longer matches what you intend to build, run `/correct-course` first to clean up before shaping again.
- If you want to rewrite the research for a different approach, run `/research` again (it will produce a new archive entry with today's date).

4. 終了する

推奨事項を提示したら、終了してください。推奨スキルを自動的に開始したり、実行するかどうかをユーザーに尋ねたりしないでください。判断するのはユーザーです。実行したい場合、ユーザー自身が呼び出します。

ユーザーが「それは違う。実際には X をしています」と応答した場合、状態を最初からすべて再確認しないでください。訂正された質問にそのまま答えてください。推奨事項はシグナルに基づくものであり、権威に基づくものではありません。

ヒューリスティックルール

• 推奨するのは1つだけです。3つも提示しません。 ユーザーが求めているのは次のステップであり、選択肢の一覧ではありません。最適なものを選び、それを明確に勧めてください。
• 状態を根拠として示してください。 すべての推奨には、それを促した具体的なシグナル（ファイルパス、イシュー番号、ブランチ名など）を含めてください。曖昧な推奨は、すぐに信頼を損ないます。
• 最も早く着手できる、ブロックされていないステップを優先してください。 未対応のスライスイシューと、マージ済みだがまだナレッジ化されていない無関係なPRがある場合、スライスの作業が中断中であるときに限り、まずナレッジ化を勧めてください。判断に迷ったら、直近の作業を前に進めるものを勧めてください。
• シグナルを捏造しないでください。 gh が認証されておらず、オープンイシューを読み取れなかった場合は、そのことを伝えてください。推測してはいけません。
• 推奨を自動で実行してはいけません。 /help は助言を行うものです。次のスキルはユーザーが実行します。

このスキルが行わないこと

• タスクトラッカーではありません。 GitHub のイシューとPRがタスクトラッカーです。このスキルはその状態を読み取るものであり、置き換えるものではありません。
• パイプライン概要の代わりではありません。 パイプラインの仕組みについて概念的な質問をされた場合は、即興で答えるのではなく、このスキルと一緒にバンドルされている references/SYSTEM-OVERVIEW.md と references/using-this-pack.md の該当セクションを参照してください。さらに詳しく知りたい場合は、リポジトリ内の原文 https://github.com/chrislacey89/skills/blob/main/SYSTEM-OVERVIEW.md と https://github.com/chrislacey89/skills/blob/main/docs/using-this-pack.md を案内してください。
• ウィザードではありません。 ユーザーをシェイピング、リサーチ、プランニングの手順に沿って案内することはありません。開始するスキルを伝えたら、そこで役目を終えます。

引き継ぎ

• 想定される入力： 「次に何をすればよいですか？」のような質問、またはパイプライン上の現在位置が曖昧な状態
• 生成するもの： 状態を示す根拠を引用した、理由を1行で添える単一の次ステップの推奨
• 引き継ぎ先： 推奨先となるパイプラインスキル — /shape、/research、/write-a-prd、/prd-to-issues、/execute、/pre-merge、/compound のいずれか
• 次に行うこと： ユーザー自身が推奨されたスキルを実行します — /help が何かを呼び出すことはありません