[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C6R4RJWG3S2R26778TPD8":3,"skill-same:01M71C6R4RJWG3S2R26778TPD8":69},{"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":26,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":14,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":43,"updatedAt":44,"install":45,"resources":58},"01M71C6R4RJWG3S2R26778TPD8","delegation",null,"Agent delegation best practices for constructing effective subagent prompts with proper scoping","yqecea\u002Fgem-swarm","yqecea","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F196189405?v=4","01M71C12KWH5QPTE12J69335KF","Yusuf","01M71C12MFS3BRGNE5SSHB4DY9",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,27,28,29,30,31,32],"subagent","scoping","for","best practices","with","prompts","2026-11-10 10:12:30",false,"---\nname: delegation\ndescription: Agent delegation best practices for constructing effective subagent prompts with proper scoping\n---\n\n# Delegation Skill\n\nActivate this skill when delegating work to subagents during orchestration execution. This skill provides the templates, rules, and patterns for constructing effective delegation prompts that produce consistent, high-quality results.\n\n## Protocol Injection\n\nBefore constructing any delegation prompt, inject the shared agent base protocol:\n\n### Injection Steps\n1. Load `agent-base-protocol` via `get_skill_content`\n2. Load `filesystem-safety-protocol` via `get_skill_content`\n3. **Ultrawork Cascade** — If the current session has `ultrawork: true` in its state (set by the `\u002Fgem-swarm:ulw` command):\n   - Load `ultrawork` via `get_skill_content`\n   - Prepend the `[ULTRAWORK ACTIVE]` header block to the delegation prompt (after filesystem-safety-protocol, before task content):\n     ```\n     [ULTRAWORK ACTIVE]\n     Mode: Maximum Intensity\n     Gate: Build → Test → Output → Integration\n     ```\n   - The ultrawork skill content provides the behavioral enforcement rules the agent must follow\n4. Prepend all protocols to the delegation prompt (base protocol first, then filesystem safety, then ultrawork if active) — these appear before the task-specific content\n5. For each phase listed in the current phase's `blocked_by`, read `phases[].downstream_context` from session state and include it in the prompt\n6. If any required `downstream_context` is missing, include an explicit placeholder noting the missing dependency context (never omit silently)\n\nThe injected protocol ensures every agent follows consistent pre-work procedures and output formatting regardless of their specialization. When Ultrawork is active, agents additionally enforce pre-implementation gates, zero-excuses completion, anti-rationalization, mandatory verification gates, and anti-AI-filler rules.\n\n### Context Chain Construction\n\nEvery delegation prompt must include a context chain that connects the current phase to prior work:\n\n**Phase Context**: Include Downstream Context blocks from all completed phases that the current phase depends on (identified via `blocked_by` relationships in the implementation plan and sourced from session state `phases[].downstream_context`):\n```\nContext from completed phases:\n- Phase [N] ([agent]): [Downstream Context summary]\n  - Interfaces introduced: [list with file locations]\n  - Patterns established: [list]\n  - Integration points: [specific files, functions, endpoints]\n  - Warnings: [list]\n```\n\n**Accumulated Patterns**: Naming conventions, directory organization patterns, and architectural decisions established by earlier phases. This ensures phase 5 does not contradict patterns set in phase 2.\n\n**File Manifest**: Complete list of files created or modified in prior phases, so the agent knows what already exists and can import from or extend those files.\n\n**Missing Context Fallback**: If a blocked dependency has no stored downstream context, include a visible placeholder entry in the prompt:\n`- Phase [N] ([agent]): Downstream Context missing in session state — verify dependency output before implementation`\n\n### Downstream Consumer Declaration\n\nEvery delegation prompt must declare who will consume the agent's output:\n```\nYour output will be consumed by: [downstream agent name(s)] who need [specific information they require]\n```\n\nThis primes the agent to structure their Downstream Context section for maximum utility to the next agent in the chain.\n\n## Settings Override Application\n\nBefore constructing any delegation prompt, resolve configurable parameters:\n\n1. Read the agent's base definition frontmatter (`temperature`, `max_turns`, `timeout_mins`, `tools`)\n2. Do not invent Maestro-level model, temperature, turn, or timeout overrides. Native delegation uses agent frontmatter defaults plus any runtime-level agent configuration already active in the session.\n3. Include only task-relevant execution context in the prompt metadata\n4. If the agent appears in `GEM_SWARM_DISABLED_AGENTS`, do not construct a delegation prompt — report to the orchestrator that the agent is disabled\n\n## Delegation Prompt Template\n\nEvery delegation to a subagent must follow this structure:\n\n```\nTask: [One-line description of what to accomplish]\n\nProgress: Phase [N] of [M]: [Phase Name]\n\nFiles to modify:\n- \u002Fabsolute\u002Fpath\u002Fto\u002Ffile1.ext: [Specific change required]\n- \u002Fabsolute\u002Fpath\u002Fto\u002Ffile2.ext: [Specific change required]\n\nFiles to create:\n- \u002Fabsolute\u002Fpath\u002Fto\u002Fnew-file.ext: [Purpose and key contents]\n\nDeliverables:\n- [Concrete output 1]\n- [Concrete output 2]\n\nValidation: [command to run after completion, e.g., \"npm run lint && npm run test\"]\n\nContext:\n[Relevant information from the design document or previous phases]\n\nDo NOT:\n- [Explicit exclusion 1]\n- [Explicit exclusion 2]\n- Modify any files not listed above\n```\n\n## Scope Boundary Rules\n\n### Absolute Paths\nAlways provide absolute file paths in delegation prompts. Never use relative paths or expect agents to search for files.\n\n### Specific Deliverables\nDefine exactly what the agent should produce. Vague instructions like \"implement the feature\" lead to inconsistent results. Instead: \"Create UserService class with createUser(), getUserById(), and deleteUser() methods implementing the IUserService interface.\"\n\n### Validation Criteria\nInclude the exact command(s) to run after completion. The agent should run these and report results. Examples:\n- `npm run lint && npm run test`\n- `cargo build && cargo test`\n- `go vet .\u002F... && go test .\u002F...`\n- `python -m pytest tests\u002F`\n\n### No Interactive Commands in Delegation Prompts\nNever include interactive CLI commands in delegation prompts. Subagents run autonomously without user input. Interactive commands will hang indefinitely.\n\n\u003CANTI-PATTERN>\nWRONG — Delegation prompt includes interactive scaffolding:\n  \"Run `npx create-next-app@latest . --typescript --tailwind`\"\n  \"Run `npm init` to create package.json\"\n\nCORRECT — Delegation prompt specifies direct file creation:\n  \"Create package.json with the following content: ...\"\n  \"Create tsconfig.json, tailwind.config.ts, and src\u002Fapp\u002Flayout.tsx directly\"\n\u003C\u002FANTI-PATTERN>\n\n### Exclusions\nExplicitly state what the agent must NOT do:\n- Files it must not modify\n- Dependencies it must not add\n- Patterns it must not introduce\n- Scope it must not exceed\n\n## Agent Selection Guide\n\n| Task Domain | Agent | Key Capability |\n|-------------|-------|---------------|\n| React\u002FNext.js, UI\u002FUX, responsive design | `frontend_specialist` | Full read\u002Fwrite\u002Fshell — design systems, accessibility, Taste Skill Pack |\n| API, server architecture, backend logic | `backend_specialist` | Full read\u002Fwrite\u002Fshell — API patterns, middleware, auth |\n| Schema design, queries, migrations, indexing | `database_architect` | Full read\u002Fwrite\u002Fshell — ORM, query optimization |\n| OWASP 2025, supply chain, zero trust | `security_auditor` | Full read\u002Fwrite\u002Fshell + web search |\n| Offensive security, exploit analysis | `penetration_tester` | Full read\u002Fwrite\u002Fshell + web search |\n| Unit\u002Fintegration testing, TDD, coverage | `test_engineer` | Full read\u002Fwrite\u002Fshell |\n| E2E testing, Playwright, CI pipelines | `qa_automation_engineer` | Full read\u002Fwrite\u002Fshell |\n| Root cause analysis, crash investigation | `debugger` | Read + shell (no write) |\n| Profiling, Core Web Vitals, bundle size | `performance_optimizer` | Full read\u002Fwrite\u002Fshell + web search |\n| CI\u002FCD, deployment, server management | `devops_engineer` | Full read\u002Fwrite\u002Fshell + web search |\n| React Native, Flutter, mobile patterns | `mobile_developer` | Full read\u002Fwrite\u002Fshell |\n| Game mechanics, engines (Unity\u002FGodot\u002FPhaser) | `game_developer` | Full read\u002Fwrite\u002Fshell |\n| Technical documentation, READMEs, API docs | `documentation_writer` | Full read\u002Fwrite\u002Fshell |\n| Requirements, user stories, prioritization | `product_manager` | Read + shell (no write) |\n| Roadmap, backlog, stakeholder management | `product_owner` | Read + shell (no write) |\n| Task breakdown, dependency graphs, planning | `project_planner` | Read + shell (no write) |\n| Codebase discovery, architectural analysis | `explorer_agent` | Read + shell + web search (no write) |\n| Legacy code analysis, codebase archaeology | `code_archaeologist` | Read-only analysis |\n| SEO, GEO, E-E-A-T, Core Web Vitals | `seo_specialist` | Read + shell + web search + write |\n\n## Agent Tool Dispatch Contract\n\nDelegate to the assigned agent using the dispatch pattern from `get_runtime_context` (loaded at session start, step 0). Every gem-swarm agent in the Agent Roster carries its frontmatter configuration:\n\n- `temperature`: Controls output determinism (e.g., frontend_specialist uses 0.2 for precise code)\n- `max_turns`: Prevents runaway sessions (e.g., 25-30 turns for implementation agents)\n- `tools`: Restricts the agent to its authorized tool surface (e.g., read-only agents cannot use file-writing tools)\n- Body: Contains the agent's specialized methodology and decision frameworks\n\nUsing a generic\u002Fdefault agent tool bypasses all of this — it uses default temperature, has no turn limit, no tool restrictions, and no specialized methodology. Never use a generic agent tool for gem-swarm phase delegations.\n\nEvery delegation must include the required header fields:\n\n```\nAgent: \u003Cagent_name>\nPhase: \u003Cid>\u002F\u003Ctotal>\nBatch: \u003Cbatch_id> (or \"single\" for sequential)\nSession: \u003Csession_id>\n```\n\n**Sequential dispatch**: Invoke the agent using your runtime's dispatch mechanism with the full delegation prompt.\n\n**Parallel dispatch**: Emit contiguous agent dispatch calls in a single turn for all agents in the ready batch. Each call includes the same header format with the shared batch ID.\n\nCall `get_agent` with the agent name (as it appears in the implementation plan or Agent Roster) to load the agent methodology body, declared tool restrictions, and the runtime-specific `tool_name`. Use the returned `tool_name` as the dispatch target when invoking the agent tool. Runtime-local agent files remain registration stubs only; do not rely on them for the full methodology body.\n\n## Parallel Delegation\n\nParallel delegation uses the runtime's native subagent scheduler. The orchestrator emits contiguous agent tool calls inside a single turn; it does not write prompt files, spawn subprocesses, or call shell-based dispatch helpers.\n\n### Native Batch Construction\n\nFor each agent in a ready batch:\n\n1. Build a full delegation prompt using the same template as sequential delegation\n2. Include the required header:\n   - `Agent: \u003Cagent_name>`\n   - `Phase: \u003Cid>\u002F\u003Ctotal>`\n   - `Batch: \u003Cbatch_id>`\n   - `Session: \u003Csession_id>`\n3. Keep prompts self-contained with explicit files, deliverables, validation commands, exclusions, and dependency context\n4. Emit only contiguous agent tool calls for the current batch turn — no shell commands, file writes, or narration between them\n\nNative parallel batches may pause if an agent asks a follow-up question. Scope prompts tightly enough that questions are rare.\n\n### Same-Agent Parallel Dispatch\n\nWhen the implementation plan assigns the same agent to multiple parallel phases (see Same-Agent Decomposition in implementation-planning):\n\n1. **Unique Phase Headers**: Each dispatch MUST have a unique Phase ID:\n   ```\n   Agent: frontend_specialist\n   Phase: 3\u002F8\n   Batch: batch-2\n   Session: session-123\n   Sub-task: Hero Section + CTA (components\u002FHero.tsx, components\u002FCTA.tsx)\n   ```\n\n2. **Explicit File Isolation**: Each prompt lists ONLY its assigned files and explicitly excludes others:\n   ```\n   Files you own: components\u002FHero.tsx, components\u002FCTA.tsx\n   \n   Do NOT create or modify files assigned to other instances:\n   - components\u002FHeader.tsx (Phase 2)\n   - components\u002FFooter.tsx (Phase 4)\n   - globals.css, layout.tsx, page.tsx (Integration Phase 5)\n   ```\n\n3. **Shared Design Context**: All parallel instances receive the same upstream context (foundation phase outputs, design tokens, chosen style) but produce independent deliverables.\n\n4. **Integration Awareness**: Include in each prompt:\n   ```\n   Your output will be integrated with parallel work from other instances.\n   Export your components cleanly. Do NOT modify shared layout files.\n   Integration happens in a dedicated phase after all parallel instances complete.\n   ```\n\n### Review-Mode Delegation\n\nWhen dispatching review phases from the Automatic Quality Review Pipeline:\n\n1. **Read-Only Enforcement**: Review instances MUST NOT modify files. Override the agent's normal write capabilities:\n   ```\n   MODE: REVIEW ONLY\n   You have READ access to all project files but MUST NOT create, modify, or delete any files.\n   Your output is a structured findings report only.\n   ```\n\n2. **Focus Scoping**: Each review instance gets ONE quality dimension:\n   ```\n   REVIEW FOCUS: [Responsive Design \u002F Design Compliance \u002F Accessibility + Performance]\n   Review ONLY your assigned dimension. Do not duplicate work from other reviewers.\n   ```\n\n3. **Findings Format**: Enforce structured output for downstream aggregation:\n   ```\n   ## Findings Report: [Focus Area]\n   \n   ### Critical\n   - [file:line] Description. Suggested fix: ...\n   \n   ### Major  \n   - [file:line] Description. Suggested fix: ...\n   \n   ### Minor\n   - [file:line] Description. Suggested fix: ...\n   ```\n\n4. **Fix Phase Aggregation**: After all review instances return, aggregate all Critical + Major findings into a single Fix Phase prompt for the implementing agent.\n\n### Tool Restriction Enforcement\n\ngem-swarm enforces tool permissions at two levels:\n\n**Level 1: Native enforcement (primary)**\n\nTool permissions are enforced natively via each agent's registered frontmatter stub. Use the `tools` array returned by `get_agent` when you mirror that restriction in the prompt. This works for both sequential and parallel delegation.\n\n**Level 2: Prompt-based enforcement (defense-in-depth)**\n\nNative tool permissions remain the primary boundary. As defense-in-depth, every delegation prompt should still include an explicit tool restriction block so the agent sees its allowed surface in plain language.\n\n1. Agent Base Protocol (load `agent-base-protocol` via `get_skill_content`)\n2. Filesystem Safety Protocol (load `filesystem-safety-protocol` via `get_skill_content`)\n3. **TOOL RESTRICTIONS block (immediately here, before any task content)**\n4. **FILE WRITING RULES block (immediately after tool restrictions)**\n5. Context chain from prior phases\n6. Task-specific instructions\n7. Scope boundaries and prohibitions\n\nThe tool restriction block template:\n\n```\nTOOL RESTRICTIONS (MANDATORY):\nYou are authorized to use ONLY the following tools: [list from agent frontmatter].\nDo NOT use any tools not listed above. Specifically:\n- Do NOT use `write_file` or `replace` unless explicitly authorized above\n- Do NOT use `run_shell_command` unless explicitly authorized above\n- Do NOT create, modify, or delete files unless authorized above\nViolation of these restrictions constitutes a security boundary breach.\n```\n\nPopulate the tool list from the `tools` array returned by `get_agent` for the delegated agent.\n\nThe file writing rules block template:\n\n```\nFILE WRITING RULES (MANDATORY):\nUse ONLY `write_file` to create files and `replace` to modify files.\nDo NOT use `run_shell_command` with cat, echo, printf, heredocs, or shell redirection (>, >>) to write file content.\nShell interpretation corrupts YAML, Markdown, and special characters. This rule has NO exceptions.\n```\n\nThis block reinforces the Agent Base Protocol's File Writing Rule directly in every delegation prompt, ensuring agents see the prohibition even if they skim the injected protocols.\n\n### Non-Overlapping File Ownership\nWhen delegating to multiple agents in parallel, ensure no two agents are assigned the same file. Each file must have exactly one owner in a parallel batch.\n\n### Batch Completion Gates\nAll agents in a parallel batch must complete before:\n- The next batch of phases begins\n- Shared\u002Fcontainer files are updated\n- Validation checkpoints run\n- The orchestrator creates a git commit for the batch\n\n### Conflict Prevention\n- Assign non-overlapping file sets to each agent\n- Reserve shared files (barrel exports, configuration, dependency manifests) for a single agent or a post-batch update step\n- If two phases must modify the same file, they cannot run in parallel — execute them sequentially\n- Parallel agents must NOT create git commits — the orchestrator commits after validating the batch\n\n## Hook Integration\n\ngem-swarm hooks fire at agent boundaries during delegation, providing context injection and output validation. Understanding hook behavior is essential for constructing correct delegation prompts.\n\n### Agent Tracking\n\nBefore each agent dispatch, a hook tracks which agent is currently executing:\n\n- Preferred signal: the required `Agent: \u003Cagent_name>` header in the delegation prompt\n- Legacy fallbacks: `GEM_SWARM_CURRENT_AGENT` from the environment, then regex-based detection of patterns like `delegate to \u003Cagent>` or `@\u003Cagent>`\n\nThe detected agent name is persisted to `\u002Ftmp\u002Fmaestro-hooks\u002F\u003Csession-id>\u002Factive-agent` and cleared by the post-delegation hook on every allowed response (both successful validation and retry allow-through). On deny (malformed output), the active agent is preserved to enable re-validation on retry.\n\n### Session Context Injection\n\nWhen an active orchestration session exists, the pre-delegation hook parses `\u003CGEM_SWARM_STATE_DIR>\u002Fstate\u002Factive-session.md` and injects a compact context line into the agent's turn:\n\n```\nActive session: current_phase=3, status=in_progress\n```\n\nThis gives delegated agents awareness of where they sit in the orchestration workflow without requiring explicit context in every delegation prompt. The injection is automatic and requires no action from the orchestrator.\n\n### Handoff Format Enforcement\n\nAfter completion, the post-delegation hook validates that every subagent response contains both required handoff sections:\n\n- `## Task Report` (or `# Task Report`)\n- `## Downstream Context` (or `# Downstream Context`)\n\nIf either heading is missing:\n\n1. **First failure**: The hook blocks the response and requests a retry with a diagnostic message specifying which section is missing.\n2. **Second failure** (`stop_hook_active=true`, mapped to `stopHookActive` in JS): The hook allows the malformed response through to prevent infinite retry loops, logging a warning.\n\nThis enforcement is the runtime complement to the Output Handoff Contract defined in the agent-base-protocol. Delegation prompts do not need to re-state the retry mechanism — the hook handles it transparently.\n\n**Exception**: The TechLead\u002Forchestrator agent is excluded from validation. Only delegated subagents are subject to format enforcement.\n\n## Validation Criteria Templates\n\n### For Implementation Agents (`frontend_specialist`, `backend_specialist`, `database_architect`, `devops_engineer`, `mobile_developer`, `game_developer`)\n```\nValidation: [build command] && [lint command] && [test command]\n```\n\n### For Test Agents (`test_engineer`, `qa_automation_engineer`)\n```\nValidation: [test command]\nVerify: All new tests pass, report coverage metrics\n```\n\n### For Assessment Agents (`debugger`, `explorer_agent`, `code_archaeologist`, `performance_optimizer`, `product_manager`, `product_owner`, `project_planner`)\n```\nValidation: N\u002FA (assessment-only or read-only tools)\nVerify: Findings reference specific files and line numbers\n```\n\n### For Security Agents (`security_auditor`, `penetration_tester`)\n```\nValidation: Security scan tools + manual review\nVerify: Findings include severity, affected files, and remediation steps\n```\n\n### For Documentation Agents (`documentation_writer`)\n```\nValidation: Verify all links resolve, code examples are syntactically valid\n```\n\n### For Product Agents (`product_manager`, `product_owner`)\n```\nValidation: N\u002FA (requirements and strategy artifacts)\nVerify: Deliverables reference user needs and acceptance criteria\n```\n\n### For SEO Agent (`seo_specialist`)\n```\nValidation: SEO audit tools + Core Web Vitals check\nVerify: Recommendations reference specific pages and measurable metrics\n```\n","# Delegation Skill\n\nActivate this skill when delegating work to subagents during orchestration execution. This skill provides the templates, rules, and patterns for constructing effective delegation prompts that produce consistent, high-quality results.\n\n## Protocol Injection\n\nBefore constructing any delegation prompt, inject the shared agent base protocol:\n\n### Injection Steps\n1. Load `agent-base-protocol` via `get_skill_content`\n2. Load `filesystem-safety-protocol` via `get_skill_content`\n3. **Ultrawork Cascade** — If the current session has `ultrawork: true` in its state (set by the `\u002Fgem-swarm:ulw` command):\n   - Load `ultrawork` via `get_skill_content`\n   - Prepend the `[ULTRAWORK ACTIVE]` header block to the delegation prompt (after filesystem-safety-protocol, before task content):\n     ```\n     [ULTRAWORK ACTIVE]\n     Mode: Maximum Intensity\n     Gate: Build → Test → Output → Integration\n     ```\n   - The ultrawork skill content provides the behavioral enforcement rules the agent must follow\n4. Prepend all protocols to the delegation prompt (base protocol first, then filesystem safety, then ultrawork if active) — these appear before the task-specific content\n5. For each phase listed in the current phase's `blocked_by`, read `phases[].downstream_context` from session state and include it in the prompt\n6. If any required `downstream_context` is missing, include an explicit placeholder noting the missing dependency context (never omit silently)\n\nThe injected protocol ensures every agent follows consistent pre-work procedures and output formatting regardless of their specialization. When Ultrawork is active, agents additionally enforce pre-implementation gates, zero-excuses completion, anti-rationalization, mandatory verification gates, and anti-AI-filler rules.\n\n### Context Chain Construction\n\nEvery delegation prompt must include a context chain that connects the current phase to prior work:\n\n**Phase Context**: Include Downstream Context blocks from all completed phases that the current phase depends on (identified via `blocked_by` relationships in the implementation plan and sourced from session state `phases[].downstream_context`):\n```\nContext from completed phases:\n- Phase [N] ([agent]): [Downstream Context summary]\n  - Interfaces introduced: [list with file locations]\n  - Patterns established: [list]\n  - Integration points: [specific files, functions, endpoints]\n  - Warnings: [list]\n```\n\n**Accumulated Patterns**: Naming conventions, directory organization patterns, and architectural decisions established by earlier phases. This ensures phase 5 does not contradict patterns set in phase 2.\n\n**File Manifest**: Complete list of files created or modified in prior phases, so the agent knows what already exists and can import from or extend those files.\n\n**Missing Context Fallback**: If a blocked dependency has no stored downstream context, include a visible placeholder entry in the prompt:\n`- Phase [N] ([agent]): Downstream Context missing in session state — verify dependency output before implementation`\n\n### Downstream Consumer Declaration\n\nEvery delegation prompt must declare who will consume the agent's output:\n```\nYour output will be consumed by: [downstream agent name(s)] who need [specific information they require]\n```\n\nThis primes the agent to structure their Downstream Context section for maximum utility to the next agent in the chain.\n\n## Settings Override Application\n\nBefore constructing any delegation prompt, resolve configurable parameters:\n\n1. Read the agent's base definition frontmatter (`temperature`, `max_turns`, `timeout_mins`, `tools`)\n2. Do not invent Maestro-level model, temperature, turn, or timeout overrides. Native delegation uses agent frontmatter defaults plus any runtime-level agent configuration already active in the session.\n3. Include only task-relevant execution context in the prompt metadata\n4. If the agent appears in `GEM_SWARM_DISABLED_AGENTS`, do not construct a delegation prompt — report to the orchestrator that the agent is disabled\n\n## Delegation Prompt Template\n\nEvery delegation to a subagent must follow this structure:\n\n```\nTask: [One-line description of what to accomplish]\n\nProgress: Phase [N] of [M]: [Phase Name]\n\nFiles to modify:\n- \u002Fabsolute\u002Fpath\u002Fto\u002Ffile1.ext: [Specific change required]\n- \u002Fabsolute\u002Fpath\u002Fto\u002Ffile2.ext: [Specific change required]\n\nFiles to create:\n- \u002Fabsolute\u002Fpath\u002Fto\u002Fnew-file.ext: [Purpose and key contents]\n\nDeliverables:\n- [Concrete output 1]\n- [Concrete output 2]\n\nValidation: [command to run after completion, e.g., \"npm run lint && npm run test\"]\n\nContext:\n[Relevant information from the design document or previous phases]\n\nDo NOT:\n- [Explicit exclusion 1]\n- [Explicit exclusion 2]\n- Modify any files not listed above\n```\n\n## Scope Boundary Rules\n\n### Absolute Paths\nAlways provide absolute file paths in delegation prompts. Never use relative paths or expect agents to search for files.\n\n### Specific Deliverables\nDefine exactly what the agent should produce. Vague instructions like \"implement the feature\" lead to inconsistent results. Instead: \"Create UserService class with createUser(), getUserById(), and deleteUser() methods implementing the IUserService interface.\"\n\n### Validation Criteria\nInclude the exact command(s) to run after completion. The agent should run these and report results. Examples:\n- `npm run lint && npm run test`\n- `cargo build && cargo test`\n- `go vet .\u002F... && go test .\u002F...`\n- `python -m pytest tests\u002F`\n\n### No Interactive Commands in Delegation Prompts\nNever include interactive CLI commands in delegation prompts. Subagents run autonomously without user input. Interactive commands will hang indefinitely.\n\n\u003CANTI-PATTERN>\nWRONG — Delegation prompt includes interactive scaffolding:\n  \"Run `npx create-next-app@latest . --typescript --tailwind`\"\n  \"Run `npm init` to create package.json\"\n\nCORRECT — Delegation prompt specifies direct file creation:\n  \"Create package.json with the following content: ...\"\n  \"Create tsconfig.json, tailwind.config.ts, and src\u002Fapp\u002Flayout.tsx directly\"\n\u003C\u002FANTI-PATTERN>\n\n### Exclusions\nExplicitly state what the agent must NOT do:\n- Files it must not modify\n- Dependencies it must not add\n- Patterns it must not introduce\n- Scope it must not exceed\n\n## Agent Selection Guide\n\n| Task Domain | Agent | Key Capability |\n|-------------|-------|---------------|\n| React\u002FNext.js, UI\u002FUX, responsive design | `frontend_specialist` | Full read\u002Fwrite\u002Fshell — design systems, accessibility, Taste Skill Pack |\n| API, server architecture, backend logic | `backend_specialist` | Full read\u002Fwrite\u002Fshell — API patterns, middleware, auth |\n| Schema design, queries, migrations, indexing | `database_architect` | Full read\u002Fwrite\u002Fshell — ORM, query optimization |\n| OWASP 2025, supply chain, zero trust | `security_auditor` | Full read\u002Fwrite\u002Fshell + web search |\n| Offensive security, exploit analysis | `penetration_tester` | Full read\u002Fwrite\u002Fshell + web search |\n| Unit\u002Fintegration testing, TDD, coverage | `test_engineer` | Full read\u002Fwrite\u002Fshell |\n| E2E testing, Playwright, CI pipelines | `qa_automation_engineer` | Full read\u002Fwrite\u002Fshell |\n| Root cause analysis, crash investigation | `debugger` | Read + shell (no write) |\n| Profiling, Core Web Vitals, bundle size | `performance_optimizer` | Full read\u002Fwrite\u002Fshell + web search |\n| CI\u002FCD, deployment, server management | `devops_engineer` | Full read\u002Fwrite\u002Fshell + web search |\n| React Native, Flutter, mobile patterns | `mobile_developer` | Full read\u002Fwrite\u002Fshell |\n| Game mechanics, engines (Unity\u002FGodot\u002FPhaser) | `game_developer` | Full read\u002Fwrite\u002Fshell |\n| Technical documentation, READMEs, API docs | `documentation_writer` | Full read\u002Fwrite\u002Fshell |\n| Requirements, user stories, prioritization | `product_manager` | Read + shell (no write) |\n| Roadmap, backlog, stakeholder management | `product_owner` | Read + shell (no write) |\n| Task breakdown, dependency graphs, planning | `project_planner` | Read + shell (no write) |\n| Codebase discovery, architectural analysis | `explorer_agent` | Read + shell + web search (no write) |\n| Legacy code analysis, codebase archaeology | `code_archaeologist` | Read-only analysis |\n| SEO, GEO, E-E-A-T, Core Web Vitals | `seo_specialist` | Read + shell + web search + write |\n\n## Agent Tool Dispatch Contract\n\nDelegate to the assigned agent using the dispatch pattern from `get_runtime_context` (loaded at session start, step 0). Every gem-swarm agent in the Agent Roster carries its frontmatter configuration:\n\n- `temperature`: Controls output determinism (e.g., frontend_specialist uses 0.2 for precise code)\n- `max_turns`: Prevents runaway sessions (e.g., 25-30 turns for implementation agents)\n- `tools`: Restricts the agent to its authorized tool surface (e.g., read-only agents cannot use file-writing tools)\n- Body: Contains the agent's specialized methodology and decision frameworks\n\nUsing a generic\u002Fdefault agent tool bypasses all of this — it uses default temperature, has no turn limit, no tool restrictions, and no specialized methodology. Never use a generic agent tool for gem-swarm phase delegations.\n\nEvery delegation must include the required header fields:\n\n```\nAgent: \u003Cagent_name>\nPhase: \u003Cid>\u002F\u003Ctotal>\nBatch: \u003Cbatch_id> (or \"single\" for sequential)\nSession: \u003Csession_id>\n```\n\n**Sequential dispatch**: Invoke the agent using your runtime's dispatch mechanism with the full delegation prompt.\n\n**Parallel dispatch**: Emit contiguous agent dispatch calls in a single turn for all agents in the ready batch. Each call includes the same header format with the shared batch ID.\n\nCall `get_agent` with the agent name (as it appears in the implementation plan or Agent Roster) to load the agent methodology body, declared tool restrictions, and the runtime-specific `tool_name`. Use the returned `tool_name` as the dispatch target when invoking the agent tool. Runtime-local agent files remain registration stubs only; do not rely on them for the full methodology body.\n\n## Parallel Delegation\n\nParallel delegation uses the runtime's native subagent scheduler. The orchestrator emits contiguous agent tool calls inside a single turn; it does not write prompt files, spawn subprocesses, or call shell-based dispatch helpers.\n\n### Native Batch Construction\n\nFor each agent in a ready batch:\n\n1. Build a full delegation prompt using the same template as sequential delegation\n2. Include the required header:\n   - `Agent: \u003Cagent_name>`\n   - `Phase: \u003Cid>\u002F\u003Ctotal>`\n   - `Batch: \u003Cbatch_id>`\n   - `Session: \u003Csession_id>`\n3. Keep prompts self-contained with explicit files, deliverables, validation commands, exclusions, and dependency context\n4. Emit only contiguous agent tool calls for the current batch turn — no shell commands, file writes, or narration between them\n\nNative parallel batches may pause if an agent asks a follow-up question. Scope prompts tightly enough that questions are rare.\n\n### Same-Agent Parallel Dispatch\n\nWhen the implementation plan assigns the same agent to multiple parallel phases (see Same-Agent Decomposition in implementation-planning):\n\n1. **Unique Phase Headers**: Each dispatch MUST have a unique Phase ID:\n   ```\n   Agent: frontend_specialist\n   Phase: 3\u002F8\n   Batch: batch-2\n   Session: session-123\n   Sub-task: Hero Section + CTA (components\u002FHero.tsx, components\u002FCTA.tsx)\n   ```\n\n2. **Explicit File Isolation**: Each prompt lists ONLY its assigned files and explicitly excludes others:\n   ```\n   Files you own: components\u002FHero.tsx, components\u002FCTA.tsx\n   \n   Do NOT create or modify files assigned to other instances:\n   - components\u002FHeader.tsx (Phase 2)\n   - components\u002FFooter.tsx (Phase 4)\n   - globals.css, layout.tsx, page.tsx (Integration Phase 5)\n   ```\n\n3. **Shared Design Context**: All parallel instances receive the same upstream context (foundation phase outputs, design tokens, chosen style) but produce independent deliverables.\n\n4. **Integration Awareness**: Include in each prompt:\n   ```\n   Your output will be integrated with parallel work from other instances.\n   Export your components cleanly. Do NOT modify shared layout files.\n   Integration happens in a dedicated phase after all parallel instances complete.\n   ```\n\n### Review-Mode Delegation\n\nWhen dispatching review phases from the Automatic Quality Review Pipeline:\n\n1. **Read-Only Enforcement**: Review instances MUST NOT modify files. Override the agent's normal write capabilities:\n   ```\n   MODE: REVIEW ONLY\n   You have READ access to all project files but MUST NOT create, modify, or delete any files.\n   Your output is a structured findings report only.\n   ```\n\n2. **Focus Scoping**: Each review instance gets ONE quality dimension:\n   ```\n   REVIEW FOCUS: [Responsive Design \u002F Design Compliance \u002F Accessibility + Performance]\n   Review ONLY your assigned dimension. Do not duplicate work from other reviewers.\n   ```\n\n3. **Findings Format**: Enforce structured output for downstream aggregation:\n   ```\n   ## Findings Report: [Focus Area]\n   \n   ### Critical\n   - [file:line] Description. Suggested fix: ...\n   \n   ### Major  \n   - [file:line] Description. Suggested fix: ...\n   \n   ### Minor\n   - [file:line] Description. Suggested fix: ...\n   ```\n\n4. **Fix Phase Aggregation**: After all review instances return, aggregate all Critical + Major findings into a single Fix Phase prompt for the implementing agent.\n\n### Tool Restriction Enforcement\n\ngem-swarm enforces tool permissions at two levels:\n\n**Level 1: Native enforcement (primary)**\n\nTool permissions are enforced natively via each agent's registered frontmatter stub. Use the `tools` array returned by `get_agent` when you mirror that restriction in the prompt. This works for both sequential and parallel delegation.\n\n**Level 2: Prompt-based enforcement (defense-in-depth)**\n\nNative tool permissions remain the primary boundary. As defense-in-depth, every delegation prompt should still include an explicit tool restriction block so the agent sees its allowed surface in plain language.\n\n1. Agent Base Protocol (load `agent-base-protocol` via `get_skill_content`)\n2. Filesystem Safety Protocol (load `filesystem-safety-protocol` via `get_skill_content`)\n3. **TOOL RESTRICTIONS block (immediately here, before any task content)**\n4. **FILE WRITING RULES block (immediately after tool restrictions)**\n5. Context chain from prior phases\n6. Task-specific instructions\n7. Scope boundaries and prohibitions\n\nThe tool restriction block template:\n\n```\nTOOL RESTRICTIONS (MANDATORY):\nYou are authorized to use ONLY the following tools: [list from agent frontmatter].\nDo NOT use any tools not listed above. Specifically:\n- Do NOT use `write_file` or `replace` unless explicitly authorized above\n- Do NOT use `run_shell_command` unless explicitly authorized above\n- Do NOT create, modify, or delete files unless authorized above\nViolation of these restrictions constitutes a security boundary breach.\n```\n\nPopulate the tool list from the `tools` array returned by `get_agent` for the delegated agent.\n\nThe file writing rules block template:\n\n```\nFILE WRITING RULES (MANDATORY):\nUse ONLY `write_file` to create files and `replace` to modify files.\nDo NOT use `run_shell_command` with cat, echo, printf, heredocs, or shell redirection (>, >>) to write file content.\nShell interpretation corrupts YAML, Markdown, and special characters. This rule has NO exceptions.\n```\n\nThis block reinforces the Agent Base Protocol's File Writing Rule directly in every delegation prompt, ensuring agents see the prohibition even if they skim the injected protocols.\n\n### Non-Overlapping File Ownership\nWhen delegating to multiple agents in parallel, ensure no two agents are assigned the same file. Each file must have exactly one owner in a parallel batch.\n\n### Batch Completion Gates\nAll agents in a parallel batch must complete before:\n- The next batch of phases begins\n- Shared\u002Fcontainer files are updated\n- Validation checkpoints run\n- The orchestrator creates a git commit for the batch\n\n### Conflict Prevention\n- Assign non-overlapping file sets to each agent\n- Reserve shared files (barrel exports, configuration, dependency manifests) for a single agent or a post-batch update step\n- If two phases must modify the same file, they cannot run in parallel — execute them sequentially\n- Parallel agents must NOT create git commits — the orchestrator commits after validating the batch\n\n## Hook Integration\n\ngem-swarm hooks fire at agent boundaries during delegation, providing context injection and output validation. Understanding hook behavior is essential for constructing correct delegation prompts.\n\n### Agent Tracking\n\nBefore each agent dispatch, a hook tracks which agent is currently executing:\n\n- Preferred signal: the required `Agent: \u003Cagent_name>` header in the delegation prompt\n- Legacy fallbacks: `GEM_SWARM_CURRENT_AGENT` from the environment, then regex-based detection of patterns like `delegate to \u003Cagent>` or `@\u003Cagent>`\n\nThe detected agent name is persisted to `\u002Ftmp\u002Fmaestro-hooks\u002F\u003Csession-id>\u002Factive-agent` and cleared by the post-delegation hook on every allowed response (both successful validation and retry allow-through). On deny (malformed output), the active agent is preserved to enable re-validation on retry.\n\n### Session Context Injection\n\nWhen an active orchestration session exists, the pre-delegation hook parses `\u003CGEM_SWARM_STATE_DIR>\u002Fstate\u002Factive-session.md` and injects a compact context line into the agent's turn:\n\n```\nActive session: current_phase=3, status=in_progress\n```\n\nThis gives delegated agents awareness of where they sit in the orchestration workflow without requiring explicit context in every delegation prompt. The injection is automatic and requires no action from the orchestrator.\n\n### Handoff Format Enforcement\n\nAfter completion, the post-delegation hook validates that every subagent response contains both required handoff sections:\n\n- `## Task Report` (or `# Task Report`)\n- `## Downstream Context` (or `# Downstream Context`)\n\nIf either heading is missing:\n\n1. **First failure**: The hook blocks the response and requests a retry with a diagnostic message specifying which section is missing.\n2. **Second failure** (`stop_hook_active=true`, mapped to `stopHookActive` in JS): The hook allows the malformed response through to prevent infinite retry loops, logging a warning.\n\nThis enforcement is the runtime complement to the Output Handoff Contract defined in the agent-base-protocol. Delegation prompts do not need to re-state the retry mechanism — the hook handles it transparently.\n\n**Exception**: The TechLead\u002Forchestrator agent is excluded from validation. Only delegated subagents are subject to format enforcement.\n\n## Validation Criteria Templates\n\n### For Implementation Agents (`frontend_specialist`, `backend_specialist`, `database_architect`, `devops_engineer`, `mobile_developer`, `game_developer`)\n```\nValidation: [build command] && [lint command] && [test command]\n```\n\n### For Test Agents (`test_engineer`, `qa_automation_engineer`)\n```\nValidation: [test command]\nVerify: All new tests pass, report coverage metrics\n```\n\n### For Assessment Agents (`debugger`, `explorer_agent`, `code_archaeologist`, `performance_optimizer`, `product_manager`, `product_owner`, `project_planner`)\n```\nValidation: N\u002FA (assessment-only or read-only tools)\nVerify: Findings reference specific files and line numbers\n```\n\n### For Security Agents (`security_auditor`, `penetration_tester`)\n```\nValidation: Security scan tools + manual review\nVerify: Findings include severity, affected files, and remediation steps\n```\n\n### For Documentation Agents (`documentation_writer`)\n```\nValidation: Verify all links resolve, code examples are syntactically valid\n```\n\n### For Product Agents (`product_manager`, `product_owner`)\n```\nValidation: N\u002FA (requirements and strategy artifacts)\nVerify: Deliverables reference user needs and acceptance criteria\n```\n\n### For SEO Agent (`seo_specialist`)\n```\nValidation: SEO audit tools + Core Web Vitals check\nVerify: Recommendations reference specific pages and measurable metrics\n```\n",{"name":5,"description":7},"main","923c514d4d5e15bbfd65ec7eaf949a997679aa3e","src\u002Fskills\u002Fshared\u002Fdelegation","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm","https:\u002F\u002Fgithub.com\u002Fyqecea","15 y.o Data Science,Student","2026-04-26 20:00:27",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add yqecea\u002Fgem-swarm --skill delegation",{"tool":51,"command":52},"bunx","bunx skills add yqecea\u002Fgem-swarm --skill delegation",{"tool":54,"command":55},"pnpm","pnpm dlx skills add yqecea\u002Fgem-swarm --skill delegation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002FSKILL.md",true,[59,65],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"protocols\u002Fagent-base-protocol.md","REFERENCE","参考文档",13650,"https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002Fprotocols\u002Fagent-base-protocol.md",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"protocols\u002Ffilesystem-safety-protocol.md",2277,"https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002Fprotocols\u002Ffilesystem-safety-protocol.md",[70,83,97,108,119,142],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":33},"01M71C74XVPP23ST10E8MYJZA0","validation","Cross-cutting validation methodology for verifying phase outputs and project integrity","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fvalidation\u002FSKILL.md",[],[72,77,78,79,80,81,29,82],"integrity","methodology","phase","outputs","project","validation methodology",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":33},"01M71C72PTKRV481M975R3QDDE","session-management","Manages orchestration session state, tracking, and resumption","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fsession-management\u002FSKILL.md",[],[90,91,92,93,94,95,96],"session management","session","management","orchestration","state","tracking","session state",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":33},"01M71C6ZY1EGM4SGVYT4B2HHD7","implementation-planning","Generates detailed implementation plans from finalized designs","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fimplementation-planning\u002FSKILL.md",[],[104,105,106,107],"planning","implementation","implementation planning","plans",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":33},"01M71C6XQVGMDFJ50BP5SBDS76","execution","Phase execution methodology for orchestration workflows with error handling and completion protocols","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fexecution\u002FSKILL.md",[],[110,78,31,115,116,93,79,117,29,118],"error","workflows","protocols","error handling",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":133,"publishedAt":33},"01M71C6VY8APWMNK1XEJ3WP7A2","design-dialogue","Guides structured design conversations for complex engineering tasks","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdesign-dialogue\u002FSKILL.md",[125,128],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[134,135,136,137,138,29,139,140,141],"design dialogue","dialogue","design","guides","conversations","tasks","engineering","structured",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":154,"publishedAt":33},"01M71C6PFKHSVBPCES0VKGSD0Y","code-review","Standalone code review methodology for structured, severity-classified code assessment","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fcode-review\u002FSKILL.md",[148,151],{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":152,"categoryName":153,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000030","开发工程师",[155,156,157,158,159,29,160,78,141],"code","review","code review","standalone","severity","assessment"]