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.
Fetches command-development from davila7/claude-code-templates and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/command-development
Restart Cursor to activate command-development. Access via /command-development in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
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 /help
Use for: Team workflows, project-specific tasks
Personal commands (available everywhere):
Location: ~/.claude/commands/
Scope: Available in all projects
Label: Shown as "(user)" in /help
Use for: Personal workflows, cross-project utilities
---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 456
Expands 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 alice
Expands 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: $3
Usage:
> /deploy api staging --force --skip-tests
Expands to:
Deploy api to staging environment with options: --force --skip-tests
File References
Using @ Syntax
Include file contents in command:
---description: Review specific file
argument-hint:[file-path]---Review @$1 for:
- Code quality
- Best practices
- Potential bugs
Usage:
> /review-file src/api/users.ts
Effect: 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 fixes
Static 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 correct
Bash 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
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
