command-development

Name: command-development
Author: anthropics

byanthropics· 237 skills

Installs

12k

Stars

139k

Forks

22k

How to install command-development?

anthropics/claude-code/command-development

$npx -y skills add anthropics/claude-code --skill command-development

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/anthropics/claude-code" --skill "anthropics/claude-code/command-development"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/anthropics/claude-code" that are relevant to the current task. Run `npx skills add "https://github.com/anthropics/claude-code"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# Command Development for Claude Code
2
3	## Overview
4
5	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.
6
7	Key concepts:
8	- Markdown file format for commands
9	- YAML frontmatter for configuration
10	- Dynamic arguments and file references
11	- Bash execution for context
12	- Command organization and namespacing
13
14	## Command Basics
15
16	### What is a Slash Command?
17
18	A slash command is a Markdown file containing a prompt that Claude executes when invoked. Commands provide:
19	- Reusability: Define once, use repeatedly
20	- Consistency: Standardize common workflows
21	- Sharing: Distribute across team or projects
22	- Efficiency: Quick access to complex prompts
23
24	### Critical: Commands are Instructions FOR Claude
25
26	Commands are written for agent consumption, not human consumption.
27
28	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.
29
30	Correct approach (instructions for Claude):
31	```markdown
32	Review this code for security vulnerabilities including:
33	- SQL injection
34	- XSS attacks
35	- Authentication issues
36
37	Provide specific line numbers and severity ratings.
38	```
39
40	Incorrect approach (messages to user):
41	```markdown
42	This command will review your code for security issues.
43	You'll receive a report with vulnerability details.
44	```
45
46	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.
47
48	### Command Locations
49
50	Project commands (shared with team):
51	- Location: `.claude/commands/`
52	- Scope: Available in specific project
53	- Label: Shown as "(project)" in `/help`
54	- Use for: Team workflows, project-specific tasks
55
56	Personal commands (available everywhere):
57	- Location: `~/.claude/commands/`
58	- Scope: Available in all projects
59	- Label: Shown as "(user)" in `/help`
60	- Use for: Personal workflows, cross-project utilities
61
62	Plugin commands (bundled with plugins):
63	- Location: `plugin-name/commands/`
64	- Scope: Available when plugin installed
65	- Label: Shown as "(plugin-name)" in `/help`
66	- Use for: Plugin-specific functionality
67
68	## File Format
69
70	### Basic Structure
71
72	Commands are Markdown files with `.md` extension:
73
74	```
75	.claude/commands/
76	├── review.md # /review command
77	├── test.md # /test command
78	└── deploy.md # /deploy command
79	```
80
81	Simple command:
82	```markdown
83	Review this code for security vulnerabilities including:
84	- SQL injection
85	- XSS attacks
86	- Authentication bypass
87	- Insecure data handling
88	```
89
90	No frontmatter needed for basic commands.
91
92	### With YAML Frontmatter
93
94	Add configuration using YAML frontmatter:
95
96	```markdown
97	---
98	description: Review code for security issues
99	allowed-tools: Read, Grep, Bash(git:*)
100	model: sonnet
101	---
102
103	Review this code for security vulnerabilities...
104	```
105
106	## YAML Frontmatter Fields
107
108	### description
109
110	Purpose: Brief description shown in `/help`
111	Type: String
112	Default: First line of command prompt
113
114	```yaml
115	---
116	description: Review pull request for code quality
117	---
118	```
119
120	Best practice: Clear, actionable description (under 60 characters)
121
122	### allowed-tools
123
124	Purpose: Specify which tools command can use
125	Type: String or Array
126	Default: Inherits from conversation
127
128	```yaml
129	---
130	allowed-tools: Read, Write, Edit, Bash(git:*)
131	---
132	```
133
134	Patterns:
135	- `Read, Write, Edit` - Specific tools
136	- `Bash(git:*)` - Bash with git commands only
137	- `*` - All tools (rarely needed)
138
139	Use when: Command requires specific tool access
140
141	### model
142
143	Purpose: Specify model for command execution
144	Type: String (sonnet, opus, haiku)
145	Default: Inherits from conversation
146
147	```yaml
148	---
149	model: haiku
150	---
151	```
152
153	Use cases:
154	- `haiku` - Fast, simple commands
155	- `sonnet` - Standard workflows
156	- `opus` - Complex analysis
157
158	### argument-hint
159
160	Purpose: Document expected arguments for autocomplete
161	Type: String
162	Default: None
163
164	```yaml
165	---
166	argument-hint: [pr-number] [priority] [assignee]
167	---
168	```
169
170	Benefits:
171	- Helps users understand command arguments
172	- Improves command discovery
173	- Documents command interface
174
175	### disable-model-invocation
176
177	Purpose: Prevent SlashCommand tool from programmatically calling command
178	Type: Boolean
179	Default: false
180
181	```yaml
182	---
183	disable-model-invocation: true
184	---
185	```
186
187	Use when: Command should only be manually invoked
188
189	## Dynamic Arguments
190
191	### Using $ARGUMENTS
192
193	Capture all arguments as single string:
194
195	```markdown
196	---
197	description: Fix issue by number
198	argument-hint: [issue-number]
199	---
200
201	Fix issue #$ARGUMENTS following our coding standards and best practices.
202	```
203
204	Usage:
205	```
206	> /fix-issue 123
207	> /fix-issue 456
208	```
209
210	Expands to:
211	```
212	Fix issue #123 following our coding standards...
213	Fix issue #456 following our coding standards...
214	```
215
216	### Using Positional Arguments
217
218	Capture individual arguments with `$1`, `$2`, `$3`, etc.:
219
220	```markdown
221	---
222	description: Review PR with priority and assignee
223	argument-hint: [pr-number] [priority] [assignee]
224	---
225
226	Review pull request #$1 with priority level $2.
227	After review, assign to $3 for follow-up.
228	```
229
230	Usage:
231	```
232	> /review-pr 123 high alice
233	```
234
235	Expands to:
236	```
237	Review pull request #123 with priority level high.
238	After review, assign to alice for follow-up.
239	```
240
241	### Combining Arguments
242
243	Mix positional and remaining arguments:
244
245	```markdown
246	Deploy $1 to $2 environment with options: $3
247	```
248
249	Usage:
250	```
251	> /deploy api staging --force --skip-tests
252	```
253
254	Expands to:
255	```
256	Deploy api to staging environment with options: --force --skip-tests
257	```
258
259	## File References
260
261	### Using @ Syntax
262
263	Include file contents in command:
264
265	```markdown
266	---
267	description: Review specific file
268	argument-hint: [file-path]
269	---
270
271	Review @$1 for:
272	- Code quality
273	- Best practices
274	- Potential bugs
275	```
276
277	Usage:
278	```
279	> /review-file src/api/users.ts
280	```
281
282	Effect: Claude reads `src/api/users.ts` before processing command
283
284	### Multiple File References
285
286	Reference multiple files:
287
288	```markdown
289	Compare @src/old-version.js with @src/new-version.js
290
291	Identify:
292	- Breaking changes
293	- New features
294	- Bug fixes
295	```
296
297	### Static File References
298
299	Reference known files without arguments:
300
301	```markdown
302	Review @package.json and @tsconfig.json for consistency
303
304	Ensure:
305	- TypeScript version matches
306	- Dependencies are aligned
307	- Build configuration is correct
308	```
309
310	## Bash Execution in Commands
311
312	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.
313
314	When to use:
315	- Include dynamic context (git status, environment vars, etc.)
316	- Gather project/repository state
317	- Build context-aware workflows
318
319	Implementation details:
320	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
321
322	## Command Organization
323
324	### Flat Structure
325
326	Simple organization for small command sets:
327
328	```
329	.claude/commands/
330	├── build.md
331	├── test.md
332	├── deploy.md
333	├── review.md
334	└── docs.md
335	```
336
337	Use when: 5-15 commands, no clear categories
338
339	### Namespaced Structure
340
341	Organize commands in subdirectories:
342
343	```
344	.claude/commands/
345	├── ci/
346	│ ├── build.md # /build (project:ci)
347	│ ├── test.md # /test (project:ci)
348	│ └── lint.md # /lint (project:ci)
349	├── git/
350	│ ├── commit.md # /commit (project:git)
351	│ └── pr.md # /pr (project:git)
352	└── docs/
353	├── generate.md # /generate (project:docs)
354	└── publish.md # /publish (project:docs)
355	```
356
357	Benefits:
358	- Logical grouping by category
359	- Namespace shown in `/help`
360	- Easier to find related commands
361
362	Use when: 15+ commands, clear categories
363
364	## Best Practices
365
366	### Command Design
367
368	1. Single responsibility: One command, one task
369	2. Clear descriptions: Self-explanatory in `/help`
370	3. Explicit dependencies: Use `allowed-tools` when needed
371	4. Document arguments: Always provide `argument-hint`
372	5. Consistent naming: Use verb-noun pattern (review-pr, fix-issue)
373
374	### Argument Handling
375
376	1. Validate arguments: Check for required arguments in prompt
377	2. Provide defaults: Suggest defaults when arguments missing
378	3. Document format: Explain expected argument format
379	4. Handle edge cases: Consider missing or invalid arguments
380
381	```markdown
382	---
383	argument-hint: [pr-number]
384	---
385
386	$IF($1,
387	Review PR #$1,
388	Please provide a PR number. Usage: /review-pr [number]
389	)
390	```
391
392	### File References
393
394	1. Explicit paths: Use clear file paths
395	2. Check existence: Handle missing files gracefully
396	3. Relative paths: Use project-relative paths
397	4. Glob support: Consider using Glob tool for patterns
398
399	### Bash Commands
400
401	1. Limit scope: Use `Bash(git:)` not `Bash()`
402	2. Safe commands: Avoid destructive operations
403	3. Handle errors: Consider command failures
404	4. Keep fast: Long-running commands slow invocation
405
406	### Documentation
407
408	1. Add comments: Explain complex logic
409	2. Provide examples: Show usage in comments
410	3. List requirements: Document dependencies
411	4. Version commands: Note breaking changes
412
413	```markdown
414	---
415	description: Deploy application to environment
416	argument-hint: [environment] [version]
417	---
418
419	<!--
420	Usage: /deploy [staging\|production] [version]
421	Requires: AWS credentials configured
422	Example: /deploy staging v1.2.3
423	-->
424
425	Deploy application to $1 environment using version $2...
426	```
427
428	## Common Patterns
429
430	### Review Pattern
431
432	```markdown
433	---
434	description: Review code changes
435	allowed-tools: Read, Bash(git:*)
436	---
437
438	Files changed: !`git diff --name-only`
439
440	Review each file for:
441	1. Code quality and style
442	2. Potential bugs or issues
443	3. Test coverage
444	4. Documentation needs
445
446	Provide specific feedback for each file.
447	```
448
449	### Testing Pattern
450
451	```markdown
452	---
453	description: Run tests for specific file
454	argument-hint: [test-file]
455	allowed-tools: Bash(npm:*)
456	---
457
458	Run tests: !`npm test $1`
459
460	Analyze results and suggest fixes for failures.
461	```
462
463	### Documentation Pattern
464
465	```markdown
466	---
467	description: Generate documentation for file
468	argument-hint: [source-file]
469	---
470
471	Generate comprehensive documentation for @$1 including:
472	- Function/class descriptions
473	- Parameter documentation
474	- Return value descriptions
475	- Usage examples
476	- Edge cases and errors
477	```
478
479	### Workflow Pattern
480
481	```markdown
482	---
483	description: Complete PR workflow
484	argument-hint: [pr-number]
485	allowed-tools: Bash(gh:*), Read
486	---
487
488	PR #$1 Workflow:
489
490	1. Fetch PR: !`gh pr view $1`
491	2. Review changes
492	3. Run checks
493	4. Approve or request changes
494	```
495
496	## Troubleshooting
497
498	Command not appearing:
499	- Check file is in correct directory
500	- Verify `.md` extension present
501	- Ensure valid Markdown format
502	- Restart Claude Code
503
504	Arguments not working:
505	- Verify `$1`, `$2` syntax correct
506	- Check `argument-hint` matches usage
507	- Ensure no extra spaces
508
509	Bash execution failing:
510	- Check `allowed-tools` includes Bash
511	- Verify command syntax in backticks
512	- Test command in terminal first
513	- Check for required permissions
514
515	File references not working:
516	- Verify `@` syntax correct
517	- Check file path is valid
518	- Ensure Read tool allowed
519	- Use absolute or project-relative paths
520
521	## Plugin-Specific Features
522
523	### CLAUDE_PLUGIN_ROOT Variable
524
525	Plugin commands have access to `${CLAUDE_PLUGIN_ROOT}`, an environment variable that resolves to the plugin's absolute path.
526
527	Purpose:
528	- Reference plugin files portably
529	- Execute plugin scripts
530	- Load plugin configuration
531	- Access plugin templates
532
533	Basic usage:
534
535	```markdown
536	---
537	description: Analyze using plugin script
538	allowed-tools: Bash(node:*)
539	---
540
541	Run analysis: !`node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1`
542
543	Review results and report findings.
544	```
545
546	Common patterns:
547
548	```markdown
549	# Execute plugin script
550	!`bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh`
551
552	# Load plugin configuration
553	@${CLAUDE_PLUGIN_ROOT}/config/settings.json
554
555	# Use plugin template
556	@${CLAUDE_PLUGIN_ROOT}/templates/report.md
557
558	# Access plugin resources
559	@${CLAUDE_PLUGIN_ROOT}/docs/reference.md
560	```
561
562	Why use it:
563	- Works across all installations
564	- Portable between systems
565	- No hardcoded paths needed
566	- Essential for multi-file plugins
567
568	### Plugin Command Organization
569
570	Plugin commands discovered automatically from `commands/` directory:
571
572	```
573	plugin-name/
574	├── commands/
575	│ ├── foo.md # /foo (plugin:plugin-name)
576	│ ├── bar.md # /bar (plugin:plugin-name)
577	│ └── utils/
578	│ └── helper.md # /helper (plugin:plugin-name:utils)
579	└── plugin.json
580	```
581
582	Namespace benefits:
583	- Logical command grouping
584	- Shown in `/help` output
585	- Avoid name conflicts
586	- Organize related commands
587
588	Naming conventions:
589	- Use descriptive action names
590	- Avoid generic names (test, run)
591	- Consider plugin-specific prefix
592	- Use hyphens for multi-word names
593
594	### Plugin Command Patterns
595
596	Configuration-based pattern:
597
598	```markdown
599	---
600	description: Deploy using plugin configuration
601	argument-hint: [environment]
602	allowed-tools: Read, Bash(*)
603	---
604
605	Load configuration: @${CLAUDE_PLUGIN_ROOT}/config/$1-deploy.json
606
607	Deploy to $1 using configuration settings.
608	Monitor deployment and report status.
609	```
610
611	Template-based pattern:
612
613	```markdown
614	---
615	description: Generate docs from template
616	argument-hint: [component]
617	---
618
619	Template: @${CLAUDE_PLUGIN_ROOT}/templates/docs.md
620
621	Generate documentation for $1 following template structure.
622	```
623
624	Multi-script pattern:
625
626	```markdown
627	---
628	description: Complete build workflow
629	allowed-tools: Bash(*)
630	---
631
632	Build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh`
633	Test: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/test.sh`
634	Package: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/package.sh`
635
636	Review outputs and report workflow status.
637	```
638
639	See `references/plugin-features-reference.md` for detailed patterns.
640
641	## Integration with Plugin Components
642
643	Commands can integrate with other plugin components for powerful workflows.
644
645	### Agent Integration
646
647	Launch plugin agents for complex tasks:
648
649	```markdown
650	---
651	description: Deep code review
652	argument-hint: [file-path]
653	---
654
655	Initiate comprehensive review of @$1 using the code-reviewer agent.
656
657	The agent will analyze:
658	- Code structure
659	- Security issues
660	- Performance
661	- Best practices
662
663	Agent uses plugin resources:
664	- ${CLAUDE_PLUGIN_ROOT}/config/rules.json
665	- ${CLAUDE_PLUGIN_ROOT}/checklists/review.md
666	```
667
668	Key points:
669	- Agent must exist in `plugin/agents/` directory
670	- Claude uses Task tool to launch agent
671	- Document agent capabilities
672	- Reference plugin resources agent uses
673
674	### Skill Integration
675
676	Leverage plugin skills for specialized knowledge:
677
678	```markdown
679	---
680	description: Document API with standards
681	argument-hint: [api-file]
682	---
683
684	Document API in @$1 following plugin standards.
685
686	Use the api-docs-standards skill to ensure:
687	- Complete endpoint documentation
688	- Consistent formatting
689	- Example quality
690	- Error documentation
691
692	Generate production-ready API docs.
693	```
694
695	Key points:
696	- Skill must exist in `plugin/skills/` directory
697	- Mention skill name to trigger invocation
698	- Document skill purpose
699	- Explain what skill provides
700
701	### Hook Coordination
702
703	Design commands that work with plugin hooks:
704	- Commands can prepare state for hooks to process
705	- Hooks execute automatically on tool events
706	- Commands should document expected hook behavior
707	- Guide Claude on interpreting hook output
708
709	See `references/plugin-features-reference.md` for examples of commands that coordinate with hooks
710
711	### Multi-Component Workflows
712
713	Combine agents, skills, and scripts:
714
715	```markdown
716	---
717	description: Comprehensive review workflow
718	argument-hint: [file]
719	allowed-tools: Bash(node:*), Read
720	---
721
722	Target: @$1
723
724	Phase 1 - Static Analysis:
725	!`node ${CLAUDE_PLUGIN_ROOT}/scripts/lint.js $1`
726
727	Phase 2 - Deep Review:
728	Launch code-reviewer agent for detailed analysis.
729
730	Phase 3 - Standards Check:
731	Use coding-standards skill for validation.
732
733	Phase 4 - Report:
734	Template: @${CLAUDE_PLUGIN_ROOT}/templates/review.md
735
736	Compile findings into report following template.
737	```
738
739	When to use:
740	- Complex multi-step workflows
741	- Leverage multiple plugin capabilities
742	- Require specialized analysis
743	- Need structured outputs
744
745	## Validation Patterns
746
747	Commands should validate inputs and resources before processing.
748
749	### Argument Validation
750
751	```markdown
752	---
753	description: Deploy with validation
754	argument-hint: [environment]
755	---
756
757	Validate environment: !`echo "$1" \| grep -E "^(dev\|staging\|prod)$" \|\| echo "INVALID"`
758
759	If $1 is valid environment:
760	Deploy to $1
761	Otherwise:
762	Explain valid environments: dev, staging, prod
763	Show usage: /deploy [environment]
764	```
765
766	### File Existence Checks
767
768	```markdown
769	---
770	description: Process configuration
771	argument-hint: [config-file]
772	---
773
774	Check file exists: !`test -f $1 && echo "EXISTS" \|\| echo "MISSING"`
775
776	If file exists:
777	Process configuration: @$1
778	Otherwise:
779	Explain where to place config file
780	Show expected format
781	Provide example configuration
782	```
783
784	### Plugin Resource Validation
785
786	```markdown
787	---
788	description: Run plugin analyzer
789	allowed-tools: Bash(test:*)
790	---
791
792	Validate plugin setup:
793	- Script: !`test -x ${CLAUDE_PLUGIN_ROOT}/bin/analyze && echo "✓" \|\| echo "✗"`
794	- Config: !`test -f ${CLAUDE_PLUGIN_ROOT}/config.json && echo "✓" \|\| echo "✗"`
795
796	If all checks pass, run analysis.
797	Otherwise, report missing components.
798	```
799
800	### Error Handling
801
802	```markdown
803	---
804	description: Build with error handling
805	allowed-tools: Bash(*)
806	---
807
808	Execute build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh 2>&1 \|\| echo "BUILD_FAILED"`
809
810	If build succeeded:
811	Report success and output location
812	If build failed:
813	Analyze error output
814	Suggest likely causes
815	Provide troubleshooting steps
816	```
817
818	Best practices:
819	- Validate early in command
820	- Provide helpful error messages
821	- Suggest corrective actions
822	- Handle edge cases gracefully
823
824	---
825
826	For detailed frontmatter field specifications, see `references/frontmatter-reference.md`.
827	For plugin-specific features and patterns, see `references/plugin-features-reference.md`.
828	For command pattern examples, see `examples/` directory.

6 picks

Type

Run `npx skills use "https://github.com/anthropics/claude-code" --skill "anthropics/claude-code/command-development"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/anthropics/claude-code" that are relevant to the current task. Run `npx skills add "https://github.com/anthropics/claude-code"` and select the relevant skills, then follow their instructions.

command-development

How to install command-development?

Related

command-development

How to install command-development?

Related