jpskill.com
🛠️ 開発・MCP コミュニティ 🔴 エンジニア向け 👤 エンジニア・AI開発者

🛠️ Plan Writing

plan-writing

機能追加やシステム改善など、複数の工程

⏱ テスト計画作成 2時間 → 20分

📺 まず動画で見る(YouTube)

▶ 【衝撃】最強のAIエージェント「Claude Code」の最新機能・使い方・プログラミングをAIで効率化する超実践術を解説! ↗

※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。

📜 元の英語説明(参考)

Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.

🇯🇵 日本人クリエイター向け解説

一言でいうと

機能追加やシステム改善など、複数の工程

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o plan-writing.zip https://jpskill.com/download/3292.zip && unzip -o plan-writing.zip && rm plan-writing.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/3292.zip -OutFile "$d\plan-writing.zip"; Expand-Archive "$d\plan-writing.zip" -DestinationPath $d -Force; ri "$d\plan-writing.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して plan-writing.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → plan-writing フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

💬 こう話しかけるだけ — サンプルプロンプト

  • Plan Writing を使って、最小構成のサンプルコードを示して
  • Plan Writing の主な使い方と注意点を教えて
  • Plan Writing を既存プロジェクトに組み込む方法を教えて

これをClaude Code に貼るだけで、このSkillが自動発動します。

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[スキル名] 計画作成

計画作成

出典: obra/superpowers

概要

このスキルは、作業を明確で実行可能なタスクに分解し、検証基準を設けるためのフレームワークを提供します。

タスク分解の原則

1. 小さく、焦点を絞ったタスク

  • 各タスクは2~5分で完了すること
  • タスクごとに1つの明確な成果があること
  • 独立して検証可能であること

2. 明確な検証

  • 完了したことをどうやって知るか?
  • 何をチェック/テストできるか?
  • 期待される出力は何か?

3. 論理的な順序付け

  • 依存関係を特定する
  • 可能な場合は並行作業を行う
  • クリティカルパスを強調する
  • フェーズX: 検証は常に最後です

4. プロジェクトルートでの動的な命名

  • 計画ファイルは、プロジェクトルートに {task-slug}.md として保存されます
  • タスクから名前を派生させます(例: "add auth" → auth-feature.md
  • 決して .claude/docs/、または一時フォルダ内には保存しません

計画の原則(テンプレートではありません!)

🔴 固定されたテンプレートはありません。各計画はタスクに固有のものです。

原則1: 短く保つ

❌ 間違い ✅ 正しい
サブサブタスクを含む50のタスク 最大5~10の明確なタスク
すべてのマイクロステップをリストアップ 実行可能な項目のみ
冗長な説明 各タスクにつき1行

ルール: 計画が1ページを超える場合は長すぎます。簡素化してください。


原則2: 具体的であること、一般的でないこと

❌ 間違い ✅ 正しい
「プロジェクトをセットアップする」 npx create-next-app を実行する」
「認証を追加する」 「next-auth をインストールし、/api/auth/[...nextauth].ts を作成する」
「UIをスタイリングする」 Header.tsx に Tailwind クラスを追加する」

ルール: 各タスクには、明確で検証可能な成果があるべきです。


原則3: プロジェクトタイプに基づいた動的なコンテンツ

新規プロジェクトの場合:

  • どの技術スタックか?(最初に決定する)
  • MVPは何か?(最小限の機能)
  • ファイル構造はどうか?

機能追加の場合:

  • どのファイルが影響を受けるか?
  • どの依存関係が必要か?
  • 動作をどのように検証するか?

バグ修正の場合:

  • 根本原因は何か?
  • どのファイル/行を変更するか?
  • 修正をどのようにテストするか?

原則4: スクリプトはプロジェクト固有であること

🔴 スクリプトコマンドをコピー&ペーストしないでください。プロジェクトタイプに基づいて選択してください。

プロジェクトタイプ 関連するスクリプト
フロントエンド/React ux_audit.py, accessibility_checker.py
バックエンド/API api_validator.py, security_scan.py
モバイル mobile_audit.py
データベース schema_validator.py
フルスタック 触れた内容に基づいて上記の組み合わせ

間違い: すべてのスクリプトをすべての計画に追加すること 正しい: このタスクに関連するスクリプトのみ


原則5: 検証はシンプルであること

❌ 間違い ✅ 正しい
「コンポーネントが正しく動作することを確認する」 npm run dev を実行し、ボタンをクリックし、トーストが表示されることを確認する」
「APIをテストする」 「curl localhost:3000/api/users が200を返すことを確認する」
「スタイルをチェックする」 「ブラウザを開き、ダークモードの切り替えが機能することを確認する」

計画の構造(柔軟であり、固定ではありません!)

# [タスク名]

## 目標
一文で: 何を構築/修正するのか?

## タスク
- [ ] タスク1: [具体的な行動] → 検証: [確認方法]
- [ ] タスク2: [具体的な行動] → 検証: [確認方法]
- [ ] タスク3: [具体的な行動] → 検証: [確認方法]

## 完了条件
- [ ] [主な成功基準]

これだけです。 本当に必要でない限り、フェーズやサブセクションはありません。 最小限に保ち、必要な場合にのみ複雑さを追加してください。

注意事項

[重要な考慮事項]



---

## ベストプラクティス(クイックリファレンス)

1. **目標から始める** - 何を構築/修正するのか?
2. **最大10タスク** - それ以上なら、複数の計画に分割する
3. **各タスクは検証可能であること** - 明確な「完了」基準
4. **プロジェクト固有であること** - テンプレートのコピー&ペーストはしない
5. **進行に合わせて更新する** - 完了したら `[x]` をマークする

---

## 使用する場面
- 新規プロジェクトをゼロから始める場合
- 機能を​​追加する場合
- バグを修正する場合(複雑な場合)
- 複数のファイルをリファクタリングする場合

## 制限事項
- このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全境界、または成功基準が不足している場合は、作業を中断し、明確化を求めてください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Plan Writing

Source: obra/superpowers

Overview

This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.

Task Breakdown Principles

1. Small, Focused Tasks

  • Each task should take 2-5 minutes
  • One clear outcome per task
  • Independently verifiable

2. Clear Verification

  • How do you know it's done?
  • What can you check/test?
  • What's the expected output?

3. Logical Ordering

  • Dependencies identified
  • Parallel work where possible
  • Critical path highlighted
  • Phase X: Verification is always LAST

4. Dynamic Naming in Project Root

  • Plan files are saved as {task-slug}.md in the PROJECT ROOT
  • Name derived from task (e.g., "add auth" → auth-feature.md)
  • NEVER inside .claude/, docs/, or temp folders

Planning Principles (NOT Templates!)

🔴 NO fixed templates. Each plan is UNIQUE to the task.

Principle 1: Keep It SHORT

❌ Wrong ✅ Right
50 tasks with sub-sub-tasks 5-10 clear tasks max
Every micro-step listed Only actionable items
Verbose descriptions One-line per task

Rule: If plan is longer than 1 page, it's too long. Simplify.


Principle 2: Be SPECIFIC, Not Generic

❌ Wrong ✅ Right
"Set up project" "Run npx create-next-app"
"Add authentication" "Install next-auth, create /api/auth/[...nextauth].ts"
"Style the UI" "Add Tailwind classes to Header.tsx"

Rule: Each task should have a clear, verifiable outcome.


Principle 3: Dynamic Content Based on Project Type

For NEW PROJECT:

  • What tech stack? (decide first)
  • What's the MVP? (minimal features)
  • What's the file structure?

For FEATURE ADDITION:

  • Which files are affected?
  • What dependencies needed?
  • How to verify it works?

For BUG FIX:

  • What's the root cause?
  • What file/line to change?
  • How to test the fix?

Principle 4: Scripts Are Project-Specific

🔴 DO NOT copy-paste script commands. Choose based on project type.

Project Type Relevant Scripts
Frontend/React ux_audit.py, accessibility_checker.py
Backend/API api_validator.py, security_scan.py
Mobile mobile_audit.py
Database schema_validator.py
Full-stack Mix of above based on what you touched

Wrong: Adding all scripts to every plan Right: Only scripts relevant to THIS task


Principle 5: Verification is Simple

❌ Wrong ✅ Right
"Verify the component works correctly" "Run npm run dev, click button, see toast"
"Test the API" "curl localhost:3000/api/users returns 200"
"Check styles" "Open browser, verify dark mode toggle works"

Plan Structure (Flexible, Not Fixed!)

# [Task Name]

## Goal
One sentence: What are we building/fixing?

## Tasks
- [ ] Task 1: [Specific action] → Verify: [How to check]
- [ ] Task 2: [Specific action] → Verify: [How to check]
- [ ] Task 3: [Specific action] → Verify: [How to check]

## Done When
- [ ] [Main success criteria]

That's it. No phases, no sub-sections unless truly needed. Keep it minimal. Add complexity only when required.

Notes

[Any important considerations]



---

## Best Practices (Quick Reference)

1. **Start with goal** - What are we building/fixing?
2. **Max 10 tasks** - If more, break into multiple plans
3. **Each task verifiable** - Clear "done" criteria
4. **Project-specific** - No copy-paste templates
5. **Update as you go** - Mark `[x]` when complete

---

## When to Use
- New project from scratch
- Adding a feature
- Fixing a bug (if complex)
- Refactoring multiple files

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.