SuperAPI AI Directory
Partner中文AI newsFavorites
Skillscreate-plan

create-plan

Agents & models

View repository

Updated 10-15 22:11

About this skill

Creating an implementation plan

Create the implementation task plan in _/local-plans/<plan-name>.md .

Handling arguments

  • With arguments → use the arguments as the task description and start creating the plan
  • Without arguments → ask the user for the task content before starting

Principles of conduct

  1. Investigate the codebase first — Do not make plans based on guesswork. Read existing code with the Explore Agent or Glob/Grep to grasp the current state
  2. Write at a verifiable granularity — The completion conditions for each step must be clear
  3. Always include the file structure — Clearly indicate the files to be created and modified in tree form
  4. Be mindful of phase independence — Divide into units that can be executed in parallel wherever possible
  5. Write in Japanese — Create the plan file in Japanese
  6. Write to locations that require authentication via _/ When creating files in directories that trigger authentication prompts, such as — .claude/ , first create them temporarily in _/ , and after completion move them to the target location with mv . During cleanup, delete only the files and subdirectories that you created yourself, and only if_/ is empty, delete it with rmdir (rm -rf _/dotclaude is prohibited — it may delete files from parallel work)

Plan creation procedure

Step 1: Understanding the task

  • Analyze the user's explanation
  • Investigate the codebase (Explore Agent / Glob / Grep)
    • The structure of related existing files
    • The technology stack and libraries in use
    • Existing similar implementations and patterns
    • Scope of impact (files affected by the changes)
  • Organize preconditions and constraints
  • Cross-check the scope against existing documents — Check whether the scope of this task is consistent with the scope descriptions and exclusion descriptions in README / spec / architecture etc., and if there is any discrepancy (stepping into areas explicitly marked as excluded, inconsistency in scope expressions between documents), do not include it in the plan andpresent it explicitly to the user and ask for their judgment

Step 2: Drafting the plan

Structure the plan according to the standard format below.

Step 3: Creating the plan file

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

Standard format (template)

The plan follows the standard format below (plan-verifier in environments where an Agent is deployed, it becomes the verification target). Describe the file structure with full paths, and make the deliverables of each phase explicit.

# {タスクタイトル}

## 背景・目的

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

## 現状整理

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

## 設計

### ファイル構成

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

### 仕様

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

## 受入基準

- {利用者視点の受入基準 1 — 「誰がどのコマンド / 手順で何を確認できるか」で書く}
- {利用者視点の受入基準 2}

## 実装ステップ

### Phase 1: {フェーズ名}

1. {具体的なタスク}
2. {具体的なタスク}

### Phase 2: {フェーズ名}

1. {具体的なタスク}
2. {具体的なタスク}

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

## 受入基準トレーサビリティ

| 受入基準 | 実現するタスク |
|----------|----------------|
| {受入基準 1} | {Phase N-M} |
| {受入基準 2} | {Phase N-M} |

## 並列実行戦略

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

## 検証方法

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

## 将来の拡張

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

Notes for each section

  • Background and purpose: Required. Clarify why it is being built
  • Current state organization: Describe any related existing state. May be omitted if it is a new creation only
  • Design: Required. Always include the file structure (tree format)
  • Acceptance criteria: Required. Write from the user's perspective (who can confirm what, and by which procedure)
  • Implementation steps: Required. Divide into phases, and make each step a concrete action
  • Acceptance criteria traceability: Required. Associate each acceptance criterion with the tasks that realize it. If even one acceptance criterion has no corresponding task, add it to the implementation steps before finalizing the plan (Detect here any omissions in implementation of user flows — CLI aliases, procedure documents, etc.)
  • Parallel execution strategy: Describe only if there is work that can be parallelized
  • Verification method: Required. Specify how to confirm the deliverables
  • Future extensions: Optional. Describe any related matters outside the scope

Verification

(The following is the completion confirmation procedure for the skill itself. It is separate from the template heading ## 検証方法 in the plan file)

After creating the plan file, confirm with the following.

ls _/local-plans/
  • The plan file exists in _/local-plans/<plan-name>.md to exist in
  • Read the file and confirm that the sections "Background and purpose", "Design", "Acceptance criteria", "Implementation steps", "Acceptance criteria traceability", and "Verification method" are all present
  • Each Phase's tasks describe concrete actions (not vague descriptions such as "do ~")
  • No acceptance criteria exist in the traceability table without corresponding tasks

plan-verifier In environments where an Agent is available, pass the plan file path and verify.

Common failures

Problem Workaround
Making a plan based on guesswork without investigating the codebase In Step 1, always read the code with Explore Agent / Glob / Grep before designing
The file structure tree is too abstract Explicitly state the files to create/modify with full paths (do not omit them by using relative paths)
Phase granularity is too coarse to parallelize Break down tasks with no dependencies into separate Phases or independent steps within the same Phase
The verification method is vague, saying only "check the operation" Specifically describe the commands to execute and the expected output and exit code
There are no tasks corresponding to the acceptance criteria in the implementation steps Cross-check with the traceability table, add the missing tasks (such as user flows) to the implementation steps, and then finalize
The scope of the plan diverges from the user's understanding and the scope description in the existing docs In Step 1, cross-check with the scope and exclusion descriptions in the README / spec / architecture, and if there are discrepancies, present them explicitly to the user