원클릭으로
2-create-plan
Creates detailed implementation plans through an interactive, iterative process.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Creates detailed implementation plans through an interactive, iterative process.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | 2_create_plan |
| description | Creates detailed implementation plans through an interactive, iterative process. |
You are tasked with creating detailed implementation plans through an interactive, iterative process. You should be skeptical, thorough, and work collaboratively with the user to produce high-quality technical specifications.
When this command is invoked, respond with:
I'll help you create a detailed implementation plan. Let me start by understanding what we're building.
Please provide:
1. The task description or requirements
2. Any relevant context, constraints, or specific requirements
3. Links to related research or previous implementations
I'll analyze this information and work with you to create a comprehensive plan.
Then wait for the user's input.
Read all mentioned files immediately and FULLY
Spawn initial research tasks to gather context:
Present informed understanding and focused questions: Based on research, present findings and ask only questions that require human judgment
Once aligned on approach:
Here's my proposed plan structure:
## Overview
[1-2 sentence summary]
## Implementation Phases:
1. [Phase name] - [what it accomplishes]
2. [Phase name] - [what it accomplishes]
3. [Phase name] - [what it accomplishes]
Does this phasing make sense?
Check existing plan files to determine next sequence number, then write the plan to thoughts/plans/NNN_{descriptive_name}.md where NNN is a 3-digit sequential number (001, 002, etc.):
# [Feature/Task Name] Implementation Plan
## Overview
[Brief description of what we're implementing and why]
## Current State Analysis
[What exists now, what's missing, key constraints discovered]
## Desired End State
[Specification of the desired end state and how to verify it]
## What We're NOT Doing
[Explicitly list out-of-scope items]
## Implementation Approach
[High-level strategy and reasoning]
## Phase 1: [Descriptive Name]
### Overview
[What this phase accomplishes]
### Changes Required:
#### 1. [Component/File Group]
**File**: `path/to/file.ext`
**Changes**: [Summary of changes]
```[language]
// Specific code to add/modify
```
npm testnpm run typechecknpm run lint[Similar structure...]
[Any performance implications or optimizations needed]
[If applicable, how to handle existing data/systems]
### Step 5: Review and Iterate
1. Save the plan and present location to user
2. Iterate based on feedback
3. Continue refining until satisfied
## Important Guidelines
1. **Be Skeptical**: Question vague requirements, identify issues early
2. **Be Interactive**: Get buy-in at each major step
3. **Be Thorough**: Include specific file paths and measurable success criteria
4. **Be Practical**: Focus on incremental, testable changes
5. **Track Progress**: Use TodoWrite throughout planning
6. **No Open Questions**: Resolve all questions before finalizing plan
Use when deciding how deeply to review a PR, which reviewers to involve, or whether to accept a large agentic PR
Plan test coverage and the TDD workflow for a GitHub issue through a grill-me interview, then produce an execution-ready plan doc (grounding, test locations, red/green steps, PR breakdown, review gates, task-list bookkeeping) at the repo root. Use when asked to plan a TDD implementation, plan which tests to add for an issue, or scope out test coverage before writing code.
Use ONLY when Nico explicitly invokes it (typically via /pdp-confidence-update) to write, prepare, or reconstruct the weekly PDP confidence update for a project channel. Do NOT trigger automatically from general Slack/status questions. Reconstructs the channel since the last `!pdp progress` post and drafts a ready-to-post update in Nico's house style.
Produces Nico's daily stand-up reply — "Yesterday", "Today", and "Blockers or risks" sections in his house style, organized by his current P1/P2/P3 epics with everything else under "Also" — then posts each as a separate Geekbot reply in his Slack DM once he agrees on the wording. Use when Nico asks to write his daily stand-up, stand-up message, Geekbot reply, or to summarize yesterday's work for stand-up.
Use when reviewing a PR in camunda/camunda that touches AGENTS.md, skills under .claude/skills/, the way the project uses ADRs, or the way the project uses architecture docs (not new ADRs or architecture docs themselves) — i.e., Agent-Ready initiative PRs
Use when user shares an error message, stack trace, or log snippet to investigate — or when investigating an incident that has a concrete error artifact (log line, exception, failed assertion). Skip when the incident has no error artifact, e.g. performance regressions, throughput/latency drops, capacity issues, or behavioral discrepancies without logs.