mirror of
https://github.com/duthaho/claudekit.git
synced 2026-08-06 11:40:19 +03:00
Enhance Claude Kit with new features and optimizations
This commit is contained in:
duthaho
@@ -150,6 +150,36 @@ After design is complete:
|
||||
2. Use `/plan --detailed` for implementation planning
|
||||
3. Use `/execute-plan` for automated implementation
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=brainstorm` |
|
||||
| `--depth=[1-5]` | Exploration depth level | `--depth=4` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed) | `--format=detailed` |
|
||||
| `--save=[path]` | Save design document to file | `--save=docs/design.md` |
|
||||
| `--quick` | Shorter session, fewer questions | `--quick` |
|
||||
| `--comprehensive` | Longer session, thorough exploration | `--comprehensive` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/brainstorm --comprehensive "authentication system design"
|
||||
/brainstorm --save=docs/payment-design.md "payment integration"
|
||||
/brainstorm --quick "simple file upload feature"
|
||||
/brainstorm --depth=5 "microservices architecture"
|
||||
```
|
||||
|
||||
### Session Depth
|
||||
|
||||
| Level | Questions | Exploration |
|
||||
|-------|-----------|-------------|
|
||||
| 1 | 2-3 | Quick validation only |
|
||||
| 2 | 4-5 | Standard session |
|
||||
| 3 | 6-8 | Thorough exploration |
|
||||
| 4 | 8-10 | Comprehensive |
|
||||
| 5 | 10+ | Exhaustive, all angles |
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- Clear "mechanical" processes with known implementation
|
||||
|
||||
@@ -0,0 +1,134 @@
|
||||
# /checkpoint
|
||||
|
||||
## Purpose
|
||||
|
||||
Save and restore conversation context using git-based checkpoints. Enables session recovery and state preservation for complex, multi-session work.
|
||||
|
||||
---
|
||||
|
||||
Manage checkpoints for the current work session.
|
||||
|
||||
## Checkpoint Operations
|
||||
|
||||
### Save Checkpoint
|
||||
|
||||
Create a checkpoint of current state:
|
||||
|
||||
```bash
|
||||
/checkpoint save [name]
|
||||
```
|
||||
|
||||
**Process:**
|
||||
1. Create git stash with descriptive message
|
||||
2. Record current context (files being worked on, task state)
|
||||
3. Save checkpoint metadata to `.claude/checkpoints/[name].json`
|
||||
|
||||
**Metadata Format:**
|
||||
```json
|
||||
{
|
||||
"name": "feature-auth",
|
||||
"created": "2024-01-15T14:30:00Z",
|
||||
"git_stash": "stash@{0}",
|
||||
"files_in_context": ["src/auth/login.ts", "src/auth/token.ts"],
|
||||
"current_task": "Implementing JWT refresh",
|
||||
"notes": "User-provided notes"
|
||||
}
|
||||
```
|
||||
|
||||
### List Checkpoints
|
||||
|
||||
Show available checkpoints:
|
||||
|
||||
```bash
|
||||
/checkpoint list
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```markdown
|
||||
## Available Checkpoints
|
||||
|
||||
| Name | Created | Task | Stash |
|
||||
|------|---------|------|-------|
|
||||
| feature-auth | 2h ago | JWT refresh | stash@{0} |
|
||||
| bugfix-login | 1d ago | Login timeout | stash@{1} |
|
||||
```
|
||||
|
||||
### Restore Checkpoint
|
||||
|
||||
Restore a previous checkpoint:
|
||||
|
||||
```bash
|
||||
/checkpoint restore [name]
|
||||
```
|
||||
|
||||
**Process:**
|
||||
1. Apply git stash
|
||||
2. Load checkpoint metadata
|
||||
3. Summarize restored context
|
||||
4. Ready to continue work
|
||||
|
||||
### Delete Checkpoint
|
||||
|
||||
Remove a checkpoint:
|
||||
|
||||
```bash
|
||||
/checkpoint delete [name]
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `--notes="[text]"` | Add notes to checkpoint |
|
||||
| `--force` | Overwrite existing checkpoint |
|
||||
| `--include-uncommitted` | Include uncommitted changes |
|
||||
| `--dry-run` | Show what would be saved |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
/checkpoint save auth-progress # Save current state
|
||||
/checkpoint save auth --notes="WIP tokens" # Save with notes
|
||||
/checkpoint list # Show checkpoints
|
||||
/checkpoint restore auth-progress # Restore state
|
||||
/checkpoint delete old-checkpoint # Remove checkpoint
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
Parse the operation (save/list/restore/delete) and checkpoint name.
|
||||
|
||||
---
|
||||
|
||||
## Auto-Checkpoint
|
||||
|
||||
For complex tasks, checkpoints are automatically suggested:
|
||||
- Before major refactoring
|
||||
- When switching contexts
|
||||
- Before risky operations
|
||||
- At natural breakpoints
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Name Descriptively**: Use task-related names
|
||||
2. **Add Notes**: Future you will thank present you
|
||||
3. **Checkpoint Often**: Before context switches
|
||||
4. **Clean Up**: Delete obsolete checkpoints
|
||||
|
||||
## Recovery Workflow
|
||||
|
||||
When resuming work:
|
||||
```
|
||||
1. /checkpoint list # See available states
|
||||
2. /checkpoint restore [name] # Restore context
|
||||
3. Continue where you left off # Context is loaded
|
||||
```
|
||||
|
||||
## Limitations
|
||||
|
||||
- Checkpoints use git stash (requires git repo)
|
||||
- Large uncommitted changes may be slow
|
||||
- Metadata stored in `.claude/checkpoints/`
|
||||
- Consider committing before checkpointing for safety
|
||||
@@ -181,6 +181,25 @@ git diff --staged
|
||||
4. Updated API documentation
|
||||
5. Commit message and PR description
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=implementation` |
|
||||
| `--depth=[1-5]` | Planning thoroughness level | `--depth=3` |
|
||||
| `--checkpoint` | Create checkpoint before starting | `--checkpoint` |
|
||||
| `--skip-tests` | Skip test generation phase | `--skip-tests` |
|
||||
| `--skip-review` | Skip code review phase | `--skip-review` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed) | `--format=concise` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/feature --mode=implementation "add user profile page"
|
||||
/feature --depth=5 --checkpoint "implement payment flow"
|
||||
/feature --format=concise "add logging utility"
|
||||
```
|
||||
|
||||
<!-- CUSTOMIZATION POINT -->
|
||||
## Variations
|
||||
|
||||
|
||||
@@ -234,6 +234,34 @@ for item in items:
|
||||
3. Fix: Add null check and proper async handling
|
||||
4. Regression test: Test for case when user is not loaded
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=deep-research` |
|
||||
| `--persona=[type]` | Apply persona expertise | `--persona=security` |
|
||||
| `--depth=[1-5]` | Investigation thoroughness | `--depth=4` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed) | `--format=concise` |
|
||||
| `--skip-regression` | Skip regression test creation | `--skip-regression` |
|
||||
| `--checkpoint` | Create checkpoint before fixing | `--checkpoint` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/fix --mode=deep-research "intermittent timeout error"
|
||||
/fix --persona=security "SQL injection vulnerability"
|
||||
/fix --depth=5 "race condition in auth flow"
|
||||
/fix --format=concise "typo in error message"
|
||||
```
|
||||
|
||||
### Persona Options
|
||||
|
||||
| Persona | Focus Area |
|
||||
|---------|------------|
|
||||
| `security` | Security vulnerabilities, OWASP |
|
||||
| `performance` | Speed, memory, efficiency |
|
||||
| `reliability` | Error handling, edge cases |
|
||||
|
||||
<!-- CUSTOMIZATION POINT -->
|
||||
## Variations
|
||||
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
# /index
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate a comprehensive project structure index for faster navigation and context loading. Creates a `PROJECT_INDEX.md` file mapping the codebase structure.
|
||||
|
||||
---
|
||||
|
||||
Analyze the current project and generate a comprehensive index.
|
||||
|
||||
## Index Generation
|
||||
|
||||
### Step 1: Scan Project Structure
|
||||
|
||||
Scan the entire project directory structure, excluding:
|
||||
- `node_modules/`
|
||||
- `.git/`
|
||||
- `__pycache__/`
|
||||
- `dist/`, `build/`, `.next/`
|
||||
- `venv/`, `.venv/`
|
||||
- Coverage and cache directories
|
||||
|
||||
### Step 2: Identify Key Components
|
||||
|
||||
Categorize files by type:
|
||||
- **Entry Points**: Main files, index files, app entry
|
||||
- **API/Routes**: Endpoint definitions
|
||||
- **Models/Types**: Data structures, schemas
|
||||
- **Services**: Business logic
|
||||
- **Utilities**: Helper functions
|
||||
- **Tests**: Test files
|
||||
- **Configuration**: Config files, env templates
|
||||
- **Documentation**: README, docs
|
||||
|
||||
### Step 3: Map Dependencies
|
||||
|
||||
Identify:
|
||||
- Package managers and dependencies (package.json, requirements.txt, etc.)
|
||||
- Internal import relationships between key files
|
||||
- External service integrations
|
||||
|
||||
### Step 4: Generate Index
|
||||
|
||||
Create `PROJECT_INDEX.md` with this structure:
|
||||
|
||||
```markdown
|
||||
# Project Index: [Project Name]
|
||||
|
||||
Generated: [timestamp]
|
||||
|
||||
## Quick Navigation
|
||||
|
||||
| Category | Key Files |
|
||||
|----------|-----------|
|
||||
| Entry Points | [list] |
|
||||
| API Routes | [list] |
|
||||
| Core Services | [list] |
|
||||
| Models | [list] |
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
[tree view]
|
||||
```
|
||||
|
||||
## Key Files
|
||||
|
||||
### Entry Points
|
||||
- `[path]` - [description]
|
||||
|
||||
### API/Routes
|
||||
- `[path]` - [description]
|
||||
|
||||
### Services
|
||||
- `[path]` - [description]
|
||||
|
||||
### Models/Types
|
||||
- `[path]` - [description]
|
||||
|
||||
## Dependencies
|
||||
|
||||
### External
|
||||
- [package]: [purpose]
|
||||
|
||||
### Internal
|
||||
- [module] → [depends on]
|
||||
|
||||
## Architecture Notes
|
||||
[Brief description of patterns observed]
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `--depth=[N]` | Limit directory depth (default: 5) |
|
||||
| `--include=[pattern]` | Include additional patterns |
|
||||
| `--exclude=[pattern]` | Exclude additional patterns |
|
||||
| `--output=[path]` | Custom output path |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
/index # Standard index
|
||||
/index --depth=3 # Shallow index
|
||||
/index --include="*.graphql" # Include GraphQL files
|
||||
/index --output=docs/INDEX.md # Custom output location
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
If no arguments provided, generate standard index with default settings.
|
||||
|
||||
---
|
||||
|
||||
After generating the index, inform the user:
|
||||
1. Index file location
|
||||
2. Number of files indexed
|
||||
3. Key components discovered
|
||||
4. Suggest using `/load` to load specific components into context
|
||||
@@ -0,0 +1,108 @@
|
||||
# /load
|
||||
|
||||
## Purpose
|
||||
|
||||
Load specific project components into context for focused work. Uses the project index to efficiently load relevant files.
|
||||
|
||||
---
|
||||
|
||||
Load the requested component(s) into context.
|
||||
|
||||
## Loading Process
|
||||
|
||||
### Step 1: Check for Index
|
||||
|
||||
First, check if `PROJECT_INDEX.md` exists:
|
||||
- If exists: Use index for efficient loading
|
||||
- If not: Suggest running `/index` first, or do quick scan
|
||||
|
||||
### Step 2: Identify Component
|
||||
|
||||
Parse the requested component:
|
||||
|
||||
| Request Type | Action |
|
||||
|--------------|--------|
|
||||
| Category name | Load all files in category |
|
||||
| File path | Load specific file |
|
||||
| Pattern | Load matching files |
|
||||
| `--all` | Load key files from all categories |
|
||||
|
||||
### Step 3: Load Files
|
||||
|
||||
Read the identified files and summarize:
|
||||
- File purposes
|
||||
- Key exports/functions
|
||||
- Dependencies
|
||||
- Current state
|
||||
|
||||
### Step 4: Context Summary
|
||||
|
||||
Provide a brief summary:
|
||||
```markdown
|
||||
## Loaded Context
|
||||
|
||||
### Files Loaded (N)
|
||||
- `path/to/file1.ts` - [purpose]
|
||||
- `path/to/file2.ts` - [purpose]
|
||||
|
||||
### Key Components
|
||||
- [Component]: [description]
|
||||
|
||||
### Ready For
|
||||
- [Suggested actions based on loaded context]
|
||||
```
|
||||
|
||||
## Component Categories
|
||||
|
||||
| Category | What It Loads |
|
||||
|----------|---------------|
|
||||
| `api` | API routes and endpoints |
|
||||
| `models` | Data models and types |
|
||||
| `services` | Business logic services |
|
||||
| `utils` | Utility functions |
|
||||
| `tests` | Test files |
|
||||
| `config` | Configuration files |
|
||||
| `auth` | Authentication related |
|
||||
| `db` | Database related |
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `--all` | Load all key components |
|
||||
| `--shallow` | Load only file summaries |
|
||||
| `--deep` | Load full file contents |
|
||||
| `--related` | Include related files |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
/load api # Load all API routes
|
||||
/load models # Load all data models
|
||||
/load src/services/user.ts # Load specific file
|
||||
/load auth --related # Load auth + related files
|
||||
/load --all # Load all key components
|
||||
/load --all --shallow # Quick overview of everything
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
If no arguments, show available components from index.
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Start Narrow**: Load specific components first
|
||||
2. **Expand as Needed**: Use `--related` when you need more context
|
||||
3. **Check Index**: Run `/index` if loading seems slow
|
||||
4. **Use Categories**: Category names are faster than patterns
|
||||
|
||||
## After Loading
|
||||
|
||||
Suggest next actions:
|
||||
- "Ready to work on [component]. What would you like to do?"
|
||||
- "I see [patterns/issues]. Want me to address them?"
|
||||
- "Related files that might be relevant: [list]"
|
||||
@@ -0,0 +1,166 @@
|
||||
# /mode
|
||||
|
||||
## Purpose
|
||||
|
||||
Switch between behavioral modes to optimize responses for different task types. Modes adjust communication style, output format, and problem-solving approach.
|
||||
|
||||
---
|
||||
|
||||
Switch to the specified behavioral mode.
|
||||
|
||||
## Available Modes
|
||||
|
||||
| Mode | Description | Best For |
|
||||
|------|-------------|----------|
|
||||
| `default` | Balanced standard behavior | General tasks |
|
||||
| `brainstorm` | Creative exploration, more questions | Design, ideation |
|
||||
| `token-efficient` | Compressed, concise output | High-volume, cost savings |
|
||||
| `deep-research` | Thorough analysis, citations | Investigation, audits |
|
||||
| `implementation` | Code-focused, minimal prose | Executing plans |
|
||||
| `review` | Critical analysis, finding issues | Code review, QA |
|
||||
| `orchestration` | Multi-task coordination | Complex parallel work |
|
||||
|
||||
## Mode Switching
|
||||
|
||||
### Activate Mode
|
||||
```bash
|
||||
/mode [mode-name]
|
||||
```
|
||||
|
||||
### Check Current Mode
|
||||
```bash
|
||||
/mode
|
||||
```
|
||||
(Shows current active mode)
|
||||
|
||||
### Reset to Default
|
||||
```bash
|
||||
/mode default
|
||||
```
|
||||
|
||||
## Mode Details
|
||||
|
||||
### Default Mode
|
||||
- Standard balanced responses
|
||||
- Mix of explanation and code
|
||||
- Normal verification steps
|
||||
|
||||
### Brainstorm Mode
|
||||
- Ask more clarifying questions
|
||||
- Present multiple alternatives
|
||||
- Explore trade-offs explicitly
|
||||
- Delay convergence on solutions
|
||||
|
||||
### Token-Efficient Mode
|
||||
- Minimal explanations
|
||||
- Code-only responses where possible
|
||||
- Skip obvious context
|
||||
- 30-70% token savings
|
||||
|
||||
### Deep-Research Mode
|
||||
- Thorough investigation
|
||||
- Evidence and citations
|
||||
- Confidence levels stated
|
||||
- Comprehensive analysis
|
||||
|
||||
### Implementation Mode
|
||||
- Jump straight to code
|
||||
- Progress indicators
|
||||
- Minimal discussion
|
||||
- Execute don't deliberate
|
||||
|
||||
### Review Mode
|
||||
- Look for issues first
|
||||
- Categorized findings
|
||||
- Severity levels
|
||||
- Actionable feedback
|
||||
|
||||
### Orchestration Mode
|
||||
- Task breakdown
|
||||
- Parallel execution planning
|
||||
- Result aggregation
|
||||
- Coordination focus
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `--info` | Show detailed mode description |
|
||||
| `--list` | List all available modes |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
/mode brainstorm # Switch to brainstorm mode
|
||||
/mode token-efficient # Switch to efficient mode
|
||||
/mode # Show current mode
|
||||
/mode --list # List all modes
|
||||
/mode default # Reset to default
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
If mode name provided: switch to that mode
|
||||
If no arguments: show current mode
|
||||
If `--list`: show all modes
|
||||
|
||||
---
|
||||
|
||||
## Mode Persistence
|
||||
|
||||
- Modes persist for the session
|
||||
- Explicitly switch when task type changes
|
||||
- Mode affects all subsequent responses
|
||||
- Can be overridden per-command with flags
|
||||
|
||||
## Command Flag Override
|
||||
|
||||
Override mode for single command:
|
||||
```bash
|
||||
/feature --mode=implementation [desc]
|
||||
/review --mode=deep-research [file]
|
||||
/plan --mode=brainstorm [task]
|
||||
```
|
||||
|
||||
## Recommended Workflows
|
||||
|
||||
### Feature Development
|
||||
```
|
||||
/mode brainstorm # Explore approaches
|
||||
[discuss design]
|
||||
/mode implementation # Execute plan
|
||||
[write code]
|
||||
/mode review # Check quality
|
||||
[review code]
|
||||
```
|
||||
|
||||
### Bug Investigation
|
||||
```
|
||||
/mode deep-research # Investigate thoroughly
|
||||
[analyze bug]
|
||||
/mode implementation # Apply fix
|
||||
[fix bug]
|
||||
/mode default # Return to normal
|
||||
```
|
||||
|
||||
### Cost-Conscious Session
|
||||
```
|
||||
/mode token-efficient # Set for session
|
||||
[work on multiple tasks]
|
||||
/mode default # Reset when done
|
||||
```
|
||||
|
||||
## Mode Files
|
||||
|
||||
Mode definitions are in `.claude/modes/`:
|
||||
- `default.md`
|
||||
- `brainstorm.md`
|
||||
- `token-efficient.md`
|
||||
- `deep-research.md`
|
||||
- `implementation.md`
|
||||
- `review.md`
|
||||
- `orchestration.md`
|
||||
|
||||
Customize modes by editing these files.
|
||||
@@ -256,6 +256,35 @@ Use `/execute-plan [plan-file]` for subagent-driven execution with code review g
|
||||
|
||||
**Reference**: `.claude/skills/methodology/executing-plans/SKILL.md`
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=brainstorm` |
|
||||
| `--detailed` | Use superpowers methodology (2-5 min tasks) | `--detailed` |
|
||||
| `--depth=[1-5]` | Planning thoroughness level | `--depth=4` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed/json) | `--format=detailed` |
|
||||
| `--save=[path]` | Save plan to file | `--save=plans/auth.md` |
|
||||
| `--checkpoint` | Create checkpoint after planning | `--checkpoint` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/plan --detailed "implement user authentication"
|
||||
/plan --mode=brainstorm "redesign checkout flow"
|
||||
/plan --depth=5 --save=plans/migration.md "database migration"
|
||||
/plan --format=json "api endpoint structure"
|
||||
```
|
||||
|
||||
### Mode Recommendations
|
||||
|
||||
| Mode | Best For |
|
||||
|------|----------|
|
||||
| `default` | Standard planning |
|
||||
| `brainstorm` | Exploratory planning, multiple approaches |
|
||||
| `deep-research` | Complex features needing investigation |
|
||||
| `implementation` | Quick plans for clear tasks |
|
||||
|
||||
<!-- CUSTOMIZATION POINT -->
|
||||
## Variations
|
||||
|
||||
|
||||
@@ -31,6 +31,36 @@ Research: **$ARGUMENTS**
|
||||
- Recommendation
|
||||
- Next steps
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=deep-research` |
|
||||
| `--depth=[1-5]` | Research thoroughness level | `--depth=5` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed/json) | `--format=detailed` |
|
||||
| `--save=[path]` | Save research to file | `--save=docs/research.md` |
|
||||
| `--compare` | Focus on comparing alternatives | `--compare` |
|
||||
| `--sequential` | Use sequential thinking methodology | `--sequential` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/research --depth=5 "authentication libraries for Node.js"
|
||||
/research --compare "React vs Vue vs Svelte"
|
||||
/research --sequential "root cause of memory leak"
|
||||
/research --save=docs/orm-research.md "ORM comparison"
|
||||
```
|
||||
|
||||
### Depth Levels
|
||||
|
||||
| Level | Behavior |
|
||||
|-------|----------|
|
||||
| 1 | Quick overview, key points only |
|
||||
| 2 | Standard analysis |
|
||||
| 3 | Thorough with examples |
|
||||
| 4 | Comprehensive with trade-offs |
|
||||
| 5 | Exhaustive with citations |
|
||||
|
||||
## Output
|
||||
|
||||
```markdown
|
||||
|
||||
@@ -252,6 +252,45 @@ Found **1 critical issue** (security), **2 recommendations**, and **2 suggestion
|
||||
|
||||
**Output**: Complete review of all staged changes with security scan, code quality assessment, and actionable feedback organized by severity.
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--mode=[mode]` | Use specific behavioral mode | `--mode=review` |
|
||||
| `--persona=[type]` | Apply persona expertise | `--persona=security` |
|
||||
| `--depth=[1-5]` | Review thoroughness level | `--depth=5` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed/json) | `--format=detailed` |
|
||||
| `--focus=[area]` | Focus on specific area | `--focus=performance` |
|
||||
| `--save` | Save review to file | `--save` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/review --persona=security src/auth/
|
||||
/review --depth=5 --format=detailed staged
|
||||
/review --focus=performance src/services/heavy-computation.ts
|
||||
/review --mode=deep-research --save pr
|
||||
```
|
||||
|
||||
### Persona Options
|
||||
|
||||
| Persona | Focus Area |
|
||||
|---------|------------|
|
||||
| `security` | Vulnerabilities, auth, data protection |
|
||||
| `performance` | Efficiency, queries, caching |
|
||||
| `architecture` | Patterns, coupling, SOLID |
|
||||
| `testing` | Coverage, test quality |
|
||||
| `accessibility` | A11y compliance |
|
||||
|
||||
### Focus Areas
|
||||
|
||||
| Focus | Checks |
|
||||
|-------|--------|
|
||||
| `security` | OWASP top 10, auth, input validation |
|
||||
| `performance` | N+1, complexity, memory |
|
||||
| `quality` | Readability, maintainability |
|
||||
| `testing` | Coverage, test patterns |
|
||||
|
||||
<!-- CUSTOMIZATION POINT -->
|
||||
## Variations
|
||||
|
||||
|
||||
@@ -0,0 +1,173 @@
|
||||
# /spawn
|
||||
|
||||
## Purpose
|
||||
|
||||
Launch background tasks for parallel execution. Enables concurrent work on independent tasks with result aggregation.
|
||||
|
||||
---
|
||||
|
||||
Launch a background task or manage running tasks.
|
||||
|
||||
## Spawn Operations
|
||||
|
||||
### Launch Task
|
||||
|
||||
Start a new background task:
|
||||
|
||||
```bash
|
||||
/spawn "[task description]"
|
||||
```
|
||||
|
||||
**Process:**
|
||||
1. Analyze task for parallelizability
|
||||
2. Launch subagent with task
|
||||
3. Return task ID for tracking
|
||||
4. Continue main conversation
|
||||
|
||||
**Output:**
|
||||
```markdown
|
||||
Spawned: Task #1
|
||||
- Description: Research authentication patterns
|
||||
- Status: Running
|
||||
- Agent: researcher
|
||||
|
||||
Continue working. Use `/spawn --list` to check status.
|
||||
```
|
||||
|
||||
### List Tasks
|
||||
|
||||
Show running and completed tasks:
|
||||
|
||||
```bash
|
||||
/spawn --list
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```markdown
|
||||
## Active Tasks
|
||||
|
||||
| ID | Description | Status | Duration |
|
||||
|----|-------------|--------|----------|
|
||||
| #1 | Research auth patterns | Running | 2m |
|
||||
| #2 | Analyze security | Complete | 5m |
|
||||
|
||||
## Completed Tasks (last hour)
|
||||
| #2 | Analyze security | ✅ Complete | Results ready |
|
||||
```
|
||||
|
||||
### Collect Results
|
||||
|
||||
Gather results from completed tasks:
|
||||
|
||||
```bash
|
||||
/spawn --collect
|
||||
```
|
||||
|
||||
**Output:**
|
||||
```markdown
|
||||
## Collected Results
|
||||
|
||||
### Task #1: Research auth patterns
|
||||
**Status**: Complete
|
||||
**Findings**:
|
||||
- Pattern A: JWT with refresh tokens
|
||||
- Pattern B: Session-based with Redis
|
||||
- Recommendation: JWT for stateless API
|
||||
|
||||
### Task #2: Analyze security
|
||||
**Status**: Complete
|
||||
**Findings**:
|
||||
- 2 high-priority issues found
|
||||
- See detailed report below
|
||||
```
|
||||
|
||||
### Cancel Task
|
||||
|
||||
Stop a running task:
|
||||
|
||||
```bash
|
||||
/spawn --cancel [id]
|
||||
```
|
||||
|
||||
## Task Types
|
||||
|
||||
| Type | Best For | Agent Used |
|
||||
|------|----------|------------|
|
||||
| Research | Information gathering | researcher |
|
||||
| Analysis | Code analysis | scout |
|
||||
| Review | Code review | code-reviewer |
|
||||
| Test | Test generation | tester |
|
||||
| Scan | Security scanning | security-auditor |
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `--list` | Show all tasks |
|
||||
| `--collect` | Gather completed results |
|
||||
| `--cancel [id]` | Cancel running task |
|
||||
| `--wait` | Wait for all tasks to complete |
|
||||
| `--agent=[type]` | Specify agent type |
|
||||
| `--priority=[high\|normal]` | Task priority |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```bash
|
||||
/spawn "Research OAuth2 best practices"
|
||||
/spawn "Analyze user service for performance issues"
|
||||
/spawn "Review security of auth module" --agent=security-auditor
|
||||
/spawn --list
|
||||
/spawn --collect
|
||||
/spawn --wait # Block until all complete
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
If quoted text: spawn that task
|
||||
If flag: execute that operation
|
||||
|
||||
---
|
||||
|
||||
## Parallel Workflow
|
||||
|
||||
### Pattern: Research Phase
|
||||
```bash
|
||||
/spawn "Research authentication approaches"
|
||||
/spawn "Analyze current auth implementation"
|
||||
/spawn "Review competitor auth patterns"
|
||||
# Continue other work...
|
||||
/spawn --wait
|
||||
/spawn --collect
|
||||
# Synthesize findings
|
||||
```
|
||||
|
||||
### Pattern: Multi-File Review
|
||||
```bash
|
||||
/spawn "Review src/auth/ for security"
|
||||
/spawn "Review src/api/ for performance"
|
||||
/spawn "Review src/db/ for SQL injection"
|
||||
/spawn --collect
|
||||
# Address findings
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Independent Tasks**: Only spawn truly independent work
|
||||
2. **Clear Descriptions**: Specific task descriptions get better results
|
||||
3. **Regular Collection**: Don't let results pile up
|
||||
4. **Resource Awareness**: Don't spawn too many concurrent tasks
|
||||
|
||||
## Limitations
|
||||
|
||||
- Tasks cannot communicate with each other
|
||||
- Results are collected, not streamed
|
||||
- Heavy tasks may take time
|
||||
- Some tasks benefit from sequential execution
|
||||
|
||||
## Combines With
|
||||
|
||||
- Orchestration mode: Manages multiple spawned tasks
|
||||
- `/plan`: Plan tasks, then spawn parallel execution
|
||||
- `/execute-plan`: Orchestrated task execution
|
||||
@@ -249,6 +249,45 @@ pytest tests/services/auth.test.ts -v
|
||||
- Consider adding integration tests for full auth flow
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
| Flag | Description | Example |
|
||||
|------|-------------|---------|
|
||||
| `--coverage` | Generate coverage-focused tests | `--coverage` |
|
||||
| `--type=[type]` | Test type to generate | `--type=integration` |
|
||||
| `--format=[fmt]` | Output format (concise/detailed) | `--format=concise` |
|
||||
| `--framework=[fw]` | Specify test framework | `--framework=vitest` |
|
||||
| `--tdd` | Generate TDD-style with failing tests first | `--tdd` |
|
||||
| `--edge-cases` | Focus on edge case coverage | `--edge-cases` |
|
||||
|
||||
### Flag Usage Examples
|
||||
|
||||
```bash
|
||||
/test --coverage src/services/
|
||||
/test --type=integration src/api/users.ts
|
||||
/test --tdd src/utils/validator.ts
|
||||
/test --edge-cases --framework=pytest src/models/user.py
|
||||
```
|
||||
|
||||
### Test Types
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| `unit` | Isolated function tests (default) |
|
||||
| `integration` | Multi-component tests |
|
||||
| `e2e` | End-to-end workflow tests |
|
||||
| `snapshot` | Snapshot tests for UI |
|
||||
| `property` | Property-based testing |
|
||||
|
||||
### Framework Options
|
||||
|
||||
| Framework | Language |
|
||||
|-----------|----------|
|
||||
| `pytest` | Python |
|
||||
| `vitest` | TypeScript/JavaScript |
|
||||
| `jest` | JavaScript |
|
||||
| `playwright` | E2E (any) |
|
||||
|
||||
<!-- CUSTOMIZATION POINT -->
|
||||
## Variations
|
||||
|
||||
|
||||
Reference in New Issue
Block a user