Command Development
AnthropicOfficialPublished by Anthropic
- Skill
- Tool integration
- Agent tooling
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Slash commands are Markdown-based instructions that allow Claude to execute specific, reusable tasks. This skill provides the framework for creating these commands, including how to use YAML frontmatter for configuration, dynamic arguments for flexibility, and bash execution for context-aware automation. It covers best practices for command structure, organization, and documentation to ensure commands are maintainable and easy to use.
What it does
- Defines the structure of slash commands using Markdown and YAML frontmatter.
- Explains how to implement dynamic arguments and file references for interactive tasks.
- Guides the integration of bash commands to gather repository or environment context.
- Provides patterns for organizing commands into project-specific or personal namespaces.
- Offers best practices for command design, validation, and error handling.
- Details how to document commands for better discoverability and maintainability.
When to use it
- When you need to automate a recurring, multi-step task in Claude Code.
- When you want to standardize workflows across a team or project.
- When you need to create custom utilities that require specific tool access or model settings.
- When you want to build complex, state-aware workflows using multiple commands.
Advantages
- Increases efficiency by turning complex prompts into simple, reusable commands.
- Ensures consistency in task execution across different users and projects.
- Enables dynamic behavior through argument passing and inline bash execution.
- Supports modular organization, making it easy to manage large sets of commands.
Usage examples
- “Create a slash command to review a pull request.”
- The agent will generate a Markdown file with appropriate frontmatter and instructions to analyze a PR, including steps for fetching details and checking code quality.
- “How do I add an argument to my custom command?”
- The agent will explain how to use $1, $2, or $ARGUMENTS syntax within your command file and how to document it using the argument-hint frontmatter field.
- “Show me how to run a bash script inside a command.”
- The agent will provide a template showing how to use backticks with bash commands and how to configure allowed-tools in the frontmatter for security.
- “How should I organize my project commands?”
- The agent will suggest a namespaced directory structure for your .claude/commands/ folder to keep related tasks grouped logically.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/anthropics/command-development/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip command-development.zip -d .agents/skills
Documentation by Anthropic
Command Development for Claude Code
Note: The
.claude/commands/directory is a legacy format. For new skills, use the.claude/skills/<name>/SKILL.mddirectory format. Both are loaded identically — the only difference is file layout. See theskill-developmentskill for the preferred format.
Overview
Slash commands are frequently-used prompts defined as Markdown files that Claude executes during interactive sessions. Understanding command structure, frontmatter options, and dynamic features enables creating powerful, reusable workflows.
Key concepts:
Markdown file format for commands
YAML frontmatter for configuration
Dynamic arguments and file references
Bash execution for context
Command organization and namespacing
Command Basics
What is a Slash Command?
A slash command is a Markdown file containing a prompt that Claude executes when invoked. Commands provide:
Reusability: Define once, use repeatedly
Consistency: Standardize common workflows
Sharing: Distribute across team or projects
Efficiency: Quick access to complex prompts
Critical: Commands are Instructions FOR Claude
Commands are written for agent consumption, not human consumption.
When a user invokes /command-name, the command content becomes Claude's instructions. Write commands as directives TO Claude about what to do, not as messages TO the user.
Correct approach (instructions for Claude):
Review this code for security vulnerabilities including:
- SQL injection
- XSS attacks
- Authentication issues
Provide specific line numbers and severity ratings.Incorrect approach (messages to user):
This command will review your code for security issues.
You'll receive a report with vulnerability details.The first example tells Claude what to do. The second tells the user what will happen but doesn't instruct Claude. Always use the first approach.
Command Locations
Project commands (shared with team):
Location:
.claude/commands/Scope: Available in specific project
Label: Shown as "(project)" in
/helpUse for: Team workflows, project-specific tasks
Personal commands (available everywhere):
Location:
~/.claude/commands/Scope: Available in all projects
Label: Shown as "(user)" in
/helpUse for: Personal workflows, cross-project utilities
Plugin commands (bundled with plugins):
Location:
plugin-name/commands/Scope: Available when plugin installed
Label: Shown as "(plugin-name)" in
/helpUse for: Plugin-specific functionality
File Format
Basic Structure
Commands are Markdown files with .md extension:
.claude/commands/
├── review.md # /review command
├── test.md # /test command
└── deploy.md # /deploy commandSimple command:
Review this code for security vulnerabilities including:
- SQL injection
- XSS attacks
- Authentication bypass
- Insecure data handlingNo frontmatter needed for basic commands.
With YAML Frontmatter
Add configuration using YAML frontmatter:
---
description: Review code for security issues
allowed-tools: Read, Grep, Bash(git:*)
model: sonnet
---
Review this code for security vulnerabilities...YAML Frontmatter Fields
description
Purpose: Brief description shown in /help
Type: String
Default: First line of command prompt
---
description: Review pull request for code quality
---Best practice: Clear, actionable description (under 60 characters)
allowed-tools
Purpose: Specify which tools command can use Type: String or Array Default: Inherits from conversation
---
allowed-tools: Read, Write, Edit, Bash(git:*)
---Patterns:
Read, Write, Edit- Specific toolsBash(git:*)- Bash with git commands only*- All tools (rarely needed)
Use when: Command requires specific tool access
model
Purpose: Specify model for command execution Type: String (sonnet, opus, haiku) Default: Inherits from conversation
---
model: haiku
---Use cases:
haiku- Fast, simple commandssonnet- Standard workflowsopus- Complex analysis
argument-hint
Purpose: Document expected arguments for autocomplete Type: String Default: None
---
argument-hint: [pr-number] [priority] [assignee]
---Benefits:
Helps users understand command arguments
Improves command discovery
Documents command interface
disable-model-invocation
Purpose: Prevent SlashCommand tool from programmatically calling command Type: Boolean Default: false
---
disable-model-invocation: true
---Use when: Command should only be manually invoked
Dynamic Arguments
Using $ARGUMENTS
Capture all arguments as single string:
---
description: Fix issue by number
argument-hint: [issue-number]
---
Fix issue #$ARGUMENTS following our coding standards and best practices.Usage:
> /fix-issue 123
> /fix-issue 456Expands to:
Fix issue #123 following our coding standards...
Fix issue #456 following our coding standards...Using Positional Arguments
Capture individual arguments with $1, $2, $3, etc.:
---
description: Review PR with priority and assignee
argument-hint: [pr-number] [priority] [assignee]
---
Review pull request #$1 with priority level $2.
After review, assign to $3 for follow-up.Usage:
> /review-pr 123 high aliceExpands to:
Review pull request #123 with priority level high.
After review, assign to alice for follow-up.Combining Arguments
Mix positional and remaining arguments:
Deploy $1 to $2 environment with options: $3Usage:
> /deploy api staging --force --skip-testsExpands to:
Deploy api to staging environment with options: --force --skip-testsFile References
Using @ Syntax
Include file contents in command:
---
description: Review specific file
argument-hint: [file-path]
---
Review @$1 for:
- Code quality
- Best practices
- Potential bugsUsage:
> /review-file src/api/users.tsEffect: Claude reads src/api/users.ts before processing command
Multiple File References
Reference multiple files:
Compare @src/old-version.js with @src/new-version.js
Identify:
- Breaking changes
- New features
- Bug fixesStatic File References
Reference known files without arguments:
Review @package.json and @tsconfig.json for consistency
Ensure:
- TypeScript version matches
- Dependencies are aligned
- Build configuration is correctBash Execution in Commands
Commands can execute bash commands inline to dynamically gather context before Claude processes the command. This is useful for including repository state, environment information, or project-specific context.
When to use:
Include dynamic context (git status, environment vars, etc.)
Gather project/repository state
Build context-aware workflows
Implementation details:
For complete syntax, examples, and best practices, see references/plugin-features-reference.md section on bash execution. The reference includes the exact syntax and multiple working examples to avoid execution issues
Command Organization
Flat Structure
Simple organization for small command sets:
.claude/commands/
├── build.md
├── test.md
├── deploy.md
├── review.md
└── docs.mdUse when: 5-15 commands, no clear categories
Namespaced Structure
Organize commands in subdirectories:
.claude/commands/
├── ci/
│ ├── build.md # /build (project:ci)
│ ├── test.md # /test (project:ci)
│ └── lint.md # /lint (project:ci)
├── git/
│ ├── commit.md # /commit (project:git)
│ └── pr.md # /pr (project:git)
└── docs/
├── generate.md # /generate (project:docs)
└── publish.md # /publish (project:docs)Benefits:
Logical grouping by category
Namespace shown in
/helpEasier to find related commands
Use when: 15+ commands, clear categories
Best Practices
Command Design
Single responsibility: One command, one task
Clear descriptions: Self-explanatory in
/helpExplicit dependencies: Use
allowed-toolswhen neededDocument arguments: Always provide
argument-hintConsistent naming: Use verb-noun pattern (review-pr, fix-issue)
Argument Handling
Validate arguments: Check for required arguments in prompt
Provide defaults: Suggest defaults when arguments missing
Document format: Explain expected argument format
Handle edge cases: Consider missing or invalid arguments
---
argument-hint: [pr-number]
---
$IF($1,
Review PR #$1,
Please provide a PR number. Usage: /review-pr [number]
)File References
Explicit paths: Use clear file paths
Check existence: Handle missing files gracefully
Relative paths: Use project-relative paths
Glob support: Consider using Glob tool for patterns
Bash Commands
Limit scope: Use
Bash(git:*)notBash(*)Safe commands: Avoid destructive operations
Handle errors: Consider command failures
Keep fast: Long-running commands slow invocation
Documentation
Add comments: Explain complex logic
Provide examples: Show usage in comments
List requirements: Document dependencies
Version commands: Note breaking changes
---
description: Deploy application to environment
argument-hint: [environment] [version]
---
<!--
Usage: /deploy [staging|production] [version]
Requires: AWS credentials configured
Example: /deploy staging v1.2.3
-->
Deploy application to $1 environment using version $2...Common Patterns
Review Pattern
---
description: Review code changes
allowed-tools: Read, Bash(git:*)
---
Files changed: !`git diff --name-only`
Review each file for:
1. Code quality and style
2. Potential bugs or issues
3. Test coverage
4. Documentation needs
Provide specific feedback for each file.Testing Pattern
---
description: Run tests for specific file
argument-hint: [test-file]
allowed-tools: Bash(npm:*)
---
Run tests: !`npm test $1`
Analyze results and suggest fixes for failures.Documentation Pattern
---
description: Generate documentation for file
argument-hint: [source-file]
---
Generate comprehensive documentation for @$1 including:
- Function/class descriptions
- Parameter documentation
- Return value descriptions
- Usage examples
- Edge cases and errorsWorkflow Pattern
---
description: Complete PR workflow
argument-hint: [pr-number]
allowed-tools: Bash(gh:*), Read
---
PR #$1 Workflow:
1. Fetch PR: !`gh pr view $1`
2. Review changes
3. Run checks
4. Approve or request changesTroubleshooting
Command not appearing:
Check file is in correct directory
Verify
.mdextension presentEnsure valid Markdown format
Restart Claude Code
Arguments not working:
Verify
$1,$2syntax correctCheck
argument-hintmatches usageEnsure no extra spaces
Bash execution failing:
Check
allowed-toolsincludes BashVerify command syntax in backticks
Test command in terminal first
Check for required permissions
File references not working:
Verify
@syntax correctCheck file path is valid
Ensure Read tool allowed
Use absolute or project-relative paths
Plugin-Specific Features
CLAUDE_PLUGIN_ROOT Variable
Plugin commands have access to ${CLAUDE_PLUGIN_ROOT}, an environment variable that resolves to the plugin's absolute path.
Purpose:
Reference plugin files portably
Execute plugin scripts
Load plugin configuration
Access plugin templates
Basic usage:
---
description: Analyze using plugin script
allowed-tools: Bash(node:*)
---
Run analysis: !`node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1`
Review results and report findings.Common patterns:
# Execute plugin script
!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh`
# Load plugin configuration
@${CLAUDE_PLUGIN_ROOT}/config/settings.json
# Use plugin template
@${CLAUDE_PLUGIN_ROOT}/templates/report.md
# Access plugin resources
@${CLAUDE_PLUGIN_ROOT}/docs/reference.mdWhy use it:
Works across all installations
Portable between systems
No hardcoded paths needed
Essential for multi-file plugins
Plugin Command Organization
Plugin commands discovered automatically from commands/ directory:
plugin-name/
├── commands/
│ ├── foo.md # /foo (plugin:plugin-name)
│ ├── bar.md # /bar (plugin:plugin-name)
│ └── utils/
│ └── helper.md # /helper (plugin:plugin-name:utils)
└── plugin.jsonNamespace benefits:
Logical command grouping
Shown in
/helpoutputAvoid name conflicts
Organize related commands
Naming conventions:
Use descriptive action names
Avoid generic names (test, run)
Consider plugin-specific prefix
Use hyphens for multi-word names
Plugin Command Patterns
Configuration-based pattern:
---
description: Deploy using plugin configuration
argument-hint: [environment]
allowed-tools: Read, Bash(*)
---
Load configuration: @${CLAUDE_PLUGIN_ROOT}/config/$1-deploy.json
Deploy to $1 using configuration settings.
Monitor deployment and report status.Template-based pattern:
---
description: Generate docs from template
argument-hint: [component]
---
Template: @${CLAUDE_PLUGIN_ROOT}/templates/docs.md
Generate documentation for $1 following template structure.Multi-script pattern:
---
description: Complete build workflow
allowed-tools: Bash(*)
---
Build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh`
Test: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/test.sh`
Package: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/package.sh`
Review outputs and report workflow status.See references/plugin-features-reference.md for detailed patterns.
Integration with Plugin Components
Commands can integrate with other plugin components for powerful workflows.
Agent Integration
Launch plugin agents for complex tasks:
---
description: Deep code review
argument-hint: [file-path]
---
Initiate comprehensive review of @$1 using the code-reviewer agent.
The agent will analyze:
- Code structure
- Security issues
- Performance
- Best practices
Agent uses plugin resources:
- ${CLAUDE_PLUGIN_ROOT}/config/rules.json
- ${CLAUDE_PLUGIN_ROOT}/checklists/review.mdKey points:
Agent must exist in
plugin/agents/directoryClaude uses Task tool to launch agent
Document agent capabilities
Reference plugin resources agent uses
Skill Integration
Leverage plugin skills for specialized knowledge:
---
description: Document API with standards
argument-hint: [api-file]
---
Document API in @$1 following plugin standards.
Use the api-docs-standards skill to ensure:
- Complete endpoint documentation
- Consistent formatting
- Example quality
- Error documentation
Generate production-ready API docs.Key points:
Skill must exist in
plugin/skills/directoryMention skill name to trigger invocation
Document skill purpose
Explain what skill provides
Hook Coordination
Design commands that work with plugin hooks:
Commands can prepare state for hooks to process
Hooks execute automatically on tool events
Commands should document expected hook behavior
Guide Claude on interpreting hook output
See references/plugin-features-reference.md for examples of commands that coordinate with hooks
Multi-Component Workflows
Combine agents, skills, and scripts:
---
description: Comprehensive review workflow
argument-hint: [file]
allowed-tools: Bash(node:*), Read
---
Target: @$1
Phase 1 - Static Analysis:
!`node ${CLAUDE_PLUGIN_ROOT}/scripts/lint.js $1`
Phase 2 - Deep Review:
Launch code-reviewer agent for detailed analysis.
Phase 3 - Standards Check:
Use coding-standards skill for validation.
Phase 4 - Report:
Template: @${CLAUDE_PLUGIN_ROOT}/templates/review.md
Compile findings into report following template.When to use:
Complex multi-step workflows
Leverage multiple plugin capabilities
Require specialized analysis
Need structured outputs
Validation Patterns
Commands should validate inputs and resources before processing.
Argument Validation
---
description: Deploy with validation
argument-hint: [environment]
---
Validate environment: !`echo "$1" | grep -E "^(dev|staging|prod)$" || echo "INVALID"`
If $1 is valid environment:
Deploy to $1
Otherwise:
Explain valid environments: dev, staging, prod
Show usage: /deploy [environment]File Existence Checks
---
description: Process configuration
argument-hint: [config-file]
---
Check file exists: !`test -f $1 && echo "EXISTS" || echo "MISSING"`
If file exists:
Process configuration: @$1
Otherwise:
Explain where to place config file
Show expected format
Provide example configurationPlugin Resource Validation
---
description: Run plugin analyzer
allowed-tools: Bash(test:*)
---
Validate plugin setup:
- Script: !`test -x ${CLAUDE_PLUGIN_ROOT}/bin/analyze && echo "✓" || echo "✗"`
- Config: !`test -f ${CLAUDE_PLUGIN_ROOT}/config.json && echo "✓" || echo "✗"`
If all checks pass, run analysis.
Otherwise, report missing components.Error Handling
---
description: Build with error handling
allowed-tools: Bash(*)
---
Execute build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh 2>&1 || echo "BUILD_FAILED"`
If build succeeded:
Report success and output location
If build failed:
Analyze error output
Suggest likely causes
Provide troubleshooting stepsBest practices:
Validate early in command
Provide helpful error messages
Suggest corrective actions
Handle edge cases gracefully
For detailed frontmatter field specifications, see references/frontmatter-reference.md.
For plugin-specific features and patterns, see references/plugin-features-reference.md.
For command pattern examples, see examples/ directory.
Files
- ATTRIBUTION.mdAdded by AutoGineer976 B
- LICENSELicence file added by AutoGineer11.1 KiB
- README.md7.5 KiB
- SKILL.md18.8 KiB
- examples/plugin-commands.md13.7 KiB
- examples/simple-commands.md8.5 KiB
- references/advanced-workflows.md13.3 KiB
- references/documentation-patterns.md14.6 KiB
- references/frontmatter-reference.md8.9 KiB
- references/interactive-commands.md20.5 KiB
- references/marketplace-considerations.md16.1 KiB
- references/plugin-features-reference.md14.3 KiB
- references/testing-strategies.md14.5 KiB
references/interactive-commands.md
Interactive Command Patterns
Comprehensive guide to creating commands that gather user feedback and make decisions through the AskUserQuestion tool.
Overview
Some commands need user input that doesn't work well with simple arguments. For example:
Choosing between multiple complex options with trade-offs
Selecting multiple items from a list
Making decisions that require explanation
Gathering preferences or configuration interactively
For these cases, use the AskUserQuestion tool within command execution rather than relying on command arguments.
When to Use AskUserQuestion
Use AskUserQuestion When:
Multiple choice decisions with explanations needed
Complex options that require context to choose
Multi-select scenarios (choosing multiple items)
Preference gathering for configuration
Interactive workflows that adapt based on answers
Use Command Arguments When:
Simple values (file paths, numbers, names)
Known inputs user already has
Scriptable workflows that should be automatable
Fast invocations where prompting would slow down
AskUserQuestion Basics
Tool Parameters
{
questions: [
{
question: "Which authentication method should we use?",
header: "Auth method", // Short label (max 12 chars)
multiSelect: false, // true for multiple selection
options: [
{
label: "OAuth 2.0",
description: "Industry standard, supports multiple providers"
},
{
label: "JWT",
description: "Stateless, good for APIs"
},
{
label: "Session",
description: "Traditional, server-side state"
}
]
}
]
}Key points:
Users can always choose "Other" to provide custom input (automatic)
multiSelect: trueallows selecting multiple optionsOptions should be 2-4 choices (not more)
Can ask 1-4 questions per tool call
Command Pattern for User Interaction
Basic Interactive Command
---
description: Interactive setup command
allowed-tools: AskUserQuestion, Write
---
# Interactive Plugin Setup
This command will guide you through configuring the plugin with a series of questions.
## Step 1: Gather Configuration
Use the AskUserQuestion tool to ask:
**Question 1 - Deployment target:**
- header: "Deploy to"
- question: "Which deployment platform will you use?"
- options:
- AWS (Amazon Web Services with ECS/EKS)
- GCP (Google Cloud with GKE)
- Azure (Microsoft Azure with AKS)
- Local (Docker on local machine)
**Question 2 - Environment strategy:**
- header: "Environments"
- question: "How many environments do you need?"
- options:
- Single (Just production)
- Standard (Dev, Staging, Production)
- Complete (Dev, QA, Staging, Production)
**Question 3 - Features to enable:**
- header: "Features"
- question: "Which features do you want to enable?"
- multiSelect: true
- options:
- Auto-scaling (Automatic resource scaling)
- Monitoring (Health checks and metrics)
- CI/CD (Automated deployment pipeline)
- Backups (Automated database backups)
## Step 2: Process Answers
Based on the answers received from AskUserQuestion:
1. Parse the deployment target choice
2. Set up environment-specific configuration
3. Enable selected features
4. Generate configuration files
## Step 3: Generate Configuration
Create `.claude/plugin-name.local.md` with:
\`\`\`yaml
---
deployment_target: [answer from Q1]
environments: [answer from Q2]
features:
auto_scaling: [true if selected in Q3]
monitoring: [true if selected in Q3]
ci_cd: [true if selected in Q3]
backups: [true if selected in Q3]
---
# Plugin Configuration
Generated: [timestamp]
Target: [deployment_target]
Environments: [environments]
\`\`\`
## Step 4: Confirm and Next Steps
Confirm configuration created and guide user on next steps.Multi-Stage Interactive Workflow
---
description: Multi-stage interactive workflow
allowed-tools: AskUserQuestion, Read, Write, Bash
---
# Multi-Stage Deployment Setup
This command walks through deployment setup in stages, adapting based on your answers.
## Stage 1: Basic Configuration
Use AskUserQuestion to ask about deployment basics.
Based on answers, determine which additional questions to ask.
## Stage 2: Advanced Options (Conditional)
If user selected "Advanced" deployment in Stage 1:
Use AskUserQuestion to ask about:
- Load balancing strategy
- Caching configuration
- Security hardening options
If user selected "Simple" deployment:
- Skip advanced questions
- Use sensible defaults
## Stage 3: Confirmation
Show summary of all selections.
Use AskUserQuestion for final confirmation:
- header: "Confirm"
- question: "Does this configuration look correct?"
- options:
- Yes (Proceed with setup)
- No (Start over)
- Modify (Let me adjust specific settings)
If "Modify", ask which specific setting to change.
## Stage 4: Execute Setup
Based on confirmed configuration, execute setup steps.Interactive Question Design
Question Structure
Good questions:
Question: "Which database should we use for this project?"
Header: "Database"
Options:
- PostgreSQL (Relational, ACID compliant, best for complex queries)
- MongoDB (Document store, flexible schema, best for rapid iteration)
- Redis (In-memory, fast, best for caching and sessions)Poor questions:
Question: "Database?" // Too vague
Header: "DB" // Unclear abbreviation
Options:
- Option 1 // Not descriptive
- Option 2Option Design Best Practices
Clear labels:
Use 1-5 words
Specific and descriptive
No jargon without context
Helpful descriptions:
Explain what the option means
Mention key benefits or trade-offs
Help user make informed decision
Keep to 1-2 sentences
Appropriate number:
2-4 options per question
Don't overwhelm with too many choices
Group related options
"Other" automatically provided
Multi-Select Questions
When to use multiSelect:
Use AskUserQuestion for enabling features:
Question: "Which features do you want to enable?"
Header: "Features"
multiSelect: true // Allow selecting multiple
Options:
- Logging (Detailed operation logs)
- Metrics (Performance monitoring)
- Alerts (Error notifications)
- Backups (Automatic backups)User can select any combination: none, some, or all.
When NOT to use multiSelect:
Question: "Which authentication method?"
multiSelect: false // Only one auth method makes senseMutually exclusive choices should not use multiSelect.
Command Patterns with AskUserQuestion
Pattern 1: Simple Yes/No Decision
---
description: Command with confirmation
allowed-tools: AskUserQuestion, Bash
---
# Destructive Operation
This operation will delete all cached data.
Use AskUserQuestion to confirm:
Question: "This will delete all cached data. Are you sure?"
Header: "Confirm"
Options:
- Yes (Proceed with deletion)
- No (Cancel operation)
If user selects "Yes":
Execute deletion
Report completion
If user selects "No":
Cancel operation
Exit without changesPattern 2: Multiple Configuration Questions
---
description: Multi-question configuration
allowed-tools: AskUserQuestion, Write
---
# Project Configuration Setup
Gather configuration through multiple questions.
Use AskUserQuestion with multiple questions in one call:
**Question 1:**
- question: "Which programming language?"
- header: "Language"
- options: Python, TypeScript, Go, Rust
**Question 2:**
- question: "Which test framework?"
- header: "Testing"
- options: Jest, PyTest, Go Test, Cargo Test
(Adapt based on language from Q1)
**Question 3:**
- question: "Which CI/CD platform?"
- header: "CI/CD"
- options: GitHub Actions, GitLab CI, CircleCI
**Question 4:**
- question: "Which features do you need?"
- header: "Features"
- multiSelect: true
- options: Linting, Type checking, Code coverage, Security scanning
Process all answers together to generate cohesive configuration.Pattern 3: Conditional Question Flow
---
description: Conditional interactive workflow
allowed-tools: AskUserQuestion, Read, Write
---
# Adaptive Configuration
## Question 1: Deployment Complexity
Use AskUserQuestion:
Question: "How complex is your deployment?"
Header: "Complexity"
Options:
- Simple (Single server, straightforward)
- Standard (Multiple servers, load balancing)
- Complex (Microservices, orchestration)
## Conditional Questions Based on Answer
If answer is "Simple":
- No additional questions
- Use minimal configuration
If answer is "Standard":
- Ask about load balancing strategy
- Ask about scaling policy
If answer is "Complex":
- Ask about orchestration platform (Kubernetes, Docker Swarm)
- Ask about service mesh (Istio, Linkerd, None)
- Ask about monitoring (Prometheus, Datadog, CloudWatch)
- Ask about logging aggregation
## Process Conditional Answers
Generate configuration appropriate for selected complexity level.Pattern 4: Iterative Collection
---
description: Collect multiple items iteratively
allowed-tools: AskUserQuestion, Write
---
# Collect Team Members
We'll collect team member information for the project.
## Question: How many team members?
Use AskUserQuestion:
Question: "How many team members should we set up?"
Header: "Team size"
Options:
- 2 people
- 3 people
- 4 people
- 6 people
## Iterate Through Team Members
For each team member (1 to N based on answer):
Use AskUserQuestion for member details:
Question: "What role for team member [number]?"
Header: "Role"
Options:
- Frontend Developer
- Backend Developer
- DevOps Engineer
- QA Engineer
- Designer
Store each member's information.
## Generate Team Configuration
After collecting all N members, create team configuration file with all members and their roles.Pattern 5: Dependency Selection
---
description: Select dependencies with multi-select
allowed-tools: AskUserQuestion
---
# Configure Project Dependencies
## Question: Required Libraries
Use AskUserQuestion with multiSelect:
Question: "Which libraries does your project need?"
Header: "Dependencies"
multiSelect: true
Options:
- React (UI framework)
- Express (Web server)
- TypeORM (Database ORM)
- Jest (Testing framework)
- Axios (HTTP client)
User can select any combination.
## Process Selections
For each selected library:
- Add to package.json dependencies
- Generate sample configuration
- Create usage examples
- Update documentationBest Practices for Interactive Commands
Question Design
Clear and specific: Question should be unambiguous
Concise header: Max 12 characters for clean display
Helpful options: Labels are clear, descriptions explain trade-offs
Appropriate count: 2-4 options per question, 1-4 questions per call
Logical order: Questions flow naturally
Error Handling
# Handle AskUserQuestion Responses
After calling AskUserQuestion, verify answers received:
If answers are empty or invalid:
Something went wrong gathering responses.
Please try again or provide configuration manually:
[Show alternative approach]
Exit.
If answers look correct:
Process as expectedProgressive Disclosure
# Start Simple, Get Detailed as Needed
## Question 1: Setup Type
Use AskUserQuestion:
Question: "How would you like to set up?"
Header: "Setup type"
Options:
- Quick (Use recommended defaults)
- Custom (Configure all options)
- Guided (Step-by-step with explanations)
If "Quick":
Apply defaults, minimal questions
If "Custom":
Ask all available configuration questions
If "Guided":
Ask questions with extra explanation
Provide recommendations along the wayMulti-Select Guidelines
Good multi-select use:
Question: "Which features do you want to enable?"
multiSelect: true
Options:
- Logging
- Metrics
- Alerts
- Backups
Reason: User might want any combinationBad multi-select use:
Question: "Which database engine?"
multiSelect: true // ❌ Should be single-select
Reason: Can only use one database engineAdvanced Patterns
Validation Loop
---
description: Interactive with validation
allowed-tools: AskUserQuestion, Bash
---
# Setup with Validation
## Gather Configuration
Use AskUserQuestion to collect settings.
## Validate Configuration
Check if configuration is valid:
- Required dependencies available?
- Settings compatible with each other?
- No conflicts detected?
If validation fails:
Show validation errors
Use AskUserQuestion to ask:
Question: "Configuration has issues. What would you like to do?"
Header: "Next step"
Options:
- Fix (Adjust settings to resolve issues)
- Override (Proceed despite warnings)
- Cancel (Abort setup)
Based on answer, retry or proceed or exit.Build Configuration Incrementally
---
description: Incremental configuration builder
allowed-tools: AskUserQuestion, Write, Read
---
# Incremental Setup
## Phase 1: Core Settings
Use AskUserQuestion for core settings.
Save to `.claude/config-partial.yml`
## Phase 2: Review Core Settings
Show user the core settings:
Based on these core settings, you need to configure:
- [Setting A] (because you chose [X])
- [Setting B] (because you chose [Y])
Ready to continue?
## Phase 3: Detailed Settings
Use AskUserQuestion for settings based on Phase 1 answers.
Merge with core settings.
## Phase 4: Final Review
Present complete configuration.
Use AskUserQuestion for confirmation:
Question: "Is this configuration correct?"
Options:
- Yes (Save and apply)
- No (Start over)
- Modify (Edit specific settings)Dynamic Options Based on Context
---
description: Context-aware questions
allowed-tools: AskUserQuestion, Bash, Read
---
# Context-Aware Setup
## Detect Current State
Check existing configuration:
- Current language: !`detect-language.sh`
- Existing frameworks: !`detect-frameworks.sh`
- Available tools: !`check-tools.sh`
## Ask Context-Appropriate Questions
Based on detected language, ask relevant questions.
If language is TypeScript:
Use AskUserQuestion:
Question: "Which TypeScript features should we enable?"
Options:
- Strict Mode (Maximum type safety)
- Decorators (Experimental decorator support)
- Path Mapping (Module path aliases)
If language is Python:
Use AskUserQuestion:
Question: "Which Python tools should we configure?"
Options:
- Type Hints (mypy for type checking)
- Black (Code formatting)
- Pylint (Linting and style)
Questions adapt to project context.Real-World Example: Multi-Agent Swarm Launch
From multi-agent-swarm plugin:
---
description: Launch multi-agent swarm
allowed-tools: AskUserQuestion, Read, Write, Bash
---
# Launch Multi-Agent Swarm
## Interactive Mode (No Task List Provided)
If user didn't provide task list file, help create one interactively.
### Question 1: Agent Count
Use AskUserQuestion:
Question: "How many agents should we launch?"
Header: "Agent count"
Options:
- 2 agents (Best for simple projects)
- 3 agents (Good for medium projects)
- 4 agents (Standard team size)
- 6 agents (Large projects)
- 8 agents (Complex multi-component projects)
### Question 2: Task Definition Approach
Use AskUserQuestion:
Question: "How would you like to define tasks?"
Header: "Task setup"
Options:
- File (I have a task list file ready)
- Guided (Help me create tasks interactively)
- Custom (Other approach)
If "File":
Ask for file path
Validate file exists and has correct format
If "Guided":
Enter iterative task creation mode (see below)
### Question 3: Coordination Mode
Use AskUserQuestion:
Question: "How should agents coordinate?"
Header: "Coordination"
Options:
- Team Leader (One agent coordinates others)
- Collaborative (Agents coordinate as peers)
- Autonomous (Independent work, minimal coordination)
### Iterative Task Creation (If "Guided" Selected)
For each agent (1 to N from Question 1):
**Question A: Agent Name**
Question: "What should we call agent [number]?"
Header: "Agent name"
Options:
- auth-agent
- api-agent
- ui-agent
- db-agent
(Provide relevant suggestions based on common patterns)
**Question B: Task Type**
Question: "What task for [agent-name]?"
Header: "Task type"
Options:
- Authentication (User auth, JWT, OAuth)
- API Endpoints (REST/GraphQL APIs)
- UI Components (Frontend components)
- Database (Schema, migrations, queries)
- Testing (Test suites and coverage)
- Documentation (Docs, README, guides)
**Question C: Dependencies**
Question: "What does [agent-name] depend on?"
Header: "Dependencies"
multiSelect: true
Options:
- [List of previously defined agents]
- No dependencies
**Question D: Base Branch**
Question: "Which base branch for PR?"
Header: "PR base"
Options:
- main
- staging
- develop
Store all task information for each agent.
### Generate Task List File
After collecting all agent task details:
1. Ask for project name
2. Generate task list in proper format
3. Save to `.daisy/swarm/tasks.md`
4. Show user the file path
5. Proceed with launch using generated task listBest Practices
Question Writing
Be specific: "Which database?" not "Choose option?"
Explain trade-offs: Describe pros/cons in option descriptions
Provide context: Question text should stand alone
Guide decisions: Help user make informed choice
Keep concise: Header max 12 chars, descriptions 1-2 sentences
Option Design
Meaningful labels: Specific, clear names
Informative descriptions: Explain what each option does
Show trade-offs: Help user understand implications
Consistent detail: All options equally explained
2-4 options: Not too few, not too many
Flow Design
Logical order: Questions flow naturally
Build on previous: Later questions use earlier answers
Minimize questions: Ask only what's needed
Group related: Ask related questions together
Show progress: Indicate where in flow
User Experience
Set expectations: Tell user what to expect
Explain why: Help user understand purpose
Provide defaults: Suggest recommended options
Allow escape: Let user cancel or restart
Confirm actions: Summarize before executing
Common Patterns
Pattern: Feature Selection
Use AskUserQuestion:
Question: "Which features do you need?"
Header: "Features"
multiSelect: true
Options:
- Authentication
- Authorization
- Rate Limiting
- CachingPattern: Environment Configuration
Use AskUserQuestion:
Question: "Which environment is this?"
Header: "Environment"
Options:
- Development (Local development)
- Staging (Pre-production testing)
- Production (Live environment)Pattern: Priority Selection
Use AskUserQuestion:
Question: "What's the priority for this task?"
Header: "Priority"
Options:
- Critical (Must be done immediately)
- High (Important, do soon)
- Medium (Standard priority)
- Low (Nice to have)Pattern: Scope Selection
Use AskUserQuestion:
Question: "What scope should we analyze?"
Header: "Scope"
Options:
- Current file (Just this file)
- Current directory (All files in directory)
- Entire project (Full codebase scan)Combining Arguments and Questions
Use Both Appropriately
Arguments for known values:
---
argument-hint: [project-name]
allowed-tools: AskUserQuestion, Write
---
Setup for project: $1
Now gather additional configuration...
Use AskUserQuestion for options that require explanation.Questions for complex choices:
Project name from argument: $1
Now use AskUserQuestion to choose:
- Architecture pattern
- Technology stack
- Deployment strategy
These require explanation, so questions work better than arguments.Troubleshooting
Questions not appearing:
Verify AskUserQuestion in allowed-tools
Check question format is correct
Ensure options array has 2-4 items
User can't make selection:
Check option labels are clear
Verify descriptions are helpful
Consider if too many options
Ensure multiSelect setting is correct
Flow feels confusing:
Reduce number of questions
Group related questions
Add explanation between stages
Show progress through workflow
With AskUserQuestion, commands become interactive wizards that guide users through complex decisions while maintaining the clarity that simple arguments provide for straightforward inputs.
Requirements and compatibility
Written for: Claude Code, Claude apps
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Names Claude Code tools, Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Anthropic
- Publisher
- Anthropic (Official)
- Source
- anthropics/claude-plugins-official · plugins/plugin-dev/skills/command-development · commit 0412be7
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from plugins/plugin-dev/LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthropic.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download command-development.zip