Initial commit
This commit is contained in:
266
skills/patterns/SKILL.md
Normal file
266
skills/patterns/SKILL.md
Normal file
@@ -0,0 +1,266 @@
|
||||
---
|
||||
name: patterns
|
||||
description: Common agent patterns and templates for Claude Code. Use when implementing agents to follow proven patterns for proxy mode, TodoWrite integration, and quality checks.
|
||||
---
|
||||
|
||||
# Agent Patterns
|
||||
|
||||
## Proxy Mode Pattern
|
||||
|
||||
Enable agents to delegate to external AI models via Claudish.
|
||||
|
||||
```xml
|
||||
<critical_constraints>
|
||||
<proxy_mode_support>
|
||||
**FIRST STEP: Check for Proxy Mode Directive**
|
||||
|
||||
Before executing, check if the incoming prompt starts with:
|
||||
```
|
||||
PROXY_MODE: {model_name}
|
||||
```
|
||||
|
||||
If you see this directive:
|
||||
|
||||
1. **Extract model name** (e.g., "x-ai/grok-code-fast-1")
|
||||
2. **Extract actual task** (everything after PROXY_MODE line)
|
||||
3. **Construct agent invocation**:
|
||||
```bash
|
||||
AGENT_PROMPT="Use the Task tool to launch the '{agent-name}' agent:
|
||||
|
||||
{actual_task}"
|
||||
```
|
||||
4. **Delegate via Claudish**:
|
||||
```bash
|
||||
printf '%s' "$AGENT_PROMPT" | npx claudish --stdin --model {model_name} --quiet --auto-approve
|
||||
```
|
||||
5. **Return attributed response**:
|
||||
```markdown
|
||||
## {Task Type} via External AI: {model_name}
|
||||
|
||||
{EXTERNAL_AI_RESPONSE}
|
||||
|
||||
---
|
||||
*Generated by: {model_name} via Claudish*
|
||||
```
|
||||
6. **STOP** - Do not execute locally
|
||||
|
||||
**If NO PROXY_MODE directive**: Proceed with normal workflow
|
||||
</proxy_mode_support>
|
||||
</critical_constraints>
|
||||
```
|
||||
|
||||
**Key Elements:**
|
||||
- Check for directive first
|
||||
- Use `--auto-approve` flag
|
||||
- Clear attribution in response
|
||||
- STOP after proxy (don't continue locally)
|
||||
|
||||
---
|
||||
|
||||
## TodoWrite Integration Pattern
|
||||
|
||||
Every agent must track workflow progress.
|
||||
|
||||
```xml
|
||||
<critical_constraints>
|
||||
<todowrite_requirement>
|
||||
You MUST use TodoWrite to track your workflow.
|
||||
|
||||
**Before starting**, create todo list:
|
||||
1. Phase 1 description
|
||||
2. Phase 2 description
|
||||
3. Phase 3 description
|
||||
|
||||
**Update continuously**:
|
||||
- Mark "in_progress" when starting
|
||||
- Mark "completed" immediately after finishing
|
||||
- Keep only ONE task "in_progress" at a time
|
||||
</todowrite_requirement>
|
||||
</critical_constraints>
|
||||
|
||||
<workflow>
|
||||
<phase number="1" name="Phase Name">
|
||||
<step>Initialize TodoWrite with all phases</step>
|
||||
<step>Mark PHASE 1 as in_progress</step>
|
||||
<step>... perform work ...</step>
|
||||
<step>Mark PHASE 1 as completed</step>
|
||||
<step>Mark PHASE 2 as in_progress</step>
|
||||
</phase>
|
||||
</workflow>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks Pattern (Implementers)
|
||||
|
||||
```xml
|
||||
<implementation_standards>
|
||||
<quality_checks mandatory="true">
|
||||
Before presenting code, perform these checks in order:
|
||||
|
||||
<check name="formatting" order="1">
|
||||
<tool>Biome.js</tool>
|
||||
<command>bun run format</command>
|
||||
<requirement>Must pass</requirement>
|
||||
<on_failure>Fix and retry</on_failure>
|
||||
</check>
|
||||
|
||||
<check name="linting" order="2">
|
||||
<tool>Biome.js</tool>
|
||||
<command>bun run lint</command>
|
||||
<requirement>All errors resolved</requirement>
|
||||
<on_failure>Fix errors, retry</on_failure>
|
||||
</check>
|
||||
|
||||
<check name="type_checking" order="3">
|
||||
<tool>TypeScript</tool>
|
||||
<command>bun run typecheck</command>
|
||||
<requirement>Zero type errors</requirement>
|
||||
<on_failure>Resolve errors, retry</on_failure>
|
||||
</check>
|
||||
|
||||
<check name="testing" order="4">
|
||||
<tool>Vitest</tool>
|
||||
<command>bun test</command>
|
||||
<requirement>All tests pass</requirement>
|
||||
<on_failure>Fix failing tests</on_failure>
|
||||
</check>
|
||||
</quality_checks>
|
||||
</implementation_standards>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Review Feedback Pattern (Reviewers)
|
||||
|
||||
```xml
|
||||
<review_criteria>
|
||||
<feedback_format>
|
||||
## Review: {name}
|
||||
|
||||
**Status**: PASS | CONDITIONAL | FAIL
|
||||
**Reviewer**: {model}
|
||||
|
||||
**Issue Summary**:
|
||||
- CRITICAL: {count}
|
||||
- HIGH: {count}
|
||||
- MEDIUM: {count}
|
||||
- LOW: {count}
|
||||
|
||||
### CRITICAL Issues
|
||||
#### Issue 1: {Title}
|
||||
- **Category**: YAML | XML | Security | Completeness
|
||||
- **Description**: What's wrong
|
||||
- **Impact**: Why it matters
|
||||
- **Fix**: How to fix it
|
||||
- **Location**: Section/line reference
|
||||
|
||||
### HIGH Priority Issues
|
||||
[Same format]
|
||||
|
||||
### Approval Decision
|
||||
**Status**: PASS | CONDITIONAL | FAIL
|
||||
**Rationale**: Why this status
|
||||
</feedback_format>
|
||||
</review_criteria>
|
||||
|
||||
<approval_criteria>
|
||||
<status name="PASS">
|
||||
- 0 CRITICAL issues
|
||||
- 0-2 HIGH issues
|
||||
- All core sections present
|
||||
</status>
|
||||
<status name="CONDITIONAL">
|
||||
- 0 CRITICAL issues
|
||||
- 3-5 HIGH issues
|
||||
- Core functionality works
|
||||
</status>
|
||||
<status name="FAIL">
|
||||
- 1+ CRITICAL issues
|
||||
- OR 6+ HIGH issues
|
||||
- Blocks functionality
|
||||
</status>
|
||||
</approval_criteria>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Orchestrator Phase Pattern (Commands)
|
||||
|
||||
```xml
|
||||
<phases>
|
||||
<phase number="1" name="Descriptive Name">
|
||||
<objective>Clear statement of what this phase achieves</objective>
|
||||
|
||||
<steps>
|
||||
<step>Mark PHASE 1 as in_progress in TodoWrite</step>
|
||||
<step>Detailed action step</step>
|
||||
<step>Detailed action step</step>
|
||||
<step>Mark PHASE 1 as completed</step>
|
||||
</steps>
|
||||
|
||||
<quality_gate>
|
||||
Exit criteria - what must be true to proceed
|
||||
</quality_gate>
|
||||
</phase>
|
||||
</phases>
|
||||
|
||||
<delegation_rules>
|
||||
<rule scope="design">ALL design → architect agent</rule>
|
||||
<rule scope="implementation">ALL implementation → developer agent</rule>
|
||||
<rule scope="review">ALL reviews → reviewer agent</rule>
|
||||
</delegation_rules>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Agent Templates
|
||||
|
||||
### Planner Template
|
||||
```yaml
|
||||
---
|
||||
name: {domain}-architect
|
||||
description: |
|
||||
Plans {domain} features with comprehensive design.
|
||||
Examples: (1) "Design X" (2) "Plan Y" (3) "Architect Z"
|
||||
model: sonnet
|
||||
color: purple
|
||||
tools: TodoWrite, Read, Write, Glob, Grep, Bash
|
||||
---
|
||||
```
|
||||
|
||||
### Implementer Template
|
||||
```yaml
|
||||
---
|
||||
name: {domain}-developer
|
||||
description: |
|
||||
Implements {domain} features with quality checks.
|
||||
Examples: (1) "Create X" (2) "Build Y" (3) "Implement Z"
|
||||
model: sonnet
|
||||
color: green
|
||||
tools: TodoWrite, Read, Write, Edit, Bash, Glob, Grep
|
||||
---
|
||||
```
|
||||
|
||||
### Reviewer Template
|
||||
```yaml
|
||||
---
|
||||
name: {domain}-reviewer
|
||||
description: |
|
||||
Reviews {domain} code for quality and standards.
|
||||
Examples: (1) "Review X" (2) "Validate Y" (3) "Check Z"
|
||||
model: sonnet
|
||||
color: cyan
|
||||
tools: TodoWrite, Read, Glob, Grep, Bash
|
||||
---
|
||||
```
|
||||
|
||||
### Orchestrator Template
|
||||
```yaml
|
||||
---
|
||||
description: |
|
||||
Orchestrates {workflow} with multi-agent coordination.
|
||||
Workflow: PHASE 1 → PHASE 2 → PHASE 3
|
||||
allowed-tools: Task, AskUserQuestion, Bash, Read, TodoWrite, Glob, Grep
|
||||
---
|
||||
```
|
||||
142
skills/schemas/SKILL.md
Normal file
142
skills/schemas/SKILL.md
Normal file
@@ -0,0 +1,142 @@
|
||||
---
|
||||
name: schemas
|
||||
description: YAML frontmatter schemas for Claude Code agents and commands. Use when creating or validating agent/command files.
|
||||
---
|
||||
|
||||
# Frontmatter Schemas
|
||||
|
||||
## Agent Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: agent-name # Required: lowercase-with-hyphens
|
||||
description: | # Required: detailed with examples
|
||||
Use this agent when [scenario]. Examples:
|
||||
(1) "Task description" - launches agent for X
|
||||
(2) "Task description" - launches agent for Y
|
||||
(3) "Task description" - launches agent for Z
|
||||
model: sonnet # Required: sonnet | opus | haiku
|
||||
color: purple # Optional: purple | cyan | green | orange | blue | red
|
||||
tools: TodoWrite, Read, Write # Required: comma-separated, space after comma
|
||||
skills: skill1, skill2 # Optional: referenced skills
|
||||
---
|
||||
```
|
||||
|
||||
### Field Reference
|
||||
|
||||
| Field | Required | Values | Description |
|
||||
|-------|----------|--------|-------------|
|
||||
| `name` | Yes | `lowercase-with-hyphens` | Agent identifier |
|
||||
| `description` | Yes | Multi-line string | 3-5 usage examples |
|
||||
| `model` | Yes | `sonnet`, `opus`, `haiku` | AI model to use |
|
||||
| `color` | No | See colors below | Terminal color |
|
||||
| `tools` | Yes | Tool list | Available tools |
|
||||
| `skills` | No | Skill list | Referenced skills |
|
||||
|
||||
### Color Guidelines
|
||||
|
||||
| Color | Agent Type | Examples |
|
||||
|-------|------------|----------|
|
||||
| `purple` | Planning | architect, api-architect |
|
||||
| `green` | Implementation | developer, ui-developer |
|
||||
| `cyan` | Review | reviewer, designer |
|
||||
| `orange` | Testing | test-architect, tester |
|
||||
| `blue` | Utility | cleaner, api-analyst |
|
||||
| `red` | Critical/Security | (rarely used) |
|
||||
|
||||
### Tool Patterns by Agent Type
|
||||
|
||||
**Orchestrators (Commands):**
|
||||
- Must have: `Task`, `TodoWrite`, `Read`, `Bash`
|
||||
- Often: `AskUserQuestion`, `Glob`, `Grep`
|
||||
- Never: `Write`, `Edit`
|
||||
|
||||
**Planners:**
|
||||
- Must have: `TodoWrite`, `Read`, `Write` (for docs)
|
||||
- Often: `Glob`, `Grep`, `Bash`
|
||||
|
||||
**Implementers:**
|
||||
- Must have: `TodoWrite`, `Read`, `Write`, `Edit`
|
||||
- Often: `Bash`, `Glob`, `Grep`
|
||||
|
||||
**Reviewers:**
|
||||
- Must have: `TodoWrite`, `Read`
|
||||
- Often: `Glob`, `Grep`, `Bash`
|
||||
- Never: `Write`, `Edit`
|
||||
|
||||
---
|
||||
|
||||
## Command Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
description: | # Required: workflow description
|
||||
Full description of what this command does.
|
||||
Workflow: PHASE 1 → PHASE 2 → PHASE 3
|
||||
allowed-tools: Task, Bash # Required: comma-separated
|
||||
skills: skill1, skill2 # Optional: referenced skills
|
||||
---
|
||||
```
|
||||
|
||||
### Field Reference
|
||||
|
||||
| Field | Required | Values | Description |
|
||||
|-------|----------|--------|-------------|
|
||||
| `description` | Yes | Multi-line | Command purpose and workflow |
|
||||
| `allowed-tools` | Yes | Tool list | Tools command can use |
|
||||
| `skills` | No | Skill list | Referenced skills |
|
||||
|
||||
---
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
### Agent Frontmatter
|
||||
- [ ] Opening `---` present
|
||||
- [ ] `name` is lowercase-with-hyphens
|
||||
- [ ] `description` includes 3+ examples
|
||||
- [ ] `model` is valid (sonnet/opus/haiku)
|
||||
- [ ] `tools` is comma-separated with spaces
|
||||
- [ ] Closing `---` present
|
||||
- [ ] No YAML syntax errors
|
||||
|
||||
### Command Frontmatter
|
||||
- [ ] Opening `---` present
|
||||
- [ ] `description` explains workflow
|
||||
- [ ] `allowed-tools` includes Task for orchestrators
|
||||
- [ ] Closing `---` present
|
||||
- [ ] No YAML syntax errors
|
||||
|
||||
---
|
||||
|
||||
## Common Errors
|
||||
|
||||
### Invalid YAML Syntax
|
||||
```yaml
|
||||
# WRONG - missing colon
|
||||
name agent-name
|
||||
|
||||
# CORRECT
|
||||
name: agent-name
|
||||
```
|
||||
|
||||
### Incorrect Tool Format
|
||||
```yaml
|
||||
# WRONG - no spaces after commas
|
||||
tools: TodoWrite,Read,Write
|
||||
|
||||
# CORRECT
|
||||
tools: TodoWrite, Read, Write
|
||||
```
|
||||
|
||||
### Missing Examples
|
||||
```yaml
|
||||
# WRONG - too generic
|
||||
description: Use this agent for development tasks.
|
||||
|
||||
# CORRECT
|
||||
description: |
|
||||
Use this agent when implementing TypeScript features. Examples:
|
||||
(1) "Create a user service" - implements service with full CRUD
|
||||
(2) "Add validation" - adds Zod schemas to endpoints
|
||||
(3) "Fix type errors" - resolves TypeScript compilation issues
|
||||
```
|
||||
249
skills/xml-standards/SKILL.md
Normal file
249
skills/xml-standards/SKILL.md
Normal file
@@ -0,0 +1,249 @@
|
||||
---
|
||||
name: xml-standards
|
||||
description: XML tag structure patterns for Claude Code agents and commands. Use when designing or implementing agents to ensure proper XML structure following Anthropic best practices.
|
||||
---
|
||||
|
||||
# XML Tag Standards
|
||||
|
||||
## Core Tags (Required for ALL Agents/Commands)
|
||||
|
||||
### `<role>`
|
||||
Defines agent identity and purpose.
|
||||
|
||||
```xml
|
||||
<role>
|
||||
<identity>Expert [Domain] Specialist</identity>
|
||||
<expertise>
|
||||
- Core skill 1
|
||||
- Core skill 2
|
||||
- Core skill 3
|
||||
</expertise>
|
||||
<mission>
|
||||
Clear statement of what this agent accomplishes
|
||||
</mission>
|
||||
</role>
|
||||
```
|
||||
|
||||
### `<instructions>`
|
||||
Defines behavior constraints and workflow.
|
||||
|
||||
```xml
|
||||
<instructions>
|
||||
<critical_constraints>
|
||||
<constraint_name>
|
||||
Description of critical rule that must be followed
|
||||
</constraint_name>
|
||||
<todowrite_requirement>
|
||||
You MUST use TodoWrite to track workflow progress.
|
||||
</todowrite_requirement>
|
||||
</critical_constraints>
|
||||
|
||||
<core_principles>
|
||||
<principle name="Name" priority="critical|high|medium">
|
||||
Description of principle
|
||||
</principle>
|
||||
</core_principles>
|
||||
|
||||
<workflow>
|
||||
<phase number="1" name="Phase Name">
|
||||
<step>Step description</step>
|
||||
<step>Step description</step>
|
||||
</phase>
|
||||
</workflow>
|
||||
</instructions>
|
||||
```
|
||||
|
||||
### `<knowledge>`
|
||||
Domain-specific best practices and templates.
|
||||
|
||||
```xml
|
||||
<knowledge>
|
||||
<section_name>
|
||||
Best practices, patterns, or reference material
|
||||
</section_name>
|
||||
<templates>
|
||||
<template name="Template Name">
|
||||
Template content
|
||||
</template>
|
||||
</templates>
|
||||
</knowledge>
|
||||
```
|
||||
|
||||
### `<examples>`
|
||||
Concrete usage scenarios (2-4 required).
|
||||
|
||||
```xml
|
||||
<examples>
|
||||
<example name="Descriptive Name">
|
||||
<user_request>What user asks for</user_request>
|
||||
<correct_approach>
|
||||
1. Step one
|
||||
2. Step two
|
||||
3. Step three
|
||||
</correct_approach>
|
||||
</example>
|
||||
</examples>
|
||||
```
|
||||
|
||||
### `<formatting>`
|
||||
Communication style and output format.
|
||||
|
||||
```xml
|
||||
<formatting>
|
||||
<communication_style>
|
||||
- Style guideline 1
|
||||
- Style guideline 2
|
||||
</communication_style>
|
||||
<completion_message_template>
|
||||
Template for completion messages
|
||||
</completion_message_template>
|
||||
</formatting>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Specialized Tags by Agent Type
|
||||
|
||||
### Orchestrators (Commands)
|
||||
|
||||
```xml
|
||||
<orchestration>
|
||||
<allowed_tools>Task, Bash, Read, TodoWrite, AskUserQuestion</allowed_tools>
|
||||
<forbidden_tools>Write, Edit</forbidden_tools>
|
||||
|
||||
<delegation_rules>
|
||||
<rule scope="design">ALL design → architect agent</rule>
|
||||
<rule scope="implementation">ALL implementation → developer agent</rule>
|
||||
<rule scope="review">ALL reviews → reviewer agent</rule>
|
||||
</delegation_rules>
|
||||
|
||||
<phases>
|
||||
<phase number="1" name="Phase Name">
|
||||
<objective>What this phase achieves</objective>
|
||||
<steps>
|
||||
<step>Step description</step>
|
||||
</steps>
|
||||
<quality_gate>Exit criteria for this phase</quality_gate>
|
||||
</phase>
|
||||
</phases>
|
||||
</orchestration>
|
||||
|
||||
<error_recovery>
|
||||
<strategy>
|
||||
Recovery steps for common failures
|
||||
</strategy>
|
||||
</error_recovery>
|
||||
```
|
||||
|
||||
### Planners (Architects)
|
||||
|
||||
```xml
|
||||
<planning_methodology>
|
||||
<approach>How planning is performed</approach>
|
||||
<deliverables>What planning produces</deliverables>
|
||||
</planning_methodology>
|
||||
|
||||
<gap_analysis>
|
||||
<checklist>Items to verify during planning</checklist>
|
||||
</gap_analysis>
|
||||
|
||||
<output_structure>
|
||||
<format>Structure of planning output</format>
|
||||
</output_structure>
|
||||
```
|
||||
|
||||
### Implementers (Developers)
|
||||
|
||||
```xml
|
||||
<implementation_standards>
|
||||
<file_writing_standards>
|
||||
<standard name="Standard Name">Description</standard>
|
||||
</file_writing_standards>
|
||||
|
||||
<quality_checks mandatory="true">
|
||||
<check name="check_name" order="1">
|
||||
<tool>Tool name</tool>
|
||||
<command>Command to run</command>
|
||||
<requirement>What must pass</requirement>
|
||||
<on_failure>Recovery action</on_failure>
|
||||
</check>
|
||||
</quality_checks>
|
||||
|
||||
<validation_checks>
|
||||
<check order="1" name="Check Name">
|
||||
Validation criteria
|
||||
</check>
|
||||
</validation_checks>
|
||||
</implementation_standards>
|
||||
```
|
||||
|
||||
### Reviewers
|
||||
|
||||
```xml
|
||||
<review_criteria>
|
||||
<focus_areas>
|
||||
<area name="Area Name" priority="critical|high|medium" weight="20%">
|
||||
**Check:**
|
||||
- Item to verify
|
||||
- Item to verify
|
||||
|
||||
**Common Issues:**
|
||||
- Issue description
|
||||
|
||||
**Critical if**: Condition for critical severity
|
||||
**High if**: Condition for high severity
|
||||
</area>
|
||||
</focus_areas>
|
||||
|
||||
<feedback_format>
|
||||
Template for review feedback
|
||||
</feedback_format>
|
||||
</review_criteria>
|
||||
|
||||
<approval_criteria>
|
||||
<status name="PASS">Criteria for passing</status>
|
||||
<status name="CONDITIONAL">Criteria for conditional approval</status>
|
||||
<status name="FAIL">Criteria for failure</status>
|
||||
</approval_criteria>
|
||||
```
|
||||
|
||||
### Testers
|
||||
|
||||
```xml
|
||||
<testing_strategy>
|
||||
<approach>Testing methodology</approach>
|
||||
<test_types>
|
||||
<type name="Type Name">Description</type>
|
||||
</test_types>
|
||||
</testing_strategy>
|
||||
|
||||
<coverage_requirements>
|
||||
<requirement>Coverage criteria</requirement>
|
||||
</coverage_requirements>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Nesting Rules
|
||||
|
||||
1. **Proper Hierarchy** - Tags must be properly nested
|
||||
2. **Closing Tags** - All opening tags must have closing tags
|
||||
3. **Semantic Attributes** - Use `name`, `priority`, `order` attributes
|
||||
4. **Consistent Naming** - Use lowercase-with-hyphens for tag names
|
||||
|
||||
## Code Blocks in XML
|
||||
|
||||
```xml
|
||||
<template name="Example">
|
||||
```language
|
||||
// code here - note: opening ``` directly under tag
|
||||
```
|
||||
</template>
|
||||
```
|
||||
|
||||
## Character Escaping
|
||||
|
||||
Only in XML attribute values and text nodes (NOT in code blocks):
|
||||
- `<` for `<`
|
||||
- `>` for `>`
|
||||
- `&` for `&`
|
||||
Reference in New Issue
Block a user