[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DSXWDWA43AFWFARKDZDPAT":3,"skill-same:01M6DSXWDWA43AFWFARKDZDPAT":56},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":14,"categories":15,"keywords":21,"publishedAt":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":35,"install":36,"resources":49},"01M6DSXWDWA43AFWFARKDZDPAT","create-agent",null,"AntifragileTech\u002Fantifragile-claude-code","AntifragileTech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F174357194?v=4","01M6DQCYMK4CDSQQAN0ZC72NTV","01M6DQCYS9YPW1WKMQ5TJMPQ43",9,"MIT","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fcreate-agent\u002FSKILL.md",[16],{"categoryNo":17,"categoryName":18,"taxonomyType":19,"taxonomyTypeDesc":20},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[22,23],"create agent","create","2026-11-10 10:12:30",false,"---\nname: customaize-agent:create-agent\ndescription: Comprehensive guide for creating Claude Code agents with proper structure, triggering conditions, system prompts, and validation - combines official Anthropic best practices with proven patterns\nargument-hint: [agent-name] [optional description of agent purpose]\nallowed-tools: Read, Write, Glob, Grep, Bash(mkdir:*), Task\n---\n\n# Create Agent Command\n\nCreate autonomous Claude Code agents that handle complex, multi-step tasks independently. This command provides comprehensive guidance based on official Anthropic documentation and proven patterns.\n\n## User Input\n\n```text\nAgent Name: $1\nDescription: $2\n```\n\n## What Are Agents?\n\nAgents are **autonomous subprocesses** spawned via the Task tool that:\n\n- Handle complex, multi-step tasks independently\n- Have their own isolated context window\n- Return results to the parent conversation\n- Can be specialized for specific domains\n\n| Concept | Agent | Command |\n|---------|-------|---------|\n| **Trigger** | Claude decides based on description | User invokes with `\u002Fname` |\n| **Purpose** | Autonomous work | User-initiated actions |\n| **Context** | Isolated subprocess | Shared conversation |\n| **File format** | `agents\u002F*.md` | `commands\u002F*.md` |\n\n## Agent File Structure\n\nAgents use a unique format combining **YAML frontmatter** with a **markdown system prompt**:\n\n```markdown\n---\nname: agent-identifier\ndescription: Use this agent when [triggering conditions]. Examples:\n\n\u003Cexample>\nContext: [Situation description]\nuser: \"[User request]\"\nassistant: \"[How assistant should respond and use this agent]\"\n\u003Ccommentary>\n[Why this agent should be triggered]\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\n\u003Cexample>\n[Additional example...]\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: blue\ntools: [\"Read\", \"Write\", \"Grep\"]\n---\n\nYou are [agent role description]...\n\n**Your Core Responsibilities:**\n1. [Responsibility 1]\n2. [Responsibility 2]\n\n**Analysis Process:**\n[Step-by-step workflow]\n\n**Output Format:**\n[What to return]\n```\n\n## Frontmatter Fields Reference\n\n### Required Fields\n\n#### `name` (Required)\n\n**Format**: Lowercase with hyphens only\n**Length**: 3-50 characters\n**Rules**:\n\n- Must start and end with alphanumeric character\n- Only lowercase letters, numbers, and hyphens\n- No underscores, spaces, or special characters\n\n| Valid | Invalid | Reason |\n|-------|---------|--------|\n| `code-reviewer` | `helper` | Too generic |\n| `test-generator` | `-agent-` | Starts\u002Fends with hyphen |\n| `api-docs-writer` | `my_agent` | Underscores not allowed |\n| `security-analyzer` | `ag` | Too short (\u003C3 chars) |\n| `pr-quality-reviewer` | `MyAgent` | Uppercase not allowed |\n\n#### `description` (Required, Critical)\n\n**The most important field** - Defines when Claude triggers the agent.\n\n**Requirements**:\n\n- Length: 10-5,000 characters (ideal: 200-1,000 with 2-4 examples)\n- **MUST start with**: \"Use this agent when...\"\n- **MUST include**: `\u003Cexample>` blocks showing usage patterns\n- Each example needs: context, user request, assistant response, commentary\n\n**Example Block Format**:\n\n```markdown\n\u003Cexample>\nContext: [Describe the situation - what led to this interaction]\nuser: \"[Exact user message or request]\"\nassistant: \"[How Claude should respond before triggering]\"\n\u003Ccommentary>\n[Explanation of why this agent should be triggered in this scenario]\n\u003C\u002Fcommentary>\nassistant: \"[How Claude triggers the agent - 'I'll use the [agent-name] agent...']\"\n\u003C\u002Fexample>\n```\n\n**Best Practices for Descriptions**:\n\n- Include 2-4 concrete examples\n- Show both proactive and reactive triggering scenarios\n- Cover different phrasings of the same intent\n- Explain reasoning in commentary\n- Be specific about when NOT to use the agent\n\n#### `model` (Required)\n\n**Values**: `inherit`, `sonnet`, `opus`, `haiku`\n**Default**: `inherit` (recommended)\n\n| Value | Use Case | Cost |\n|-------|----------|------|\n| `inherit` | Use parent conversation model | Default |\n| `haiku` | Fast, simple tasks | Lowest |\n| `sonnet` | Balanced performance | Medium |\n| `opus` | Maximum capability, complex reasoning | Highest |\n\n**Recommendation**: Use `inherit` unless you have a specific reason to override.\n\n#### `color` (Required)\n\n**Purpose**: Visual indicator in UI to distinguish agents\n\n**Values**: `blue`, `cyan`, `green`, `yellow`, `magenta`, `red`\n\n**Best Practice**: Use different colors for different agents in the same plugin to distinguish them visually.\n\n### Optional Fields\n\n#### `tools` (Optional)\n\n**Purpose**: Restrict available tools (principle of least privilege)\n**Format**: Array of tool names\n**Default**: All tools available\n\n```yaml\n# Common tool restrictions\ntools: [\"Read\", \"Grep\", \"Glob\"]           # Read-only analysis\ntools: [\"Read\", \"Write\", \"Grep\", \"Glob\"]  # Code modification\ntools: [\"Read\", \"Bash\", \"Grep\"]           # System operations\n```\n\n**Security Principle**: Only grant tools the agent actually needs.\n\n## Triggering Patterns\n\n### Pattern 1: Explicit Request\n\nUser directly asks for the agent's function.\n\n```markdown\n\u003Cexample>\nContext: User wants code reviewed\nuser: \"Can you review my code changes?\"\nassistant: \"I'll use the code-reviewer agent to analyze the changes.\"\n\u003Ccommentary>\nUser explicitly requested code review, trigger the code-reviewer agent.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n```\n\n### Pattern 2: Implicit Need\n\nAgent needed based on context, not explicit request.\n\n```markdown\n\u003Cexample>\nContext: User mentions code is hard to understand\nuser: \"This code is confusing and hard to follow\"\nassistant: \"I can help improve the code clarity.\"\n\u003Ccommentary>\nUser indicates complexity issues. Trigger code-simplifier agent to refactor\nfor better readability.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the code-simplifier agent to suggest improvements.\"\n\u003C\u002Fexample>\n```\n\n### Pattern 3: Proactive Trigger\n\nAgent triggers after completing relevant work without explicit request.\n\n```markdown\n\u003Cexample>\nContext: User just implemented database queries\nuser: \"I've added the user search functionality\"\nassistant: \"Great! Let me review it for security.\"\n\u003Ccommentary>\nDatabase code written. Proactively trigger security-analyzer to check\nfor SQL injection and other database security issues.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the security-analyzer agent to check the database code.\"\n\u003C\u002Fexample>\n```\n\n### Pattern 4: Tool Usage Pattern\n\nAgent triggers based on prior tool usage.\n\n```markdown\n\u003Cexample>\nContext: User made multiple edits to test files\nuser: \"I've updated all the tests\"\nassistant: \"Great! Let me verify test quality.\"\n\u003Ccommentary>\nMultiple Edit tools used on test files. Proactively trigger test-quality-analyzer\nto ensure tests follow best practices.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the test-quality-analyzer agent to review the tests.\"\n\u003C\u002Fexample>\n```\n\n## System Prompt Design\n\nThe system prompt (markdown body after frontmatter) defines agent behavior. Use this proven template:\n\n```markdown\nYou are [role] specializing in [domain].\n\n**Your Core Responsibilities:**\n1. [Primary responsibility - what the agent MUST do]\n2. [Secondary responsibility]\n3. [Additional responsibilities...]\n\n**Analysis Process:**\n1. [Step one - be specific]\n2. [Step two]\n3. [Step three]\n[...]\n\n**Quality Standards:**\n- [Standard 1 - measurable criteria]\n- [Standard 2]\n\n**Output Format:**\nProvide results in this format:\n- [What to include]\n- [How to structure]\n\n**Edge Cases:**\nHandle these situations:\n- [Edge case 1]: [How to handle]\n- [Edge case 2]: [How to handle]\n\n**What NOT to Do:**\n- [Anti-pattern 1]\n- [Anti-pattern 2]\n```\n\n### System Prompt Principles\n\n| Principle | Good | Bad |\n|-----------|------|-----|\n| Be specific | \"Check for SQL injection in query strings\" | \"Look for security issues\" |\n| Include examples | \"Format: `## Critical Issues\\n- Issue 1`\" | \"Use proper formatting\" |\n| Define boundaries | \"Do NOT modify files, only analyze\" | No boundaries stated |\n| Provide fallbacks | \"If unsure, ask for clarification\" | Assume and proceed |\n| Quality mechanisms | \"Verify each finding with evidence\" | No verification |\n\n### Validation Requirements\n\nSystem prompts must be:\n\n- **Length**: 20-10,000 characters (ideal: 500-3,000)\n- **Well-structured**: Clear sections with responsibilities, process, output format\n- **Specific**: Actionable instructions, not vague guidance\n- **Complete**: Handles edge cases and quality standards\n\n## AI-Assisted Agent Generation\n\nUse this prompt to generate agent configurations automatically:\n\n```markdown\nCreate an agent configuration based on this request: \"[YOUR DESCRIPTION]\"\n\nRequirements:\n1. Extract core intent and responsibilities\n2. Design expert persona for the domain\n3. Create comprehensive system prompt with:\n   - Clear behavioral boundaries\n   - Specific methodologies\n   - Edge case handling\n   - Output format\n4. Create identifier (lowercase, hyphens, 3-50 chars)\n5. Write description with triggering conditions\n6. Include 2-3 \u003Cexample> blocks showing when to use\n\nReturn JSON with:\n{\n  \"identifier\": \"agent-name\",\n  \"whenToUse\": \"Use this agent when... Examples: \u003Cexample>...\u003C\u002Fexample>\",\n  \"systemPrompt\": \"You are...\"\n}\n```\n\n### Elite Agent Architect Process\n\nWhen creating agents, follow this 6-step process:\n\n1. **Extract Core Intent**: Identify fundamental purpose, key responsibilities, success criteria\n2. **Design Expert Persona**: Create compelling expert identity with domain knowledge\n3. **Architect Comprehensive Instructions**: Behavioral boundaries, methodologies, edge cases, output formats\n4. **Optimize for Performance**: Decision frameworks, quality control, workflow patterns, fallback strategies\n5. **Create Identifier**: Concise, descriptive, 2-4 words with hyphens\n6. **Generate Examples**: Triggering scenarios with context, user\u002Fassistant dialogue, commentary\n\n## Default Agent Standards\n\n### Frontmatter Rules\n\n- `description`: Keep to ONE sentence - descriptions load into parent context, every token counts\n- Do NOT add verbose `\u003Cexample>` blocks in description - they waste context tokens\n\n### Required Agent Sections (in order)\n\n1. **Title** - `# \u003CRole Title>` with strong identity statement\n2. **Identity** - Quality expectations and motivation (consequences for poor work)\n3. **Goal** - Clear single-paragraph objective\n4. **Input** - What files\u002Fdata the agent receives\n5. **CRITICAL: Load Context** - Explicit requirement to read ALL relevant files BEFORE analysis\n6. **Process\u002FStages** - Step-by-step workflow with proper ordering\n\n### Process Stage Ordering (critical for multi-stage agents)\n\n```\nWRONG: Decompose → Self-Critique → Produce → Solve\nRIGHT: Decompose → Solve → Produce Full Solution → Self-Critique → Output\n```\n\n- Self-critique comes as the last step, always\n- Always produce everything first, then evaluate and select\n\n### Decision Tables\n\nPut reasoning column BEFORE decision column:\n\n```markdown\nWRONG: | Section | Include? | Reasoning |\nRIGHT: | Section | Reasoning | Include? |\n```\n\nThis forces the agent to explain WHY before deciding, improving decision quality.\n\n## Validation Rules\n\n### Structural Validation\n\n| Component | Rule | Valid | Invalid |\n|-----------|------|-------|---------|\n| Name | 3-50 chars, lowercase, hyphens | `code-reviewer` | `Code_Reviewer` |\n| Description | 10-5000 chars, starts \"Use this agent when\" | `Use this agent when reviewing code...` | `Reviews code` |\n| Model | One of: inherit, sonnet, opus, haiku | `inherit` | `gpt-4` |\n| Color | One of: blue, cyan, green, yellow, magenta, red | `blue` | `purple` |\n| System prompt | 20-10000 chars | 500+ char prompt | Empty body |\n| Examples | At least one `\u003Cexample>` block | Has examples | No examples |\n\n### Validation Script\n\n```bash\n# Validate agent structure\nscripts\u002Fvalidate-agent.sh agents\u002Fyour-agent.md\n```\n\n### Quality Checklist\n\nBefore deployment:\n\n- [ ] Name follows conventions (lowercase, hyphens, 3-50 chars)\n- [ ] Description starts with \"Use this agent when...\"\n- [ ] Description includes 2-4 `\u003Cexample>` blocks\n- [ ] Each example has context, user, assistant, commentary\n- [ ] Model is appropriate for task complexity\n- [ ] Color is unique among related agents\n- [ ] Tools restricted to what's needed (least privilege)\n- [ ] System prompt has clear structure\n- [ ] Responsibilities are specific and actionable\n- [ ] Process steps are concrete\n- [ ] Output format is defined\n- [ ] Edge cases are addressed\n\n## Production Examples\n\n### Code Quality Reviewer Agent\n\n```markdown\n---\nname: code-quality-reviewer\ndescription: Use this agent when the user asks to review code changes, check code quality, or analyze modifications for bugs and improvements. Examples:\n\n\u003Cexample>\nContext: User has completed implementing a feature\nuser: \"I've finished the authentication module\"\nassistant: \"Great! Let me review it for quality.\"\n\u003Ccommentary>\nCode implementation complete. Proactively trigger code-quality-reviewer\nto check for bugs, security issues, and best practices.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the code-quality-reviewer agent to analyze the changes.\"\n\u003C\u002Fexample>\n\n\u003Cexample>\nContext: User explicitly requests review\nuser: \"Can you review PR #123 for code quality?\"\nassistant: \"I'll use the code-quality-reviewer agent to analyze the PR.\"\n\u003Ccommentary>\nPR review request triggers the code-quality-reviewer agent.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: blue\ntools: [\"Read\", \"Grep\", \"Glob\"]\n---\n\nYou are an expert code quality reviewer specializing in identifying bugs, security vulnerabilities, and improvement opportunities.\n\n**Your Core Responsibilities:**\n1. Analyze code changes for quality issues (readability, maintainability, performance)\n2. Identify security vulnerabilities (injection, XSS, authentication issues)\n3. Check adherence to project best practices and coding standards\n4. Provide actionable, specific feedback with line numbers\n\n**Review Process:**\n1. **Initial scan**: Quick pass for obvious issues\n2. **Deep analysis**: Line-by-line review of changed code\n3. **Context evaluation**: Check impact on related code\n4. **Best practices**: Compare against project and language standards\n5. **Recommendations**: Prioritized list of improvements\n\n**Output Format:**\nFor each file reviewed:\n\n## Summary\n[2-3 sentence overview]\n\n## Critical Issues (must fix)\n- [Issue with file:line reference and fix suggestion]\n\n## Major Issues (should fix)\n- [Issue with explanation]\n\n## Minor Issues (nice to fix)\n- [Suggestion]\n\n## Positive Observations\n- [What was done well]\n\n## Overall Assessment\n[Pass\u002FNeeds Work\u002FFail with reasoning]\n\n**Quality Standards:**\n- Every issue must have a specific location (file:line)\n- Every issue must have a suggested fix\n- Prioritize security over style issues\n- Acknowledge good patterns, not just problems\n```\n\n### Test Generator Agent\n\n```markdown\n---\nname: test-generator\ndescription: Use this agent when the user asks for test generation, needs test coverage, or has written new code requiring tests. Examples:\n\n\u003Cexample>\nContext: User has written new functionality without tests\nuser: \"I've implemented the payment processing module\"\nassistant: \"Let me generate comprehensive tests for it.\"\n\u003Ccommentary>\nNew code written without tests. Trigger test-generator to create\nunit tests, integration tests, and edge case coverage.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the test-generator agent to create comprehensive tests.\"\n\u003C\u002Fexample>\n\n\u003Cexample>\nContext: User explicitly requests tests\nuser: \"Can you write tests for the utils folder?\"\nassistant: \"I'll use the test-generator agent to create tests.\"\n\u003Ccommentary>\nExplicit test generation request.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: green\ntools: [\"Read\", \"Write\", \"Grep\", \"Glob\"]\n---\n\nYou are an expert test engineer specializing in creating comprehensive test suites.\n\n**Your Core Responsibilities:**\n1. Analyze code to understand behavior and dependencies\n2. Generate unit tests for individual functions\u002Fmethods\n3. Create integration tests for module interactions\n4. Design edge case and error condition tests\n5. Follow project testing conventions and patterns\n\n**Expertise Areas:**\n- **Unit testing**: Individual function\u002Fmethod tests\n- **Integration testing**: Module interaction tests\n- **Edge cases**: Boundary conditions, error paths\n- **Test organization**: Proper structure and naming\n- **Mocking**: Appropriate use of mocks and stubs\n\n**Process:**\n1. Read target code and understand its behavior\n2. Identify testable units and their dependencies\n3. Design test cases covering:\n   - Happy paths (expected behavior)\n   - Edge cases (boundary conditions)\n   - Error cases (invalid inputs, failures)\n4. Generate tests following project patterns\n5. Add comprehensive assertions\n\n**Output Format:**\nComplete test files with:\n- Proper test suite structure (describe\u002Fit or test blocks)\n- Setup\u002Fteardown if needed\n- Descriptive test names explaining what's being tested\n- Comprehensive assertions covering all behaviors\n- Comments explaining complex test logic\n\n**Quality Standards:**\n- Each function should have at least 3 tests (happy, edge, error)\n- Test names should describe the scenario being tested\n- Mocks should be clearly documented\n- No test interdependencies\n```\n\n## Agent Creation Process\n\n### Step 1: Gather Requirements\n\nAsk user (if not provided):\n\n1. **Agent name**: What should the agent be called? (kebab-case)\n2. **Purpose**: What problem does this agent solve?\n3. **Triggers**: When should Claude use this agent?\n4. **Responsibilities**: What are the core tasks?\n5. **Tools needed**: Read-only? Can modify files?\n6. **Model**: Need maximum capability (opus) or balanced (sonnet\u002Finherit)?\n\n### Step 2: Create Agent File\n\n```bash\n# Create agents directory if needed\nmkdir -p ${CLAUDE_PLUGIN_ROOT}\u002Fagents\n\n# Create agent file\ntouch ${CLAUDE_PLUGIN_ROOT}\u002Fagents\u002F\u003Cagent-name>.md\n```\n\n### Step 3: Write Frontmatter\n\nGenerate frontmatter with:\n\n- Unique, descriptive name\n- Description with triggering conditions and examples\n- Appropriate model setting\n- Distinct color\n- Minimal required tools\n\n### Step 4: Write System Prompt\n\nCreate system prompt following the template:\n\n1. Role statement with specialization\n2. Core responsibilities (numbered list)\n3. Analysis\u002Fwork process (step-by-step)\n4. Quality standards (measurable criteria)\n5. Output format (specific structure)\n6. Edge cases (how to handle special situations)\n\n### Step 5: Validate\n\nRun validation:\n\n```bash\nscripts\u002Fvalidate-agent.sh agents\u002F\u003Cagent-name>.md\n```\n\nCheck:\n\n- [ ] Frontmatter parses correctly\n- [ ] All required fields present\n- [ ] Examples are complete\n- [ ] System prompt is comprehensive\n\n### Step 6: Test Triggering\n\nTest with various scenarios:\n\n1. Explicit requests matching examples\n2. Implicit needs where agent should activate\n3. Scenarios where agent should NOT activate\n4. Edge cases and variations\n\n## Best Practices Summary\n\n### DO\n\n- Include 2-4 concrete examples in agent descriptions\n- Write specific, unambiguous triggering conditions\n- Use \"inherit\" model setting unless specific need\n- Apply principle of least privilege for tools\n- Write clear, structured system prompts with explicit steps\n- Test agent triggering thoroughly before deployment\n- Use different colors for different agents\n- Include commentary explaining trigger logic\n\n### DON'T\n\n- Generic descriptions without examples\n- Omit triggering conditions\n- Use same color for multiple agents in same plugin\n- Grant unnecessary tool access\n- Write vague system prompts\n- Skip testing phases\n- Use underscores or uppercase in names\n- Forget to handle edge cases\n\n## Integration with Workflows\n\nAgents integrate with plugin workflows:\n\n1. **Phase 5: Component Implementation** uses agent-creator to generate agents\n2. **Validation phase** uses validate-agent.sh script\n3. **Testing phase** verifies triggering across scenarios\n\nFor comprehensive plugin development, use:\n\n- `\u002Fplugin-dev:create-plugin` for full plugin workflow\n- This command for individual agent creation\u002Frefinement\n\n## Create the Agent\n\nBased on user input, create:\n\n1. **Directory structure**: `${CLAUDE_PLUGIN_ROOT}\u002Fagents\u002F`\n2. **Agent file**: Complete markdown with frontmatter + system prompt\n3. **Validation**: Run validation script\n4. **Testing suggestions**: Scenarios to verify triggering\n\nAfter creation, suggest testing with `\u002Fcustomaize-agent:test-prompt` command to verify agent behavior under various scenarios.\n","# Create Agent Command\n\nCreate autonomous Claude Code agents that handle complex, multi-step tasks independently. This command provides comprehensive guidance based on official Anthropic documentation and proven patterns.\n\n## User Input\n\n```text\nAgent Name: $1\nDescription: $2\n```\n\n## What Are Agents?\n\nAgents are **autonomous subprocesses** spawned via the Task tool that:\n\n- Handle complex, multi-step tasks independently\n- Have their own isolated context window\n- Return results to the parent conversation\n- Can be specialized for specific domains\n\n| Concept | Agent | Command |\n|---------|-------|---------|\n| **Trigger** | Claude decides based on description | User invokes with `\u002Fname` |\n| **Purpose** | Autonomous work | User-initiated actions |\n| **Context** | Isolated subprocess | Shared conversation |\n| **File format** | `agents\u002F*.md` | `commands\u002F*.md` |\n\n## Agent File Structure\n\nAgents use a unique format combining **YAML frontmatter** with a **markdown system prompt**:\n\n```markdown\n---\nname: agent-identifier\ndescription: Use this agent when [triggering conditions]. Examples:\n\n\u003Cexample>\nContext: [Situation description]\nuser: \"[User request]\"\nassistant: \"[How assistant should respond and use this agent]\"\n\u003Ccommentary>\n[Why this agent should be triggered]\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\n\u003Cexample>\n[Additional example...]\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: blue\ntools: [\"Read\", \"Write\", \"Grep\"]\n---\n\nYou are [agent role description]...\n\n**Your Core Responsibilities:**\n1. [Responsibility 1]\n2. [Responsibility 2]\n\n**Analysis Process:**\n[Step-by-step workflow]\n\n**Output Format:**\n[What to return]\n```\n\n## Frontmatter Fields Reference\n\n### Required Fields\n\n#### `name` (Required)\n\n**Format**: Lowercase with hyphens only\n**Length**: 3-50 characters\n**Rules**:\n\n- Must start and end with alphanumeric character\n- Only lowercase letters, numbers, and hyphens\n- No underscores, spaces, or special characters\n\n| Valid | Invalid | Reason |\n|-------|---------|--------|\n| `code-reviewer` | `helper` | Too generic |\n| `test-generator` | `-agent-` | Starts\u002Fends with hyphen |\n| `api-docs-writer` | `my_agent` | Underscores not allowed |\n| `security-analyzer` | `ag` | Too short (\u003C3 chars) |\n| `pr-quality-reviewer` | `MyAgent` | Uppercase not allowed |\n\n#### `description` (Required, Critical)\n\n**The most important field** - Defines when Claude triggers the agent.\n\n**Requirements**:\n\n- Length: 10-5,000 characters (ideal: 200-1,000 with 2-4 examples)\n- **MUST start with**: \"Use this agent when...\"\n- **MUST include**: `\u003Cexample>` blocks showing usage patterns\n- Each example needs: context, user request, assistant response, commentary\n\n**Example Block Format**:\n\n```markdown\n\u003Cexample>\nContext: [Describe the situation - what led to this interaction]\nuser: \"[Exact user message or request]\"\nassistant: \"[How Claude should respond before triggering]\"\n\u003Ccommentary>\n[Explanation of why this agent should be triggered in this scenario]\n\u003C\u002Fcommentary>\nassistant: \"[How Claude triggers the agent - 'I'll use the [agent-name] agent...']\"\n\u003C\u002Fexample>\n```\n\n**Best Practices for Descriptions**:\n\n- Include 2-4 concrete examples\n- Show both proactive and reactive triggering scenarios\n- Cover different phrasings of the same intent\n- Explain reasoning in commentary\n- Be specific about when NOT to use the agent\n\n#### `model` (Required)\n\n**Values**: `inherit`, `sonnet`, `opus`, `haiku`\n**Default**: `inherit` (recommended)\n\n| Value | Use Case | Cost |\n|-------|----------|------|\n| `inherit` | Use parent conversation model | Default |\n| `haiku` | Fast, simple tasks | Lowest |\n| `sonnet` | Balanced performance | Medium |\n| `opus` | Maximum capability, complex reasoning | Highest |\n\n**Recommendation**: Use `inherit` unless you have a specific reason to override.\n\n#### `color` (Required)\n\n**Purpose**: Visual indicator in UI to distinguish agents\n\n**Values**: `blue`, `cyan`, `green`, `yellow`, `magenta`, `red`\n\n**Best Practice**: Use different colors for different agents in the same plugin to distinguish them visually.\n\n### Optional Fields\n\n#### `tools` (Optional)\n\n**Purpose**: Restrict available tools (principle of least privilege)\n**Format**: Array of tool names\n**Default**: All tools available\n\n```yaml\n# Common tool restrictions\ntools: [\"Read\", \"Grep\", \"Glob\"]           # Read-only analysis\ntools: [\"Read\", \"Write\", \"Grep\", \"Glob\"]  # Code modification\ntools: [\"Read\", \"Bash\", \"Grep\"]           # System operations\n```\n\n**Security Principle**: Only grant tools the agent actually needs.\n\n## Triggering Patterns\n\n### Pattern 1: Explicit Request\n\nUser directly asks for the agent's function.\n\n```markdown\n\u003Cexample>\nContext: User wants code reviewed\nuser: \"Can you review my code changes?\"\nassistant: \"I'll use the code-reviewer agent to analyze the changes.\"\n\u003Ccommentary>\nUser explicitly requested code review, trigger the code-reviewer agent.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n```\n\n### Pattern 2: Implicit Need\n\nAgent needed based on context, not explicit request.\n\n```markdown\n\u003Cexample>\nContext: User mentions code is hard to understand\nuser: \"This code is confusing and hard to follow\"\nassistant: \"I can help improve the code clarity.\"\n\u003Ccommentary>\nUser indicates complexity issues. Trigger code-simplifier agent to refactor\nfor better readability.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the code-simplifier agent to suggest improvements.\"\n\u003C\u002Fexample>\n```\n\n### Pattern 3: Proactive Trigger\n\nAgent triggers after completing relevant work without explicit request.\n\n```markdown\n\u003Cexample>\nContext: User just implemented database queries\nuser: \"I've added the user search functionality\"\nassistant: \"Great! Let me review it for security.\"\n\u003Ccommentary>\nDatabase code written. Proactively trigger security-analyzer to check\nfor SQL injection and other database security issues.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the security-analyzer agent to check the database code.\"\n\u003C\u002Fexample>\n```\n\n### Pattern 4: Tool Usage Pattern\n\nAgent triggers based on prior tool usage.\n\n```markdown\n\u003Cexample>\nContext: User made multiple edits to test files\nuser: \"I've updated all the tests\"\nassistant: \"Great! Let me verify test quality.\"\n\u003Ccommentary>\nMultiple Edit tools used on test files. Proactively trigger test-quality-analyzer\nto ensure tests follow best practices.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the test-quality-analyzer agent to review the tests.\"\n\u003C\u002Fexample>\n```\n\n## System Prompt Design\n\nThe system prompt (markdown body after frontmatter) defines agent behavior. Use this proven template:\n\n```markdown\nYou are [role] specializing in [domain].\n\n**Your Core Responsibilities:**\n1. [Primary responsibility - what the agent MUST do]\n2. [Secondary responsibility]\n3. [Additional responsibilities...]\n\n**Analysis Process:**\n1. [Step one - be specific]\n2. [Step two]\n3. [Step three]\n[...]\n\n**Quality Standards:**\n- [Standard 1 - measurable criteria]\n- [Standard 2]\n\n**Output Format:**\nProvide results in this format:\n- [What to include]\n- [How to structure]\n\n**Edge Cases:**\nHandle these situations:\n- [Edge case 1]: [How to handle]\n- [Edge case 2]: [How to handle]\n\n**What NOT to Do:**\n- [Anti-pattern 1]\n- [Anti-pattern 2]\n```\n\n### System Prompt Principles\n\n| Principle | Good | Bad |\n|-----------|------|-----|\n| Be specific | \"Check for SQL injection in query strings\" | \"Look for security issues\" |\n| Include examples | \"Format: `## Critical Issues\\n- Issue 1`\" | \"Use proper formatting\" |\n| Define boundaries | \"Do NOT modify files, only analyze\" | No boundaries stated |\n| Provide fallbacks | \"If unsure, ask for clarification\" | Assume and proceed |\n| Quality mechanisms | \"Verify each finding with evidence\" | No verification |\n\n### Validation Requirements\n\nSystem prompts must be:\n\n- **Length**: 20-10,000 characters (ideal: 500-3,000)\n- **Well-structured**: Clear sections with responsibilities, process, output format\n- **Specific**: Actionable instructions, not vague guidance\n- **Complete**: Handles edge cases and quality standards\n\n## AI-Assisted Agent Generation\n\nUse this prompt to generate agent configurations automatically:\n\n```markdown\nCreate an agent configuration based on this request: \"[YOUR DESCRIPTION]\"\n\nRequirements:\n1. Extract core intent and responsibilities\n2. Design expert persona for the domain\n3. Create comprehensive system prompt with:\n   - Clear behavioral boundaries\n   - Specific methodologies\n   - Edge case handling\n   - Output format\n4. Create identifier (lowercase, hyphens, 3-50 chars)\n5. Write description with triggering conditions\n6. Include 2-3 \u003Cexample> blocks showing when to use\n\nReturn JSON with:\n{\n  \"identifier\": \"agent-name\",\n  \"whenToUse\": \"Use this agent when... Examples: \u003Cexample>...\u003C\u002Fexample>\",\n  \"systemPrompt\": \"You are...\"\n}\n```\n\n### Elite Agent Architect Process\n\nWhen creating agents, follow this 6-step process:\n\n1. **Extract Core Intent**: Identify fundamental purpose, key responsibilities, success criteria\n2. **Design Expert Persona**: Create compelling expert identity with domain knowledge\n3. **Architect Comprehensive Instructions**: Behavioral boundaries, methodologies, edge cases, output formats\n4. **Optimize for Performance**: Decision frameworks, quality control, workflow patterns, fallback strategies\n5. **Create Identifier**: Concise, descriptive, 2-4 words with hyphens\n6. **Generate Examples**: Triggering scenarios with context, user\u002Fassistant dialogue, commentary\n\n## Default Agent Standards\n\n### Frontmatter Rules\n\n- `description`: Keep to ONE sentence - descriptions load into parent context, every token counts\n- Do NOT add verbose `\u003Cexample>` blocks in description - they waste context tokens\n\n### Required Agent Sections (in order)\n\n1. **Title** - `# \u003CRole Title>` with strong identity statement\n2. **Identity** - Quality expectations and motivation (consequences for poor work)\n3. **Goal** - Clear single-paragraph objective\n4. **Input** - What files\u002Fdata the agent receives\n5. **CRITICAL: Load Context** - Explicit requirement to read ALL relevant files BEFORE analysis\n6. **Process\u002FStages** - Step-by-step workflow with proper ordering\n\n### Process Stage Ordering (critical for multi-stage agents)\n\n```\nWRONG: Decompose → Self-Critique → Produce → Solve\nRIGHT: Decompose → Solve → Produce Full Solution → Self-Critique → Output\n```\n\n- Self-critique comes as the last step, always\n- Always produce everything first, then evaluate and select\n\n### Decision Tables\n\nPut reasoning column BEFORE decision column:\n\n```markdown\nWRONG: | Section | Include? | Reasoning |\nRIGHT: | Section | Reasoning | Include? |\n```\n\nThis forces the agent to explain WHY before deciding, improving decision quality.\n\n## Validation Rules\n\n### Structural Validation\n\n| Component | Rule | Valid | Invalid |\n|-----------|------|-------|---------|\n| Name | 3-50 chars, lowercase, hyphens | `code-reviewer` | `Code_Reviewer` |\n| Description | 10-5000 chars, starts \"Use this agent when\" | `Use this agent when reviewing code...` | `Reviews code` |\n| Model | One of: inherit, sonnet, opus, haiku | `inherit` | `gpt-4` |\n| Color | One of: blue, cyan, green, yellow, magenta, red | `blue` | `purple` |\n| System prompt | 20-10000 chars | 500+ char prompt | Empty body |\n| Examples | At least one `\u003Cexample>` block | Has examples | No examples |\n\n### Validation Script\n\n```bash\n# Validate agent structure\nscripts\u002Fvalidate-agent.sh agents\u002Fyour-agent.md\n```\n\n### Quality Checklist\n\nBefore deployment:\n\n- [ ] Name follows conventions (lowercase, hyphens, 3-50 chars)\n- [ ] Description starts with \"Use this agent when...\"\n- [ ] Description includes 2-4 `\u003Cexample>` blocks\n- [ ] Each example has context, user, assistant, commentary\n- [ ] Model is appropriate for task complexity\n- [ ] Color is unique among related agents\n- [ ] Tools restricted to what's needed (least privilege)\n- [ ] System prompt has clear structure\n- [ ] Responsibilities are specific and actionable\n- [ ] Process steps are concrete\n- [ ] Output format is defined\n- [ ] Edge cases are addressed\n\n## Production Examples\n\n### Code Quality Reviewer Agent\n\n```markdown\n---\nname: code-quality-reviewer\ndescription: Use this agent when the user asks to review code changes, check code quality, or analyze modifications for bugs and improvements. Examples:\n\n\u003Cexample>\nContext: User has completed implementing a feature\nuser: \"I've finished the authentication module\"\nassistant: \"Great! Let me review it for quality.\"\n\u003Ccommentary>\nCode implementation complete. Proactively trigger code-quality-reviewer\nto check for bugs, security issues, and best practices.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the code-quality-reviewer agent to analyze the changes.\"\n\u003C\u002Fexample>\n\n\u003Cexample>\nContext: User explicitly requests review\nuser: \"Can you review PR #123 for code quality?\"\nassistant: \"I'll use the code-quality-reviewer agent to analyze the PR.\"\n\u003Ccommentary>\nPR review request triggers the code-quality-reviewer agent.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: blue\ntools: [\"Read\", \"Grep\", \"Glob\"]\n---\n\nYou are an expert code quality reviewer specializing in identifying bugs, security vulnerabilities, and improvement opportunities.\n\n**Your Core Responsibilities:**\n1. Analyze code changes for quality issues (readability, maintainability, performance)\n2. Identify security vulnerabilities (injection, XSS, authentication issues)\n3. Check adherence to project best practices and coding standards\n4. Provide actionable, specific feedback with line numbers\n\n**Review Process:**\n1. **Initial scan**: Quick pass for obvious issues\n2. **Deep analysis**: Line-by-line review of changed code\n3. **Context evaluation**: Check impact on related code\n4. **Best practices**: Compare against project and language standards\n5. **Recommendations**: Prioritized list of improvements\n\n**Output Format:**\nFor each file reviewed:\n\n## Summary\n[2-3 sentence overview]\n\n## Critical Issues (must fix)\n- [Issue with file:line reference and fix suggestion]\n\n## Major Issues (should fix)\n- [Issue with explanation]\n\n## Minor Issues (nice to fix)\n- [Suggestion]\n\n## Positive Observations\n- [What was done well]\n\n## Overall Assessment\n[Pass\u002FNeeds Work\u002FFail with reasoning]\n\n**Quality Standards:**\n- Every issue must have a specific location (file:line)\n- Every issue must have a suggested fix\n- Prioritize security over style issues\n- Acknowledge good patterns, not just problems\n```\n\n### Test Generator Agent\n\n```markdown\n---\nname: test-generator\ndescription: Use this agent when the user asks for test generation, needs test coverage, or has written new code requiring tests. Examples:\n\n\u003Cexample>\nContext: User has written new functionality without tests\nuser: \"I've implemented the payment processing module\"\nassistant: \"Let me generate comprehensive tests for it.\"\n\u003Ccommentary>\nNew code written without tests. Trigger test-generator to create\nunit tests, integration tests, and edge case coverage.\n\u003C\u002Fcommentary>\nassistant: \"I'll use the test-generator agent to create comprehensive tests.\"\n\u003C\u002Fexample>\n\n\u003Cexample>\nContext: User explicitly requests tests\nuser: \"Can you write tests for the utils folder?\"\nassistant: \"I'll use the test-generator agent to create tests.\"\n\u003Ccommentary>\nExplicit test generation request.\n\u003C\u002Fcommentary>\n\u003C\u002Fexample>\n\nmodel: inherit\ncolor: green\ntools: [\"Read\", \"Write\", \"Grep\", \"Glob\"]\n---\n\nYou are an expert test engineer specializing in creating comprehensive test suites.\n\n**Your Core Responsibilities:**\n1. Analyze code to understand behavior and dependencies\n2. Generate unit tests for individual functions\u002Fmethods\n3. Create integration tests for module interactions\n4. Design edge case and error condition tests\n5. Follow project testing conventions and patterns\n\n**Expertise Areas:**\n- **Unit testing**: Individual function\u002Fmethod tests\n- **Integration testing**: Module interaction tests\n- **Edge cases**: Boundary conditions, error paths\n- **Test organization**: Proper structure and naming\n- **Mocking**: Appropriate use of mocks and stubs\n\n**Process:**\n1. Read target code and understand its behavior\n2. Identify testable units and their dependencies\n3. Design test cases covering:\n   - Happy paths (expected behavior)\n   - Edge cases (boundary conditions)\n   - Error cases (invalid inputs, failures)\n4. Generate tests following project patterns\n5. Add comprehensive assertions\n\n**Output Format:**\nComplete test files with:\n- Proper test suite structure (describe\u002Fit or test blocks)\n- Setup\u002Fteardown if needed\n- Descriptive test names explaining what's being tested\n- Comprehensive assertions covering all behaviors\n- Comments explaining complex test logic\n\n**Quality Standards:**\n- Each function should have at least 3 tests (happy, edge, error)\n- Test names should describe the scenario being tested\n- Mocks should be clearly documented\n- No test interdependencies\n```\n\n## Agent Creation Process\n\n### Step 1: Gather Requirements\n\nAsk user (if not provided):\n\n1. **Agent name**: What should the agent be called? (kebab-case)\n2. **Purpose**: What problem does this agent solve?\n3. **Triggers**: When should Claude use this agent?\n4. **Responsibilities**: What are the core tasks?\n5. **Tools needed**: Read-only? Can modify files?\n6. **Model**: Need maximum capability (opus) or balanced (sonnet\u002Finherit)?\n\n### Step 2: Create Agent File\n\n```bash\n# Create agents directory if needed\nmkdir -p ${CLAUDE_PLUGIN_ROOT}\u002Fagents\n\n# Create agent file\ntouch ${CLAUDE_PLUGIN_ROOT}\u002Fagents\u002F\u003Cagent-name>.md\n```\n\n### Step 3: Write Frontmatter\n\nGenerate frontmatter with:\n\n- Unique, descriptive name\n- Description with triggering conditions and examples\n- Appropriate model setting\n- Distinct color\n- Minimal required tools\n\n### Step 4: Write System Prompt\n\nCreate system prompt following the template:\n\n1. Role statement with specialization\n2. Core responsibilities (numbered list)\n3. Analysis\u002Fwork process (step-by-step)\n4. Quality standards (measurable criteria)\n5. Output format (specific structure)\n6. Edge cases (how to handle special situations)\n\n### Step 5: Validate\n\nRun validation:\n\n```bash\nscripts\u002Fvalidate-agent.sh agents\u002F\u003Cagent-name>.md\n```\n\nCheck:\n\n- [ ] Frontmatter parses correctly\n- [ ] All required fields present\n- [ ] Examples are complete\n- [ ] System prompt is comprehensive\n\n### Step 6: Test Triggering\n\nTest with various scenarios:\n\n1. Explicit requests matching examples\n2. Implicit needs where agent should activate\n3. Scenarios where agent should NOT activate\n4. Edge cases and variations\n\n## Best Practices Summary\n\n### DO\n\n- Include 2-4 concrete examples in agent descriptions\n- Write specific, unambiguous triggering conditions\n- Use \"inherit\" model setting unless specific need\n- Apply principle of least privilege for tools\n- Write clear, structured system prompts with explicit steps\n- Test agent triggering thoroughly before deployment\n- Use different colors for different agents\n- Include commentary explaining trigger logic\n\n### DON'T\n\n- Generic descriptions without examples\n- Omit triggering conditions\n- Use same color for multiple agents in same plugin\n- Grant unnecessary tool access\n- Write vague system prompts\n- Skip testing phases\n- Use underscores or uppercase in names\n- Forget to handle edge cases\n\n## Integration with Workflows\n\nAgents integrate with plugin workflows:\n\n1. **Phase 5: Component Implementation** uses agent-creator to generate agents\n2. **Validation phase** uses validate-agent.sh script\n3. **Testing phase** verifies triggering across scenarios\n\nFor comprehensive plugin development, use:\n\n- `\u002Fplugin-dev:create-plugin` for full plugin workflow\n- This command for individual agent creation\u002Frefinement\n\n## Create the Agent\n\nBased on user input, create:\n\n1. **Directory structure**: `${CLAUDE_PLUGIN_ROOT}\u002Fagents\u002F`\n2. **Agent file**: Complete markdown with frontmatter + system prompt\n3. **Validation**: Run validation script\n4. **Testing suggestions**: Scenarios to verify triggering\n\nAfter creation, suggest testing with `\u002Fcustomaize-agent:test-prompt` command to verify agent behavior under various scenarios.\n",{},"master","c73386b305dec167db7654e0e6feacb462d4f9dc","assets\u002Fskills\u002Fthinking\u002Fcreate-agent",1,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code","https:\u002F\u002Fgithub.com\u002FAntifragileTech","2026-10-02 14:22:14",{"source":7,"skillName":5,"commands":37,"prompt":47,"zipAvailable":48},[38,41,44],{"tool":39,"command":40},"npx","npx skills add AntifragileTech\u002Fantifragile-claude-code --skill create-agent",{"tool":42,"command":43},"bunx","bunx skills add AntifragileTech\u002Fantifragile-claude-code --skill create-agent",{"tool":45,"command":46},"pnpm","pnpm dlx skills add AntifragileTech\u002Fantifragile-claude-code --skill create-agent","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fcreate-agent\u002FSKILL.md",true,[50],{"path":51,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":54,"sourceHtmlUrl":55},"index.json","REFERENCE","参考文档",510,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Flinux-proc-fd-enum\u002Findex.json",[57,81,96,111,124,137],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":74,"publishedAt":24},"01M6DT9Q6VYA615SCXR757TZZ7","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-skills\u002FSKILL.md",[63,66,69],{"categoryNo":64,"categoryName":65,"taxonomyType":19,"taxonomyTypeDesc":20},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":67,"categoryName":68,"taxonomyType":19,"taxonomyTypeDesc":20},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[75,76,77,78,79,80],"writing skills","writing","use","editing","work","deployment",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":89,"publishedAt":24},"01M6DT9GFHDNY90P41WGAE1TV0","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-plans\u002FSKILL.md",[87,88],{"categoryNo":67,"categoryName":68,"taxonomyType":19,"taxonomyTypeDesc":20},{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},[90,91,76,92,93,77,94,95],"plans","writing plans","requirements","task","code","spec",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":104,"publishedAt":24},"01M6DT9C6PFGD86WS3HY7YE3XG","docs:write-concisely","Apply writing rules to any documentation that humans will read. Makes your writing clearer, stronger, and more professional.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwrite-concisely\u002FSKILL.md",[102,103],{"categoryNo":67,"categoryName":68,"taxonomyType":19,"taxonomyTypeDesc":20},{"categoryNo":70,"categoryName":71,"taxonomyType":72,"taxonomyTypeDesc":73},[105,106,107,108,109,110,76],"docs:write concisely","write","docs","read","Rules","documentation",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":24},"01M6DT98AWQ27P0N1CG97WAG66","kaizen:why","Iterative Five Whys root cause analysis drilling from symptoms to fundamentals","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwhy\u002FSKILL.md",[],[113,118,119,120,121,122,123],"why","kaizen","issue","five whys","analysis","root cause analysis",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":24},"01M6DT93EH25NAX19R3WGE1P53","verification-loop","A comprehensive verification system for Claude Code sessions.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-loop\u002FSKILL.md",[],[131,132,133,134,94,135,136],"verification loop","verification","loop","sessions","claude code sessions","system",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":6,"repositoryNo":11,"starsCount":12,"licenseSpdxId":13,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":24},"01M6DT90GW7Z7VCN98P9DVYSNC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-before-completion\u002FSKILL.md",[],[144,132,145,79,77,146,147,148],"verification before completion","commands","evidence","claim","complete"]