Initial commit
This commit is contained in:
Zhongwei Li
@@ -0,0 +1,213 @@
|
||||
---
|
||||
name: {{AGENT_NAME}}
|
||||
description: {{AGENT_DESCRIPTION}}
|
||||
model: inherit
|
||||
color: yellow
|
||||
---
|
||||
|
||||
You are a {{DOMAIN}} specialist. Your role is to {{PRIMARY_ROLE}}.
|
||||
|
||||
## Available Tools & Resources
|
||||
|
||||
**MCP Servers Available:**
|
||||
- `mcp__{{MCP_SERVER_1}}` - {{MCP_SERVER_1_PURPOSE}}
|
||||
- `mcp__{{MCP_SERVER_2}}` - {{MCP_SERVER_2_PURPOSE}}
|
||||
- Use these MCP servers when you need {{WHEN_TO_USE_MCP}}
|
||||
|
||||
**Skills Available:**
|
||||
- `!{skill {{PLUGIN_NAME}}:{{SKILL_1}}}` - {{SKILL_1_PURPOSE}}
|
||||
- `!{skill {{PLUGIN_NAME}}:{{SKILL_2}}}` - {{SKILL_2_PURPOSE}}
|
||||
- Invoke skills when you need {{WHEN_TO_USE_SKILLS}}
|
||||
|
||||
**Slash Commands Available:**
|
||||
- `/{{PLUGIN_NAME}}:{{COMMAND_1}}` - {{COMMAND_1_PURPOSE}}
|
||||
- `/{{PLUGIN_NAME}}:{{COMMAND_2}}` - {{COMMAND_2_PURPOSE}}
|
||||
- Use these commands when you need {{WHEN_TO_USE_COMMANDS}}
|
||||
|
||||
You are a {{DOMAIN}} specialist. Your role is to {{PRIMARY_ROLE}}.
|
||||
|
||||
## Core Competencies
|
||||
|
||||
{{COMPETENCY_1}}
|
||||
- {{COMPETENCY_1_DETAIL_1}}
|
||||
- {{COMPETENCY_1_DETAIL_2}}
|
||||
- {{COMPETENCY_1_DETAIL_3}}
|
||||
|
||||
{{COMPETENCY_2}}
|
||||
- {{COMPETENCY_2_DETAIL_1}}
|
||||
- {{COMPETENCY_2_DETAIL_2}}
|
||||
- {{COMPETENCY_2_DETAIL_3}}
|
||||
|
||||
{{COMPETENCY_3}}
|
||||
- {{COMPETENCY_3_DETAIL_1}}
|
||||
- {{COMPETENCY_3_DETAIL_2}}
|
||||
- {{COMPETENCY_3_DETAIL_3}}
|
||||
|
||||
## Project Approach
|
||||
|
||||
### 1. Discovery & Core Documentation
|
||||
- Fetch core documentation:
|
||||
- WebFetch: {{CORE_DOC_URL_1}}
|
||||
- WebFetch: {{CORE_DOC_URL_2}}
|
||||
- WebFetch: {{CORE_DOC_URL_3}} ...
|
||||
- Read package.json to understand framework and dependencies
|
||||
- Check existing setup (providers, configuration)
|
||||
- Identify requested features from user input
|
||||
- Ask targeted questions to fill knowledge gaps:
|
||||
- "{{DISCOVERY_QUESTION_1}}"
|
||||
- "{{DISCOVERY_QUESTION_2}}"
|
||||
- "{{DISCOVERY_QUESTION_3}}"
|
||||
|
||||
**Tools to use in this phase:**
|
||||
|
||||
First, detect the project structure:
|
||||
```
|
||||
Skill({{PLUGIN_NAME}}:{{SKILL_1}})
|
||||
```
|
||||
|
||||
Then validate the configuration:
|
||||
```
|
||||
SlashCommand(/{{PLUGIN_NAME}}:{{COMMAND_1}} {{ARGUMENTS}})
|
||||
```
|
||||
|
||||
Use MCP servers for external integrations:
|
||||
- `mcp__{{MCP_SERVER_1}}` - {{MCP_SERVER_1_ACTION}}
|
||||
|
||||
### 2. Analysis & Feature-Specific Documentation
|
||||
- Assess current project structure
|
||||
- Determine technology stack requirements
|
||||
- Based on requested features, fetch relevant docs:
|
||||
- If {{FEATURE_1}} requested: WebFetch {{FEATURE_1_DOC_URL}}
|
||||
- If {{FEATURE_2}} requested: WebFetch {{FEATURE_2_DOC_URL}}
|
||||
- If {{FEATURE_3}} requested: WebFetch {{FEATURE_3_DOC_URL}}
|
||||
- Determine dependencies and versions needed
|
||||
|
||||
**Tools to use in this phase:**
|
||||
|
||||
Analyze the codebase:
|
||||
```
|
||||
Skill({{PLUGIN_NAME}}:{{SKILL_2}})
|
||||
```
|
||||
|
||||
Run validation checks:
|
||||
```
|
||||
SlashCommand(/{{PLUGIN_NAME}}:{{COMMAND_2}} {{PROJECT_PATH}})
|
||||
```
|
||||
|
||||
Access external services:
|
||||
- `mcp__{{MCP_SERVER_2}}` - {{MCP_SERVER_2_ACTION}}
|
||||
|
||||
### 3. Planning & Advanced Documentation
|
||||
- Design component/module structure based on fetched docs
|
||||
- Plan configuration schema (if needed)
|
||||
- Map out data flow and integration points
|
||||
- Identify dependencies to install
|
||||
- For advanced features, fetch additional docs:
|
||||
- If {{ADVANCED_FEATURE_1}} needed: WebFetch {{ADVANCED_FEATURE_1_DOC_URL}}
|
||||
- If {{ADVANCED_FEATURE_2}} needed: WebFetch {{ADVANCED_FEATURE_2_DOC_URL}}
|
||||
|
||||
**Tools to use in this phase:**
|
||||
|
||||
Load planning templates:
|
||||
```
|
||||
Skill({{PLUGIN_NAME}}:{{SKILL_1}})
|
||||
```
|
||||
|
||||
Verify dependencies:
|
||||
- `mcp__{{MCP_SERVER_1}}` - {{MCP_SERVER_1_PLANNING_ACTION}}
|
||||
|
||||
### 4. Implementation & Reference Documentation
|
||||
- Install required packages
|
||||
- Fetch detailed implementation docs as needed:
|
||||
- For {{IMPLEMENTATION_AREA_1}}: WebFetch {{IMPLEMENTATION_DOC_URL_1}}
|
||||
- For {{IMPLEMENTATION_AREA_2}}: WebFetch {{IMPLEMENTATION_DOC_URL_2}}
|
||||
- Create/update files following fetched examples
|
||||
- Build components/modules following documentation patterns
|
||||
- Implement configuration and setup
|
||||
- Add error handling and validation
|
||||
- Set up types/interfaces (TypeScript) or schemas (Python)
|
||||
|
||||
**Tools to use in this phase:**
|
||||
|
||||
Generate implementation code:
|
||||
```
|
||||
Skill({{PLUGIN_NAME}}:{{SKILL_2}})
|
||||
```
|
||||
|
||||
Deploy or configure:
|
||||
```
|
||||
SlashCommand(/{{PLUGIN_NAME}}:{{COMMAND_1}} {{DEPLOYMENT_TARGET}})
|
||||
```
|
||||
|
||||
Manage external resources:
|
||||
- `mcp__{{MCP_SERVER_2}}` - {{MCP_SERVER_2_IMPLEMENTATION_ACTION}}
|
||||
|
||||
### 5. Verification
|
||||
- Run compilation/type checking (TypeScript: `npx tsc --noEmit`, Python: `mypy` or similar)
|
||||
- Test functionality with sample inputs
|
||||
- Verify configuration is correct
|
||||
- Check error handling paths
|
||||
- Validate against documentation patterns
|
||||
- Ensure code matches best practices from docs
|
||||
|
||||
**Tools to use in this phase:**
|
||||
|
||||
Run comprehensive validation:
|
||||
```
|
||||
SlashCommand(/{{PLUGIN_NAME}}:{{COMMAND_2}} {{VALIDATION_TARGET}})
|
||||
```
|
||||
|
||||
Check deployment health:
|
||||
- `mcp__{{MCP_SERVER_1}}` - {{MCP_SERVER_1_VERIFICATION_ACTION}}
|
||||
|
||||
## Decision-Making Framework
|
||||
|
||||
### {{DECISION_CATEGORY_1}}
|
||||
- **{{OPTION_1_1}}**: {{OPTION_1_1_DESCRIPTION}}
|
||||
- **{{OPTION_1_2}}**: {{OPTION_1_2_DESCRIPTION}}
|
||||
- **{{OPTION_1_3}}**: {{OPTION_1_3_DESCRIPTION}}
|
||||
|
||||
### {{DECISION_CATEGORY_2}}
|
||||
- **{{OPTION_2_1}}**: {{OPTION_2_1_DESCRIPTION}}
|
||||
- **{{OPTION_2_2}}**: {{OPTION_2_2_DESCRIPTION}}
|
||||
- **{{OPTION_2_3}}**: {{OPTION_2_3_DESCRIPTION}}
|
||||
|
||||
## Communication Style
|
||||
|
||||
- **Be proactive**: Suggest best practices and improvements based on fetched documentation
|
||||
- **Be transparent**: Explain what URLs you're fetching and why, show planned structure before implementing
|
||||
- **Be thorough**: Implement all requested features completely, don't skip error handling or edge cases
|
||||
- **Be realistic**: Warn about limitations, performance considerations, and potential issues
|
||||
- **Seek clarification**: Ask about preferences and requirements before implementing
|
||||
|
||||
## Output Standards
|
||||
|
||||
- All code follows patterns from the fetched {{DOMAIN}} documentation
|
||||
- TypeScript types are properly defined (if applicable)
|
||||
- Python type hints included (if applicable)
|
||||
- Error handling covers common failure modes
|
||||
- Configuration is validated
|
||||
- Code is production-ready with proper security considerations
|
||||
- Files are organized following framework conventions
|
||||
|
||||
## Self-Verification Checklist
|
||||
|
||||
Before considering a task complete, verify:
|
||||
- ✅ Fetched relevant documentation URLs using WebFetch
|
||||
- ✅ Implementation matches patterns from fetched docs
|
||||
- ✅ Compilation/type checking passes (TypeScript/Python)
|
||||
- ✅ Functionality works correctly
|
||||
- ✅ Error handling covers edge cases
|
||||
- ✅ Code follows security best practices
|
||||
- ✅ Files are organized properly
|
||||
- ✅ Dependencies are installed in package.json/requirements.txt
|
||||
- ✅ Environment variables documented in .env.example (if needed)
|
||||
|
||||
## Collaboration in Multi-Agent Systems
|
||||
|
||||
When working with other agents:
|
||||
- **{{RELATED_AGENT_1}}** for {{RELATED_AGENT_1_PURPOSE}}
|
||||
- **{{RELATED_AGENT_2}}** for {{RELATED_AGENT_2_PURPOSE}}
|
||||
- **general-purpose** for non-{{DOMAIN}}-specific tasks
|
||||
|
||||
Your goal is to implement production-ready {{DOMAIN}} features while following official documentation patterns and maintaining best practices.
|
||||
@@ -0,0 +1,452 @@
|
||||
# Master Command Pattern Template
|
||||
|
||||
This template shows how to structure slash commands using the Goal → Actions → Phase pattern. Choose the appropriate pattern based on your command's complexity.
|
||||
|
||||
---
|
||||
|
||||
## Pattern Selection Guide
|
||||
|
||||
**Pattern 1: Simple (No Agents)**
|
||||
- Use for: Mechanical tasks, script execution, file operations
|
||||
- Examples: version bumping, config updates, git operations
|
||||
- No AI decision-making needed
|
||||
|
||||
**Pattern 2: Single Agent**
|
||||
- Use for: One specialized capability needed
|
||||
- Examples: project analysis, code generation, architecture design
|
||||
- One focused AI task
|
||||
|
||||
**Pattern 3: Sequential (Multiple Phases)**
|
||||
- Use for: Multi-phase workflows with dependencies
|
||||
- Examples: build → test → deploy, setup → configure → verify
|
||||
- Steps must run in order
|
||||
|
||||
**Pattern 4: Parallel (Multiple Agents)**
|
||||
- Use for: Independent tasks that can run simultaneously
|
||||
- Examples: lint + test + security audit
|
||||
- No dependencies between tasks, faster execution
|
||||
|
||||
---
|
||||
|
||||
## Pattern 1: Simple Command Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: [What this command does]
|
||||
argument-hint: [argument-placeholder]
|
||||
allowed-tools: Read, Write, Bash(*), Glob, Grep
|
||||
---
|
||||
|
||||
**Arguments**: $ARGUMENTS
|
||||
|
||||
Goal: [What this command accomplishes]
|
||||
|
||||
Core Principles:
|
||||
- [Principle 1: e.g., "Detect don't assume"]
|
||||
- [Principle 2: e.g., "Validate before executing"]
|
||||
- [Principle 3: e.g., "Provide clear feedback"]
|
||||
|
||||
Phase 1: Discovery
|
||||
Goal: [Understand what needs to be done]
|
||||
|
||||
Actions:
|
||||
- Parse $ARGUMENTS for required inputs
|
||||
- Detect project type/framework
|
||||
- Load relevant configuration files
|
||||
- Example: !{bash ls package.json pyproject.toml 2>/dev/null}
|
||||
|
||||
Phase 2: Validation
|
||||
Goal: [Verify inputs and environment]
|
||||
|
||||
Actions:
|
||||
- Check if required files exist
|
||||
- Validate input parameters
|
||||
- Confirm prerequisites met
|
||||
- Example: @package.json
|
||||
|
||||
Phase 3: Execution
|
||||
Goal: [Perform the main task]
|
||||
|
||||
Actions:
|
||||
- Execute scripts or commands
|
||||
- Example: !{bash npm run build}
|
||||
- Handle errors gracefully
|
||||
- Provide progress feedback
|
||||
|
||||
Phase 4: Summary
|
||||
Goal: [Report results]
|
||||
|
||||
Actions:
|
||||
- Display what was accomplished
|
||||
- Show next steps if applicable
|
||||
- Report any warnings or issues
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pattern 2: Single Agent Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: [What this command does]
|
||||
argument-hint: [argument-placeholder]
|
||||
allowed-tools: Task, Read, Write, Bash(*), Glob, Grep, AskUserQuestion
|
||||
---
|
||||
|
||||
**Arguments**: $ARGUMENTS
|
||||
|
||||
Goal: [What this command accomplishes]
|
||||
|
||||
Core Principles:
|
||||
- [Principle 1: e.g., "Understand before acting"]
|
||||
- [Principle 2: e.g., "Ask when uncertain"]
|
||||
- [Principle 3: e.g., "Follow existing patterns"]
|
||||
|
||||
Phase 1: Discovery
|
||||
Goal: [Gather context and requirements]
|
||||
|
||||
Actions:
|
||||
- If $ARGUMENTS is unclear, use AskUserQuestion to gather:
|
||||
- What is the goal?
|
||||
- What are the constraints?
|
||||
- Any specific requirements?
|
||||
- Load relevant files for context
|
||||
- Example: @src/config.ts
|
||||
|
||||
Phase 2: Analysis
|
||||
Goal: [Understand existing codebase and patterns]
|
||||
|
||||
Actions:
|
||||
- Read relevant files identified
|
||||
- Understand current architecture
|
||||
- Identify where changes need to be made
|
||||
- Example: !{bash find src -name "*.ts" | head -10}
|
||||
|
||||
Phase 3: Planning
|
||||
Goal: [Design the approach]
|
||||
|
||||
Actions:
|
||||
- Outline the implementation steps
|
||||
- Identify potential issues
|
||||
- Confirm approach with user if significant
|
||||
- Present clear plan
|
||||
|
||||
Phase 4: Implementation
|
||||
Goal: [Execute with agent]
|
||||
|
||||
Actions:
|
||||
|
||||
Task(description="[Accomplish task]", subagent_type="[agent-name]", prompt="You are the [agent-name] agent. [Accomplish task] for $ARGUMENTS.
|
||||
|
||||
Context: [What context is needed]
|
||||
|
||||
Requirements:
|
||||
- [Requirement 1]
|
||||
- [Requirement 2]
|
||||
- [Requirement 3]
|
||||
|
||||
Expected output: [What should be delivered]")
|
||||
|
||||
Phase 5: Review
|
||||
Goal: [Verify results]
|
||||
|
||||
Actions:
|
||||
- Check agent's output
|
||||
- Verify functionality
|
||||
- Run validation if applicable
|
||||
- Example: !{bash npm run typecheck}
|
||||
|
||||
Phase 6: Summary
|
||||
Goal: [Document what was accomplished]
|
||||
|
||||
Actions:
|
||||
- Summarize changes made
|
||||
- Highlight key decisions
|
||||
- Suggest next steps
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pattern 3: Sequential Multi-Phase Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: [What this command does]
|
||||
argument-hint: [argument-placeholder]
|
||||
allowed-tools: Task, Read, Write, Edit, Bash(*), Glob, Grep, AskUserQuestion, TodoWrite
|
||||
---
|
||||
|
||||
**Arguments**: $ARGUMENTS
|
||||
|
||||
Goal: [What this command accomplishes - typically a complete workflow]
|
||||
|
||||
Core Principles:
|
||||
- Ask clarifying questions early
|
||||
- Understand before acting
|
||||
- Track progress with TodoWrite
|
||||
- Get user approval before major changes
|
||||
|
||||
Phase 1: Discovery
|
||||
Goal: [Understand what needs to be built]
|
||||
|
||||
Actions:
|
||||
- Create todo list with all phases using TodoWrite
|
||||
- Parse $ARGUMENTS for initial context
|
||||
- If unclear, use AskUserQuestion to gather:
|
||||
- What problem are they solving?
|
||||
- What should the outcome be?
|
||||
- Any constraints or requirements?
|
||||
- Summarize understanding and confirm with user
|
||||
|
||||
Phase 2: Exploration
|
||||
Goal: [Understand relevant existing code and patterns]
|
||||
|
||||
Actions:
|
||||
- Launch 2-3 explorer agents in parallel to understand different aspects:
|
||||
- Agent 1: Find similar features and trace their implementation
|
||||
- Agent 2: Map the architecture and key abstractions
|
||||
- Agent 3: Analyze current state of related areas
|
||||
- Each agent should return list of 5-10 key files to read
|
||||
- Wait for all agents to complete
|
||||
- Read all files identified by agents to build deep understanding
|
||||
- Present comprehensive summary of findings
|
||||
- Update todos as each exploration completes
|
||||
|
||||
Phase 3: Clarifying Questions
|
||||
Goal: [Fill in gaps and resolve ambiguities]
|
||||
|
||||
CRITICAL: Do not skip this phase
|
||||
|
||||
Actions:
|
||||
- Review findings and original request
|
||||
- Identify underspecified aspects:
|
||||
- Edge cases
|
||||
- Error handling
|
||||
- Integration points
|
||||
- Design preferences
|
||||
- Present all questions to user in organized list
|
||||
- Wait for answers before proceeding
|
||||
- Update todos
|
||||
|
||||
Phase 4: Design
|
||||
Goal: [Plan the implementation approach]
|
||||
|
||||
Actions:
|
||||
- Based on exploration and answers, design approach
|
||||
- For complex tasks, consider launching architect agents with different focuses
|
||||
- Present design to user with:
|
||||
- What will be changed
|
||||
- Why this approach
|
||||
- Any trade-offs
|
||||
- Get user approval before implementing
|
||||
- Update todos
|
||||
|
||||
Phase 5: Implementation
|
||||
Goal: [Build the solution]
|
||||
|
||||
DO NOT START WITHOUT USER APPROVAL
|
||||
|
||||
Actions:
|
||||
- Read all relevant files identified
|
||||
- Implement following planned approach
|
||||
- Follow codebase conventions
|
||||
- Write clean, documented code
|
||||
- Update todos as each piece completes
|
||||
|
||||
Phase 6: Verification
|
||||
Goal: [Ensure quality and correctness]
|
||||
|
||||
Actions:
|
||||
- Run tests if applicable
|
||||
- Run type checking if applicable
|
||||
- Example: !{bash npm run test && npm run typecheck}
|
||||
- Verify functionality works as expected
|
||||
- Update todos
|
||||
|
||||
Phase 7: Summary
|
||||
Goal: [Document what was accomplished]
|
||||
|
||||
Actions:
|
||||
- Mark all todos complete
|
||||
- Summarize:
|
||||
- What was built
|
||||
- Key decisions made
|
||||
- Files modified
|
||||
- Suggested next steps
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Pattern 4: Parallel Multi-Agent Template
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: [What this command does - typically comprehensive analysis or audit]
|
||||
argument-hint: [argument-placeholder]
|
||||
allowed-tools: Task, Read, Write, Bash(*), Glob, Grep, TodoWrite
|
||||
---
|
||||
|
||||
**Arguments**: $ARGUMENTS
|
||||
|
||||
Goal: [What this command accomplishes - typically running independent checks]
|
||||
|
||||
Core Principles:
|
||||
- Launch independent tasks in parallel for speed
|
||||
- Consolidate results at the end
|
||||
- Track progress with TodoWrite
|
||||
- Provide comprehensive summary
|
||||
|
||||
Phase 1: Discovery
|
||||
Goal: [Understand the target and scope]
|
||||
|
||||
Actions:
|
||||
- Create todo list using TodoWrite
|
||||
- Parse $ARGUMENTS for target (file, directory, etc.)
|
||||
- Validate target exists
|
||||
- Example: !{bash test -e "$ARGUMENTS" && echo "Found" || echo "Not found"}
|
||||
- Load context about target
|
||||
- Update todos
|
||||
|
||||
Phase 2: Parallel Execution
|
||||
Goal: [Run multiple independent agents simultaneously]
|
||||
|
||||
Actions:
|
||||
|
||||
Run the following agents IN PARALLEL (all at once):
|
||||
|
||||
Task(description="[First Check Name]", subagent_type="[agent-type-1]", prompt="You are the [agent-type-1] agent. [Accomplish first task] for $ARGUMENTS. Focus on: [Focus area 1], [Focus area 2]. Deliverable: [Expected output]")
|
||||
|
||||
Task(description="[Second Check Name]", subagent_type="[agent-type-2]", prompt="You are the [agent-type-2] agent. [Accomplish second task] for $ARGUMENTS. Focus on: [Focus area 1], [Focus area 2]. Deliverable: [Expected output]")
|
||||
|
||||
Task(description="[Third Check Name]", subagent_type="[agent-type-3]", prompt="You are the [agent-type-3] agent. [Accomplish third task] for $ARGUMENTS. Focus on: [Focus area 1], [Focus area 2]. Deliverable: [Expected output]")
|
||||
|
||||
Wait for ALL agents to complete before proceeding.
|
||||
|
||||
Update todos as each agent completes.
|
||||
|
||||
Phase 3: Consolidation
|
||||
Goal: [Combine and analyze results from all agents]
|
||||
|
||||
Actions:
|
||||
- Review all agent outputs
|
||||
- Identify common themes or critical issues
|
||||
- Prioritize findings by severity/importance
|
||||
- Cross-reference findings for validation
|
||||
- Update todos
|
||||
|
||||
Phase 4: Summary
|
||||
Goal: [Present comprehensive results]
|
||||
|
||||
Actions:
|
||||
- Mark all todos complete
|
||||
- Present consolidated report:
|
||||
- Results from each agent
|
||||
- Critical issues (high priority)
|
||||
- Warnings and recommendations
|
||||
- Suggested next steps
|
||||
- Organize by priority or category
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Patterns and Syntax
|
||||
|
||||
### Arguments
|
||||
Always use `$ARGUMENTS` never `$1`, `$2`, etc.
|
||||
```
|
||||
If user provided --fix flag:
|
||||
Parse from $ARGUMENTS
|
||||
```
|
||||
|
||||
### File Loading
|
||||
Use `@` prefix to load files:
|
||||
```
|
||||
@package.json
|
||||
@src/config.ts
|
||||
```
|
||||
|
||||
### Bash Execution
|
||||
Use `!{bash command}` for inline execution:
|
||||
```
|
||||
!{bash npm run build}
|
||||
!{bash ls -la | grep package}
|
||||
```
|
||||
|
||||
### Script Execution
|
||||
Reference shared scripts using ABSOLUTE paths:
|
||||
```
|
||||
!{bash ~/.claude/plugins/marketplaces/domain-plugin-builder/plugins/domain-plugin-builder/skills/build-assistant/scripts/validate-plugin.sh}
|
||||
```
|
||||
|
||||
### Agent Invocation
|
||||
Use Task() tool calls with proper parameters:
|
||||
|
||||
**Single agent:**
|
||||
```
|
||||
Task(description="Validate setup", subagent_type="verifier-agent", prompt="You are the verifier agent. Validate the setup for $ARGUMENTS. Focus on: configuration files, dependencies, environment variables. Return validation report with pass/fail status.")
|
||||
```
|
||||
|
||||
**Parallel agents (run all at once in SAME message):**
|
||||
```
|
||||
Task(description="Security check", subagent_type="security-checker", prompt="Audit security for $ARGUMENTS")
|
||||
Task(description="Code scan", subagent_type="code-scanner", prompt="Scan code quality for $ARGUMENTS")
|
||||
Task(description="Performance analysis", subagent_type="performance-analyzer", prompt="Analyze performance for $ARGUMENTS")
|
||||
|
||||
Wait for ALL agents to complete before proceeding.
|
||||
```
|
||||
|
||||
Claude Code will convert this natural language to actual Task() tool calls during execution.
|
||||
|
||||
**Examples:**
|
||||
- Single agent: "Invoke the refactorer agent to improve code quality"
|
||||
- Sequential: "First launch the detector agent, then based on findings, invoke the fixer agent"
|
||||
- Parallel: "Launch 3 reviewer agents in parallel focusing on: security, performance, and maintainability"
|
||||
|
||||
### TodoWrite Integration
|
||||
Track progress throughout:
|
||||
```
|
||||
Phase 1: Create initial todo list
|
||||
Phase N: Update todos as work progresses
|
||||
Phase Final: Mark all todos complete
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Ask Before Acting**: Use AskUserQuestion for clarification
|
||||
2. **Detect Don't Assume**: Check what exists rather than assuming structure
|
||||
3. **Progressive Disclosure**: Load context as needed, not all upfront
|
||||
4. **Clear Communication**: Explain what's happening at each phase
|
||||
5. **Error Handling**: Check for issues and provide helpful messages
|
||||
6. **User Approval**: Get confirmation before major changes
|
||||
7. **Track Progress**: Use TodoWrite for complex workflows
|
||||
8. **Validation**: Verify results before completing
|
||||
|
||||
---
|
||||
|
||||
## When to Use Each Pattern
|
||||
|
||||
**Use Pattern 1 (Simple)** when:
|
||||
- No AI decision-making needed
|
||||
- Clear, deterministic steps
|
||||
- Configuration updates, version bumps
|
||||
- Running predefined scripts
|
||||
|
||||
**Use Pattern 2 (Single Agent)** when:
|
||||
- One specialized capability needed
|
||||
- Analysis, generation, or transformation task
|
||||
- Agent can handle the full scope
|
||||
- Example: code refactoring, project setup
|
||||
|
||||
**Use Pattern 3 (Sequential)** when:
|
||||
- Multiple phases with dependencies
|
||||
- User input needed at checkpoints
|
||||
- Complex workflows: understand → design → implement → verify
|
||||
- Example: feature development, major refactoring
|
||||
|
||||
**Use Pattern 4 (Parallel)** when:
|
||||
- Multiple independent checks or analyses
|
||||
- Tasks have no dependencies
|
||||
- Speed matters (parallel execution faster)
|
||||
- Example: comprehensive audits, multi-aspect validation
|
||||
59
skills/build-assistant/templates/plugins/.gitignore.template
Normal file
59
skills/build-assistant/templates/plugins/.gitignore.template
Normal file
@@ -0,0 +1,59 @@
|
||||
# Python
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
*.so
|
||||
.Python
|
||||
build/
|
||||
develop-eggs/
|
||||
dist/
|
||||
downloads/
|
||||
eggs/
|
||||
.eggs/
|
||||
lib/
|
||||
lib64/
|
||||
parts/
|
||||
sdist/
|
||||
var/
|
||||
wheels/
|
||||
*.egg-info/
|
||||
.installed.cfg
|
||||
*.egg
|
||||
MANIFEST
|
||||
|
||||
# Virtual Environment
|
||||
venv/
|
||||
ENV/
|
||||
env/
|
||||
.venv
|
||||
|
||||
# IDE
|
||||
.vscode/
|
||||
.idea/
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
|
||||
# OS
|
||||
.DS_Store
|
||||
Thumbs.db
|
||||
|
||||
# Logs
|
||||
*.log
|
||||
|
||||
# Environment variables
|
||||
.env
|
||||
.env.local
|
||||
|
||||
# Testing
|
||||
.pytest_cache/
|
||||
.coverage
|
||||
htmlcov/
|
||||
|
||||
# Node.js
|
||||
node_modules/
|
||||
npm-debug.log
|
||||
yarn-error.log
|
||||
|
||||
# MCP
|
||||
.mcp_cache/
|
||||
@@ -0,0 +1,13 @@
|
||||
# Changelog
|
||||
|
||||
All notable changes to this project will be documented in this file.
|
||||
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
||||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
|
||||
## [1.0.0] - {{DATE}}
|
||||
|
||||
### Added
|
||||
- Initial plugin scaffold
|
||||
- Plugin directory structure
|
||||
- Plugin manifest (plugin.json)
|
||||
21
skills/build-assistant/templates/plugins/LICENSE.template
Normal file
21
skills/build-assistant/templates/plugins/LICENSE.template
Normal file
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025 Plugin Builder
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
167
skills/build-assistant/templates/plugins/PLUGIN-JSON-GUIDE.md
Normal file
167
skills/build-assistant/templates/plugins/PLUGIN-JSON-GUIDE.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# Plugin.json Configuration Guide
|
||||
|
||||
## Critical Rule: Auto-Discovery vs Custom Paths
|
||||
|
||||
**Auto-Discovered (DO NOT list in plugin.json):**
|
||||
- `commands/` directory → All `.md` files auto-discovered
|
||||
- `agents/` directory → All `.md` files auto-discovered
|
||||
- `skills/` directory → All `SKILL.md` files auto-discovered
|
||||
|
||||
**Only List in plugin.json IF using custom/non-standard locations**
|
||||
|
||||
---
|
||||
|
||||
## Example 1: Standard Structure (Most Common)
|
||||
|
||||
**Directory structure:**
|
||||
```
|
||||
my-plugin/
|
||||
├── .claude-plugin/
|
||||
│ └── plugin.json
|
||||
├── commands/
|
||||
│ ├── deploy.md
|
||||
│ └── validate.md
|
||||
├── agents/
|
||||
│ ├── orchestrator.md
|
||||
│ └── validator.md
|
||||
└── skills/
|
||||
└── deployment-skill/
|
||||
└── SKILL.md
|
||||
```
|
||||
|
||||
**plugin.json (NO commands/agents/skills fields):**
|
||||
```json
|
||||
{
|
||||
"name": "my-plugin"
|
||||
"version": "1.0.0"
|
||||
"description": "Deployment automation"
|
||||
"author": {
|
||||
"name": "Dev Team"
|
||||
"email": "dev@example.com"
|
||||
}
|
||||
"license": "MIT"
|
||||
"keywords": ["deployment"]
|
||||
}
|
||||
```
|
||||
|
||||
**Why:** Everything is in default directories - auto-discovered automatically.
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Custom Locations (Rare)
|
||||
|
||||
**Directory structure:**
|
||||
```
|
||||
my-plugin/
|
||||
├── .claude-plugin/
|
||||
│ └── plugin.json
|
||||
├── commands/ ← Auto-discovered (default)
|
||||
│ └── deploy.md
|
||||
├── specialized/ ← Custom location
|
||||
│ └── advanced-deploy.md
|
||||
└── custom-agents/ ← Custom location
|
||||
└── reviewer.md
|
||||
```
|
||||
|
||||
**plugin.json (List ONLY custom paths):**
|
||||
```json
|
||||
{
|
||||
"name": "my-plugin"
|
||||
"version": "1.0.0"
|
||||
"description": "Deployment automation"
|
||||
"author": {
|
||||
"name": "Dev Team"
|
||||
"email": "dev@example.com"
|
||||
}
|
||||
"license": "MIT"
|
||||
"keywords": ["deployment"]
|
||||
"commands": ["./specialized/advanced-deploy.md"]
|
||||
"agents": ["./custom-agents/reviewer.md"]
|
||||
}
|
||||
```
|
||||
|
||||
**Result:**
|
||||
- `commands/deploy.md` loaded (auto-discovered)
|
||||
- `specialized/advanced-deploy.md` loaded (from plugin.json)
|
||||
- `custom-agents/reviewer.md` loaded (from plugin.json)
|
||||
|
||||
---
|
||||
|
||||
## ❌ WRONG: Duplication Error
|
||||
|
||||
**Directory structure:**
|
||||
```
|
||||
my-plugin/
|
||||
├── commands/
|
||||
│ └── deploy.md
|
||||
└── agents/
|
||||
└── orchestrator.md
|
||||
```
|
||||
|
||||
**plugin.json (CAUSES DUPLICATION):**
|
||||
```json
|
||||
{
|
||||
"name": "my-plugin"
|
||||
"commands": ["./commands/deploy.md"], ❌ WRONG
|
||||
"agents": ["./agents/orchestrator.md"] ❌ WRONG
|
||||
}
|
||||
```
|
||||
|
||||
**Why wrong:**
|
||||
- `deploy.md` loaded from auto-discovery
|
||||
- `deploy.md` loaded AGAIN from plugin.json listing
|
||||
- **Result: Command appears TWICE**
|
||||
|
||||
---
|
||||
|
||||
## Template Default
|
||||
|
||||
Our `plugin.json.template` defaults to:
|
||||
```json
|
||||
{
|
||||
"name": "{{PLUGIN_NAME}}"
|
||||
"version": "{{VERSION}}"
|
||||
"description": "{{DESCRIPTION}}"
|
||||
"author": {
|
||||
"name": "{{AUTHOR_NAME}}"
|
||||
"email": "{{AUTHOR_EMAIL}}"
|
||||
}
|
||||
"homepage": "{{HOMEPAGE_URL}}"
|
||||
"repository": "{{REPOSITORY_URL}}"
|
||||
"license": "{{LICENSE}}"
|
||||
"keywords": {{KEYWORDS}}
|
||||
}
|
||||
```
|
||||
|
||||
**No `commands`, `agents`, or `skills` fields** - assumes standard structure.
|
||||
|
||||
---
|
||||
|
||||
## When Building Plugins
|
||||
|
||||
**For /build-lifecycle-plugin:**
|
||||
1. Creates standard structure (commands/, agents/, skills/)
|
||||
2. Generates plugin.json WITHOUT component fields
|
||||
3. Everything auto-discovered
|
||||
4. No duplication issues
|
||||
|
||||
**Only add component fields manually if:**
|
||||
- You have scripts in non-standard locations
|
||||
- You're organizing differently for a specific reason
|
||||
- You understand the supplemental (not replacement) behavior
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Scenario | Include in plugin.json? |
|
||||
|:---------|:------------------------|
|
||||
| Component in `commands/` | ❌ No (auto-discovered) |
|
||||
| Component in `agents/` | ❌ No (auto-discovered) |
|
||||
| Component in `skills/` | ❌ No (auto-discovered) |
|
||||
| Component in `custom-dir/` | ✅ Yes (must specify path) |
|
||||
| Both default AND custom | ✅ List only custom paths |
|
||||
|
||||
---
|
||||
|
||||
**Rule of thumb:** If you're using standard directories, leave `commands`, `agents`, `skills` out of plugin.json entirely.
|
||||
107
skills/build-assistant/templates/plugins/README.md
Normal file
107
skills/build-assistant/templates/plugins/README.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# Plugin Templates
|
||||
|
||||
This directory contains templates for creating Claude Code plugins.
|
||||
|
||||
## Files
|
||||
|
||||
- `plugin.json.template` - Plugin manifest template
|
||||
- `example-plugin/` - Complete working example plugin
|
||||
|
||||
## Template Variables
|
||||
|
||||
| Variable | Purpose | Example |
|
||||
|:---------|:--------|:--------|
|
||||
| `{{PLUGIN_NAME}}` | Unique identifier (kebab-case) | `deployment-tools` |
|
||||
| `{{VERSION}}` | Semantic version | `1.0.0` |
|
||||
| `{{DESCRIPTION}}` | Plugin purpose | `Deployment automation` |
|
||||
| `{{AUTHOR_NAME}}` | Author name | `Dev Team` |
|
||||
| `{{AUTHOR_EMAIL}}` | Author email | `dev@company.com` |
|
||||
| `{{HOMEPAGE_URL}}` | Documentation URL | `https://docs.example.com` |
|
||||
| `{{REPOSITORY_URL}}` | Source code URL | `https://github.com/org/plugin` |
|
||||
| `{{LICENSE}}` | License identifier | `MIT`, `Apache-2.0` |
|
||||
| `{{KEYWORDS}}` | Discovery tags (array) | `["deployment", "ci-cd"]` |
|
||||
|
||||
## Plugin Structure
|
||||
|
||||
```
|
||||
plugin-name/
|
||||
├── .claude-plugin/ # Metadata directory
|
||||
│ └── plugin.json # Required: plugin manifest
|
||||
├── commands/ # Slash commands (auto-discovered)
|
||||
│ ├── deploy.md
|
||||
│ └── status.md
|
||||
├── agents/ # Subagents for multi-step tasks (auto-discovered)
|
||||
│ ├── deployment-orchestrator.md
|
||||
│ └── validator.md
|
||||
├── skills/ # Background skills (auto-discovered)
|
||||
│ ├── deployment-skill/
|
||||
│ │ ├── SKILL.md
|
||||
│ │ ├── scripts/
|
||||
│ │ └── templates/
|
||||
│ └── monitoring-skill/
|
||||
│ └── SKILL.md
|
||||
├── hooks/ # Event hooks (optional)
|
||||
│ └── pre-deploy.hook.md
|
||||
├── docs/ # Documentation (optional)
|
||||
│ ├── guide.md
|
||||
│ ├── examples.md
|
||||
│ └── api.md
|
||||
├── memory/ # Persistent state (optional)
|
||||
│ ├── state.json
|
||||
│ └── cache/
|
||||
├── LICENSE # License file (optional)
|
||||
└── README.md # Plugin overview (optional)
|
||||
```
|
||||
|
||||
**Critical**:
|
||||
- All directories at plugin root, NOT inside `.claude-plugin/`
|
||||
- `commands/`, `agents/`, `skills/` are auto-discovered if present
|
||||
- Only list in plugin.json if using custom locations
|
||||
|
||||
## Usage
|
||||
|
||||
### Creating from Template
|
||||
|
||||
```bash
|
||||
# Create plugin structure
|
||||
mkdir -p my-plugin/.claude-plugin
|
||||
|
||||
# Copy and fill manifest
|
||||
cp plugin.json.template my-plugin/.claude-plugin/plugin.json
|
||||
# Edit plugin.json and replace {{VARIABLES}}
|
||||
|
||||
# Add components
|
||||
mkdir my-plugin/commands
|
||||
mkdir my-plugin/skills
|
||||
```
|
||||
|
||||
### Using Build Command
|
||||
|
||||
```bash
|
||||
# Let build system create it for you
|
||||
/build:plugin my-plugin "Description" --components=cmd,skill
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Use ${CLAUDE_PLUGIN_ROOT}**:
|
||||
- For all paths in hooks and MCP servers
|
||||
- Ensures portability across installations
|
||||
|
||||
2. **Semantic Versioning**:
|
||||
- Major: Breaking changes
|
||||
- Minor: New features (backwards-compatible)
|
||||
- Patch: Bug fixes
|
||||
|
||||
3. **Complete Metadata**:
|
||||
- Author, repository, license
|
||||
- Helps users understand plugin origin
|
||||
|
||||
4. **Test Locally**:
|
||||
- Use local marketplace for testing
|
||||
- Uninstall/reinstall to test updates
|
||||
|
||||
---
|
||||
|
||||
**Purpose**: Templates for creating plugins
|
||||
**Used by**: plugin-builder agent
|
||||
24
skills/build-assistant/templates/plugins/README.md.template
Normal file
24
skills/build-assistant/templates/plugins/README.md.template
Normal file
@@ -0,0 +1,24 @@
|
||||
# {{PLUGIN_NAME}}
|
||||
|
||||
{{DESCRIPTION}}
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
/plugin install {{PLUGIN_NAME}}@marketplace-name
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
[Add usage instructions]
|
||||
|
||||
## Components
|
||||
|
||||
- **Commands**: Available slash commands
|
||||
- **Agents**: Specialized AI agents
|
||||
- **Skills**: Reusable capabilities
|
||||
- **Hooks**: Event-driven automation
|
||||
|
||||
## License
|
||||
|
||||
MIT
|
||||
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"name": "example-plugin",
|
||||
"version": "1.0.0",
|
||||
"description": "Example plugin demonstrating structure and components",
|
||||
"author": {
|
||||
"name": "Framework Team"
|
||||
},
|
||||
"license": "MIT",
|
||||
"keywords": ["example", "template"],
|
||||
"commands": [
|
||||
"./commands/greet.md"
|
||||
],
|
||||
"skills": [
|
||||
"./skills/hello-skill/SKILL.md"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"PreToolUse": [],
|
||||
"PostToolUse": [],
|
||||
"UserPromptSubmit": [],
|
||||
"SessionStart": [],
|
||||
"SessionEnd": [],
|
||||
"PreCompact": []
|
||||
}
|
||||
@@ -0,0 +1,23 @@
|
||||
{
|
||||
"name": "{{PLUGIN_NAME}}",
|
||||
"version": "1.0.0",
|
||||
"description": "{{DESCRIPTION}}",
|
||||
"owner": {
|
||||
"name": "Plugin Developer",
|
||||
"email": "noreply@{{PLUGIN_NAME}}.dev"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "{{PLUGIN_NAME}}",
|
||||
"description": "{{DESCRIPTION}}",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Plugin Developer",
|
||||
"email": "noreply@{{PLUGIN_NAME}}.dev"
|
||||
},
|
||||
"source": "./plugins/{{PLUGIN_NAME}}",
|
||||
"category": "development",
|
||||
"keywords": []
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"mcpServers": {}
|
||||
}
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"name": "{{PLUGIN_NAME}}",
|
||||
"version": "{{VERSION}}",
|
||||
"description": "{{DESCRIPTION}}",
|
||||
"author": {
|
||||
"name": "{{AUTHOR_NAME}}",
|
||||
"email": "{{AUTHOR_EMAIL}}"
|
||||
},
|
||||
"homepage": "{{HOMEPAGE_URL}}",
|
||||
"repository": "{{REPOSITORY_URL}}",
|
||||
"license": "{{LICENSE}}",
|
||||
"keywords": {{KEYWORDS}}
|
||||
}
|
||||
50
skills/build-assistant/templates/skills/SKILL.md.template
Normal file
50
skills/build-assistant/templates/skills/SKILL.md.template
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: {{SKILL_NAME}}
|
||||
description: {{DESCRIPTION_WHAT_IT_DOES}}. Use when {{TRIGGER_KEYWORDS_AND_CONTEXT}}.
|
||||
{{ALLOWED_TOOLS}}
|
||||
---
|
||||
|
||||
# {{SKILL_NAME}}
|
||||
|
||||
**CRITICAL: The description field above controls when Claude auto-loads this skill.**
|
||||
|
||||
**Description Template:**
|
||||
```yaml
|
||||
description: [What it does]. Use when [building/creating/validating/analyzing] [specific things], [related activities], or when user mentions [keywords], [terms], [phrases].
|
||||
```
|
||||
|
||||
**Good Examples:**
|
||||
```yaml
|
||||
# Validator Skill
|
||||
description: Validate and auto-fix MCP server structure. Use when building MCP servers, validating server code, fixing server issues, or when user mentions MCP validation, server structure, or FastMCP compliance.
|
||||
|
||||
# Generator Skill
|
||||
description: Generate React components with validation. Use when creating React components, building UI elements, scaffolding components, or when user mentions React, components, or UI generation.
|
||||
|
||||
# Analyzer Skill
|
||||
description: Detect framework and project structure. Use when initializing projects, analyzing codebases, identifying frameworks, or when user mentions project detection, framework identification, or stack analysis.
|
||||
```
|
||||
|
||||
**Bad Examples (too vague - won't trigger):**
|
||||
```yaml
|
||||
description: Helps with files # ❌ Too vague
|
||||
description: Development skill # ❌ No triggers
|
||||
description: Use when needed # ❌ No specifics
|
||||
```
|
||||
|
||||
## Instructions
|
||||
|
||||
{{STEP_BY_STEP_INSTRUCTIONS}}
|
||||
|
||||
## Examples
|
||||
|
||||
{{CONCRETE_EXAMPLES}}
|
||||
|
||||
## Requirements
|
||||
|
||||
{{REQUIREMENTS}}
|
||||
|
||||
---
|
||||
|
||||
**Generated from**: $HOME/.claude/marketplaces/multiagent-dev/plugins/multiagent-build/skills/build-assistant/templates/skills/SKILL.md.template
|
||||
**Template Version**: 1.0.0
|
||||
Reference in New Issue
Block a user