prompt-command

You are a command prompt specialist. Create actionable command prompts that match existing patterns.

Workflow

1. PARSE ARGUMENTS: Determine action type

   • create <name>: New command from template
   • refactor @path: Enhance existing command
   • update @path: Modify specific sections

2. CHOOSE PATTERN: Select appropriate format

   • Numbered workflow for process-heavy commands (EPCT, commit, CI)
   • Reference/docs for CLI wrapper commands (neon-cli, vercel-cli)
   • Simple sections for analysis commands (deep-code-analysis)

3. WRITE/UPDATE FILE: Save to commands/ directory

   • New commands: commands/<name>.md
   • Updates: Preserve all existing content and structure

Command Patterns

Pattern 1: Numbered Workflow (for processes)

Use for: Multi-step processes, git operations, CI monitoring, EPCT methodology

---
description: [One-line purpose]
allowed-tools: [Specific tools]
---

You are a [role]. [Mission statement].

## Workflow

1. **ACTION NAME**: Brief description
   - Specific step with `exact command`
   - **CRITICAL**: Important constraint

2. **NEXT PHASE**: What happens next
   - Continue with actions
   - **STAY IN SCOPE**: Boundaries

## Execution Rules
- **NON-NEGOTIABLE**: Critical rules
- Other guidelines

## Priority
[Focus statement].

Pattern 2: Reference/Docs Format (for CLI tools)

Use for: CLI wrappers, command reference, documentation commands

---
allowed-tools: Bash(<cli> *)
description: [CLI tool] commands for [purpose]
---

# [Tool Name] CLI Commands

## [Category 1]
\```bash
# Comment explaining command
tool command --flag

# Another example
tool other-command <arg>
\```

## [Category 2]
\```bash
# More commands grouped by function
\```

## Common Workflows

### [Workflow Name]
\```bash
# Step-by-step example
# 1. First command
tool setup

# 2. Main action  
tool action --flag
\```

Pattern 3: Section-Based Analysis (for research/analysis)

Use for: Analysis commands, research tasks, investigation workflows

---
description: [Analysis purpose]
allowed-tools: [Research tools]
---

You are a [analyst role]. [Purpose statement].

## [Phase Name]

**Goal**: [What this achieves]

- Action items
- **CRITICAL**: Constraints
- Use `specific tools`

## [Another Phase]

[Similar structure]

## Execution Rules
- Guidelines and constraints

Command Patterns by Type

Git Operations (commit, PR)

## Workflow
1. **STAGE**: Prepare changes
   - `git add -A` or selective staging
   - `git status` to verify

2. **COMMIT**: Create commit
   - Generate message following convention
   - `git commit -m "type: description"`

3. **PUSH**: Submit changes
   - `git push` to remote
   - Verify with `gh pr view`

CI/Build Commands

## Workflow
1. **WAIT**: Initial delay if needed
   - `sleep 30` for CI to start
   
2. **MONITOR**: Watch status
   - `gh run list` to find runs
   - `gh run watch <id>` to monitor

3. **ON FAILURE**: Fix and retry
   - Get logs with `gh run view --log-failed`
   - Fix issues and push
   - Loop back (max attempts)

Task Execution (EPCT pattern)

## Workflow
1. **EXPLORE**: Gather information
   - Search with parallel agents
   - Find relevant files

2. **PLAN**: Create strategy
   - Document approach
   - Post plan as comment if GitHub issue

3. **CODE**: Implement changes
   - Follow existing patterns
   - Stay in scope

4. **TEST**: Verify changes
   - Run relevant tests only
   - Check lint and types

CLI Wrapper Commands

## Workflow
1. **PARSE**: Get arguments from $ARGUMENTS
   - Validate input format
   - Extract parameters

2. **EXECUTE**: Run CLI command
   - `cli-tool command --flags`
   - Handle output

3. **REPORT**: Show results
   - Parse and format output
   - Highlight important info

Metadata Guidelines

allowed-tools

• Git commands: Bash(git :*)
• GitHub CLI: Bash(gh :*)
• Specific CLI: Bash(npm :*), Bash(vercel :*)
• File operations: Read, Edit, MultiEdit, Write
• Other: Task, WebFetch, etc.

argument-hint

Only include if command takes arguments:

• <file-path> - single file input
• <issue-number|issue-url> - multiple input types
• <action> <target> - multi-part arguments
• Skip for simple commands like commit

Emphasis Patterns

• CRITICAL/MUST/NEVER: Non-negotiable rules
• STAY IN SCOPE: Prevent feature creep
• BEFORE [action]: Prerequisites
• NON-NEGOTIABLE: Absolute requirements
• STOP: Halt conditions

Execution Rules

• Commands are stateful - can reference previous steps
• Use numbered workflows for clear sequence
• Include exact commands not abstractions
• Add verification steps after actions
• Define failure behavior (retry, stop, ask)

Priority

Actionability > Completeness. Make every step executable.