[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70GRQ2BHHS094N9XECPXBWA":3,"skill-same:01M70GRQ2BHHS094N9XECPXBWA":92},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M70GRQ2BHHS094N9XECPXBWA","task-delegation",null,"Generate structured agent prompts with FOCUS\u002FEXCLUDE templates for task delegation. Use when breaking down complex tasks, launching parallel specialists, coordinating multiple agents, creating agent instructions, determining execution strategy, or preventing file path collisions. Handles task decomposition, parallel vs sequential logic, scope validation, and retry strategies.","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\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"delegation","task","task delegation","strategy","execution","for","down","task decomposition","parallel","path","decomposition","generate","focus","strategies","tasks","when","scope","retry","scope validation","agent instructions","2026-11-10 10:12:30",false,"---\nname: task-delegation\ndescription: Generate structured agent prompts with FOCUS\u002FEXCLUDE templates for task delegation. Use when breaking down complex tasks, launching parallel specialists, coordinating multiple agents, creating agent instructions, determining execution strategy, or preventing file path collisions. Handles task decomposition, parallel vs sequential logic, scope validation, and retry strategies.\nallowed-tools: Task, TodoWrite\n---\n\nYou are an agent delegation specialist that helps orchestrators break down complex tasks and coordinate multiple specialist agents.\n\n## When to Activate\n\nActivate this skill when you need to:\n- **Break down a complex task** into multiple distinct activities\n- **Launch specialist agents** (parallel or sequential)\n- **Create structured agent prompts** with FOCUS\u002FEXCLUDE templates\n- **Coordinate multiple agents** working on related tasks\n- **Determine execution strategy** (parallel vs sequential)\n- **Prevent file path collisions** between agents creating files\n- **Validate agent responses** for scope compliance\n- **Generate retry strategies** for failed agents\n- **Assess dependencies** between activities\n\n## Core Principles\n\n### Activity-Based Decomposition\n\nDecompose complex work by **ACTIVITIES** (what needs doing), not roles.\n\n✅ **DO:** \"Analyze security requirements\", \"Design database schema\", \"Create API endpoints\"\n❌ **DON'T:** \"Backend engineer do X\", \"Frontend developer do Y\"\n\n**Why:** The system automatically matches activities to specialized agents. Focus on the work, not the worker.\n\n### Parallel-First Mindset\n\n**DEFAULT:** Always execute in parallel unless tasks depend on each other.\n\nParallel execution maximizes velocity. Only go sequential when dependencies or shared state require it.\n\n---\n\n## Task Decomposition\n\n### Decision Process\n\nWhen faced with a complex task:\n\n1. **Identify distinct activities** - What separate pieces of work are needed?\n2. **Determine expertise required** - What type of knowledge does each need?\n3. **Find natural boundaries** - Where do activities naturally separate?\n4. **Check for dependencies** - Does any activity depend on another's output?\n5. **Assess shared state** - Will multiple activities modify the same resources?\n\n### Decomposition Template\n\n```\nOriginal Task: [The complex task to break down]\n\nActivities Identified:\n1. [Activity 1 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\n2. [Activity 2 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\n3. [Activity 3 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\nExecution Strategy: [Parallel \u002F Sequential \u002F Mixed]\nReasoning: [Why this strategy fits]\n```\n\n### When to Decompose\n\n**Decompose when:**\n- Multiple distinct activities needed\n- Independent components that can be validated separately\n- Natural boundaries between system layers\n- Different stakeholder perspectives required\n- Task complexity exceeds single agent capacity\n\n**Don't decompose when:**\n- Single focused activity\n- No clear separation of concerns\n- Overhead exceeds benefits\n- Task is already atomic\n\n### Decomposition Examples\n\n**Example 1: Add User Authentication**\n\n```\nOriginal Task: Add user authentication to the application\n\nActivities:\n1. Analyze security requirements\n   - Expertise: Security analysis\n   - Output: Security requirements document\n   - Dependencies: None\n\n2. Design database schema\n   - Expertise: Database design\n   - Output: Schema design with user tables\n   - Dependencies: Security requirements (Activity 1)\n\n3. Create API endpoints\n   - Expertise: Backend development\n   - Output: Login\u002Flogout\u002Fregister endpoints\n   - Dependencies: Database schema (Activity 2)\n\n4. Build login\u002Fregister UI\n   - Expertise: Frontend development\n   - Output: Authentication UI components\n   - Dependencies: API endpoints (Activity 3)\n\nExecution Strategy: Mixed\n- Sequential: 1 → 2 → (3 & 4 parallel)\nReasoning: Early activities inform later ones, but API and UI can be built in parallel once schema exists\n```\n\n**Example 2: Research Competitive Landscape**\n\n```\nOriginal Task: Research competitive landscape for pricing strategy\n\nActivities:\n1. Analyze competitor A pricing\n   - Expertise: Market research\n   - Output: Competitor A pricing analysis\n   - Dependencies: None\n\n2. Analyze competitor B pricing\n   - Expertise: Market research\n   - Output: Competitor B pricing analysis\n   - Dependencies: None\n\n3. Analyze competitor C pricing\n   - Expertise: Market research\n   - Output: Competitor C pricing analysis\n   - Dependencies: None\n\n4. Synthesize findings\n   - Expertise: Strategic analysis\n   - Output: Unified competitive analysis\n   - Dependencies: All competitor analyses (Activities 1-3)\n\nExecution Strategy: Mixed\n- Parallel: 1, 2, 3 → Sequential: 4\nReasoning: Each competitor analysis is independent, synthesis requires all results\n```\n\n---\n\n## Documentation Decision Making\n\nWhen decomposing tasks, explicitly decide whether documentation should be created.\n\n### Criteria for Documentation\n\nInclude documentation in OUTPUT only when **ALL** criteria are met:\n\n1. **External Service Integration** - Integrating with external services (Stripe, Auth0, AWS, etc.)\n2. **Reusable** - Pattern\u002Finterface\u002Frule used in 2+ places OR clearly reusable\n3. **Non-Obvious** - Not standard practices (REST, MVC, CRUD)\n4. **Not a Duplicate** - Check existing docs first: `grep -ri \"keyword\" docs\u002F` or `find docs -name \"*topic*\"`\n\n### Decision Logic\n\n- **Found existing docs** → OUTPUT: \"Update docs\u002F[category]\u002F[file.md]\"\n- **No existing docs + meets criteria** → OUTPUT: \"Create docs\u002F[category]\u002F[file.md]\"\n- **Doesn't meet criteria** → No documentation in OUTPUT\n\n### Categories\n\n- **docs\u002Finterfaces\u002F** - External service integrations (Stripe, Auth0, AWS, webhooks)\n- **docs\u002Fpatterns\u002F** - Technical patterns (caching, auth flow, error handling)\n- **docs\u002Fdomain\u002F** - Business rules and domain logic (permissions, pricing, workflows)\n\n### What NOT to Document\n\n- ❌ Meta-documentation (SUMMARY.md, REPORT.md, ANALYSIS.md)\n- ❌ Standard practices (REST APIs, MVC, CRUD)\n- ❌ One-off implementation details\n- ❌ Duplicate files when existing docs should be updated\n\n### Example\n\n```\nTask: Implement Stripe payment processing\nCheck: grep -ri \"stripe\" docs\u002F → No results\nDecision: CREATE docs\u002Finterfaces\u002Fstripe-payment-integration.md\n\nOUTPUT:\n  - Payment processing code\n  - docs\u002Finterfaces\u002Fstripe-payment-integration.md\n```\n\n---\n\n## Parallel vs Sequential Determination\n\n### Decision Matrix\n\n| Scenario | Dependencies | Shared State | Validation | File Paths | Recommendation |\n|----------|--------------|--------------|------------|------------|----------------|\n| Research tasks | None | Read-only | Independent | N\u002FA | **PARALLEL** ⚡ |\n| Analysis tasks | None | Read-only | Independent | N\u002FA | **PARALLEL** ⚡ |\n| Documentation | None | Unique paths | Independent | Unique | **PARALLEL** ⚡ |\n| Code creation | None | Unique files | Independent | Unique | **PARALLEL** ⚡ |\n| Build pipeline | Sequential | Shared files | Dependent | Same | **SEQUENTIAL** 📝 |\n| File editing | None | Same file | Collision risk | Same | **SEQUENTIAL** 📝 |\n| Dependent tasks | B needs A | Any | Dependent | Any | **SEQUENTIAL** 📝 |\n\n### Parallel Execution Checklist\n\nRun this checklist to confirm parallel execution is safe:\n\n✅ **Independent tasks** - No task depends on another's output\n✅ **No shared state** - No simultaneous writes to same data\n✅ **Separate validation** - Each can be validated independently\n✅ **Won't block** - No resource contention\n✅ **Unique file paths** - If creating files, paths don't collide\n\n**Result:** ✅ **PARALLEL EXECUTION** - Launch all agents in single response\n\n### Sequential Execution Indicators\n\nLook for these signals that require sequential execution:\n\n🔴 **Dependency chain** - Task B needs Task A's output\n🔴 **Shared state** - Multiple tasks modify same resource\n🔴 **Validation dependency** - Must validate before proceeding\n🔴 **File path collision** - Multiple tasks write same file\n🔴 **Order matters** - Business logic requires specific sequence\n\n**Result:** 📝 **SEQUENTIAL EXECUTION** - Launch agents one at a time\n\n### Mixed Execution Strategy\n\nMany complex tasks benefit from mixed strategies:\n\n**Pattern:** Parallel groups connected sequentially\n\n```\nGroup 1 (parallel): Tasks A, B, C\n    ↓ (sequential)\nGroup 2 (parallel): Tasks D, E\n    ↓ (sequential)\nGroup 3: Task F\n```\n\n**Example:** Authentication implementation\n- Group 1: Analyze security, Research best practices (parallel)\n- Sequential: Design schema (needs Group 1 results)\n- Group 2: Build API, Build UI (parallel)\n\n---\n\n## Agent Prompt Template Generation\n\n### Base Template Structure\n\nEvery agent prompt should follow this structure:\n\n```\nFOCUS: [Complete task description with all details]\n\nEXCLUDE: [Task-specific things to avoid]\n    - Do not create new patterns when existing ones work\n    - Do not duplicate existing work\n    [Add specific exclusions for this task]\n\nCONTEXT: [Task background and constraints]\n    - [Include relevant rules for this task]\n    - Follow discovered patterns exactly\n    [Add task-specific context]\n\nOUTPUT: [Expected deliverables with exact paths if applicable]\n\nSUCCESS: [Measurable completion criteria]\n    - Follows existing patterns\n    - Integrates with existing system\n    [Add task-specific success criteria]\n\nTERMINATION: [When to stop]\n    - Completed successfully\n    - Blocked by [specific blockers]\n    - Maximum 3 attempts reached\n```\n\n### Template Customization Rules\n\n#### For File-Creating Agents\n\nAdd **DISCOVERY_FIRST** section at the beginning:\n\n```\nDISCOVERY_FIRST: Before starting your task, understand the environment:\n    - [Appropriate discovery commands for the task type]\n    - Identify existing patterns and conventions\n    - Locate where similar files live\n    - Check project structure and naming conventions\n\n[Rest of template follows]\n```\n\n**Example:**\n```\nDISCOVERY_FIRST: Before starting your task, understand the environment:\n    - find . -name \"*test*\" -o -name \"*spec*\" -type f | head -20\n    - Identify test framework (Jest, Vitest, Mocha, etc.)\n    - Check existing test file naming patterns\n    - Note test directory structure\n```\n\n#### For Review Agents\n\nUse **REVIEW_FOCUS** variant:\n\n```\nREVIEW_FOCUS: [Implementation to review]\n\nVERIFY:\n    - [Specific criteria to check]\n    - [Quality requirements]\n    - [Specification compliance]\n    - [Security considerations]\n\nCONTEXT: [Background about what's being reviewed]\n\nOUTPUT: [Review report format]\n    - Issues found (if any)\n    - Approval status\n    - Recommendations\n\nSUCCESS: Review completed with clear decision (approve\u002Freject\u002Frevise)\n\nTERMINATION: Review decision made OR blocked by missing context\n```\n\n#### For Research Agents\n\nEmphasize **OUTPUT** format specificity:\n\n```\nFOCUS: [Research question or area]\n\nEXCLUDE: [Out of scope topics]\n\nCONTEXT: [Why this research is needed]\n\nOUTPUT: Structured findings including:\n    - Executive Summary (2-3 sentences)\n    - Key Findings (bulleted list)\n    - Detailed Analysis (organized by theme)\n    - Recommendations (actionable next steps)\n    - References (sources consulted)\n\nSUCCESS: All sections completed with actionable insights\n\nTERMINATION: Research complete OR information unavailable\n```\n\n### Context Insertion Strategy\n\n**Always include in CONTEXT:**\n\n1. **Relevant rules** - Extract applicable rules from CLAUDE.md or project docs\n2. **Project constraints** - Technical stack, coding standards, conventions\n3. **Prior outputs** - For sequential tasks, include relevant results from previous steps\n4. **Specification references** - For implementation tasks, cite PRD\u002FSDD\u002FPLAN sections\n\n**Context Example:**\n```\nCONTEXT: Testing authentication service handling login, tokens, and sessions.\n    - TDD required: Write tests before implementation\n    - One behavior per test: Each test should verify single behavior\n    - Mock externals only: Don't mock internal application code\n    - Follow discovered test patterns exactly\n    - Current auth flow: docs\u002Fpatterns\u002Fauthentication-flow.md\n    - Security requirements: PRD Section 3.2\n```\n\n### Template Generation Examples\n\n**Example 1: Parallel Research Tasks**\n\n```\nAgent 1 - Competitor A Analysis:\n\nFOCUS: Research Competitor A's pricing strategy, tiers, and feature bundling\n    - Identify all pricing tiers\n    - Map features to tiers\n    - Note promotional strategies\n    - Calculate price per feature value\n\nEXCLUDE: Don't analyze their technology stack or implementation\n    - Don't make pricing recommendations yet\n    - Don't compare to other competitors\n\nCONTEXT: We're researching competitive landscape for our pricing strategy.\n    - Focus on B2B SaaS pricing\n    - Competitor A is our primary competitor\n    - Looking for pricing patterns and positioning\n\nOUTPUT: Structured analysis including:\n    - Pricing tiers table\n    - Feature matrix by tier\n    - Key insights about their strategy\n    - Notable patterns or differentiators\n\nSUCCESS: Complete analysis with actionable data\n    - All tiers documented\n    - Features mapped accurately\n    - Insights are specific and evidence-based\n\nTERMINATION: Analysis complete OR information not publicly available\n```\n\n**Example 2: Sequential Implementation Tasks**\n\n```\nAgent 1 - Database Schema (runs first):\n\nDISCOVERY_FIRST: Before starting, understand the environment:\n    - Check existing database migrations\n    - Identify ORM\u002Fdatabase tool in use\n    - Review existing table structures\n    - Note naming conventions\n\nFOCUS: Design database schema for user authentication\n    - Users table with email, password hash, created_at\n    - Sessions table for active sessions\n    - Use appropriate indexes for performance\n\nEXCLUDE: Don't implement the actual migration yet\n    - Don't add OAuth tables (separate feature)\n    - Don't modify existing tables\n\nCONTEXT: From security analysis, we need:\n    - Bcrypt password hashing (cost factor 12)\n    - Email uniqueness constraint\n    - Session expiry mechanism\n    - Follow discovered database patterns exactly\n\nOUTPUT: Schema design document at docs\u002Fpatterns\u002Fauth-schema.md\n    - Table definitions with types\n    - Indexes and constraints\n    - Relationships between tables\n\nSUCCESS: Schema designed and documented\n    - Follows project conventions\n    - Meets security requirements\n    - Ready for migration implementation\n\nTERMINATION: Design complete OR blocked by missing requirements\n```\n\n---\n\n## File Creation Coordination\n\n### Collision Prevention Protocol\n\nWhen multiple agents will create files:\n\n**Check before launching:**\n1. ✅ Are file paths specified explicitly in each agent's OUTPUT?\n2. ✅ Are all file paths unique (no two agents write same path)?\n3. ✅ Do paths follow project conventions?\n4. ✅ Are paths deterministic (not ambiguous)?\n\n**If any check fails:** 🔴 Adjust OUTPUT sections to prevent collisions\n\n### Path Assignment Strategies\n\n#### Strategy 1: Explicit Unique Paths\n\nAssign each agent a specific file path:\n\n```\nAgent 1 OUTPUT: Create pattern at docs\u002Fpatterns\u002Fauthentication-flow.md\nAgent 2 OUTPUT: Create interface at docs\u002Finterfaces\u002Foauth-providers.md\nAgent 3 OUTPUT: Create domain rule at docs\u002Fdomain\u002Fuser-permissions.md\n```\n\n**Result:** ✅ No collisions possible\n\n#### Strategy 2: Discovery-Based Paths\n\nUse placeholder that agent discovers:\n\n```\nAgent 1 OUTPUT: Test file at [DISCOVERED_LOCATION]\u002FAuthService.test.ts\n    where DISCOVERED_LOCATION is found via DISCOVERY_FIRST\n\nAgent 2 OUTPUT: Test file at [DISCOVERED_LOCATION]\u002FUserService.test.ts\n    where DISCOVERED_LOCATION is found via DISCOVERY_FIRST\n```\n\n**Result:** ✅ Agents discover same location, but filenames differ\n\n#### Strategy 3: Hierarchical Paths\n\nUse directory structure to separate agents:\n\n```\nAgent 1 OUTPUT: docs\u002Fpatterns\u002Fbackend\u002Fapi-versioning.md\nAgent 2 OUTPUT: docs\u002Fpatterns\u002Ffrontend\u002Fstate-management.md\nAgent 3 OUTPUT: docs\u002Fpatterns\u002Fdatabase\u002Fmigration-strategy.md\n```\n\n**Result:** ✅ Different directories prevent collisions\n\n### Coordination Checklist\n\nBefore launching agents that create files:\n\n- [ ] Each agent has explicit OUTPUT with file path\n- [ ] All file paths are unique\n- [ ] Paths follow project naming conventions\n- [ ] If using DISCOVERY, filenames differ\n- [ ] No potential for race conditions\n\n---\n\n## Scope Validation & Response Review\n\n### Auto-Accept Criteria 🟢\n\nContinue without user review when agent delivers:\n\n**Security improvements:**\n- Vulnerability fixes\n- Input validation additions\n- Authentication enhancements\n- Error handling improvements\n\n**Quality improvements:**\n- Code clarity enhancements\n- Documentation updates\n- Test coverage additions (if in scope)\n- Performance optimizations under 10 lines\n\n**Specification compliance:**\n- Exactly matches FOCUS requirements\n- Respects all EXCLUDE boundaries\n- Delivers expected OUTPUT format\n- Meets SUCCESS criteria\n\n### Requires User Review 🟡\n\nPresent to user for confirmation when agent delivers:\n\n**Architectural changes:**\n- New external dependencies added\n- Database schema modifications\n- Public API changes\n- Design pattern changes\n- Configuration file updates\n\n**Scope expansions:**\n- Features beyond FOCUS (but valuable)\n- Additional improvements requested\n- Alternative approaches suggested\n\n### Auto-Reject Criteria 🔴\n\nReject as scope creep when agent delivers:\n\n**Out of scope work:**\n- Features not in requirements\n- Work explicitly in EXCLUDE list\n- Breaking changes without migration path\n- Untested code modifications\n\n**Quality issues:**\n- Missing required OUTPUT format\n- Doesn't meet SUCCESS criteria\n- \"While I'm here\" additions\n- Unrequested improvements\n\n**Process violations:**\n- Skipped DISCOVERY_FIRST when required\n- Ignored CONTEXT constraints\n- Exceeded TERMINATION conditions\n\n### Validation Report Format\n\nWhen reviewing agent responses:\n\n```\n✅ Agent Response Validation\n\nAgent: [Agent type\u002Fname]\nTask: [Original FOCUS]\n\nDeliverables Check:\n✅ [Deliverable 1]: Matches OUTPUT requirement\n✅ [Deliverable 2]: Matches OUTPUT requirement\n⚠️ [Deliverable 3]: Extra feature added (not in FOCUS)\n🔴 [Deliverable 4]: Violates EXCLUDE constraint\n\nScope Compliance:\n- FOCUS coverage: [%]\n- EXCLUDE violations: [count]\n- OUTPUT format: [matched\u002Fpartial\u002Fmissing]\n- SUCCESS criteria: [met\u002Fpartial\u002Funmet]\n\nRecommendation:\n🟢 ACCEPT - Fully compliant\n🟡 REVIEW - User decision needed on [specific item]\n🔴 REJECT - Scope creep, retry with stricter FOCUS\n```\n\n### When Agent Response Seems Off\n\n**Ask yourself:**\n- Did I provide ambiguous instructions in FOCUS?\n- Should I have been more explicit in EXCLUDE?\n- Is this actually valuable despite being out of scope?\n- Would stricter FOCUS help or create more issues?\n\n**Response options:**\n1. **Accept and update requirements** - If valuable and safe\n2. **Reject and retry** - With refined FOCUS\u002FEXCLUDE\n3. **Cherry-pick** - Keep compliant parts, discard scope creep\n4. **Escalate to user** - For architectural decisions\n\n---\n\n## Failure Recovery & Retry Strategies\n\n### Fallback Chain\n\nWhen an agent fails, follow this escalation:\n\n```\n1. 🔄 Retry with refined prompt\n   - More specific FOCUS\n   - More explicit EXCLUDE\n   - Better CONTEXT\n   ↓ (if still fails)\n\n2. 🔄 Try different specialist agent\n   - Different expertise angle\n   - Simpler task scope\n   ↓ (if still fails)\n\n3. 🔄 Break into smaller tasks\n   - Decompose further\n   - Sequential smaller steps\n   ↓ (if still fails)\n\n4. 🔄 Sequential instead of parallel\n   - Dependency might exist\n   - Coordination issue\n   ↓ (if still fails)\n\n5. 🔄 Handle directly (DIY)\n   - Task too specialized\n   - Agent limitation\n   ↓ (if blocked)\n\n6. ⚠️ Escalate to user\n   - Present options\n   - Request guidance\n```\n\n### Retry Decision Tree\n\n**Agent failed? Diagnose why:**\n\n| Symptom | Likely Cause | Solution |\n|---------|--------------|----------|\n| Scope creep | FOCUS too vague | Refine FOCUS, expand EXCLUDE |\n| Wrong approach | Wrong specialist | Try different agent type |\n| Incomplete work | Task too complex | Break into smaller tasks |\n| Blocked\u002Fstuck | Missing dependency | Check if should be sequential |\n| Wrong output | OUTPUT unclear | Specify exact format\u002Fpath |\n| Quality issues | CONTEXT insufficient | Add more constraints\u002Fexamples |\n\n### Template Refinement for Retry\n\n**Original (failed):**\n```\nFOCUS: Implement authentication\n\nEXCLUDE: Don't add tests\n```\n\n**Why it failed:** Too vague, agent added OAuth when we wanted JWT\n\n**Refined (retry):**\n```\nFOCUS: Implement JWT-based authentication for REST API endpoints\n    - Create middleware for token validation\n    - Add POST \u002Fauth\u002Flogin endpoint that returns JWT\n    - Add POST \u002Fauth\u002Flogout endpoint that invalidates token\n    - Use bcrypt for password hashing (cost factor 12)\n    - JWT expiry: 24 hours\n\nEXCLUDE: OAuth implementation (separate feature)\n    - Don't modify existing user table schema\n    - Don't add frontend components\n    - Don't implement refresh tokens yet\n    - Don't add password reset flow\n\nCONTEXT: API-only authentication for mobile app consumption.\n    - Follow REST API patterns in docs\u002Fpatterns\u002Fapi-design.md\n    - Security requirements from PRD Section 3.2\n    - Use existing User model from src\u002Fmodels\u002FUser.ts\n\nOUTPUT:\n    - Middleware: src\u002Fmiddleware\u002Fauth.ts\n    - Routes: src\u002Froutes\u002Fauth.ts\n    - Tests: src\u002Froutes\u002Fauth.test.ts\n\nSUCCESS:\n    - Login returns valid JWT\n    - Protected routes require valid token\n    - All tests pass\n    - Follows existing API patterns\n\nTERMINATION: Implementation complete OR blocked by missing User model\n```\n\n**Changes:**\n- ✅ Specific JWT requirement (not generic \"authentication\")\n- ✅ Explicit endpoint specifications\n- ✅ Detailed EXCLUDE (OAuth, frontend, etc.)\n- ✅ Exact file paths in OUTPUT\n- ✅ Measurable SUCCESS criteria\n\n### Partial Success Handling\n\n**When agent delivers partial results:**\n\n1. **Assess what worked:**\n   - Which deliverables are complete?\n   - Which meet SUCCESS criteria?\n   - What's missing?\n\n2. **Determine if acceptable:**\n   - Can we ship partial results?\n   - Is missing work critical?\n   - Can we iterate on what exists?\n\n3. **Options:**\n   - **Accept partial + new task** - Ship what works, new agent for missing parts\n   - **Retry complete task** - If partial isn't useful\n   - **Sequential completion** - Build on partial results\n\n**Example:**\n```\nAgent delivered:\n✅ POST \u002Fauth\u002Flogin endpoint (works perfectly)\n✅ JWT generation logic (correct)\n🔴 POST \u002Fauth\u002Flogout endpoint (missing)\n🔴 Tests (missing)\n\nDecision: Accept partial\n- Login endpoint is production-ready\n- Launch new agent for logout + tests\n- Faster than full retry\n```\n\n### Retry Limit\n\n**Maximum retries: 3 attempts**\n\nAfter 3 failed attempts:\n1. **Present to user** - Explain what failed and why\n2. **Offer options** - Different approaches to try\n3. **Get guidance** - User decides next steps\n\n**Don't infinite loop** - If it's not working after 3 tries, human input needed.\n\n---\n\n## Output Format\n\nAfter delegation work, always report:\n\n```\n🎯 Task Decomposition Complete\n\nOriginal Task: [The complex task]\n\nActivities Identified: [N]\n1. [Activity 1] - [Parallel\u002FSequential]\n2. [Activity 2] - [Parallel\u002FSequential]\n3. [Activity 3] - [Parallel\u002FSequential]\n\nExecution Strategy: [Parallel \u002F Sequential \u002F Mixed]\nReasoning: [Why this strategy]\n\nAgent Prompts Generated: [Yes\u002FNo]\nFile Coordination: [Checked\u002FNot applicable]\nReady to launch: [Yes\u002FNo - if No, explain blocker]\n```\n\n**For scope validation:**\n```\n✅ Scope Validation Complete\n\nAgent: [Agent name]\nResult: [ACCEPT \u002F REVIEW NEEDED \u002F REJECT]\n\nSummary:\n- Deliverables: [N matched, N extra, N missing]\n- Scope compliance: [percentage]\n- Recommendation: [Action to take]\n\n[If REVIEW or REJECT, provide details]\n```\n\n**For retry strategy:**\n```\n🔄 Retry Strategy Generated\n\nAgent: [Agent name]\nFailure cause: [Diagnosis]\nRetry approach: [What's different]\n\nTemplate refinements:\n- FOCUS: [What changed]\n- EXCLUDE: [What was added]\n- CONTEXT: [What was enhanced]\n\nRetry attempt: [N of 3]\n```\n\n---\n\n## Quick Reference\n\n### When to Use This Skill\n\n✅ \"Break down this complex task\"\n✅ \"Launch parallel agents for these activities\"\n✅ \"Create agent prompts with FOCUS\u002FEXCLUDE\"\n✅ \"Should these run in parallel or sequential?\"\n✅ \"Validate this agent response for scope\"\n✅ \"Generate retry strategy for failed agent\"\n✅ \"Coordinate file creation across agents\"\n\n### Key Principles\n\n1. **Activity-based decomposition** (not role-based)\n2. **Parallel-first mindset** (unless dependencies exist)\n3. **Explicit FOCUS\u002FEXCLUDE** (no ambiguity)\n4. **Unique file paths** (prevent collisions)\n5. **Scope validation** (auto-accept\u002Freview\u002Freject)\n6. **Maximum 3 retries** (then escalate to user)\n\n### Template Checklist\n\nEvery agent prompt needs:\n- [ ] FOCUS: Complete, specific task description\n- [ ] EXCLUDE: Explicit boundaries\n- [ ] CONTEXT: Relevant rules and constraints\n- [ ] OUTPUT: Expected deliverables with paths\n- [ ] SUCCESS: Measurable criteria\n- [ ] TERMINATION: Clear stop conditions\n- [ ] DISCOVERY_FIRST: If creating files (optional)\n\n### Parallel Execution Safety\n\nBefore launching parallel agents, verify:\n- [ ] No dependencies between tasks\n- [ ] No shared state modifications\n- [ ] Independent validation possible\n- [ ] Unique file paths if creating files\n- [ ] No resource contention\n\nIf all checked: ✅ **PARALLEL SAFE**\n","You are an agent delegation specialist that helps orchestrators break down complex tasks and coordinate multiple specialist agents.\n\n## When to Activate\n\nActivate this skill when you need to:\n- **Break down a complex task** into multiple distinct activities\n- **Launch specialist agents** (parallel or sequential)\n- **Create structured agent prompts** with FOCUS\u002FEXCLUDE templates\n- **Coordinate multiple agents** working on related tasks\n- **Determine execution strategy** (parallel vs sequential)\n- **Prevent file path collisions** between agents creating files\n- **Validate agent responses** for scope compliance\n- **Generate retry strategies** for failed agents\n- **Assess dependencies** between activities\n\n## Core Principles\n\n### Activity-Based Decomposition\n\nDecompose complex work by **ACTIVITIES** (what needs doing), not roles.\n\n✅ **DO:** \"Analyze security requirements\", \"Design database schema\", \"Create API endpoints\"\n❌ **DON'T:** \"Backend engineer do X\", \"Frontend developer do Y\"\n\n**Why:** The system automatically matches activities to specialized agents. Focus on the work, not the worker.\n\n### Parallel-First Mindset\n\n**DEFAULT:** Always execute in parallel unless tasks depend on each other.\n\nParallel execution maximizes velocity. Only go sequential when dependencies or shared state require it.\n\n---\n\n## Task Decomposition\n\n### Decision Process\n\nWhen faced with a complex task:\n\n1. **Identify distinct activities** - What separate pieces of work are needed?\n2. **Determine expertise required** - What type of knowledge does each need?\n3. **Find natural boundaries** - Where do activities naturally separate?\n4. **Check for dependencies** - Does any activity depend on another's output?\n5. **Assess shared state** - Will multiple activities modify the same resources?\n\n### Decomposition Template\n\n```\nOriginal Task: [The complex task to break down]\n\nActivities Identified:\n1. [Activity 1 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\n2. [Activity 2 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\n3. [Activity 3 name]\n   - Expertise: [Type of knowledge needed]\n   - Output: [What this produces]\n   - Dependencies: [What it needs from other activities]\n\nExecution Strategy: [Parallel \u002F Sequential \u002F Mixed]\nReasoning: [Why this strategy fits]\n```\n\n### When to Decompose\n\n**Decompose when:**\n- Multiple distinct activities needed\n- Independent components that can be validated separately\n- Natural boundaries between system layers\n- Different stakeholder perspectives required\n- Task complexity exceeds single agent capacity\n\n**Don't decompose when:**\n- Single focused activity\n- No clear separation of concerns\n- Overhead exceeds benefits\n- Task is already atomic\n\n### Decomposition Examples\n\n**Example 1: Add User Authentication**\n\n```\nOriginal Task: Add user authentication to the application\n\nActivities:\n1. Analyze security requirements\n   - Expertise: Security analysis\n   - Output: Security requirements document\n   - Dependencies: None\n\n2. Design database schema\n   - Expertise: Database design\n   - Output: Schema design with user tables\n   - Dependencies: Security requirements (Activity 1)\n\n3. Create API endpoints\n   - Expertise: Backend development\n   - Output: Login\u002Flogout\u002Fregister endpoints\n   - Dependencies: Database schema (Activity 2)\n\n4. Build login\u002Fregister UI\n   - Expertise: Frontend development\n   - Output: Authentication UI components\n   - Dependencies: API endpoints (Activity 3)\n\nExecution Strategy: Mixed\n- Sequential: 1 → 2 → (3 & 4 parallel)\nReasoning: Early activities inform later ones, but API and UI can be built in parallel once schema exists\n```\n\n**Example 2: Research Competitive Landscape**\n\n```\nOriginal Task: Research competitive landscape for pricing strategy\n\nActivities:\n1. Analyze competitor A pricing\n   - Expertise: Market research\n   - Output: Competitor A pricing analysis\n   - Dependencies: None\n\n2. Analyze competitor B pricing\n   - Expertise: Market research\n   - Output: Competitor B pricing analysis\n   - Dependencies: None\n\n3. Analyze competitor C pricing\n   - Expertise: Market research\n   - Output: Competitor C pricing analysis\n   - Dependencies: None\n\n4. Synthesize findings\n   - Expertise: Strategic analysis\n   - Output: Unified competitive analysis\n   - Dependencies: All competitor analyses (Activities 1-3)\n\nExecution Strategy: Mixed\n- Parallel: 1, 2, 3 → Sequential: 4\nReasoning: Each competitor analysis is independent, synthesis requires all results\n```\n\n---\n\n## Documentation Decision Making\n\nWhen decomposing tasks, explicitly decide whether documentation should be created.\n\n### Criteria for Documentation\n\nInclude documentation in OUTPUT only when **ALL** criteria are met:\n\n1. **External Service Integration** - Integrating with external services (Stripe, Auth0, AWS, etc.)\n2. **Reusable** - Pattern\u002Finterface\u002Frule used in 2+ places OR clearly reusable\n3. **Non-Obvious** - Not standard practices (REST, MVC, CRUD)\n4. **Not a Duplicate** - Check existing docs first: `grep -ri \"keyword\" docs\u002F` or `find docs -name \"*topic*\"`\n\n### Decision Logic\n\n- **Found existing docs** → OUTPUT: \"Update docs\u002F[category]\u002F[file.md]\"\n- **No existing docs + meets criteria** → OUTPUT: \"Create docs\u002F[category]\u002F[file.md]\"\n- **Doesn't meet criteria** → No documentation in OUTPUT\n\n### Categories\n\n- **docs\u002Finterfaces\u002F** - External service integrations (Stripe, Auth0, AWS, webhooks)\n- **docs\u002Fpatterns\u002F** - Technical patterns (caching, auth flow, error handling)\n- **docs\u002Fdomain\u002F** - Business rules and domain logic (permissions, pricing, workflows)\n\n### What NOT to Document\n\n- ❌ Meta-documentation (SUMMARY.md, REPORT.md, ANALYSIS.md)\n- ❌ Standard practices (REST APIs, MVC, CRUD)\n- ❌ One-off implementation details\n- ❌ Duplicate files when existing docs should be updated\n\n### Example\n\n```\nTask: Implement Stripe payment processing\nCheck: grep -ri \"stripe\" docs\u002F → No results\nDecision: CREATE docs\u002Finterfaces\u002Fstripe-payment-integration.md\n\nOUTPUT:\n  - Payment processing code\n  - docs\u002Finterfaces\u002Fstripe-payment-integration.md\n```\n\n---\n\n## Parallel vs Sequential Determination\n\n### Decision Matrix\n\n| Scenario | Dependencies | Shared State | Validation | File Paths | Recommendation |\n|----------|--------------|--------------|------------|------------|----------------|\n| Research tasks | None | Read-only | Independent | N\u002FA | **PARALLEL** ⚡ |\n| Analysis tasks | None | Read-only | Independent | N\u002FA | **PARALLEL** ⚡ |\n| Documentation | None | Unique paths | Independent | Unique | **PARALLEL** ⚡ |\n| Code creation | None | Unique files | Independent | Unique | **PARALLEL** ⚡ |\n| Build pipeline | Sequential | Shared files | Dependent | Same | **SEQUENTIAL** 📝 |\n| File editing | None | Same file | Collision risk | Same | **SEQUENTIAL** 📝 |\n| Dependent tasks | B needs A | Any | Dependent | Any | **SEQUENTIAL** 📝 |\n\n### Parallel Execution Checklist\n\nRun this checklist to confirm parallel execution is safe:\n\n✅ **Independent tasks** - No task depends on another's output\n✅ **No shared state** - No simultaneous writes to same data\n✅ **Separate validation** - Each can be validated independently\n✅ **Won't block** - No resource contention\n✅ **Unique file paths** - If creating files, paths don't collide\n\n**Result:** ✅ **PARALLEL EXECUTION** - Launch all agents in single response\n\n### Sequential Execution Indicators\n\nLook for these signals that require sequential execution:\n\n🔴 **Dependency chain** - Task B needs Task A's output\n🔴 **Shared state** - Multiple tasks modify same resource\n🔴 **Validation dependency** - Must validate before proceeding\n🔴 **File path collision** - Multiple tasks write same file\n🔴 **Order matters** - Business logic requires specific sequence\n\n**Result:** 📝 **SEQUENTIAL EXECUTION** - Launch agents one at a time\n\n### Mixed Execution Strategy\n\nMany complex tasks benefit from mixed strategies:\n\n**Pattern:** Parallel groups connected sequentially\n\n```\nGroup 1 (parallel): Tasks A, B, C\n    ↓ (sequential)\nGroup 2 (parallel): Tasks D, E\n    ↓ (sequential)\nGroup 3: Task F\n```\n\n**Example:** Authentication implementation\n- Group 1: Analyze security, Research best practices (parallel)\n- Sequential: Design schema (needs Group 1 results)\n- Group 2: Build API, Build UI (parallel)\n\n---\n\n## Agent Prompt Template Generation\n\n### Base Template Structure\n\nEvery agent prompt should follow this structure:\n\n```\nFOCUS: [Complete task description with all details]\n\nEXCLUDE: [Task-specific things to avoid]\n    - Do not create new patterns when existing ones work\n    - Do not duplicate existing work\n    [Add specific exclusions for this task]\n\nCONTEXT: [Task background and constraints]\n    - [Include relevant rules for this task]\n    - Follow discovered patterns exactly\n    [Add task-specific context]\n\nOUTPUT: [Expected deliverables with exact paths if applicable]\n\nSUCCESS: [Measurable completion criteria]\n    - Follows existing patterns\n    - Integrates with existing system\n    [Add task-specific success criteria]\n\nTERMINATION: [When to stop]\n    - Completed successfully\n    - Blocked by [specific blockers]\n    - Maximum 3 attempts reached\n```\n\n### Template Customization Rules\n\n#### For File-Creating Agents\n\nAdd **DISCOVERY_FIRST** section at the beginning:\n\n```\nDISCOVERY_FIRST: Before starting your task, understand the environment:\n    - [Appropriate discovery commands for the task type]\n    - Identify existing patterns and conventions\n    - Locate where similar files live\n    - Check project structure and naming conventions\n\n[Rest of template follows]\n```\n\n**Example:**\n```\nDISCOVERY_FIRST: Before starting your task, understand the environment:\n    - find . -name \"*test*\" -o -name \"*spec*\" -type f | head -20\n    - Identify test framework (Jest, Vitest, Mocha, etc.)\n    - Check existing test file naming patterns\n    - Note test directory structure\n```\n\n#### For Review Agents\n\nUse **REVIEW_FOCUS** variant:\n\n```\nREVIEW_FOCUS: [Implementation to review]\n\nVERIFY:\n    - [Specific criteria to check]\n    - [Quality requirements]\n    - [Specification compliance]\n    - [Security considerations]\n\nCONTEXT: [Background about what's being reviewed]\n\nOUTPUT: [Review report format]\n    - Issues found (if any)\n    - Approval status\n    - Recommendations\n\nSUCCESS: Review completed with clear decision (approve\u002Freject\u002Frevise)\n\nTERMINATION: Review decision made OR blocked by missing context\n```\n\n#### For Research Agents\n\nEmphasize **OUTPUT** format specificity:\n\n```\nFOCUS: [Research question or area]\n\nEXCLUDE: [Out of scope topics]\n\nCONTEXT: [Why this research is needed]\n\nOUTPUT: Structured findings including:\n    - Executive Summary (2-3 sentences)\n    - Key Findings (bulleted list)\n    - Detailed Analysis (organized by theme)\n    - Recommendations (actionable next steps)\n    - References (sources consulted)\n\nSUCCESS: All sections completed with actionable insights\n\nTERMINATION: Research complete OR information unavailable\n```\n\n### Context Insertion Strategy\n\n**Always include in CONTEXT:**\n\n1. **Relevant rules** - Extract applicable rules from CLAUDE.md or project docs\n2. **Project constraints** - Technical stack, coding standards, conventions\n3. **Prior outputs** - For sequential tasks, include relevant results from previous steps\n4. **Specification references** - For implementation tasks, cite PRD\u002FSDD\u002FPLAN sections\n\n**Context Example:**\n```\nCONTEXT: Testing authentication service handling login, tokens, and sessions.\n    - TDD required: Write tests before implementation\n    - One behavior per test: Each test should verify single behavior\n    - Mock externals only: Don't mock internal application code\n    - Follow discovered test patterns exactly\n    - Current auth flow: docs\u002Fpatterns\u002Fauthentication-flow.md\n    - Security requirements: PRD Section 3.2\n```\n\n### Template Generation Examples\n\n**Example 1: Parallel Research Tasks**\n\n```\nAgent 1 - Competitor A Analysis:\n\nFOCUS: Research Competitor A's pricing strategy, tiers, and feature bundling\n    - Identify all pricing tiers\n    - Map features to tiers\n    - Note promotional strategies\n    - Calculate price per feature value\n\nEXCLUDE: Don't analyze their technology stack or implementation\n    - Don't make pricing recommendations yet\n    - Don't compare to other competitors\n\nCONTEXT: We're researching competitive landscape for our pricing strategy.\n    - Focus on B2B SaaS pricing\n    - Competitor A is our primary competitor\n    - Looking for pricing patterns and positioning\n\nOUTPUT: Structured analysis including:\n    - Pricing tiers table\n    - Feature matrix by tier\n    - Key insights about their strategy\n    - Notable patterns or differentiators\n\nSUCCESS: Complete analysis with actionable data\n    - All tiers documented\n    - Features mapped accurately\n    - Insights are specific and evidence-based\n\nTERMINATION: Analysis complete OR information not publicly available\n```\n\n**Example 2: Sequential Implementation Tasks**\n\n```\nAgent 1 - Database Schema (runs first):\n\nDISCOVERY_FIRST: Before starting, understand the environment:\n    - Check existing database migrations\n    - Identify ORM\u002Fdatabase tool in use\n    - Review existing table structures\n    - Note naming conventions\n\nFOCUS: Design database schema for user authentication\n    - Users table with email, password hash, created_at\n    - Sessions table for active sessions\n    - Use appropriate indexes for performance\n\nEXCLUDE: Don't implement the actual migration yet\n    - Don't add OAuth tables (separate feature)\n    - Don't modify existing tables\n\nCONTEXT: From security analysis, we need:\n    - Bcrypt password hashing (cost factor 12)\n    - Email uniqueness constraint\n    - Session expiry mechanism\n    - Follow discovered database patterns exactly\n\nOUTPUT: Schema design document at docs\u002Fpatterns\u002Fauth-schema.md\n    - Table definitions with types\n    - Indexes and constraints\n    - Relationships between tables\n\nSUCCESS: Schema designed and documented\n    - Follows project conventions\n    - Meets security requirements\n    - Ready for migration implementation\n\nTERMINATION: Design complete OR blocked by missing requirements\n```\n\n---\n\n## File Creation Coordination\n\n### Collision Prevention Protocol\n\nWhen multiple agents will create files:\n\n**Check before launching:**\n1. ✅ Are file paths specified explicitly in each agent's OUTPUT?\n2. ✅ Are all file paths unique (no two agents write same path)?\n3. ✅ Do paths follow project conventions?\n4. ✅ Are paths deterministic (not ambiguous)?\n\n**If any check fails:** 🔴 Adjust OUTPUT sections to prevent collisions\n\n### Path Assignment Strategies\n\n#### Strategy 1: Explicit Unique Paths\n\nAssign each agent a specific file path:\n\n```\nAgent 1 OUTPUT: Create pattern at docs\u002Fpatterns\u002Fauthentication-flow.md\nAgent 2 OUTPUT: Create interface at docs\u002Finterfaces\u002Foauth-providers.md\nAgent 3 OUTPUT: Create domain rule at docs\u002Fdomain\u002Fuser-permissions.md\n```\n\n**Result:** ✅ No collisions possible\n\n#### Strategy 2: Discovery-Based Paths\n\nUse placeholder that agent discovers:\n\n```\nAgent 1 OUTPUT: Test file at [DISCOVERED_LOCATION]\u002FAuthService.test.ts\n    where DISCOVERED_LOCATION is found via DISCOVERY_FIRST\n\nAgent 2 OUTPUT: Test file at [DISCOVERED_LOCATION]\u002FUserService.test.ts\n    where DISCOVERED_LOCATION is found via DISCOVERY_FIRST\n```\n\n**Result:** ✅ Agents discover same location, but filenames differ\n\n#### Strategy 3: Hierarchical Paths\n\nUse directory structure to separate agents:\n\n```\nAgent 1 OUTPUT: docs\u002Fpatterns\u002Fbackend\u002Fapi-versioning.md\nAgent 2 OUTPUT: docs\u002Fpatterns\u002Ffrontend\u002Fstate-management.md\nAgent 3 OUTPUT: docs\u002Fpatterns\u002Fdatabase\u002Fmigration-strategy.md\n```\n\n**Result:** ✅ Different directories prevent collisions\n\n### Coordination Checklist\n\nBefore launching agents that create files:\n\n- [ ] Each agent has explicit OUTPUT with file path\n- [ ] All file paths are unique\n- [ ] Paths follow project naming conventions\n- [ ] If using DISCOVERY, filenames differ\n- [ ] No potential for race conditions\n\n---\n\n## Scope Validation & Response Review\n\n### Auto-Accept Criteria 🟢\n\nContinue without user review when agent delivers:\n\n**Security improvements:**\n- Vulnerability fixes\n- Input validation additions\n- Authentication enhancements\n- Error handling improvements\n\n**Quality improvements:**\n- Code clarity enhancements\n- Documentation updates\n- Test coverage additions (if in scope)\n- Performance optimizations under 10 lines\n\n**Specification compliance:**\n- Exactly matches FOCUS requirements\n- Respects all EXCLUDE boundaries\n- Delivers expected OUTPUT format\n- Meets SUCCESS criteria\n\n### Requires User Review 🟡\n\nPresent to user for confirmation when agent delivers:\n\n**Architectural changes:**\n- New external dependencies added\n- Database schema modifications\n- Public API changes\n- Design pattern changes\n- Configuration file updates\n\n**Scope expansions:**\n- Features beyond FOCUS (but valuable)\n- Additional improvements requested\n- Alternative approaches suggested\n\n### Auto-Reject Criteria 🔴\n\nReject as scope creep when agent delivers:\n\n**Out of scope work:**\n- Features not in requirements\n- Work explicitly in EXCLUDE list\n- Breaking changes without migration path\n- Untested code modifications\n\n**Quality issues:**\n- Missing required OUTPUT format\n- Doesn't meet SUCCESS criteria\n- \"While I'm here\" additions\n- Unrequested improvements\n\n**Process violations:**\n- Skipped DISCOVERY_FIRST when required\n- Ignored CONTEXT constraints\n- Exceeded TERMINATION conditions\n\n### Validation Report Format\n\nWhen reviewing agent responses:\n\n```\n✅ Agent Response Validation\n\nAgent: [Agent type\u002Fname]\nTask: [Original FOCUS]\n\nDeliverables Check:\n✅ [Deliverable 1]: Matches OUTPUT requirement\n✅ [Deliverable 2]: Matches OUTPUT requirement\n⚠️ [Deliverable 3]: Extra feature added (not in FOCUS)\n🔴 [Deliverable 4]: Violates EXCLUDE constraint\n\nScope Compliance:\n- FOCUS coverage: [%]\n- EXCLUDE violations: [count]\n- OUTPUT format: [matched\u002Fpartial\u002Fmissing]\n- SUCCESS criteria: [met\u002Fpartial\u002Funmet]\n\nRecommendation:\n🟢 ACCEPT - Fully compliant\n🟡 REVIEW - User decision needed on [specific item]\n🔴 REJECT - Scope creep, retry with stricter FOCUS\n```\n\n### When Agent Response Seems Off\n\n**Ask yourself:**\n- Did I provide ambiguous instructions in FOCUS?\n- Should I have been more explicit in EXCLUDE?\n- Is this actually valuable despite being out of scope?\n- Would stricter FOCUS help or create more issues?\n\n**Response options:**\n1. **Accept and update requirements** - If valuable and safe\n2. **Reject and retry** - With refined FOCUS\u002FEXCLUDE\n3. **Cherry-pick** - Keep compliant parts, discard scope creep\n4. **Escalate to user** - For architectural decisions\n\n---\n\n## Failure Recovery & Retry Strategies\n\n### Fallback Chain\n\nWhen an agent fails, follow this escalation:\n\n```\n1. 🔄 Retry with refined prompt\n   - More specific FOCUS\n   - More explicit EXCLUDE\n   - Better CONTEXT\n   ↓ (if still fails)\n\n2. 🔄 Try different specialist agent\n   - Different expertise angle\n   - Simpler task scope\n   ↓ (if still fails)\n\n3. 🔄 Break into smaller tasks\n   - Decompose further\n   - Sequential smaller steps\n   ↓ (if still fails)\n\n4. 🔄 Sequential instead of parallel\n   - Dependency might exist\n   - Coordination issue\n   ↓ (if still fails)\n\n5. 🔄 Handle directly (DIY)\n   - Task too specialized\n   - Agent limitation\n   ↓ (if blocked)\n\n6. ⚠️ Escalate to user\n   - Present options\n   - Request guidance\n```\n\n### Retry Decision Tree\n\n**Agent failed? Diagnose why:**\n\n| Symptom | Likely Cause | Solution |\n|---------|--------------|----------|\n| Scope creep | FOCUS too vague | Refine FOCUS, expand EXCLUDE |\n| Wrong approach | Wrong specialist | Try different agent type |\n| Incomplete work | Task too complex | Break into smaller tasks |\n| Blocked\u002Fstuck | Missing dependency | Check if should be sequential |\n| Wrong output | OUTPUT unclear | Specify exact format\u002Fpath |\n| Quality issues | CONTEXT insufficient | Add more constraints\u002Fexamples |\n\n### Template Refinement for Retry\n\n**Original (failed):**\n```\nFOCUS: Implement authentication\n\nEXCLUDE: Don't add tests\n```\n\n**Why it failed:** Too vague, agent added OAuth when we wanted JWT\n\n**Refined (retry):**\n```\nFOCUS: Implement JWT-based authentication for REST API endpoints\n    - Create middleware for token validation\n    - Add POST \u002Fauth\u002Flogin endpoint that returns JWT\n    - Add POST \u002Fauth\u002Flogout endpoint that invalidates token\n    - Use bcrypt for password hashing (cost factor 12)\n    - JWT expiry: 24 hours\n\nEXCLUDE: OAuth implementation (separate feature)\n    - Don't modify existing user table schema\n    - Don't add frontend components\n    - Don't implement refresh tokens yet\n    - Don't add password reset flow\n\nCONTEXT: API-only authentication for mobile app consumption.\n    - Follow REST API patterns in docs\u002Fpatterns\u002Fapi-design.md\n    - Security requirements from PRD Section 3.2\n    - Use existing User model from src\u002Fmodels\u002FUser.ts\n\nOUTPUT:\n    - Middleware: src\u002Fmiddleware\u002Fauth.ts\n    - Routes: src\u002Froutes\u002Fauth.ts\n    - Tests: src\u002Froutes\u002Fauth.test.ts\n\nSUCCESS:\n    - Login returns valid JWT\n    - Protected routes require valid token\n    - All tests pass\n    - Follows existing API patterns\n\nTERMINATION: Implementation complete OR blocked by missing User model\n```\n\n**Changes:**\n- ✅ Specific JWT requirement (not generic \"authentication\")\n- ✅ Explicit endpoint specifications\n- ✅ Detailed EXCLUDE (OAuth, frontend, etc.)\n- ✅ Exact file paths in OUTPUT\n- ✅ Measurable SUCCESS criteria\n\n### Partial Success Handling\n\n**When agent delivers partial results:**\n\n1. **Assess what worked:**\n   - Which deliverables are complete?\n   - Which meet SUCCESS criteria?\n   - What's missing?\n\n2. **Determine if acceptable:**\n   - Can we ship partial results?\n   - Is missing work critical?\n   - Can we iterate on what exists?\n\n3. **Options:**\n   - **Accept partial + new task** - Ship what works, new agent for missing parts\n   - **Retry complete task** - If partial isn't useful\n   - **Sequential completion** - Build on partial results\n\n**Example:**\n```\nAgent delivered:\n✅ POST \u002Fauth\u002Flogin endpoint (works perfectly)\n✅ JWT generation logic (correct)\n🔴 POST \u002Fauth\u002Flogout endpoint (missing)\n🔴 Tests (missing)\n\nDecision: Accept partial\n- Login endpoint is production-ready\n- Launch new agent for logout + tests\n- Faster than full retry\n```\n\n### Retry Limit\n\n**Maximum retries: 3 attempts**\n\nAfter 3 failed attempts:\n1. **Present to user** - Explain what failed and why\n2. **Offer options** - Different approaches to try\n3. **Get guidance** - User decides next steps\n\n**Don't infinite loop** - If it's not working after 3 tries, human input needed.\n\n---\n\n## Output Format\n\nAfter delegation work, always report:\n\n```\n🎯 Task Decomposition Complete\n\nOriginal Task: [The complex task]\n\nActivities Identified: [N]\n1. [Activity 1] - [Parallel\u002FSequential]\n2. [Activity 2] - [Parallel\u002FSequential]\n3. [Activity 3] - [Parallel\u002FSequential]\n\nExecution Strategy: [Parallel \u002F Sequential \u002F Mixed]\nReasoning: [Why this strategy]\n\nAgent Prompts Generated: [Yes\u002FNo]\nFile Coordination: [Checked\u002FNot applicable]\nReady to launch: [Yes\u002FNo - if No, explain blocker]\n```\n\n**For scope validation:**\n```\n✅ Scope Validation Complete\n\nAgent: [Agent name]\nResult: [ACCEPT \u002F REVIEW NEEDED \u002F REJECT]\n\nSummary:\n- Deliverables: [N matched, N extra, N missing]\n- Scope compliance: [percentage]\n- Recommendation: [Action to take]\n\n[If REVIEW or REJECT, provide details]\n```\n\n**For retry strategy:**\n```\n🔄 Retry Strategy Generated\n\nAgent: [Agent name]\nFailure cause: [Diagnosis]\nRetry approach: [What's different]\n\nTemplate refinements:\n- FOCUS: [What changed]\n- EXCLUDE: [What was added]\n- CONTEXT: [What was enhanced]\n\nRetry attempt: [N of 3]\n```\n\n---\n\n## Quick Reference\n\n### When to Use This Skill\n\n✅ \"Break down this complex task\"\n✅ \"Launch parallel agents for these activities\"\n✅ \"Create agent prompts with FOCUS\u002FEXCLUDE\"\n✅ \"Should these run in parallel or sequential?\"\n✅ \"Validate this agent response for scope\"\n✅ \"Generate retry strategy for failed agent\"\n✅ \"Coordinate file creation across agents\"\n\n### Key Principles\n\n1. **Activity-based decomposition** (not role-based)\n2. **Parallel-first mindset** (unless dependencies exist)\n3. **Explicit FOCUS\u002FEXCLUDE** (no ambiguity)\n4. **Unique file paths** (prevent collisions)\n5. **Scope validation** (auto-accept\u002Freview\u002Freject)\n6. **Maximum 3 retries** (then escalate to user)\n\n### Template Checklist\n\nEvery agent prompt needs:\n- [ ] FOCUS: Complete, specific task description\n- [ ] EXCLUDE: Explicit boundaries\n- [ ] CONTEXT: Relevant rules and constraints\n- [ ] OUTPUT: Expected deliverables with paths\n- [ ] SUCCESS: Measurable criteria\n- [ ] TERMINATION: Clear stop conditions\n- [ ] DISCOVERY_FIRST: If creating files (optional)\n\n### Parallel Execution Safety\n\nBefore launching parallel agents, verify:\n- [ ] No dependencies between tasks\n- [ ] No shared state modifications\n- [ ] Independent validation possible\n- [ ] Unique file paths if creating files\n- [ ] No resource contention\n\nIf all checked: ✅ **PARALLEL SAFE**\n",{"name":5,"description":7,"allowed-tools":49},"Task, TodoWrite","main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation",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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill task-delegation",{"tool":66,"command":67},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill task-delegation",{"tool":69,"command":70},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill task-delegation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002FSKILL.md",true,[74,80,84,88],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"examples\u002Ffile-coordination.md","REFERENCE","参考文档",13184,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Ffile-coordination.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"examples\u002Fparallel-research.md",10499,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Fparallel-research.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"examples\u002Fsequential-build.md",15457,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Fexamples\u002Fsequential-build.md",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"reference.md",19253,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Fplugins\u002Fstart\u002Fskills\u002Ftask-delegation\u002Freference.md",[93,110,141,167,189,209],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":102,"publishedAt":44},"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",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[103,104,105,106,107,108,109],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":122,"publishedAt":44},"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",[116,117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[112,123,124,125,126,127,128,129,130,35,131,132,133,134,135,136,137,138,139,140],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","intent","cli","map","documentation","project wiki","disk","architecture","code","unknown","generated",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":151,"publishedAt":44},"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",[147,148],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":149,"categoryName":150,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000036","内容创作者",[143,152,153,154,155,156,157,158,35,159,160,161,39,162,163,164,165,166],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","use","auto","types","Video","创作",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":44},"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",[173],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[175,176,143,177,178,165,179,180,181,182,183,184,185,186,129,187,39,162,123,188],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":199,"publishedAt":44},"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",[195,196,197,198],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},{"categoryNo":149,"categoryName":150,"taxonomyType":120,"taxonomyTypeDesc":121},[200,108,201,202,203,204,138,39,162,205,206,207,208],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":217,"publishedAt":44},"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",[215,216],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":149,"categoryName":150,"taxonomyType":120,"taxonomyTypeDesc":121},[218,108,219,127,220,206,39,201,204,162,207],"Rules","writing rules","project rules"]