
create-slash-commands
by nicanac
High-performance directory and orchestration hub for Senior Vibe Architects. Discover tools, prompts, and agent profiles.
SKILL.md
name: create-slash-commands description: Expert guidance for creating Antigravity slash commands. Use when working with slash commands, creating custom commands, understanding command structure, or learning YAML configuration.
Objective
Create effective slash commands for Antigravity that enable users to trigger reusable prompts with /command-name syntax. Slash commands expand as prompts in the current conversation, allowing teams to standardize workflows and operations.
Commands can be global (available everywhere in ~/.agent/commands/) or project-specific (shared with team in .agent/commands/). This skill teaches you to structure commands with proper formatting (Markdown), YAML frontmatter, dynamic context loading, and intelligent argument handling.
CRITICAL WORKFLOW: This skill enforces a mandatory research phase where you MUST:
- Read all reference documentation
- Examine existing slash commands for patterns
- Understand syntax and best practices
- Only then create the command
This prevents poorly-structured commands and ensures consistency with established patterns.
Quick Start
Workflow
- Create
.agent/commands/directory (project) or use~/.agent/commands/(personal) - Create
command-name.mdfile - Add YAML frontmatter (at minimum:
description) - Write command prompt
- Test with
/command-name [args]
Example
File: .agent/commands/optimize.md
---
description: Analyze this code for performance issues and suggest optimizations
---
Analyze the performance of this code and suggest three specific optimizations:
Usage: /optimize
Antigravity receives the expanded prompt and analyzes the code in context.
Markdown Structure
Slash commands should use Markdown headings (Headers) in the body (after YAML frontmatter).
Format:
- Markdown Headers: The standard for Antigravity commands (
## Objective,## Process) - Compatibility: Antigravity parses Markdown headers effectively for instruction structuring.
Required Sections
## Objective - What the command does and why it matters
## Objective
What needs to happen and why this matters.
Context about who uses this and what it accomplishes.
## Process - How to execute the command
## Process
1. First step
2. Second step
3. Final step
## Success Criteria - How to know the command succeeded
## Success Criteria
- Clear, measurable criteria for successful completion.
Conditional Sections
## Context - When loading dynamic state or files
## Context
Current state: ! `git status`
Relevant files: @ package.json
(Note: Remove the space after @ in actual usage)
## Verification - When producing artifacts that need checking
## Verification
Before completing, verify:
- Specific test or check to perform
- How to confirm it works
## Testing - When running tests is part of the workflow
## Testing
Run tests: ! `npm test`
Check linting: ! `npm run lint`
## Output - When creating/modifying specific files
## Output
Files created/modified:
- `./path/to/file.ext` - Description
Structure Example
---
name: example-command
description: Does something useful
argument-hint: [input]
---
## Objective
Process #$ARGUMENTS to accomplish [goal].
This helps [who] achieve [outcome].
## Context
Current state: ! `relevant command`
Files: @ relevant/files
## Process
1. Parse #$ARGUMENTS
2. Execute operation
3. Verify results
## Success Criteria
- Operation completed without errors
- Output matches expected format
Intelligence Rules
Simple commands (single operation, no artifacts):
- Required:
## Objective,## Process,## Success Criteria - Example:
/check-todos,/first-principles
Complex commands (multi-step, produces artifacts):
- Required:
## Objective,## Process,## Success Criteria - Add:
## Context(if loading state),## Verification(if creating files),## Output(what gets created) - Example:
/commit,/create-prompt,/run-prompt
Commands with dynamic arguments:
- Use
#$ARGUMENTSin body - Include
argument-hintin frontmatter - Make it clear what the arguments are for
Commands that produce files:
- Always include
## Outputsection specifying what gets created - Always include
## Verificationsection with checks to perform
Commands that run tests/builds:
- Include
## Testingsection with specific commands - Include pass/fail criteria in
## Success Criteria
Arguments Intelligence
The skill should intelligently determine whether a slash command needs arguments.
Commands That Need Arguments
User provides specific input:
/fix-issue [issue-number]- Needs issue number/review-pr [pr-number]- Needs PR number/optimize [file-path]- Needs file to optimize/commit [type]- Needs commit type (optional)
Pattern: Task operates on user-specified data
Include argument-hint: [description] in frontmatter and reference #$ARGUMENTS in the body.
Commands Without Arguments
Self-contained procedures:
/check-todos- Operates on known file (TO-DOS.md)/first-principles- Operates on current conversation/whats-next- Analyzes current context
Pattern: Task operates on implicit context (current conversation, known files, project state)
Omit argument-hint and don't reference #$ARGUMENTS.
Incorporating Arguments
In Objective:
## Objective
Fix issue #$ARGUMENTS following project conventions.
In Process:
## Process
1. Understand issue #$ARGUMENTS from issue tracker
In Context:
## Context
Issue details: @ issues/#$ARGUMENTS.md
Related files: ! `grep -r "TODO.*#$ARGUMENTS" src/`
Positional Arguments
For structured input, use $1, $2, $3:
---
argument-hint: <pr-number> <priority> <assignee>
---
## Objective
Review PR #$1 with priority $2 and assign to $3.
Usage: /review-pr 456 high alice
File Structure
Project commands: .agent/commands/ (in project root)
- Shared with team via version control
- Project-specific workflows
- Shows
(project)in/helplist
Global commands: ~/.agent/commands/ (user home directory)
- Available across all your projects
- Personal productivity commands
- Shows
(user)in/helplist
Choosing between global and project:
- Use global for: Personal workflows, general utilities, commands you use everywhere
- Use project for: Team workflows, project-specific operations, shared conventions
YAML Frontmatter
Field: description
Required - Describes what the command does
description: Analyze this code for performance issues and suggest optimizations
Field: allowed-tools
Optional - Restricts which tools Antigravity can use
allowed-tools: [Read, Edit, Write]
# or
allowed-tools: Bash(git add:*)
Arguments Usage
All Arguments String
Use #$ARGUMENTS to capture all arguments strings.
Fix issue #$ARGUMENTS following our coding standards
Usage: /fix-issue 123 high-priority
Received: "Fix issue #123 high-priority following our coding standards"
Positional Arguments
Use $1, $2 for split arguments.
Review PR #$1 with priority $2
Usage: /review-pr 456 high
Received: "Review PR #456 with priority high"
Dynamic Context
Execute bash commands before the prompt using the exclamation mark prefix directly before backticks !.
## Context
- Current git status: ! `git status`
- Current git diff: ! `git diff HEAD`
Use @ prefix to reference specific files:
Review the implementation in @ src/utils/helpers.js
Best Practices
1. Always use Markdown Structure After frontmatter, use standard Markdown headers:
## Objective## Process## Success Criteria
2. Clear descriptions
Write descriptive summaries for the /help list.
3. Use dynamic context for state-dependent tasks Load fresh status for git ops or tests.
4. Restrict tools when appropriate
Use allowed-tools to prevent unintended actions (e.g. restrict to Analysis tools only).
5. Use #$ARGUMENTS for flexibility Let users specify files or IDs at runtime.
6. Reference relevant files
Use @filename to load context automatically.
Common Patterns
Simple Analysis Command
---
description: Review this code for security vulnerabilities
---
## Objective
Review code for security vulnerabilities and suggest fixes.
## Process
1. Scan code for common vulnerabilities
2. Identify specific issues
3. Suggest remediation
## Success Criteria
- All major vulnerability types checked
- Issues identified with locations
Git Workflow with Context
---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---
## Objective
Create a git commit for current changes following repository conventions.
## Context
- Current status: ! `git status`
- Changes: ! `git diff HEAD`
- Recent commits: ! `git log --oneline -5`
## Process
1. Review staged and unstaged changes
2. Stage relevant files
3. Write commit message
4. Create commit
## Success Criteria
- Commit created successfully
- Message follows conventions
Reference Guides
Slash command specific references:
Generation Protocol (See mandatory research steps in previous sections)
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
3ヶ月以内に更新がある
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon