Create Prompt

Create a prompt for a well-defined task that's ready to implement.

Task: $ARGUMENTS

If $ARGUMENTS is empty or vague, ask the user: "What task do you want to create a prompt for?" Do not proceed until you have a clear task description.

Use this when:

• •The task is clear and scoped
• •You understand what needs to be built
• •No research phase needed

If the task needs exploration first, use /create-meta-prompt instead. Heuristic: if you need to read more than 5 files to understand the scope, or if there are multiple viable approaches, redirect to /create-meta-prompt. If a dedicated slash command exists for the task type (e.g., /ddd-analysis, /extract-requirements), use that instead of creating a prompt. See /pipeline for the complete list of pipeline commands.

Steps

1. •

   Read project context

   • •CLAUDE.md (required if exists)
   • •README.md
   • •Relevant source files
2. •

   Clarify if needed (1-2 questions max)

   • •What does success look like?
   • •Any constraints or preferences?
   • •Skip if obvious from context
3. •

   Design checkpoints

   • •Break work into incremental steps
   • •Each checkpoint: implementation + unit tests for that checkpoint's code
   • •All existing + new tests must pass at the end of each checkpoint
   • •Each should be reviewable/commitable independently
   • •NEVER put a dedicated "testing" checkpoint at the end — tests are written alongside the code they verify
   • •Exception: a checkpoint that is purely non-code work (documentation, configuration) does not need tests
   • •Target 3-7 checkpoints. If more than 7 are needed, the task may be too large — consider splitting into multiple prompts or using /create-meta-prompt for better planning.
4. •

   Write prompt to .prompts/NNN-name.md (use lowercase-hyphenated format for the name, e.g., 001-add-user-validation.md). Create .prompts/ directory if it doesn't exist.

   Important: Do NOT use names ending in -research or -plan — these suffixes are reserved for meta-prompt directories and would cause ambiguity in /run-prompt resolution.

Prompt Template

# [Task Name]

## Objective
[What to build and why - 1-2 sentences]

## Context
- Guidelines: `CLAUDE.md`
- Key files: [relevant paths]
- Stack: [if relevant]

## Checkpoints

### 1. [First increment]
- Build: [what to implement]
- Test: [unit tests for the code in this checkpoint]
- Verify: [all tests pass]

### 2. [Second increment]
- Build: [what to implement]
- Test: [unit tests for the code in this checkpoint]
- Verify: [all tests pass]

[Continue as needed - prefer smaller checkpoints. Never have a testing-only checkpoint at the end.]

## Verification
[Test command from CLAUDE.md, e.g., `npm test`, `dotnet test`]

## Done When
[Clear success criteria]

Numbering

ls .prompts/[0-9][0-9][0-9]-*.md 2>/dev/null | sort | tail -1

Increment highest number, or start at 001. Always zero-pad to 3 digits. The glob [0-9][0-9][0-9]-*.md ensures only numbered task prompts are matched, excluding progress files and non-numeric filenames.

After Saving

Say: "Created .prompts/NNN-name.md with N checkpoints. Run with /run-prompt NNN or review first."

Task prompts do not include a metadata block (metadata is only for research.md/plan.md). Progress will be tracked in .prompts/NNN-name.progress.md during execution.