create-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

実装計画の作成

Creating Implementation Plans

実装タスクの計画を

_/local-plans/<plan-name>.md

に作成する。

Create implementation task plans in

_/local-plans/<plan-name>.md

引数の処理

Argument Handling

引数あり → 引数をタスク説明として使用し、計画作成を開始する
引数なし → ユーザーにタスク内容を質問してから開始する

With arguments → Use the arguments as task description and start creating the plan
Without arguments → Ask the user for task details before starting

行動原則

Action Principles

コードベースの調査を先に行う — 推測で計画を立てない。Explore Agent や Glob/Grep で既存コードを読んで現状を把握する
検証可能な粒度で書く — 各ステップの完了条件が明確であること
ファイル構成を必ず含める — 作成・変更するファイルをツリー形式で明示する
フェーズは独立性を意識する — 可能な限り並列実行可能な単位で分割する
日本語で記述する — 計画ファイルは日本語で作成する
認証が必要な場所への書き込みは
_/
経由で行う —
```
.claude/
```
など認証プロンプトが発生するディレクトリにファイルを作成する場合、まず
```
_/
```
に一時的に作成し、完成後に
```
mv
```
で目的の場所に移動する。後片付けでは自分が作成したファイル・サブディレクトリのみ削除し、
```
_/
```
が空の場合のみ
```
rmdir
```
で削除する（
```
rm -rf _/dotclaude
```
は禁止 — 並行作業のファイルを消す恐れがある）

Investigate the codebase first — Do not make plans based on assumptions. Use Explore Agent, Glob/Grep to read existing code and understand the current state
Write in verifiable granularity — Each step must have clear completion criteria
Always include file structure — Explicitly list files to be created/modified in tree format
Focus on phase independence — Split into parallel-executable units as much as possible
Write in Japanese — Plan files must be created in Japanese
Write to authenticated locations via
_/
— When creating files in directories that trigger authentication prompts (e.g.,
```
.claude/
```
), first create them temporarily in
```
_/
```
, then move to the target location with
```
mv
```
after completion. During cleanup, only delete files/subdirectories you created, and only delete
```
_/
```
with
```
rmdir
```
if it is empty (Prohibited:
```
rm -rf _/dotclaude
```
— risk of deleting files from concurrent work)

計画作成の手順

Plan Creation Steps

Step 1: タスクの理解

Step 1: Understand the Task

ユーザーの説明を解析する
必要に応じてコードベースを調査する（Explore Agent / Glob / Grep）
- 関連する既存ファイルの構造
- 使用している技術スタック・ライブラリ
- 既存の類似実装やパターン
- 影響範囲（変更が波及するファイル）
前提条件・制約を整理する

Analyze the user's description
Investigate the codebase as needed (Explore Agent / Glob / Grep)
- Structure of related existing files
- Technology stack/libraries used
- Existing similar implementations or patterns
- Scope of impact (files affected by changes)
Organize prerequisites and constraints

Step 2: 計画のドラフト

Step 2: Draft the Plan

以下の標準フォーマットに従って計画を構成する。

Structure the plan according to the following standard format.

Step 3: 計画ファイルの作成

Step 3: Create the Plan File

ファイル名: kebab-case でタスク内容を反映した簡潔な名前にする
- 例:
```
auth-middleware-rewrite.md
```
  ,
```
chakra-ui-skill.md
```
  ,
```
api-endpoint-refactor.md
```
出力先:
```
_/local-plans/<plan-name>.md
```
ユーザーに計画ファイルのパスを報告する

File name: Use a concise kebab-case name that reflects the task content
- Examples:
```
auth-middleware-rewrite.md
```
  ,
```
chakra-ui-skill.md
```
  ,
```
api-endpoint-refactor.md
```
Output location:
```
_/local-plans/<plan-name>.md
```
Report the plan file path to the user

標準フォーマット（テンプレート）

Standard Format (Template)

計画は

plan-verifier

Agent で検証可能な形式にすること。ファイル構成はフルパスで記載し、各フェーズの成果物を明示する。

markdown

undefined

The plan must be in a format that can be validated by the

plan-verifier

Agent. File structures should be written with full paths, and deliverables for each phase should be clearly stated.

markdown

undefined

{タスクタイトル}

{Task Title}

背景・目的

Background & Purpose

{なぜこのタスクが必要か} {解決したい課題} {期待される成果}

{Why this task is necessary} {Issues to solve} {Expected outcomes}

現状整理

Current Status

{関連する現在の状態 — 既存ファイル、技術スタック、依存関係}

{Relevant current state — existing files, technology stack, dependencies}

設計

Design

ファイル構成

File Structure

{作成・変更するファイルのツリー図}

{Tree diagram of files to be created/modified}

仕様

Specifications

{技術的な設計詳細 — API、データ構造、フォーマット等}

{Technical design details — APIs, data structures, formats, etc.}

実装ステップ

Implementation Steps

Phase 1: {フェーズ名}

Phase 1: {Phase Name}

{具体的なタスク}
{具体的なタスク}

{Specific task}
{Specific task}

Phase 2: {フェーズ名}

Phase 2: {Phase Name}

{具体的なタスク}
{具体的なタスク}

{必要に応じて Phase N まで}

{Specific task}
{Specific task}

{Add Phase N as needed}

並列実行戦略

Parallel Execution Strategy

{並列化可能な作業がある場合のみ記載}

{Only include if there are parallelizable tasks}

検証方法

Verification Methods

{計画の成果物が正しく完成したことをどう確認するか} {plan-verifier Agent での検証ポイント}

{How to confirm that the plan deliverables are correctly completed} {Verification points for the plan-verifier Agent}

将来の拡張

Future Enhancements

{スコープ外だが関連する発展可能性 — 任意}

undefined

{Related development possibilities outside the scope — optional}

undefined

セクションごとの注意

Notes for Each Section

背景・目的: 必須。なぜ作るのかを明確にする
現状整理: 関連する既存の状態があれば記載する。新規作成のみの場合は省略可
設計: 必須。ファイル構成（ツリー形式）は必ず含める
実装ステップ: 必須。フェーズ分割し、各ステップは具体的なアクションにする
並列実行戦略: 並列化可能な作業がある場合のみ記載
検証方法: 必須。成果物の確認方法を明記する
将来の拡張: 任意。スコープ外の関連事項があれば記載する

Background & Purpose: Required. Clearly state why the task is being done
Current Status: Include if there is relevant existing state. Can be omitted if only creating new items
Design: Required. Must include file structure (tree format)
Implementation Steps: Required. Split into phases, each step should be a specific action
Parallel Execution Strategy: Only include if there are parallelizable tasks
Verification Methods: Required. Clearly state how to verify deliverables
Future Enhancements: Optional. Include if there are related items outside the scope