mirror of
https://github.com/duthaho/claudekit.git
synced 2026-06-26 03:14:38 +03:00
feat: improved the Claude Kit as a plugin
This commit is contained in:
duthaho
@@ -0,0 +1,161 @@
|
||||
---
|
||||
name: init
|
||||
description: >
|
||||
Interactive setup wizard for claudekit. Scaffolds rules, modes, hooks, and MCP
|
||||
server configs into the user's project. Run /claudekit:init to configure.
|
||||
Use when setting up a new project with claudekit or reconfiguring an existing one.
|
||||
user-invocable: true
|
||||
argument-hint: "[--all] to skip prompts and install everything"
|
||||
---
|
||||
|
||||
# Claudekit Init
|
||||
|
||||
Interactive setup wizard that scaffolds project-level configuration files into the user's `.claude/` directory.
|
||||
|
||||
## What It Generates
|
||||
|
||||
| Category | Files | Location |
|
||||
|----------|-------|----------|
|
||||
| Rules | api.md, frontend.md, migrations.md, security.md, testing.md | `.claude/rules/` |
|
||||
| Modes | brainstorm.md, deep-research.md, default.md, implementation.md, orchestration.md, review.md, token-efficient.md | `.claude/modes/` |
|
||||
| Hooks | auto-format, block-dangerous-commands, notify | `.claude/hooks/` + `settings.local.json` |
|
||||
| MCP Servers | context7, sequential, playwright, memory, filesystem | `.mcp.json` |
|
||||
|
||||
---
|
||||
|
||||
## Wizard Flow
|
||||
|
||||
When invoked, ask the user **ONE question at a time**:
|
||||
|
||||
### Step 1: Rules
|
||||
|
||||
"Which rules do you want to install?"
|
||||
- a) All rules (api, frontend, migrations, security, testing)
|
||||
- b) Let me pick individually
|
||||
- c) Skip rules
|
||||
|
||||
If (b), list each rule with a one-line description and let user select:
|
||||
- **api.md** — REST API design conventions (naming, versioning, error responses)
|
||||
- **frontend.md** — React/Next.js component patterns and file organization
|
||||
- **migrations.md** — Database migration safety rules (backward compatibility, rollback)
|
||||
- **security.md** — OWASP-aligned security rules (no hardcoded secrets, parameterized queries)
|
||||
- **testing.md** — Test naming, coverage thresholds, mocking conventions
|
||||
|
||||
For each selected rule, read the template from `${CLAUDE_PLUGIN_ROOT}/skills/init/templates/rules/<name>.md` and write it to `.claude/rules/<name>.md`.
|
||||
|
||||
### Step 2: Modes
|
||||
|
||||
"Which behavioral modes do you want to install?"
|
||||
- a) All modes (brainstorm, deep-research, default, implementation, orchestration, review, token-efficient)
|
||||
- b) Let me pick individually
|
||||
- c) Skip modes
|
||||
|
||||
If (b), list each mode with a one-line description:
|
||||
- **brainstorm.md** — Creative exploration, divergent thinking, pro/con comparisons
|
||||
- **deep-research.md** — Thorough analysis with citations and evidence
|
||||
- **default.md** — Balanced standard behavior
|
||||
- **implementation.md** — Code-focused, minimal prose, maximum productivity
|
||||
- **orchestration.md** — Multi-task coordination and parallel work
|
||||
- **review.md** — Critical analysis, finding issues, security focus
|
||||
- **token-efficient.md** — Compressed output for cost savings (30-70%)
|
||||
|
||||
For each selected mode, read the template from `${CLAUDE_PLUGIN_ROOT}/skills/init/templates/modes/<name>.md` and write it to `.claude/modes/<name>.md`.
|
||||
|
||||
### Step 3: Hooks
|
||||
|
||||
"Which hooks do you want to install?"
|
||||
- a) Auto-format (runs linter after Write/Edit)
|
||||
- b) Block dangerous commands (prevents rm -rf /, force push main, etc.)
|
||||
- c) Notifications (desktop notifications on completion)
|
||||
- d) All of the above
|
||||
- e) Skip hooks
|
||||
|
||||
For each selected hook:
|
||||
|
||||
1. Read the hook metadata from `${CLAUDE_PLUGIN_ROOT}/skills/init/templates/hooks.json`
|
||||
2. Copy the hook script from `${CLAUDE_PLUGIN_ROOT}/scripts/<script>.cjs` to `.claude/hooks/<script>.cjs`
|
||||
3. Merge the hook entry into `.claude/settings.local.json` (create if it doesn't exist)
|
||||
|
||||
Hook entry format for `settings.local.json`:
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"<event>": [
|
||||
{
|
||||
"matcher": "<matcher>",
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "node .claude/hooks/<script>.cjs"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If `settings.local.json` already has a `hooks` key, merge new entries into the existing structure — do not overwrite.
|
||||
|
||||
### Step 4: MCP Servers
|
||||
|
||||
"Which MCP servers do you want to configure?"
|
||||
- a) Context7 (library documentation lookup)
|
||||
- b) Sequential Thinking (multi-step reasoning)
|
||||
- c) Playwright (browser automation)
|
||||
- d) Memory (persistent knowledge graph)
|
||||
- e) Filesystem (secure file operations)
|
||||
- f) All of the above
|
||||
- g) Skip MCP setup
|
||||
|
||||
For each selected server:
|
||||
|
||||
1. Read the server config from `${CLAUDE_PLUGIN_ROOT}/skills/init/templates/mcp-servers.json`
|
||||
2. Detect platform: check if `process.platform === "win32"` or use Bash `uname` to determine OS
|
||||
3. Select the correct config (`win32` or `posix` key)
|
||||
4. Merge into the project's `.mcp.json` (create with `{"mcpServers": {}}` if it doesn't exist)
|
||||
|
||||
### Step 5: Summary
|
||||
|
||||
Print a summary table of everything installed:
|
||||
|
||||
```
|
||||
Claudekit setup complete!
|
||||
|
||||
Rules: 5 installed → .claude/rules/
|
||||
Modes: 7 installed → .claude/modes/
|
||||
Hooks: 3 installed → .claude/hooks/ + settings.local.json
|
||||
MCP: 5 configured → .mcp.json
|
||||
|
||||
Next steps:
|
||||
- Skills are available as /claudekit:<name> (44 skills)
|
||||
- Agents are available as claudekit:<name> (20 agents)
|
||||
- Switch modes: "switch to brainstorm mode"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## --all Flag
|
||||
|
||||
If `$ARGUMENTS` contains `--all`, skip all prompts and install everything:
|
||||
- All 5 rules
|
||||
- All 7 modes
|
||||
- All 3 hooks
|
||||
- All 5 MCP servers
|
||||
|
||||
---
|
||||
|
||||
## Important Rules
|
||||
|
||||
- **NEVER overwrite existing files without asking.** If a target file already exists, ask: "[filename] already exists. Overwrite? (y/n)"
|
||||
- **Create directories as needed.** If `.claude/rules/` doesn't exist, create it before writing files.
|
||||
- **For hooks, always use `settings.local.json`** (not `settings.json`) — local is gitignored so hook config stays personal.
|
||||
- **Use `${CLAUDE_PLUGIN_ROOT}`** to reference template files within the plugin.
|
||||
- **Platform detection for MCP**: Windows uses `cmd /c npx`, macOS/Linux uses `npx` directly.
|
||||
|
||||
---
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `writing-skills` — for creating custom skills after init
|
||||
- `mode-switching` — for using the installed modes
|
||||
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"auto-format": {
|
||||
"event": "PostToolUse",
|
||||
"matcher": "Write|Edit",
|
||||
"script": "auto-format.cjs",
|
||||
"description": "Auto-formats files after Write/Edit using ruff (Python) or eslint (JS/TS)"
|
||||
},
|
||||
"block-dangerous-commands": {
|
||||
"event": "PreToolUse",
|
||||
"matcher": "Bash",
|
||||
"script": "block-dangerous-commands.cjs",
|
||||
"description": "Blocks rm -rf /, force push to main, hard reset, DROP TABLE, etc."
|
||||
},
|
||||
"notify": {
|
||||
"event": "Notification",
|
||||
"matcher": "",
|
||||
"script": "notify.cjs",
|
||||
"description": "Cross-platform desktop notifications (macOS, Linux, Windows)"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,52 @@
|
||||
{
|
||||
"context7": {
|
||||
"win32": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "@upstash/context7-mcp"]
|
||||
},
|
||||
"posix": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@upstash/context7-mcp"]
|
||||
}
|
||||
},
|
||||
"sequential": {
|
||||
"win32": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-sequential-thinking"]
|
||||
},
|
||||
"posix": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
|
||||
}
|
||||
},
|
||||
"playwright": {
|
||||
"win32": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "@playwright/mcp"]
|
||||
},
|
||||
"posix": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@playwright/mcp"]
|
||||
}
|
||||
},
|
||||
"memory": {
|
||||
"win32": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-memory"]
|
||||
},
|
||||
"posix": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-memory"]
|
||||
}
|
||||
},
|
||||
"filesystem": {
|
||||
"win32": {
|
||||
"command": "cmd",
|
||||
"args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "."]
|
||||
},
|
||||
"posix": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,112 @@
|
||||
# Brainstorm Mode
|
||||
|
||||
## Description
|
||||
|
||||
Creative exploration mode optimized for ideation, design discussions, and exploring alternatives. Emphasizes divergent thinking, questions, and possibilities over implementation.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Initial feature exploration
|
||||
- Architecture decisions
|
||||
- Problem definition
|
||||
- Design sessions
|
||||
- When stuck on approach
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Ask more questions before concluding
|
||||
- Present multiple alternatives
|
||||
- Explore edge cases verbally
|
||||
- Use "what if" scenarios
|
||||
|
||||
### Problem Solving
|
||||
- Divergent thinking first
|
||||
- Delay convergence on solutions
|
||||
- Consider unconventional approaches
|
||||
- Map trade-offs explicitly
|
||||
|
||||
### Output Format
|
||||
- Structured comparisons
|
||||
- Pro/con lists
|
||||
- Decision matrices
|
||||
- Visual diagrams (ASCII/Mermaid)
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to brainstorm mode"
|
||||
"let's brainstorm [topic]"
|
||||
"explore options for [feature]"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example Behaviors
|
||||
|
||||
### Before Implementing
|
||||
```
|
||||
Before we implement, let me explore some approaches:
|
||||
|
||||
Option A: [approach]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
|
||||
Option B: [approach]
|
||||
- Pros: ...
|
||||
- Cons: ...
|
||||
|
||||
Which direction interests you? Or should we explore more options?
|
||||
```
|
||||
|
||||
### Question-First Approach
|
||||
```
|
||||
I have some questions to clarify before we dive in:
|
||||
|
||||
1. [Clarifying question about scope]
|
||||
2. [Question about constraints]
|
||||
3. [Question about preferences]
|
||||
|
||||
Once I understand these, I can provide better recommendations.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MCP Integration
|
||||
|
||||
This mode leverages MCP servers for enhanced brainstorming:
|
||||
|
||||
### Sequential Thinking (Primary)
|
||||
```
|
||||
ALWAYS use Sequential Thinking in brainstorm mode:
|
||||
- Explore design options systematically
|
||||
- Track trade-offs for each approach
|
||||
- Build confidence in recommendations incrementally
|
||||
- Allow for revisions and backtracking
|
||||
```
|
||||
|
||||
### Memory
|
||||
```
|
||||
Persist design decisions:
|
||||
- Store design concepts and rationale
|
||||
- Remember user preferences from previous sessions
|
||||
- Build project design knowledge over time
|
||||
```
|
||||
|
||||
### Context7
|
||||
```
|
||||
For informed technology choices:
|
||||
- Fetch docs to compare library options
|
||||
- Ground recommendations in real capabilities
|
||||
```
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `brainstorming` skill (auto-triggered for creative exploration)
|
||||
- `writing-plans` skill (transition from exploration to planning)
|
||||
- Deep research mode (for informed exploration)
|
||||
@@ -0,0 +1,158 @@
|
||||
# Deep Research Mode
|
||||
|
||||
## Description
|
||||
|
||||
Thorough analysis mode for comprehensive investigation. Prioritizes completeness, evidence gathering, and citations over speed. Use when accuracy and depth matter more than efficiency.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Technology evaluation
|
||||
- Architecture research
|
||||
- Security audits
|
||||
- Performance analysis
|
||||
- Complex debugging
|
||||
- Due diligence tasks
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Cite sources and evidence
|
||||
- Acknowledge uncertainty explicitly
|
||||
- Present confidence levels
|
||||
- Include caveats and limitations
|
||||
|
||||
### Problem Solving
|
||||
- Exhaustive exploration
|
||||
- Multiple verification passes
|
||||
- Cross-reference findings
|
||||
- Document assumptions
|
||||
|
||||
### Output Format
|
||||
- Structured reports
|
||||
- Evidence sections
|
||||
- Source citations
|
||||
- Confidence indicators
|
||||
|
||||
---
|
||||
|
||||
## Research Process
|
||||
|
||||
### Phase 1: Scope Definition
|
||||
- Clarify research questions
|
||||
- Define success criteria
|
||||
- Identify constraints
|
||||
|
||||
### Phase 2: Information Gathering
|
||||
- Search codebase thoroughly
|
||||
- Consult documentation
|
||||
- Web research if needed
|
||||
- Gather all relevant data
|
||||
|
||||
### Phase 3: Analysis
|
||||
- Cross-reference findings
|
||||
- Identify patterns
|
||||
- Note contradictions
|
||||
- Assess reliability
|
||||
|
||||
### Phase 4: Synthesis
|
||||
- Draw conclusions
|
||||
- Present evidence
|
||||
- State confidence levels
|
||||
- Acknowledge gaps
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Research: [Topic]
|
||||
|
||||
### Question
|
||||
[What we're investigating]
|
||||
|
||||
### Methodology
|
||||
[How we researched]
|
||||
|
||||
### Findings
|
||||
|
||||
#### Finding 1: [Title]
|
||||
- Evidence: [source/location]
|
||||
- Confidence: [High/Medium/Low]
|
||||
- Details: [explanation]
|
||||
|
||||
#### Finding 2: [Title]
|
||||
...
|
||||
|
||||
### Conclusions
|
||||
- [Conclusion 1] (Confidence: X/10)
|
||||
- [Conclusion 2] (Confidence: X/10)
|
||||
|
||||
### Gaps & Limitations
|
||||
- [What we couldn't determine]
|
||||
- [Areas needing more investigation]
|
||||
|
||||
### Sources
|
||||
- [Source 1]
|
||||
- [Source 2]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to deep-research mode"
|
||||
"research [topic] thoroughly"
|
||||
"do a deep investigation of [area]"
|
||||
```
|
||||
|
||||
### Depth Levels
|
||||
|
||||
| Level | Behavior |
|
||||
|-------|----------|
|
||||
| 1 | Quick scan, surface findings |
|
||||
| 2 | Standard analysis |
|
||||
| 3 | Thorough investigation |
|
||||
| 4 | Comprehensive with cross-references |
|
||||
| 5 | Exhaustive, leave no stone unturned |
|
||||
|
||||
---
|
||||
|
||||
## MCP Integration
|
||||
|
||||
This mode leverages MCP servers for comprehensive research:
|
||||
|
||||
### Sequential Thinking (Primary)
|
||||
```
|
||||
ALWAYS use Sequential Thinking in deep-research mode:
|
||||
- Structure analysis into logical thought sequences
|
||||
- Track confidence scores for each finding
|
||||
- Revise conclusions as evidence emerges
|
||||
- Document reasoning chain for transparency
|
||||
```
|
||||
|
||||
### Context7
|
||||
```
|
||||
For library/technology research:
|
||||
- Fetch current documentation with get-library-docs
|
||||
- Use mode='info' for conceptual understanding
|
||||
- Verify findings against authoritative sources
|
||||
```
|
||||
|
||||
### Memory
|
||||
```
|
||||
Build persistent research knowledge:
|
||||
- Store research findings as entities
|
||||
- Create relations between discovered concepts
|
||||
- Recall previous research in future sessions
|
||||
```
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `sequential-thinking` skill (structured step-by-step analysis)
|
||||
- `researcher` agent (comprehensive technology research)
|
||||
- Security audits
|
||||
- Performance optimization
|
||||
@@ -0,0 +1,47 @@
|
||||
# Default Mode
|
||||
|
||||
## Description
|
||||
|
||||
Standard balanced mode for general development tasks. This is the baseline behavior that provides a good mix of thoroughness and efficiency.
|
||||
|
||||
## When Active
|
||||
|
||||
This mode is active by default unless another mode is explicitly specified.
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Clear, concise responses
|
||||
- Balance between explanation and action
|
||||
- Standard code comments where helpful
|
||||
|
||||
### Problem Solving
|
||||
- Balanced analysis depth
|
||||
- Standard verification steps
|
||||
- Normal iteration cycles
|
||||
|
||||
### Output Format
|
||||
- Full code blocks with context
|
||||
- Explanations where helpful
|
||||
- Standard documentation level
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
This mode is active by default. No activation needed.
|
||||
|
||||
To switch to another mode, use natural language:
|
||||
```
|
||||
"switch to brainstorm mode"
|
||||
"use implementation mode"
|
||||
"switch to token-efficient mode"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Compatible With
|
||||
|
||||
All skills and workflows. This mode provides baseline behavior that other modes modify.
|
||||
@@ -0,0 +1,139 @@
|
||||
# Implementation Mode
|
||||
|
||||
## Description
|
||||
|
||||
Code-focused execution mode that minimizes discussion and maximizes code output. For when the plan is clear and it's time to build.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Executing approved plans
|
||||
- Clear, well-defined tasks
|
||||
- Repetitive code generation
|
||||
- When design is already decided
|
||||
- Batch file operations
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Minimal prose
|
||||
- Action-oriented updates
|
||||
- Progress indicators only
|
||||
- Skip explanations unless asked
|
||||
|
||||
### Problem Solving
|
||||
- Execute, don't deliberate
|
||||
- Follow established patterns
|
||||
- Make reasonable defaults
|
||||
- Flag blockers immediately
|
||||
|
||||
### Output Format
|
||||
- Code blocks primarily
|
||||
- File paths clearly marked
|
||||
- Minimal inline comments
|
||||
- Progress checkmarks
|
||||
|
||||
---
|
||||
|
||||
## Output Pattern
|
||||
|
||||
```markdown
|
||||
Creating `src/services/user-service.ts`:
|
||||
```typescript
|
||||
[code]
|
||||
```
|
||||
|
||||
Creating `src/services/user-service.test.ts`:
|
||||
```typescript
|
||||
[code]
|
||||
```
|
||||
|
||||
Running tests...
|
||||
✓ 5 passing
|
||||
|
||||
Committing: `feat(user): add user service`
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### Standard Pattern
|
||||
1. Read task requirements
|
||||
2. Identify files to create/modify
|
||||
3. Generate code
|
||||
4. Run verification
|
||||
5. Report completion
|
||||
|
||||
### Progress Updates
|
||||
```
|
||||
[1/5] Creating model...
|
||||
[2/5] Creating service...
|
||||
[3/5] Creating tests...
|
||||
[4/5] Running tests... ✓
|
||||
[5/5] Committing...
|
||||
|
||||
Done. Created 3 files, all tests passing.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to implementation mode"
|
||||
"just code it"
|
||||
"execute the plan"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Decision Making
|
||||
|
||||
When encountering choices during implementation:
|
||||
|
||||
| Situation | Behavior |
|
||||
|-----------|----------|
|
||||
| Style choice | Follow existing patterns |
|
||||
| Missing detail | Use reasonable default |
|
||||
| Ambiguity | Flag and continue with assumption |
|
||||
| Blocker | Stop and report immediately |
|
||||
|
||||
---
|
||||
|
||||
## Tool Usage
|
||||
|
||||
### Built-in Tools (Primary)
|
||||
```
|
||||
Use Claude Code built-in tools for file operations:
|
||||
- Read to check existing code
|
||||
- Write to create new files
|
||||
- Edit for modifications
|
||||
- Grep/Glob to find patterns to follow
|
||||
```
|
||||
|
||||
### MCP Integration
|
||||
|
||||
#### Context7
|
||||
```
|
||||
For accurate library usage:
|
||||
- Fetch current API documentation
|
||||
- Get correct patterns and examples
|
||||
```
|
||||
|
||||
#### Memory
|
||||
```
|
||||
Recall implementation context:
|
||||
- Remember established patterns
|
||||
- Recall user preferences
|
||||
- Store decisions for consistency
|
||||
```
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `executing-plans` skill (structured plan execution)
|
||||
- `test-driven-development` skill (TDD workflow)
|
||||
- Token-efficient mode (for maximum efficiency)
|
||||
- After brainstorm/planning phases
|
||||
@@ -0,0 +1,163 @@
|
||||
# Orchestration Mode
|
||||
|
||||
## Description
|
||||
|
||||
Multi-agent coordination mode for managing complex tasks that benefit from parallel execution, task delegation, and result aggregation. Optimized for efficiency through parallelization.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Large-scale refactoring
|
||||
- Multi-file changes
|
||||
- Complex feature implementation
|
||||
- When tasks are parallelizable
|
||||
- Coordinating multiple concerns
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Task delegation clarity
|
||||
- Progress aggregation
|
||||
- Coordination updates
|
||||
- Final synthesis
|
||||
|
||||
### Problem Solving
|
||||
- Identify parallelizable work
|
||||
- Delegate to specialized agents
|
||||
- Aggregate results
|
||||
- Resolve conflicts
|
||||
|
||||
### Output Format
|
||||
- Task breakdown
|
||||
- Agent assignments
|
||||
- Progress tracking
|
||||
- Consolidated results
|
||||
|
||||
---
|
||||
|
||||
## Orchestration Pattern
|
||||
|
||||
### Phase 1: Analysis
|
||||
```markdown
|
||||
## Task Decomposition
|
||||
|
||||
Total work: [description]
|
||||
|
||||
### Parallelizable Tasks
|
||||
1. [Task A] - Can run independently
|
||||
2. [Task B] - Can run independently
|
||||
3. [Task C] - Can run independently
|
||||
|
||||
### Sequential Tasks
|
||||
4. [Task D] - Depends on A, B
|
||||
5. [Task E] - Final integration
|
||||
```
|
||||
|
||||
### Phase 2: Delegation
|
||||
```markdown
|
||||
## Agent Assignments
|
||||
|
||||
| Task | Agent Type | Status |
|
||||
|------|------------|--------|
|
||||
| Task A | researcher | Running |
|
||||
| Task B | tester | Running |
|
||||
| Task C | code-reviewer | Running |
|
||||
```
|
||||
|
||||
### Phase 3: Aggregation
|
||||
```markdown
|
||||
## Results
|
||||
|
||||
### Task A: Complete
|
||||
- Findings: [summary]
|
||||
|
||||
### Task B: Complete
|
||||
- Results: [summary]
|
||||
|
||||
### Task C: Complete
|
||||
- Findings: [summary]
|
||||
|
||||
### Synthesis
|
||||
[Combined conclusions and next steps]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Dispatch Pattern
|
||||
|
||||
For launching parallel background tasks using the Agent tool:
|
||||
|
||||
```markdown
|
||||
Dispatching parallel agents:
|
||||
|
||||
1. Agent(researcher, "Research authentication patterns") -> Background #1
|
||||
2. Agent(security-auditor, "Analyze current security") -> Background #2
|
||||
3. Agent(scout-external, "Review competitor approaches") -> Background #3
|
||||
|
||||
Monitoring progress...
|
||||
|
||||
Results collected:
|
||||
- Agent #1: [findings]
|
||||
- Agent #2: [findings]
|
||||
- Agent #3: [findings]
|
||||
|
||||
Synthesizing...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to orchestration mode"
|
||||
"coordinate these tasks in parallel"
|
||||
"use parallel agents for this"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task Parallelization Rules
|
||||
|
||||
### Good Candidates for Parallel
|
||||
- Independent file modifications
|
||||
- Research tasks across different areas
|
||||
- Test generation for different modules
|
||||
- Documentation for separate components
|
||||
|
||||
### Must Be Sequential
|
||||
- Tasks with dependencies
|
||||
- Database migrations
|
||||
- Changes to shared state
|
||||
- Integration after parallel work
|
||||
|
||||
### Decision Matrix
|
||||
|
||||
| Condition | Parallelize? |
|
||||
|-----------|--------------|
|
||||
| No shared files | Yes |
|
||||
| Independent modules | Yes |
|
||||
| Shared dependencies | No |
|
||||
| Order matters | No |
|
||||
| Can merge results | Yes |
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
Between parallel phases:
|
||||
1. Verify all agents completed
|
||||
2. Check for conflicts
|
||||
3. Review combined results
|
||||
4. Run integration tests
|
||||
5. Proceed to next phase
|
||||
|
||||
---
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `dispatching-parallel-agents` skill (structured parallel task dispatch)
|
||||
- `executing-plans` skill (plan execution with quality gates)
|
||||
- `subagent-driven-development` skill (automated agent coordination)
|
||||
- Complex feature development
|
||||
@@ -0,0 +1,141 @@
|
||||
# Review Mode
|
||||
|
||||
## Description
|
||||
|
||||
Critical analysis mode optimized for code review, auditing, and quality assessment. Emphasizes finding issues, suggesting improvements, and thorough examination.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Code reviews
|
||||
- Security audits
|
||||
- Performance reviews
|
||||
- Pre-merge checks
|
||||
- Quality assessments
|
||||
- Architecture reviews
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Direct feedback
|
||||
- Prioritized findings
|
||||
- Constructive criticism
|
||||
- Specific, actionable suggestions
|
||||
|
||||
### Problem Solving
|
||||
- Look for issues first
|
||||
- Question assumptions
|
||||
- Check edge cases
|
||||
- Verify against standards
|
||||
|
||||
### Output Format
|
||||
- Categorized findings
|
||||
- Severity levels
|
||||
- Line-specific comments
|
||||
- Improvement suggestions
|
||||
|
||||
---
|
||||
|
||||
## Review Categories
|
||||
|
||||
### Severity Levels
|
||||
|
||||
| Level | Description | Action |
|
||||
|-------|-------------|--------|
|
||||
| Critical | Bugs, security issues | Must fix before merge |
|
||||
| Important | Code smells, performance | Should fix |
|
||||
| Minor | Style, naming | Consider fixing |
|
||||
| Nitpick | Preferences | Optional |
|
||||
|
||||
### Review Areas
|
||||
|
||||
| Area | Focus |
|
||||
|------|-------|
|
||||
| Correctness | Does it work? Edge cases? |
|
||||
| Security | Vulnerabilities, data exposure |
|
||||
| Performance | Efficiency, scalability |
|
||||
| Maintainability | Readability, complexity |
|
||||
| Testing | Coverage, quality of tests |
|
||||
| Standards | Convention compliance |
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
```markdown
|
||||
## Code Review: [file/PR]
|
||||
|
||||
### Summary
|
||||
[1-2 sentence overview]
|
||||
|
||||
### Critical Issues
|
||||
1. **[Issue]** (line X)
|
||||
- Problem: [description]
|
||||
- Fix: [suggestion]
|
||||
|
||||
### Important Issues
|
||||
1. **[Issue]** (line X)
|
||||
- Problem: [description]
|
||||
- Suggestion: [improvement]
|
||||
|
||||
### Minor Issues
|
||||
- Line X: [issue and suggestion]
|
||||
- Line Y: [issue and suggestion]
|
||||
|
||||
### Positive Notes
|
||||
- [What was done well]
|
||||
|
||||
### Verdict
|
||||
[ ] Ready to merge
|
||||
[x] Needs changes (N critical, M important issues)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to review mode"
|
||||
"review this code critically"
|
||||
"do a security-focused review"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MCP Integration
|
||||
|
||||
This mode leverages MCP servers for thorough review:
|
||||
|
||||
### Playwright
|
||||
```
|
||||
For UI/frontend reviews:
|
||||
- Render and verify visual changes
|
||||
- Test responsive behavior
|
||||
- Check accessibility
|
||||
- Capture screenshots for comparison
|
||||
```
|
||||
|
||||
### Sequential Thinking
|
||||
```
|
||||
For systematic code analysis:
|
||||
- Step through logic methodically
|
||||
- Track multiple concerns
|
||||
- Build comprehensive issue list
|
||||
```
|
||||
|
||||
### Memory
|
||||
```
|
||||
Apply consistent review standards:
|
||||
- Recall past review decisions
|
||||
- Remember approved patterns
|
||||
- Track recurring issues
|
||||
```
|
||||
|
||||
## Combines Well With
|
||||
|
||||
- `review` skill (user-invocable PR review)
|
||||
- `security-review` skill (user-invocable security audit)
|
||||
- Deep research mode (for thorough audits)
|
||||
- `security-auditor` agent, `code-reviewer` agent
|
||||
@@ -0,0 +1,113 @@
|
||||
# Token-Efficient Mode
|
||||
|
||||
## Description
|
||||
|
||||
Cost optimization mode that produces compressed, concise outputs while maintaining accuracy. Reduces token usage by 30-70% depending on task type.
|
||||
|
||||
## When to Use
|
||||
|
||||
- High-volume sessions
|
||||
- Simple tasks
|
||||
- When cost is a concern
|
||||
- Repeated similar operations
|
||||
- Quick iterations
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
### Communication
|
||||
- Minimal explanations
|
||||
- No conversational filler
|
||||
- Direct answers only
|
||||
- Skip obvious context
|
||||
|
||||
### Problem Solving
|
||||
- Jump to solutions
|
||||
- Assume competence
|
||||
- Skip basic explanations
|
||||
- Reference docs instead of explaining
|
||||
|
||||
### Output Format
|
||||
- Code without surrounding prose
|
||||
- Abbreviated comments
|
||||
- Terse commit messages
|
||||
- Bullet points over paragraphs
|
||||
|
||||
---
|
||||
|
||||
## Output Patterns
|
||||
|
||||
### Standard vs Token-Efficient
|
||||
|
||||
**Standard:**
|
||||
```
|
||||
I'll help you fix this bug. First, let me explain what's happening.
|
||||
The issue is in the user service where we're not properly validating
|
||||
the email format before saving to the database. Here's the fix:
|
||||
|
||||
[code block]
|
||||
|
||||
This change adds email validation using a regex pattern that checks
|
||||
for a valid email format before proceeding with the save operation.
|
||||
```
|
||||
|
||||
**Token-Efficient:**
|
||||
```
|
||||
Fix: Add email validation
|
||||
|
||||
[code block]
|
||||
```
|
||||
|
||||
### Compression Techniques
|
||||
|
||||
| Technique | Savings |
|
||||
|-----------|---------|
|
||||
| Skip preambles | 20-30% |
|
||||
| Code-only responses | 40-50% |
|
||||
| Abbreviated comments | 10-15% |
|
||||
| Reference over explain | 30-40% |
|
||||
|
||||
---
|
||||
|
||||
## Activation
|
||||
|
||||
Use natural language:
|
||||
```
|
||||
"switch to token-efficient mode"
|
||||
"be concise"
|
||||
"code only"
|
||||
```
|
||||
|
||||
### Verbosity Levels
|
||||
|
||||
| Level | Trigger | Savings |
|
||||
|-------|---------|---------|
|
||||
| Concise | "be concise" | 30-40% |
|
||||
| Ultra | "code only" | 60-70% |
|
||||
|
||||
---
|
||||
|
||||
## When NOT to Use
|
||||
|
||||
- Complex architectural decisions
|
||||
- Code reviews (need thorough analysis)
|
||||
- Documentation tasks
|
||||
- Teaching/explanation requests
|
||||
- Debugging complex issues
|
||||
|
||||
---
|
||||
|
||||
## Example Output
|
||||
|
||||
**Request:** Fix the null pointer in user.ts
|
||||
|
||||
**Token-Efficient Response:**
|
||||
```typescript
|
||||
// user.ts:42
|
||||
if (!user) return null;
|
||||
// Before: user.name (crashes when null)
|
||||
// After: user?.name ?? 'Unknown'
|
||||
```
|
||||
|
||||
Done. Test: `npm test -- --grep "null user"`
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
paths:
|
||||
- "src/api/**"
|
||||
- "**/routes/**"
|
||||
- "**/endpoints/**"
|
||||
- "**/controllers/**"
|
||||
---
|
||||
|
||||
# API Development Rules
|
||||
|
||||
- All endpoints must include input validation (Zod for TS, Pydantic for Python)
|
||||
- Use standard error response format: `{ error: string, code: number, details?: any }`
|
||||
- Return appropriate HTTP status codes — never use 200 for errors
|
||||
- Include OpenAPI documentation comments on all endpoints
|
||||
- Rate limiting required on all public endpoints
|
||||
- Authentication middleware on all protected routes
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
paths:
|
||||
- "**/*.tsx"
|
||||
- "**/*.jsx"
|
||||
- "src/components/**"
|
||||
- "src/app/**"
|
||||
---
|
||||
|
||||
# Frontend Rules
|
||||
|
||||
- One component per file, named with PascalCase
|
||||
- Use Server Components by default in Next.js — add `'use client'` only when needed
|
||||
- Tailwind utility classes for styling — avoid inline styles
|
||||
- All interactive elements must be keyboard accessible
|
||||
- Include `aria-label` on icon-only buttons
|
||||
- Use semantic HTML (`<nav>`, `<main>`, `<section>`) over generic `<div>`
|
||||
- Images require `alt` text
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
paths:
|
||||
- "**/migrations/**"
|
||||
- "**/*.migration.*"
|
||||
- "**/alembic/**"
|
||||
---
|
||||
|
||||
# Database Migration Rules
|
||||
|
||||
- Every migration must be reversible — include down/rollback logic
|
||||
- Never modify existing migrations — create new ones
|
||||
- Add indexes for foreign keys and frequently queried columns
|
||||
- Use transactions for multi-step migrations
|
||||
- Test migrations against a copy of production data when possible
|
||||
@@ -0,0 +1,12 @@
|
||||
# Security Rules
|
||||
|
||||
- Never hardcode secrets, API keys, or credentials in source code
|
||||
- Use parameterized queries only — never string concatenation for SQL
|
||||
- No `eval()`, `new Function()`, or dynamic code execution
|
||||
- No `any` types in TypeScript — use proper typing
|
||||
- Validate all user inputs at API boundaries
|
||||
- Output encoding for all rendered content
|
||||
- Secrets via environment variables only
|
||||
- No disabled security headers
|
||||
- Authentication required on all protected endpoints
|
||||
- Rate limiting on public APIs
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
paths:
|
||||
- "**/*.test.*"
|
||||
- "**/*.spec.*"
|
||||
- "**/tests/**"
|
||||
- "**/test_*"
|
||||
- "**/__tests__/**"
|
||||
---
|
||||
|
||||
# Test Writing Rules
|
||||
|
||||
- Python test naming: `test_[function]_[scenario]_[expected]`
|
||||
- TypeScript test naming: `describe('[Component]', () => { it('should [behavior]') })`
|
||||
- Each test file must have at least one happy path and one error case
|
||||
- Mock external dependencies, not internal modules
|
||||
- Use factories/fixtures over inline test data
|
||||
- Never commit `.skip()` or `.only()` — remove before pushing
|
||||
- Minimum coverage: 80% overall, 95% for critical paths
|
||||
- Prefer pytest for Python, vitest for TypeScript
|
||||
Reference in New Issue
Block a user