[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FPRF258XT2ZNDA3ACKHJS":3,"skill-same:01M70FPRF258XT2ZNDA3ACKHJS":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M70FPRF258XT2ZNDA3ACKHJS","prompt-engineering",null,"Core prompt engineering and context engineering best practices for Claude Code prompts.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fclaude-code\u002Fskills\u002Fprompt-engineering\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38],"prompt","prompt engineering","engineering","code","context","core","for","best practices","context engineering","prompts","2026-11-10 10:12:30",false,"---\nname: prompt-engineering\ndescription: Core prompt engineering and context engineering best practices for Claude Code prompts.\n---\n\n\u003Cclaude_code_prompts>\n## Claude Code Prompt Types\n\n\u003Ccommand_type>\n### 1. Commands\n**Purpose**: Reusable instruction presets invoked by users with `\u002Fcommand-name [args]`\n\n**Structure**:\n- **Location**: `.claude\u002Fcommands\u002F\u003Ccommand-name>.md`\n- **Invocation**: `\u002Fcommand-name [additional instructions]`\n- **Processing**: Front matter excluded; body content passed as instructions\n\n**Front Matter**:\n```yaml\n---\ndescription: 'Brief description (required, \u003C80 chars, repository's primary language)'\nallowed-tools: Bash(git, gh), Read(*), Edit(*.ts), Grep  # optional but recommended\n---\n```\n\n**allowed-tools formats**: `ToolName(*)`, `Bash(git)`, `Bash(git, gh)`, `Edit(*.ts)`, `Write`\n- Multiple tools: comma+space separated\n- Default-allowed tools (can omit): `TodoWrite`, `Task`, `Glob`, `Grep`, `Read`\n\n**Audience**: `description` → user (project language); body → LLM worker (English)\n\u003C\u002Fcommand_type>\n\n\u003Cagent_type>\n### 2. Agents\n**Purpose**: Specialized sub-agents invoked via Task tool or `@agent-name`\n\n**Structure**:\n- **Location**: `.claude\u002Fagents\u002F\u003Cagent-name>.md`\n- **Invocation**: `@agent-name [instructions]` or `Task(subagent_type=\"agent-name\", ...)`\n- **Processing**: Front matter excluded; body content passed as instructions\n\n**Front Matter**:\n```yaml\n---\nname: agent-name  # must match filename without .md\ndescription: 'Brief agent description'\nmodel: sonnet  # or haiku, or inherit (use caller's model)\ncolor: cyan    # terminal display color\nskills:        # optional: auto-load skills when agent starts\n  - typescript\n  - react\n---\n```\n\n**skills field**:\n- Skills listed here are automatically loaded when the agent is invoked\n- No need for manual `Skill(...)` calls or \"Enable the X skill\" instructions in body\n- Use this for skills the agent ALWAYS needs (not conditionally)\n- For dynamic\u002Fconditional skill loading, use `Skill(...)` tool in the prompt body\n\n**Audience**: Both caller (orchestrator LLM) and executor (sub-agent LLM) are LLMs\n- Always English\n- No orchestrator concerns (when to invoke, what to do with output)\n- Focus on capability grant and input\u002Foutput contract\n\u003C\u002Fagent_type>\n\n\u003Cskill_type>\n### 3. Skills\n**Purpose**: Reusable knowledge\u002Fguidelines loaded into sessions\n\n**Structure**:\n- **Location**: `.claude\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`\n- **Invocation**: Skill tool or auto-loaded based on description\n- **Processing**: Front matter excluded; body injected into context\n\n**Front Matter**:\n```yaml\n---\nname: skill-name  # must match directory name\ndescription: 'When this skill should be enabled'\n---\n```\n\n**Audience**: Any LLM (main session, orchestrator, or sub-agent)\n- Grant knowledge\u002Fcapability, not orchestrate workflows\n- Principles, best practices, rules (not \"first do X, then Y\")\n- Reproducible, interpretation-stable content\n\u003C\u002Fskill_type>\n\n\u003Cdocument_type>\n### 4. Documents\n**Purpose**: Standalone prompts not tied to command\u002Fagent system\n\n**Structure**:\n- **Location**: User-specified (e.g., `docs\u002Fprompts\u002F\u003Cname>.md`)\n- **Invocation**: Manual reference or inclusion\n- **Processing**: No front matter; entire content is the prompt\n\u003C\u002Fdocument_type>\n\n\u003Ccontext_files>\n### 5. Context Files (CLAUDE.md, GEMINI.md, AGENTS.md, etc.)\n**Purpose**: Project-wide or global context that is automatically loaded in every session\n\n**File Structure**:\n- **Location**:\n  - Project: `.claude\u002FCLAUDE.md`, `.gemini\u002FGEMINI.md`, `.claude\u002FAGENTS.md`\n  - Global: `~\u002F.claude\u002FCLAUDE.md`, `~\u002F.gemini\u002FGEMINI.md`, `~\u002F.claude\u002FAGENTS.md`\n- **Processing**: Entire content is injected into every session's base context\n- **No front matter**: Write content directly\n\n**Critical Characteristics**:\n- **Always loaded**: Read in every single session, regardless of task\n- **Maximum cost**: Context tokens consumed in every interaction\n- **Minimum content**: Only include what 80% of tasks need\n\n**IMPORTANT**: These are guidelines, not absolute rules. Some projects have unique contexts that justify exceptions. Use judgment, but default to minimalism when uncertain.\n\n**Content Principles**:\n\n1. **Index-first**: Pointers to detailed docs, not exhaustive content\n   - ❌ \"Use camelCase for variables, PascalCase for types...\"\n   - ✅ \"Coding conventions: docs\u002Fcoding-style.md\"\n   - Use direct content only if: cannot be discovered, critically affects every task, extremely concise (1-2 lines)\n\n2. **80% rule**: Only information needed in 80% of tasks\n   - ✅ Repository structure, key conventions, critical constraints\n   - ❌ Deployment procedures, testing strategies, specific library usage\n\n3. **Abstract\u002Fnavigational**: Materials to find information, not exhaustive details\n   - ✅ \"Database: alembic files in db\u002Fmigrations\u002F\"\n   - ❌ \"To create migration: alembic revision -m 'description'\"\n\n4. **Command scrutiny**: Only commands LLM runs autonomously in typical tasks\n   - ✅ `pnpm build`, `pnpm test` (LLM runs these)\n   - ❌ `pnpm dev`, `docker-compose up` (user runs these)\n\n**Good example**:\n```markdown\n# Project Context\n## Architecture\n- Monorepo: pnpm workspaces\n- API: packages\u002Fapi (NestJS), Frontend: packages\u002Fweb (Next.js)\n- Details: docs\u002Farchitecture\u002FREADME.md\n\n## Key Conventions\n- Branch naming: feature\u002F*, bugfix\u002F* (docs\u002Fgit-workflow.md)\n- Never modify: src\u002Fgenerated\u002F* (auto-generated)\n- Testing: Vitest\u002FPlaywright (docs\u002Ftesting.md)\n\n## Critical Constraints\n- Database changes require migration (alembic)\n- Public API changes require version bump (semver)\n```\n\n**Bad example** (avoid):\n```markdown\n# Project Setup\n## Installation\n1. Install dependencies: `pnpm install`\n2. Set up database: `pnpm db:setup`\n...\n[Detailed step-by-step procedures, exhaustive architecture details...]\n```\n\u003C\u002Fcontext_files>\n\u003C\u002Fclaude_code_prompts>\n\n\u003Ccore_principles>\n## Core Principles\n\n\u003Csingle_responsibility>\n### Single Responsibility Principle\n**Like functions in programming - one clear purpose**:\n- Each prompt (especially agents) should have one well-defined responsibility\n- Avoid mixing multiple concerns (e.g., don't mix \"setup environment\" with \"implement code\")\n- Clear boundaries make prompts composable and maintainable\n\n**Example**:\n- ✅ Agent A: Environment setup only\n- ✅ Agent B: Code implementation only\n- ❌ Agent C: Setup, implement, review, and deploy (too many responsibilities)\n\u003C\u002Fsingle_responsibility>\n\n\u003Ccaller_independence>\n### Caller Independence\n**Prompts should not know about their caller's context**:\n- Don't reference \"orchestrator\", \"parent task\", or calling patterns\n- Focus on: \"What do I receive?\" and \"What do I produce?\"\n- Users and other agents should be able to invoke the same prompt\n- Maximize reusability by keeping prompts context-free\n\n**Avoid**:\n- ❌ \"You are invoked by the orchestrator with a task document path...\"\n- ❌ \"After completion, report back to the orchestrator...\"\n- ❌ \"Read the task document to understand what the parent wants...\"\n\n**Prefer**:\n- ✅ \"Analyze the provided code and identify issues...\"\n- ✅ \"Based on the instructions, design an implementation approach...\"\n\u003C\u002Fcaller_independence>\n\n\u003Cconciseness>\n### Conciseness and Clarity\n**Think harder about what's essential**:\n- Include only necessary information for execution\n- Remove redundant explanations\n- Focus on rules and knowledge, not procedures\n\n**Red flags**:\n- Detailed step-by-step procedures (trust the LLM)\n- Repetitive examples for multiple languages (choose primary language)\n- User-facing instructions (description field handles this)\n- Implementation details that should be in CLAUDE.md\n\u003C\u002Fconciseness>\n\n\u003Corchestration_patterns>\n### Orchestration Patterns\n**When designing prompts for orchestrated workflows with subagents**:\n\n\u003Cprompt_templates>\n#### Use Prompt Templates for Subagent Invocation\n**CRITICAL REQUIREMENT: Orchestrators MUST provide explicit invocation templates**:\n- Include complete prompt templates showing how to invoke subagents with all parameters\n- Templates are NOT optional—they are essential for stable, reproducible orchestration\n- Keep summaries minimal; let templates convey specifics through concrete examples\n- Templates ensure consistency across multiple invocations and make maintenance easier\n\n**Why templates are essential**:\n1. **Consistency**: Same invocation pattern every time, reducing variability\n2. **Reproducibility**: Future maintainers can see exact invocation structure\n3. **Clarity**: Makes the orchestration contract explicit, not implicit\n4. **Maintainability**: Single source of truth for how subagents should be invoked\n5. **Discoverability**: New users can understand the pattern immediately\n\n**Without templates** (❌ Bad):\n```markdown\nInvoke the engineer agent to implement the feature.\n```\n**Problem**: Orchestrator must guess parameter structure, leading to inconsistent invocations\n\n**With templates** (✅ Good):\n```markdown\n## Invoking the Implementation Agent\n\nUse this template:\n\nTask(\n  subagent_type=\"engineer\",\n  prompt=\"\"\"\nImplement the following feature:\n{feature_description}\n\nRequirements:\n{requirements}\n\nAcceptance criteria:\n{acceptance_criteria}\n\nFollow project conventions and include tests.\n\"\"\",\n  description=\"Implement {feature_name}\"\n)\n```\n\u003C\u002Fprompt_templates>\n\n\u003Cresponsibility_split>\n#### Split Responsibilities Between Orchestrator and Subagent\n\n**Design principle**: Subagents are single-purpose but reusable across many tasks. Task-specific context belongs in the orchestrator's template; responsibility-specific practices belong in the subagent.\n\n**Subagent prompt** (responsibility-specific, reusable):\n- Core practices always needed for this responsibility\n- Domain-specific knowledge and constraints\n- General workflow for this type of task\n- Error handling patterns for this domain\n- Quality standards for this responsibility\n\n**Orchestrator's invocation template** (task-specific, contextual):\n- Current task context and background\n- Task-specific rules and constraints\n- Specific focus areas or priorities for this task\n- Integration requirements with other workflow steps\n- Project-specific constraints not universally applicable\n\n**Example - Code Review Agent**:\n\nSubagent prompt (`.claude\u002Fagents\u002Freviewer.md`):\n```markdown\nReview code changes for quality and correctness.\n\nCheck for:\n- Type safety and correctness\n- Security vulnerabilities\n- Performance issues\n- Code style consistency\n- Test coverage adequacy\n\nReport issues with:\n- Severity level (critical\u002Fmoderate\u002Fminor)\n- File path and line numbers\n- Specific recommendations\n- Priority order (critical first)\n```\n\nOrchestrator's template:\n```markdown\nTask(\n  subagent_type=\"reviewer\",\n  prompt=\"\"\"\nReview the authentication feature implementation.\n\nContext: Healthcare application handling PHI data under HIPAA.\n\nAdditional requirements for this review:\n- HIPAA compliance is critical (report violations as critical)\n- All database queries must use parameterized statements\n- Session tokens must expire within 15 minutes\n- Password hashing must use bcrypt with cost factor ≥12\n\nFiles to review: src\u002Fauth\u002F*.ts\n\nFocus on security and compliance issues.\n\"\"\",\n  description=\"Review auth implementation\"\n)\n```\n\u003C\u002Fresponsibility_split>\n\n\u003Cdesign_questions>\n#### Design Questions for Responsibility Split\n\nWhen designing orchestrated prompts, ask these questions:\n\n**Should this go in the subagent prompt?**\n- Is this practice always required for this type of task?\n- Does this define the agent's core responsibility?\n- Would this agent need this knowledge for ANY task it handles?\n- Is this domain-specific expertise for this responsibility?\n→ **YES**: Include in subagent prompt\n\n**Should this go in the orchestrator's template?**\n- Is this specific to the current task or project?\n- Does this depend on previous steps in the workflow?\n- Is this a temporary constraint or priority?\n- Does this require context from the orchestration flow?\n→ **YES**: Include in invocation template\n\n**Examples**:\n- ✅ Subagent: \"Check for type errors and unused variables\"\n- ✅ Orchestrator: \"Focus on the payment module we refactored in the previous step\"\n- ✅ Subagent: \"Report security vulnerabilities with severity levels\"\n- ✅ Orchestrator: \"This handles credit card data—PCI-DSS compliance is critical\"\n- ✅ Subagent: \"Include test coverage for new functionality\"\n- ✅ Orchestrator: \"We're under tight deadline—prioritize happy path tests\"\n\u003C\u002Fdesign_questions>\n\n\u003Cbenefits>\n#### Benefits of This Approach\n\n**Reusability**: Subagents work across different tasks and projects without modification\n\n**Maintainability**: Task-specific logic lives in one place (orchestrator), not scattered across agent prompts\n\n**Clarity**: Clear separation makes it obvious what's universal vs. contextual\n\n**Consistency**: Templates ensure subagents receive consistent, well-formed instructions\n\n**Testability**: Subagents can be tested independently with different invocation parameters\n\u003C\u002Fbenefits>\n\n\u003Corchestration_anti_patterns>\n#### Common Anti-Patterns in Orchestration\n\n**❌ Duplicating logic across orchestrator and subagent**:\n```markdown\n# Subagent prompt\n- Follow project coding conventions\n- Use TypeScript strict mode\n- Never commit secrets\n\n# Orchestrator template\nTask(prompt=\"\"\"\nFollow project coding conventions.\nUse TypeScript strict mode.\nNever commit secrets.\nImplement feature X...\n\"\"\")\n```\n**Problem**: Maintenance burden, inconsistency risk\n\n**✅ Keep domain practices in subagent only**:\n```markdown\n# Subagent prompt\n- Follow project coding conventions\n- Use TypeScript strict mode\n- Never commit secrets\n\n# Orchestrator template\nTask(prompt=\"\"\"\nImplement feature X with focus on payment processing logic.\nEnsure PCI-DSS compliance for card data handling.\n\"\"\")\n```\n\n---\n\n**❌ Making subagents too task-specific**:\n```markdown\nname: implement-user-authentication-with-jwt-and-oauth\n```\n**Problem**: Not reusable, violates single responsibility\n\n**✅ Keep subagents generic within their domain**:\n```markdown\nname: engineer\n# Orchestrator specifies: \"Implement user authentication using JWT and OAuth\"\n```\n\n---\n\n**❌ Passing orchestration context to subagents**:\n```markdown\nTask(prompt=\"\"\"\nThis is step 3 of 5 in the workflow.\nAfter you finish, I will invoke the testing agent.\nThe architect agent already designed this in step 1.\n\"\"\")\n```\n**Problem**: Violates caller independence, adds unnecessary context\n\n**✅ Provide only task-relevant information**:\n```markdown\nTask(prompt=\"\"\"\nImplement the authentication feature.\nArchitecture decisions: See attached design document.\nFocus on token generation and validation logic.\n\"\"\")\n```\n\u003C\u002Forchestration_anti_patterns>\n\n\u003Corchestration_considerations>\n#### Additional Considerations\n\n**Failure Handling**:\n- Orchestrators should handle subagent failures gracefully\n- Define retry strategies for critical tasks\n- Provide clear error reporting from subagents back to orchestrators\n- Consider fallback strategies for non-critical failures\n\n**Template Maintenance**:\n- Keep invocation templates in one location for easy updates\n- When subagent prompts change, review all orchestrator templates\n- Document expected inputs\u002Foutputs for each subagent\n\u003C\u002Forchestration_considerations>\n\u003C\u002Forchestration_patterns>\n\u003C\u002Fcore_principles>\n\n\u003Cstructure_and_clarity>\n## Structure and Clarity\n\n\u003Cxml_tags>\n### XML Tag Utilization\nStructure prompts with XML tags when multiple sections or concepts exist:\n- **Recommended tags**: `\u003Crole>`, `\u003Cscope>`, `\u003Cprinciples>`, `\u003Cerror_handling>`, `\u003Cworkflow>`\n- **Attribute usage**: `\u003Cstep_1 name=\"descriptive_name\">`, `\u003Cexample type=\"good\">`\n- **Effect**: Clear instruction boundaries improve LLM comprehension accuracy\n\u003C\u002Fxml_tags>\n\n\u003Cspecificity>\n### Instruction Specificity\n- Eliminate ambiguity with concrete, non-contradictory instructions\n- Include only verified, tested commands\n- Explicitly define conditional logic and error handling\n\u003C\u002Fspecificity>\n\n\u003Ccohesion>\n### Cohesion Optimization\nGroup related instructions, rules, and constraints within the same section.\n\n**High cohesion example**:\n```xml\n\u003Cworkflow>\n## Basic Flow\n\n**1. Check prerequisites**:\n- Verify git repository exists\n- Confirm gh CLI is authenticated\n- Error if not: Run `gh auth login`\n\n**2. Proceed with task**:\n...\n\u003C\u002Fworkflow>\n```\n\n**Low cohesion example** (avoid):\n```xml\n\u003Cprerequisites>Verify git repository\u003C\u002Fprerequisites>\n\u003Cstep_1>Check authentication\u003C\u002Fstep_1>\n\u003Cerrors>If gh fails, run gh auth login\u003C\u002Ferrors>\n```\n\u003C\u002Fcohesion>\n\u003C\u002Fstructure_and_clarity>\n\n\u003Cinformation_design>\n## Information Design\n\n\u003Cinformation_responsibility>\n### Responsibility Boundaries\n**What belongs in prompts vs. CLAUDE.md**:\n\n**CLAUDE.md** (project-level, always available):\n- Overall architecture and tech stack\n- File naming conventions (not just examples - actual rules)\n- Project-wide coding standards\n- Development workflows\n- Tool configurations\n\n**Prompts** (task-specific):\n- Task-specific rules and knowledge\n- Workflow for the specific responsibility\n- Error handling for this specific task\n- Task-specific constraints\n\n**Example**:\n- ❌ In agent: \"Check CONTRIBUTING.md or docs\u002Fcontributing.md for conventions\"\n  - Problem: Guessing file locations is noisy\n  - Solution: CLAUDE.md should document where conventions are\n- ✅ In agent: \"Follow project conventions for branch naming\"\n  - The agent trusts conventions are available in base context\n\u003C\u002Finformation_responsibility>\n\n\u003Cextended_thinking>\n### Extended Thinking Activation\n**Automatic activation via keywords**:\n- Use \"think harder\" for complex reasoning tasks\n- Use \"ultrathink\" for very deep analysis\n- Claude Code automatically enables extended thinking mode\n- No need to instruct `\u003Cthink>` tag usage\n\n**Example**:\n```markdown\nReview the code changes carefully. Think harder about potential edge cases and security implications.\n```\n\u003C\u002Fextended_thinking>\n\n\u003Cavoid_noise>\n### Avoid Noise\n**Common sources of noise**:\n- Multiple language examples (pick primary: Node.js > others for most projects)\n- Hypothetical file paths without project confirmation (CONTRIBUTING.md, ARCHITECTURE.md)\n- Generic architectural patterns (should be in CLAUDE.md if relevant)\n- Detailed procedures the LLM can infer\n\n**Example of noisy content** (avoid):\n```markdown\nInstall dependencies:\n- Node.js: npm install OR yarn install OR pnpm install\n- Python: pip install -r requirements.txt OR poetry install\n- Ruby: bundle install\n- Go: go mod download\n```\n\n**Better** (concise):\n```markdown\nInstall dependencies using project's package manager (detected from lock files).\n```\n\u003C\u002Favoid_noise>\n\u003C\u002Finformation_design>\n\n\u003Clanguage_and_format>\n## Language and Format\n\n\u003Clanguage_rule>\n### Language Usage Rules\n- **Prompt body**: Write in English (for context efficiency)\n- **`description` field (commands\u002Fagents)**: Match repository's primary language\n  - Japanese project → Japanese\n  - English project → English\n\u003C\u002Flanguage_rule>\n\n\u003Cformat_rules>\n### Format Rules\n- **No h1 headings**: Never start with h1 (`#`) title\n- Start prompt content immediately after front matter\n- Specify appropriate language for code blocks\n\u003C\u002Fformat_rules>\n\u003C\u002Flanguage_and_format>\n\n\u003Cvalidation_checklist>\n## Validation Checklist\n\nVerify before creation\u002Fupdate:\n\n**For all prompt types**:\n- [ ] Does not start with h1 heading (`#`)\n- [ ] XML tags are properly closed (matching pairs)\n- [ ] Prompt body is written in English (for context efficiency)\n- [ ] Error handling is defined for expected failure cases\n- [ ] **Single responsibility**: Prompt has one clear purpose\n- [ ] **Caller independent**: No references to \"orchestrator\", \"parent\", calling context\n- [ ] **Concise**: Only essential information included (typically 100-150 lines for agents)\n- [ ] **No noise**: Removed redundant examples, hypothetical paths, generic patterns\n\n**For commands** (`.claude\u002Fcommands\u002F*.md`):\n- [ ] Front matter includes `description` field\n- [ ] `allowed-tools` is defined with correct syntax (optional but recommended)\n\n**For agents** (`.claude\u002Fagents\u002F*.md`):\n- [ ] Front matter includes `name`, `description`, `model`, `color`\n- [ ] `name` field matches filename (without .md extension)\n- [ ] Appropriate model selected (`sonnet` for complex tasks, `haiku` for speed, `inherit` for caller's model)\n- [ ] `skills` field used for always-required skills (no manual \"Enable X skill\" in body)\n- [ ] No \"invocation_context\" or similar caller-specific sections\n\n**For orchestrator prompts** (commands\u002Fagents that invoke subagents):\n- [ ] Includes explicit invocation templates for all subagents used\n- [ ] Templates show complete Task tool usage with all parameters\n- [ ] Task-specific context is in templates, not duplicated in subagent prompts\n- [ ] No orchestration workflow details passed to subagents (violates caller independence)\n- [ ] Subagents are kept generic and reusable within their domain\n\n**For documents** (custom paths):\n- [ ] No front matter included (entire content is prompt)\n- [ ] Location\u002Fpath is clearly specified in user instructions\n\n**For context files** (CLAUDE.md, AGENTS.md, GEMINI.md, etc.):\n- [ ] No front matter included (entire content is context)\n- [ ] **80% rule**: Every piece of information is needed in 80% of tasks\n- [ ] **Index-first**: Direct content minimized, pointers to detailed docs used instead\n- [ ] **Abstract\u002Fnavigational**: Provides materials to find information, not exhaustive details\n- [ ] **Command scrutiny**: Only commands LLM autonomously runs in typical tasks\n- [ ] No step-by-step procedures (e.g., \"1. Install, 2. Setup, 3. Run...\")\n- [ ] No user-facing workflows (e.g., \"Start dev server and open browser\")\n- [ ] Extremely concise (typically \u003C100 lines for project context)\n\u003C\u002Fvalidation_checklist>\n\n\u003Canti_patterns>\n## Common Anti-Patterns to Avoid\n\n**❌ Caller coupling**:\n```markdown\nYou are invoked by the orchestrator with a task document at `.cc-delegate\u002Ftasks\u002F\u003Cid>.md`.\nRead the task document to understand...\n```\n\n**✅ Caller independence**:\n```markdown\nDesign an implementation approach based on the provided requirements and context.\n```\n\n---\n\n**❌ Multiple responsibilities**:\n```markdown\nAgent: setup-and-implement\n- Create branch\n- Install dependencies\n- Implement feature\n- Run tests\n- Create PR\n```\n\n**✅ Single responsibility**:\n```markdown\nAgent: implement-feature\n- Focus solely on implementation\n- Assume environment is ready\n- Produce working code with tests\n```\n\n---\n\n**❌ Noise and redundancy**:\n```markdown\nInstall dependencies:\n- pnpm-lock.yaml exists → run pnpm install\n- package-lock.json exists → run npm install\n- yarn.lock exists → run yarn install\n- Pipfile exists → run pipenv install\n- requirements.txt exists → run pip install\n```\n\n**✅ Concise abstraction**:\n```markdown\nInstall dependencies using detected package manager (from lock file).\n```\n\n---\n\n**❌ Hypothetical file paths**:\n```markdown\nCheck CONTRIBUTING.md, CONTRIBUTING.txt, docs\u002FCONTRIBUTING.md,\ndocs\u002Fcontributing.md, or DEVELOPMENT.md for conventions.\n```\n\n**✅ Trust base context**:\n```markdown\nFollow project conventions (documented in base context).\n```\n\n---\n\n**❌ Context file with exhaustive details**:\n```markdown\n# CLAUDE.md\n\n## Coding Style\n- Variables: camelCase (e.g., userName, itemCount)\n- Types: PascalCase (e.g., UserProfile, ItemList)\n- Files: kebab-case (e.g., user-profile.ts, item-list.tsx)\n- Constants: UPPER_SNAKE_CASE (e.g., API_URL, MAX_ITEMS)\n- Functions: camelCase with verb prefix (e.g., getUserName, calculateTotal)\n...\n[50 more lines of coding style]\n```\n\n**✅ Context file with index**:\n```markdown\n# CLAUDE.md\n\n## Coding Style\nSee docs\u002Fcoding-style.md for naming conventions and formatting rules.\n\n## Critical: Never modify src\u002Fgenerated\u002F* (auto-generated)\n```\n\n---\n\n**❌ Context file with user-facing workflows**:\n```markdown\n## Development Setup\n1. Install dependencies: `pnpm install`\n2. Start database: `docker-compose up db`\n3. Run migrations: `pnpm db:migrate`\n4. Start dev server: `pnpm dev`\n5. Open http:\u002F\u002Flocalhost:3000 in your browser\n```\n\n**✅ Context file with LLM-relevant info**:\n```markdown\n## Development\n- Package manager: pnpm (workspaces enabled)\n- Database migrations: alembic (db\u002Fmigrations\u002F)\n- Build: `pnpm build`, Test: `pnpm test`\n```\n\u003C\u002Fanti_patterns>\n","\u003Cclaude_code_prompts>\n## Claude Code Prompt Types\n\n\u003Ccommand_type>\n### 1. Commands\n**Purpose**: Reusable instruction presets invoked by users with `\u002Fcommand-name [args]`\n\n**Structure**:\n- **Location**: `.claude\u002Fcommands\u002F\u003Ccommand-name>.md`\n- **Invocation**: `\u002Fcommand-name [additional instructions]`\n- **Processing**: Front matter excluded; body content passed as instructions\n\n**Front Matter**:\n```yaml\n---\ndescription: 'Brief description (required, \u003C80 chars, repository's primary language)'\nallowed-tools: Bash(git, gh), Read(*), Edit(*.ts), Grep  # optional but recommended\n---\n```\n\n**allowed-tools formats**: `ToolName(*)`, `Bash(git)`, `Bash(git, gh)`, `Edit(*.ts)`, `Write`\n- Multiple tools: comma+space separated\n- Default-allowed tools (can omit): `TodoWrite`, `Task`, `Glob`, `Grep`, `Read`\n\n**Audience**: `description` → user (project language); body → LLM worker (English)\n\u003C\u002Fcommand_type>\n\n\u003Cagent_type>\n### 2. Agents\n**Purpose**: Specialized sub-agents invoked via Task tool or `@agent-name`\n\n**Structure**:\n- **Location**: `.claude\u002Fagents\u002F\u003Cagent-name>.md`\n- **Invocation**: `@agent-name [instructions]` or `Task(subagent_type=\"agent-name\", ...)`\n- **Processing**: Front matter excluded; body content passed as instructions\n\n**Front Matter**:\n```yaml\n---\nname: agent-name  # must match filename without .md\ndescription: 'Brief agent description'\nmodel: sonnet  # or haiku, or inherit (use caller's model)\ncolor: cyan    # terminal display color\nskills:        # optional: auto-load skills when agent starts\n  - typescript\n  - react\n---\n```\n\n**skills field**:\n- Skills listed here are automatically loaded when the agent is invoked\n- No need for manual `Skill(...)` calls or \"Enable the X skill\" instructions in body\n- Use this for skills the agent ALWAYS needs (not conditionally)\n- For dynamic\u002Fconditional skill loading, use `Skill(...)` tool in the prompt body\n\n**Audience**: Both caller (orchestrator LLM) and executor (sub-agent LLM) are LLMs\n- Always English\n- No orchestrator concerns (when to invoke, what to do with output)\n- Focus on capability grant and input\u002Foutput contract\n\u003C\u002Fagent_type>\n\n\u003Cskill_type>\n### 3. Skills\n**Purpose**: Reusable knowledge\u002Fguidelines loaded into sessions\n\n**Structure**:\n- **Location**: `.claude\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`\n- **Invocation**: Skill tool or auto-loaded based on description\n- **Processing**: Front matter excluded; body injected into context\n\n**Front Matter**:\n```yaml\n---\nname: skill-name  # must match directory name\ndescription: 'When this skill should be enabled'\n---\n```\n\n**Audience**: Any LLM (main session, orchestrator, or sub-agent)\n- Grant knowledge\u002Fcapability, not orchestrate workflows\n- Principles, best practices, rules (not \"first do X, then Y\")\n- Reproducible, interpretation-stable content\n\u003C\u002Fskill_type>\n\n\u003Cdocument_type>\n### 4. Documents\n**Purpose**: Standalone prompts not tied to command\u002Fagent system\n\n**Structure**:\n- **Location**: User-specified (e.g., `docs\u002Fprompts\u002F\u003Cname>.md`)\n- **Invocation**: Manual reference or inclusion\n- **Processing**: No front matter; entire content is the prompt\n\u003C\u002Fdocument_type>\n\n\u003Ccontext_files>\n### 5. Context Files (CLAUDE.md, GEMINI.md, AGENTS.md, etc.)\n**Purpose**: Project-wide or global context that is automatically loaded in every session\n\n**File Structure**:\n- **Location**:\n  - Project: `.claude\u002FCLAUDE.md`, `.gemini\u002FGEMINI.md`, `.claude\u002FAGENTS.md`\n  - Global: `~\u002F.claude\u002FCLAUDE.md`, `~\u002F.gemini\u002FGEMINI.md`, `~\u002F.claude\u002FAGENTS.md`\n- **Processing**: Entire content is injected into every session's base context\n- **No front matter**: Write content directly\n\n**Critical Characteristics**:\n- **Always loaded**: Read in every single session, regardless of task\n- **Maximum cost**: Context tokens consumed in every interaction\n- **Minimum content**: Only include what 80% of tasks need\n\n**IMPORTANT**: These are guidelines, not absolute rules. Some projects have unique contexts that justify exceptions. Use judgment, but default to minimalism when uncertain.\n\n**Content Principles**:\n\n1. **Index-first**: Pointers to detailed docs, not exhaustive content\n   - ❌ \"Use camelCase for variables, PascalCase for types...\"\n   - ✅ \"Coding conventions: docs\u002Fcoding-style.md\"\n   - Use direct content only if: cannot be discovered, critically affects every task, extremely concise (1-2 lines)\n\n2. **80% rule**: Only information needed in 80% of tasks\n   - ✅ Repository structure, key conventions, critical constraints\n   - ❌ Deployment procedures, testing strategies, specific library usage\n\n3. **Abstract\u002Fnavigational**: Materials to find information, not exhaustive details\n   - ✅ \"Database: alembic files in db\u002Fmigrations\u002F\"\n   - ❌ \"To create migration: alembic revision -m 'description'\"\n\n4. **Command scrutiny**: Only commands LLM runs autonomously in typical tasks\n   - ✅ `pnpm build`, `pnpm test` (LLM runs these)\n   - ❌ `pnpm dev`, `docker-compose up` (user runs these)\n\n**Good example**:\n```markdown\n# Project Context\n## Architecture\n- Monorepo: pnpm workspaces\n- API: packages\u002Fapi (NestJS), Frontend: packages\u002Fweb (Next.js)\n- Details: docs\u002Farchitecture\u002FREADME.md\n\n## Key Conventions\n- Branch naming: feature\u002F*, bugfix\u002F* (docs\u002Fgit-workflow.md)\n- Never modify: src\u002Fgenerated\u002F* (auto-generated)\n- Testing: Vitest\u002FPlaywright (docs\u002Ftesting.md)\n\n## Critical Constraints\n- Database changes require migration (alembic)\n- Public API changes require version bump (semver)\n```\n\n**Bad example** (avoid):\n```markdown\n# Project Setup\n## Installation\n1. Install dependencies: `pnpm install`\n2. Set up database: `pnpm db:setup`\n...\n[Detailed step-by-step procedures, exhaustive architecture details...]\n```\n\u003C\u002Fcontext_files>\n\u003C\u002Fclaude_code_prompts>\n\n\u003Ccore_principles>\n## Core Principles\n\n\u003Csingle_responsibility>\n### Single Responsibility Principle\n**Like functions in programming - one clear purpose**:\n- Each prompt (especially agents) should have one well-defined responsibility\n- Avoid mixing multiple concerns (e.g., don't mix \"setup environment\" with \"implement code\")\n- Clear boundaries make prompts composable and maintainable\n\n**Example**:\n- ✅ Agent A: Environment setup only\n- ✅ Agent B: Code implementation only\n- ❌ Agent C: Setup, implement, review, and deploy (too many responsibilities)\n\u003C\u002Fsingle_responsibility>\n\n\u003Ccaller_independence>\n### Caller Independence\n**Prompts should not know about their caller's context**:\n- Don't reference \"orchestrator\", \"parent task\", or calling patterns\n- Focus on: \"What do I receive?\" and \"What do I produce?\"\n- Users and other agents should be able to invoke the same prompt\n- Maximize reusability by keeping prompts context-free\n\n**Avoid**:\n- ❌ \"You are invoked by the orchestrator with a task document path...\"\n- ❌ \"After completion, report back to the orchestrator...\"\n- ❌ \"Read the task document to understand what the parent wants...\"\n\n**Prefer**:\n- ✅ \"Analyze the provided code and identify issues...\"\n- ✅ \"Based on the instructions, design an implementation approach...\"\n\u003C\u002Fcaller_independence>\n\n\u003Cconciseness>\n### Conciseness and Clarity\n**Think harder about what's essential**:\n- Include only necessary information for execution\n- Remove redundant explanations\n- Focus on rules and knowledge, not procedures\n\n**Red flags**:\n- Detailed step-by-step procedures (trust the LLM)\n- Repetitive examples for multiple languages (choose primary language)\n- User-facing instructions (description field handles this)\n- Implementation details that should be in CLAUDE.md\n\u003C\u002Fconciseness>\n\n\u003Corchestration_patterns>\n### Orchestration Patterns\n**When designing prompts for orchestrated workflows with subagents**:\n\n\u003Cprompt_templates>\n#### Use Prompt Templates for Subagent Invocation\n**CRITICAL REQUIREMENT: Orchestrators MUST provide explicit invocation templates**:\n- Include complete prompt templates showing how to invoke subagents with all parameters\n- Templates are NOT optional—they are essential for stable, reproducible orchestration\n- Keep summaries minimal; let templates convey specifics through concrete examples\n- Templates ensure consistency across multiple invocations and make maintenance easier\n\n**Why templates are essential**:\n1. **Consistency**: Same invocation pattern every time, reducing variability\n2. **Reproducibility**: Future maintainers can see exact invocation structure\n3. **Clarity**: Makes the orchestration contract explicit, not implicit\n4. **Maintainability**: Single source of truth for how subagents should be invoked\n5. **Discoverability**: New users can understand the pattern immediately\n\n**Without templates** (❌ Bad):\n```markdown\nInvoke the engineer agent to implement the feature.\n```\n**Problem**: Orchestrator must guess parameter structure, leading to inconsistent invocations\n\n**With templates** (✅ Good):\n```markdown\n## Invoking the Implementation Agent\n\nUse this template:\n\nTask(\n  subagent_type=\"engineer\",\n  prompt=\"\"\"\nImplement the following feature:\n{feature_description}\n\nRequirements:\n{requirements}\n\nAcceptance criteria:\n{acceptance_criteria}\n\nFollow project conventions and include tests.\n\"\"\",\n  description=\"Implement {feature_name}\"\n)\n```\n\u003C\u002Fprompt_templates>\n\n\u003Cresponsibility_split>\n#### Split Responsibilities Between Orchestrator and Subagent\n\n**Design principle**: Subagents are single-purpose but reusable across many tasks. Task-specific context belongs in the orchestrator's template; responsibility-specific practices belong in the subagent.\n\n**Subagent prompt** (responsibility-specific, reusable):\n- Core practices always needed for this responsibility\n- Domain-specific knowledge and constraints\n- General workflow for this type of task\n- Error handling patterns for this domain\n- Quality standards for this responsibility\n\n**Orchestrator's invocation template** (task-specific, contextual):\n- Current task context and background\n- Task-specific rules and constraints\n- Specific focus areas or priorities for this task\n- Integration requirements with other workflow steps\n- Project-specific constraints not universally applicable\n\n**Example - Code Review Agent**:\n\nSubagent prompt (`.claude\u002Fagents\u002Freviewer.md`):\n```markdown\nReview code changes for quality and correctness.\n\nCheck for:\n- Type safety and correctness\n- Security vulnerabilities\n- Performance issues\n- Code style consistency\n- Test coverage adequacy\n\nReport issues with:\n- Severity level (critical\u002Fmoderate\u002Fminor)\n- File path and line numbers\n- Specific recommendations\n- Priority order (critical first)\n```\n\nOrchestrator's template:\n```markdown\nTask(\n  subagent_type=\"reviewer\",\n  prompt=\"\"\"\nReview the authentication feature implementation.\n\nContext: Healthcare application handling PHI data under HIPAA.\n\nAdditional requirements for this review:\n- HIPAA compliance is critical (report violations as critical)\n- All database queries must use parameterized statements\n- Session tokens must expire within 15 minutes\n- Password hashing must use bcrypt with cost factor ≥12\n\nFiles to review: src\u002Fauth\u002F*.ts\n\nFocus on security and compliance issues.\n\"\"\",\n  description=\"Review auth implementation\"\n)\n```\n\u003C\u002Fresponsibility_split>\n\n\u003Cdesign_questions>\n#### Design Questions for Responsibility Split\n\nWhen designing orchestrated prompts, ask these questions:\n\n**Should this go in the subagent prompt?**\n- Is this practice always required for this type of task?\n- Does this define the agent's core responsibility?\n- Would this agent need this knowledge for ANY task it handles?\n- Is this domain-specific expertise for this responsibility?\n→ **YES**: Include in subagent prompt\n\n**Should this go in the orchestrator's template?**\n- Is this specific to the current task or project?\n- Does this depend on previous steps in the workflow?\n- Is this a temporary constraint or priority?\n- Does this require context from the orchestration flow?\n→ **YES**: Include in invocation template\n\n**Examples**:\n- ✅ Subagent: \"Check for type errors and unused variables\"\n- ✅ Orchestrator: \"Focus on the payment module we refactored in the previous step\"\n- ✅ Subagent: \"Report security vulnerabilities with severity levels\"\n- ✅ Orchestrator: \"This handles credit card data—PCI-DSS compliance is critical\"\n- ✅ Subagent: \"Include test coverage for new functionality\"\n- ✅ Orchestrator: \"We're under tight deadline—prioritize happy path tests\"\n\u003C\u002Fdesign_questions>\n\n\u003Cbenefits>\n#### Benefits of This Approach\n\n**Reusability**: Subagents work across different tasks and projects without modification\n\n**Maintainability**: Task-specific logic lives in one place (orchestrator), not scattered across agent prompts\n\n**Clarity**: Clear separation makes it obvious what's universal vs. contextual\n\n**Consistency**: Templates ensure subagents receive consistent, well-formed instructions\n\n**Testability**: Subagents can be tested independently with different invocation parameters\n\u003C\u002Fbenefits>\n\n\u003Corchestration_anti_patterns>\n#### Common Anti-Patterns in Orchestration\n\n**❌ Duplicating logic across orchestrator and subagent**:\n```markdown\n# Subagent prompt\n- Follow project coding conventions\n- Use TypeScript strict mode\n- Never commit secrets\n\n# Orchestrator template\nTask(prompt=\"\"\"\nFollow project coding conventions.\nUse TypeScript strict mode.\nNever commit secrets.\nImplement feature X...\n\"\"\")\n```\n**Problem**: Maintenance burden, inconsistency risk\n\n**✅ Keep domain practices in subagent only**:\n```markdown\n# Subagent prompt\n- Follow project coding conventions\n- Use TypeScript strict mode\n- Never commit secrets\n\n# Orchestrator template\nTask(prompt=\"\"\"\nImplement feature X with focus on payment processing logic.\nEnsure PCI-DSS compliance for card data handling.\n\"\"\")\n```\n\n---\n\n**❌ Making subagents too task-specific**:\n```markdown\nname: implement-user-authentication-with-jwt-and-oauth\n```\n**Problem**: Not reusable, violates single responsibility\n\n**✅ Keep subagents generic within their domain**:\n```markdown\nname: engineer\n# Orchestrator specifies: \"Implement user authentication using JWT and OAuth\"\n```\n\n---\n\n**❌ Passing orchestration context to subagents**:\n```markdown\nTask(prompt=\"\"\"\nThis is step 3 of 5 in the workflow.\nAfter you finish, I will invoke the testing agent.\nThe architect agent already designed this in step 1.\n\"\"\")\n```\n**Problem**: Violates caller independence, adds unnecessary context\n\n**✅ Provide only task-relevant information**:\n```markdown\nTask(prompt=\"\"\"\nImplement the authentication feature.\nArchitecture decisions: See attached design document.\nFocus on token generation and validation logic.\n\"\"\")\n```\n\u003C\u002Forchestration_anti_patterns>\n\n\u003Corchestration_considerations>\n#### Additional Considerations\n\n**Failure Handling**:\n- Orchestrators should handle subagent failures gracefully\n- Define retry strategies for critical tasks\n- Provide clear error reporting from subagents back to orchestrators\n- Consider fallback strategies for non-critical failures\n\n**Template Maintenance**:\n- Keep invocation templates in one location for easy updates\n- When subagent prompts change, review all orchestrator templates\n- Document expected inputs\u002Foutputs for each subagent\n\u003C\u002Forchestration_considerations>\n\u003C\u002Forchestration_patterns>\n\u003C\u002Fcore_principles>\n\n\u003Cstructure_and_clarity>\n## Structure and Clarity\n\n\u003Cxml_tags>\n### XML Tag Utilization\nStructure prompts with XML tags when multiple sections or concepts exist:\n- **Recommended tags**: `\u003Crole>`, `\u003Cscope>`, `\u003Cprinciples>`, `\u003Cerror_handling>`, `\u003Cworkflow>`\n- **Attribute usage**: `\u003Cstep_1 name=\"descriptive_name\">`, `\u003Cexample type=\"good\">`\n- **Effect**: Clear instruction boundaries improve LLM comprehension accuracy\n\u003C\u002Fxml_tags>\n\n\u003Cspecificity>\n### Instruction Specificity\n- Eliminate ambiguity with concrete, non-contradictory instructions\n- Include only verified, tested commands\n- Explicitly define conditional logic and error handling\n\u003C\u002Fspecificity>\n\n\u003Ccohesion>\n### Cohesion Optimization\nGroup related instructions, rules, and constraints within the same section.\n\n**High cohesion example**:\n```xml\n\u003Cworkflow>\n## Basic Flow\n\n**1. Check prerequisites**:\n- Verify git repository exists\n- Confirm gh CLI is authenticated\n- Error if not: Run `gh auth login`\n\n**2. Proceed with task**:\n...\n\u003C\u002Fworkflow>\n```\n\n**Low cohesion example** (avoid):\n```xml\n\u003Cprerequisites>Verify git repository\u003C\u002Fprerequisites>\n\u003Cstep_1>Check authentication\u003C\u002Fstep_1>\n\u003Cerrors>If gh fails, run gh auth login\u003C\u002Ferrors>\n```\n\u003C\u002Fcohesion>\n\u003C\u002Fstructure_and_clarity>\n\n\u003Cinformation_design>\n## Information Design\n\n\u003Cinformation_responsibility>\n### Responsibility Boundaries\n**What belongs in prompts vs. CLAUDE.md**:\n\n**CLAUDE.md** (project-level, always available):\n- Overall architecture and tech stack\n- File naming conventions (not just examples - actual rules)\n- Project-wide coding standards\n- Development workflows\n- Tool configurations\n\n**Prompts** (task-specific):\n- Task-specific rules and knowledge\n- Workflow for the specific responsibility\n- Error handling for this specific task\n- Task-specific constraints\n\n**Example**:\n- ❌ In agent: \"Check CONTRIBUTING.md or docs\u002Fcontributing.md for conventions\"\n  - Problem: Guessing file locations is noisy\n  - Solution: CLAUDE.md should document where conventions are\n- ✅ In agent: \"Follow project conventions for branch naming\"\n  - The agent trusts conventions are available in base context\n\u003C\u002Finformation_responsibility>\n\n\u003Cextended_thinking>\n### Extended Thinking Activation\n**Automatic activation via keywords**:\n- Use \"think harder\" for complex reasoning tasks\n- Use \"ultrathink\" for very deep analysis\n- Claude Code automatically enables extended thinking mode\n- No need to instruct `\u003Cthink>` tag usage\n\n**Example**:\n```markdown\nReview the code changes carefully. Think harder about potential edge cases and security implications.\n```\n\u003C\u002Fextended_thinking>\n\n\u003Cavoid_noise>\n### Avoid Noise\n**Common sources of noise**:\n- Multiple language examples (pick primary: Node.js > others for most projects)\n- Hypothetical file paths without project confirmation (CONTRIBUTING.md, ARCHITECTURE.md)\n- Generic architectural patterns (should be in CLAUDE.md if relevant)\n- Detailed procedures the LLM can infer\n\n**Example of noisy content** (avoid):\n```markdown\nInstall dependencies:\n- Node.js: npm install OR yarn install OR pnpm install\n- Python: pip install -r requirements.txt OR poetry install\n- Ruby: bundle install\n- Go: go mod download\n```\n\n**Better** (concise):\n```markdown\nInstall dependencies using project's package manager (detected from lock files).\n```\n\u003C\u002Favoid_noise>\n\u003C\u002Finformation_design>\n\n\u003Clanguage_and_format>\n## Language and Format\n\n\u003Clanguage_rule>\n### Language Usage Rules\n- **Prompt body**: Write in English (for context efficiency)\n- **`description` field (commands\u002Fagents)**: Match repository's primary language\n  - Japanese project → Japanese\n  - English project → English\n\u003C\u002Flanguage_rule>\n\n\u003Cformat_rules>\n### Format Rules\n- **No h1 headings**: Never start with h1 (`#`) title\n- Start prompt content immediately after front matter\n- Specify appropriate language for code blocks\n\u003C\u002Fformat_rules>\n\u003C\u002Flanguage_and_format>\n\n\u003Cvalidation_checklist>\n## Validation Checklist\n\nVerify before creation\u002Fupdate:\n\n**For all prompt types**:\n- [ ] Does not start with h1 heading (`#`)\n- [ ] XML tags are properly closed (matching pairs)\n- [ ] Prompt body is written in English (for context efficiency)\n- [ ] Error handling is defined for expected failure cases\n- [ ] **Single responsibility**: Prompt has one clear purpose\n- [ ] **Caller independent**: No references to \"orchestrator\", \"parent\", calling context\n- [ ] **Concise**: Only essential information included (typically 100-150 lines for agents)\n- [ ] **No noise**: Removed redundant examples, hypothetical paths, generic patterns\n\n**For commands** (`.claude\u002Fcommands\u002F*.md`):\n- [ ] Front matter includes `description` field\n- [ ] `allowed-tools` is defined with correct syntax (optional but recommended)\n\n**For agents** (`.claude\u002Fagents\u002F*.md`):\n- [ ] Front matter includes `name`, `description`, `model`, `color`\n- [ ] `name` field matches filename (without .md extension)\n- [ ] Appropriate model selected (`sonnet` for complex tasks, `haiku` for speed, `inherit` for caller's model)\n- [ ] `skills` field used for always-required skills (no manual \"Enable X skill\" in body)\n- [ ] No \"invocation_context\" or similar caller-specific sections\n\n**For orchestrator prompts** (commands\u002Fagents that invoke subagents):\n- [ ] Includes explicit invocation templates for all subagents used\n- [ ] Templates show complete Task tool usage with all parameters\n- [ ] Task-specific context is in templates, not duplicated in subagent prompts\n- [ ] No orchestration workflow details passed to subagents (violates caller independence)\n- [ ] Subagents are kept generic and reusable within their domain\n\n**For documents** (custom paths):\n- [ ] No front matter included (entire content is prompt)\n- [ ] Location\u002Fpath is clearly specified in user instructions\n\n**For context files** (CLAUDE.md, AGENTS.md, GEMINI.md, etc.):\n- [ ] No front matter included (entire content is context)\n- [ ] **80% rule**: Every piece of information is needed in 80% of tasks\n- [ ] **Index-first**: Direct content minimized, pointers to detailed docs used instead\n- [ ] **Abstract\u002Fnavigational**: Provides materials to find information, not exhaustive details\n- [ ] **Command scrutiny**: Only commands LLM autonomously runs in typical tasks\n- [ ] No step-by-step procedures (e.g., \"1. Install, 2. Setup, 3. Run...\")\n- [ ] No user-facing workflows (e.g., \"Start dev server and open browser\")\n- [ ] Extremely concise (typically \u003C100 lines for project context)\n\u003C\u002Fvalidation_checklist>\n\n\u003Canti_patterns>\n## Common Anti-Patterns to Avoid\n\n**❌ Caller coupling**:\n```markdown\nYou are invoked by the orchestrator with a task document at `.cc-delegate\u002Ftasks\u002F\u003Cid>.md`.\nRead the task document to understand...\n```\n\n**✅ Caller independence**:\n```markdown\nDesign an implementation approach based on the provided requirements and context.\n```\n\n---\n\n**❌ Multiple responsibilities**:\n```markdown\nAgent: setup-and-implement\n- Create branch\n- Install dependencies\n- Implement feature\n- Run tests\n- Create PR\n```\n\n**✅ Single responsibility**:\n```markdown\nAgent: implement-feature\n- Focus solely on implementation\n- Assume environment is ready\n- Produce working code with tests\n```\n\n---\n\n**❌ Noise and redundancy**:\n```markdown\nInstall dependencies:\n- pnpm-lock.yaml exists → run pnpm install\n- package-lock.json exists → run npm install\n- yarn.lock exists → run yarn install\n- Pipfile exists → run pipenv install\n- requirements.txt exists → run pip install\n```\n\n**✅ Concise abstraction**:\n```markdown\nInstall dependencies using detected package manager (from lock file).\n```\n\n---\n\n**❌ Hypothetical file paths**:\n```markdown\nCheck CONTRIBUTING.md, CONTRIBUTING.txt, docs\u002FCONTRIBUTING.md,\ndocs\u002Fcontributing.md, or DEVELOPMENT.md for conventions.\n```\n\n**✅ Trust base context**:\n```markdown\nFollow project conventions (documented in base context).\n```\n\n---\n\n**❌ Context file with exhaustive details**:\n```markdown\n# CLAUDE.md\n\n## Coding Style\n- Variables: camelCase (e.g., userName, itemCount)\n- Types: PascalCase (e.g., UserProfile, ItemList)\n- Files: kebab-case (e.g., user-profile.ts, item-list.tsx)\n- Constants: UPPER_SNAKE_CASE (e.g., API_URL, MAX_ITEMS)\n- Functions: camelCase with verb prefix (e.g., getUserName, calculateTotal)\n...\n[50 more lines of coding style]\n```\n\n**✅ Context file with index**:\n```markdown\n# CLAUDE.md\n\n## Coding Style\nSee docs\u002Fcoding-style.md for naming conventions and formatting rules.\n\n## Critical: Never modify src\u002Fgenerated\u002F* (auto-generated)\n```\n\n---\n\n**❌ Context file with user-facing workflows**:\n```markdown\n## Development Setup\n1. Install dependencies: `pnpm install`\n2. Start database: `docker-compose up db`\n3. Run migrations: `pnpm db:migrate`\n4. Start dev server: `pnpm dev`\n5. Open http:\u002F\u002Flocalhost:3000 in your browser\n```\n\n**✅ Context file with LLM-relevant info**:\n```markdown\n## Development\n- Package manager: pnpm (workspaces enabled)\n- Database migrations: alembic (db\u002Fmigrations\u002F)\n- Build: `pnpm build`, Test: `pnpm test`\n```\n\u003C\u002Fanti_patterns>\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Fclaude-code\u002Fskills\u002Fprompt-engineering",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill prompt-engineering",{"tool":60,"command":61},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill prompt-engineering",{"tool":63,"command":64},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill prompt-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fclaude-code\u002Fskills\u002Fprompt-engineering\u002FSKILL.md",true,[],[69,86,113,140,162,182],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":78,"publishedAt":39},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[79,80,81,82,83,84,85],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":94,"publishedAt":39},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[92,93],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[88,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,32,111,112],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","unknown","generated",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":123,"publishedAt":39},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[119,120],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[115,124,125,126,127,128,129,130,103,131,132,133,134,135,136,137,138,139],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","when","use","auto","types","Video","创作",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":147,"publishedAt":39},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[146],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[148,149,115,150,151,138,152,153,154,155,156,157,158,159,101,160,134,135,95,161],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":39},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[168,169,170,171],{"categoryNo":76,"categoryName":77,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},[173,84,174,175,176,177,32,134,135,178,179,180,181],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":190,"publishedAt":39},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[188,189],{"categoryNo":76,"categoryName":77,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":121,"categoryName":122,"taxonomyType":26,"taxonomyTypeDesc":27},[191,84,192,99,193,179,134,174,177,135,180],"Rules","writing rules","project rules"]