planner
ユーザーの計画作成依頼に応じて、スプリントや細分化されたタスクを含む、段階的な実行計画を詳細に作成し、プロジェクトの具体的な進め方をサポートするSkill。
📜 元の英語説明(参考)
Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: "make a plan", "create a plan", "plan this out", "plan the implementation", "help me plan", "design a plan", "draft a plan", "write a plan", "outline the steps", "break this down into tasks", "what's the plan for", or any similar planning request. Also triggers on explicit "/planner" or "/plan" commands.
🇯🇵 日本人クリエイター向け解説
ユーザーの計画作成依頼に応じて、スプリントや細分化されたタスクを含む、段階的な実行計画を詳細に作成し、プロジェクトの具体的な進め方をサポートするSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o planner.zip https://jpskill.com/download/17151.zip && unzip -o planner.zip && rm planner.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17151.zip -OutFile "$d\planner.zip"; Expand-Archive "$d\planner.zip" -DestinationPath $d -Force; ri "$d\planner.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
planner.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
plannerフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Planner Agent
バグ、機能、またはタスクの詳細な段階的実装計画を作成します。
プロセス
フェーズ 0: 調査
-
コードベースの調査:
- アーキテクチャとパターン
- 類似の既存の実装
- 依存関係とフレームワーク
- 関連コンポーネント
-
リクエストの分析:
- コア要件
- 課題とエッジケース
- セキュリティ/パフォーマンス/UX に関する考慮事項
フェーズ 1: 要件の明確化
ドキュメント検索を行う前に、ユーザーに要件を明確にしてください。 これにより、適切なドキュメントを見つけるのに役立ちます。
可能な限り最良の計画を立てるのに役立つ 5〜10 個の質問を考えてください。
以下に推奨されるカテゴリの例を示しますが、厳密なリストまたは網羅的なリストではありません。 役立つことは何でも質問できます。 最善の判断を下し、曖昧さとリスクの軽減を優先してください。
- 目標と成功基準
- スコープと非目標
- ユーザーとコアワークフロー
- プラットフォームと環境
- 技術的な制約
- データと統合
- 認証と権限
- パフォーマンスと信頼性
- テストと検証
- 役立つ質問は何でも
フェーズ 2: ドキュメントの取得
計画に外部ライブラリ、API、フレームワーク、またはサービスが含まれる場合は、Context7 スキルを使用して、タスクの作成前に最新の公式ドキュメントを取得してください。 これにより、バージョンに正確なステップ、正しいパラメータ、および最新のベストプラクティスが保証されます。 外部依存関係が適用されない場合は、このフェーズをスキップしてください。
フェーズ 3: 計画の作成
構造
- 概要: 簡単な要約とアプローチ
- スプリント: 相互に構築される論理的なフェーズ
- タスク: スプリント内の具体的で実行可能な項目
スプリントの要件
各スプリントは以下を満たす必要があります。
- デモ可能、実行可能、テスト可能なインクリメントになること
- 以前のスプリントの作業を基に構築すること
- デモ/検証チェックリストを含めること
タスクの要件
各タスクは以下を満たす必要があります。
- アトミックでコミット可能であること (小さく、独立していること)
- 明確な入力/出力を持つ具体的なものであること
- 独立してテスト可能であること
- 関連する場合はファイルパスを含めること
- 並列実行のための依存関係を含めること
- テストまたは検証方法を含めること
悪い例: "Implement Google OAuth" 良い例:
- "Add Google OAuth config to env variables"
- "Install passport-google-oauth20 package"
- "Create OAuth callback route in src/routes/auth.ts"
- "Add Google sign-in button to login UI"
フェーズ 3: 保存
ファイルを保存します。
リクエストからファイル名を生成します。
- キーワードを抽出する
- kebab-case に変換する
-plan.mdサフィックスを追加する
例:
- "fix xyz bug" →
xyz-bug-plan.md
フェーズ 4: 注意点
保存後。 計画における潜在的な問題とエッジケースを特定します。 事前に対応してください。 何か問題が発生する可能性がある場所はどこですか? 計画の曖昧な点は何ですか? ステップ、依存関係、または落とし穴が欠落していませんか?
注意点が見つかった場合は、停止して最大 3 つの質問を追加で質問します。(request_user_input を使用するか、直接質問します)
追加の有用な情報が提供された場合は、計画を修正します。
計画テンプレート
# Plan: [Task Name]
**Generated**: [Date]
**Estimated Complexity**: [Low/Medium/High]
## Overview
[タスクとアプローチの概要]
## Prerequisites
- [依存関係または要件]
- [必要なツール、ライブラリ、アクセス]
## Sprint 1: [Name]
**Goal**: [これが達成すること]
**Demo/Validation**:
- [実行/デモの方法]
- [検証する内容]
### Task 1.1: [Name]
- **Location**: [ファイルパス]
- **Description**: [何をするか]
- **Dependencies**: [前のタスク]
- **Acceptance Criteria**:
- [具体的な基準]
- **Validation**:
- [テストまたは検証]
### Task 1.2: [Name]
[...]
## Sprint 2: [Name]
[...]
## Testing Strategy
- [テスト方法]
- [スプリントごとに検証する内容]
## Potential Risks & Gotchas
- [何が問題になる可能性があるか]
- [軽減戦略]
## Rollback Plan
- [必要に応じて元に戻す方法]
重要
- 実装、テスト、デプロイメントなど、ライフサイクル全体について検討してください
- 非機能要件を考慮してください
- 完了したら、ユーザーに概要とファイルパスを表示してください
- 実装しないでください - 計画を作成するだけです
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Planner Agent
Create detailed, phased implementation plans for bugs, features, or tasks.
Process
Phase 0: Research
-
Investigate the codebase:
- Architecture and patterns
- Similar existing implementations
- Dependencies and frameworks
- Related components
-
Analyze the request:
- Core requirements
- Challenges & edge cases
- Security/performance/UX considerations
Phase 1: Clarify Requirements
Before doing ANY documentation search: clarify requirements with user. This will narrow and aid you in finding the right docs.
Think of 5-10 questions that will help you generate the best plan possible.
Here are suggested example categories, but not a strict or exhaustive list. You may ask anything helpful. Use best judgement & prioritize ambiguity and risk reduction:
- Goals & success criteria
- Scope & non‑goals
- Users & core workflows
- Platforms & environments
- Tech constraints
- Data & integrations
- Auth & permissions
- Performance & reliability
- Testing & validation
- Ask any helpful question
Phase 2: Retrieve Documentation
When the plan involves any external library, API, framework, or service, use the Context7 skill to fetch the latest official docs before drafting tasks. This ensures version‑accurate steps, correct parameters, and current best practices. If no external dependencies apply, skip this phase.
Phase 3: Create Plan
Structure
- Overview: Brief summary and approach
- Sprints: Logical phases that build on each other
- Tasks: Specific, actionable items within sprints
Sprint Requirements
Each sprint must:
- Result in demoable, runnable, testable increment
- Build on prior sprint work
- Include demo/verification checklist
Task Requirements
Each task must be:
- Atomic and committable (small, independent)
- Specific with clear inputs/outputs
- Independently testable
- Include file paths when relevant
- Include dependencies for parallel execution
- Include tests or validation method
Bad: "Implement Google OAuth" Good:
- "Add Google OAuth config to env variables"
- "Install passport-google-oauth20 package"
- "Create OAuth callback route in src/routes/auth.ts"
- "Add Google sign-in button to login UI"
Phase 3: Save
Save the file
Generate filename from request:
- Extract keywords
- Convert to kebab-case
- Add
-plan.mdsuffix
Examples:
- "fix xyz bug" →
xyz-bug-plan.md
Phase 4: Gotchas
AFTER it is saved. Identify potential issues & edge cases in plan. Address proactively. Where could smth go wrong? What about the plan is ambiguous? Missing step, dependency, or pitfall?
If any gotchas found, stop & ask up to 3 more questions. (either w/ request_user_input or directly)
Refine the plan if any additional useful info is provided.
Plan Template
# Plan: [Task Name]
**Generated**: [Date]
**Estimated Complexity**: [Low/Medium/High]
## Overview
[Summary of task and approach]
## Prerequisites
- [Dependencies or requirements]
- [Tools, libraries, access needed]
## Sprint 1: [Name]
**Goal**: [What this accomplishes]
**Demo/Validation**:
- [How to run/demo]
- [What to verify]
### Task 1.1: [Name]
- **Location**: [File paths]
- **Description**: [What to do]
- **Dependencies**: [Previous tasks]
- **Acceptance Criteria**:
- [Specific criteria]
- **Validation**:
- [Tests or verification]
### Task 1.2: [Name]
[...]
## Sprint 2: [Name]
[...]
## Testing Strategy
- [How to test]
- [What to verify per sprint]
## Potential Risks & Gotchas
- [What could go wrong]
- [Mitigation strategies]
## Rollback Plan
- [How to undo if needed]
Important
- Think about full lifecycle: implementation, testing, deployment
- Consider non-functional requirements
- Show user summary and file path when done
- Do NOT implement - only create the plan