[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71C6XQVGMDFJ50BP5SBDS76":3,"skill-same:01M71C6XQVGMDFJ50BP5SBDS76":54},{"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":18,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":14,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":6,"ownerDescription":38,"updatedAt":39,"install":40,"resources":53},"01M71C6XQVGMDFJ50BP5SBDS76","execution",null,"Phase execution methodology for orchestration workflows with error handling and completion protocols","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\u002Fexecution\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27],"error","workflows","orchestration","phase","protocols","for","error handling","with","methodology","2026-11-10 10:12:30",false,"---\nname: execution\ndescription: Phase execution methodology for orchestration workflows with error handling and completion protocols\n---\n\n# Execution Skill\n\nActivate this skill during Phase 3 (Execution) of Maestro orchestration. This skill defines how Maestro executes implementation phases through native subagent delegation.\n\n## Execution Mode Gate\n\n### Step 0 — Express bypass (early return)\n\nIf `workflow_mode` is `express` in the current session, STOP HERE. Do not proceed\nto the execution mode gate. Do not prompt the user. Do not resolve execution mode.\nExpress always dispatches sequentially. Return to the Express Workflow and continue\nfrom the delegation step.\n\n### Step 0.5 — Ultrawork bypass (early return)\n\nIf `ultrawork` is `true` in the current session state (set by `\u002Fgem-swarm:ulw`), STOP HERE.\nCall `update_session` with `{ execution_mode: 'parallel', execution_backend: 'native', ultrawork: true }`.\nUltrawork always dispatches parallel with `GEM_SWARM_MAX_CONCURRENT` forced to `0` (full batch dispatch, no slicing).\nDo not prompt the user. Do not analyze parallelization ratios. Skip directly to delegation.\n\n\u003CHARD-GATE>\nThis gate MUST resolve before ANY delegation proceeds. Do not skip it. Do not defer it. Do not begin delegating to subagents until execution_mode is recorded in session state. If you reach a delegation step and execution_mode is not set, STOP and return here.\n\u003C\u002FHARD-GATE>\n\n### Step 1 — Read the configured mode\n\nRead `GEM_SWARM_EXECUTION_MODE` (default: `ask`).\n\n- If `parallel`: call `update_session` with `{ execution_mode: 'parallel', execution_backend: 'native' }` to record in session state. Skip to delegation.\n- If `sequential`: call `update_session` with `{ execution_mode: 'sequential', execution_backend: 'native' }` to record in session state. Skip to delegation.\n- If `ask`: proceed to Step 2.\n\n### Step 2 — Analyze the implementation plan\n\nBefore prompting the user, analyze the approved plan to generate a recommendation:\n\n1. Count total phases in the plan\n2. Count phases marked `parallel: true` (parallelizable phases)\n3. Count distinct parallel batches (groups of parallelizable phases at the same dependency depth)\n4. Count sequential-only phases (phases with `blocked_by` dependencies that prevent parallelization)\n5. Cross-check file ownership across all phases. If any two phases share a file in their `files` arrays, those phases CANNOT be parallel-eligible — subtract them from the parallelizable count. Report each overlap as an Overlapping-file Warning in the prompt.\n\n6. If `validate_plan` was called during planning and returned a `parallelization_profile`, use its `parallel_eligible` and `effective_batches` counts as the authoritative source for items 1-5 above. These are computed from actual dependency depths and override any manual flag-based counts. If `parallelization_profile` is not available, use the counts from items 1-5 as-is.\n\nRecord these counts — they feed into the prompt.\n\n### Step 3 — Determine the recommendation\n\n- If parallelizable phases ≤ 1 → auto-select **sequential**. Call `update_session` with `{ execution_mode: 'sequential', execution_backend: 'native' }`. Inform the user: \"All phases are sequential — no parallel batches available.\" Skip to delegation. Do NOT prompt with a choice. Do NOT call `ask_user`. Do NOT present options. (Parallelism requires at least 2 phases at the same dependency depth; a single parallel-eligible phase has nothing to batch with.)\n\n\u003CANTI-PATTERN>\nWRONG — 1 parallel-eligible phase but user still prompted:\n  Parallel-eligible Phases: 1\n  → Presented choice: \"Sequential (Recommended)\" \u002F \"Parallel\"\n\nWhen parallelizable phases ≤ 1, there is NO choice to make. Auto-select sequential\nand skip directly to delegation. Do not show a picker.\n\u003C\u002FANTI-PATTERN>\n\n- If parallelizable phases > 50% of total phases → recommend **parallel**\n- If parallelizable phases ≤ 50% but > 1 → recommend **sequential** (limited benefit)\n- The recommended option appears first in the `ask_user` options list with \"(Recommended)\" appended to its label. The non-recommended option MUST NOT include \"(Recommended)\" in its label.\n\n### Step 4 — Prompt the user\n\nCall `ask_user` with `type: 'choice'` using exactly one of these option sets:\n\n**When recommending parallel:**\n  options:\n    - label: \"Parallel (Recommended)\"\n      description: \"Spawn child agents for each ready batch where file ownership does not overlap.\"\n    - label: \"Sequential (High Precision)\"\n      description: \"Spawn one child agent at a time in dependency order.\"\n\n**When recommending sequential:**\n  options:\n    - label: \"Sequential (Recommended)\"\n      description: \"Spawn one child agent at a time in dependency order.\"\n    - label: \"Parallel\"\n      description: \"Spawn child agents for each ready batch where file ownership does not overlap.\"\n\n\u003CANTI-PATTERN>\nWRONG — Both options labeled \"(Recommended)\":\n  options:\n    - label: \"Parallel (Recommended)\"\n    - label: \"Sequential (High Precision) (Recommended)\"\n\nOnly ONE option receives the \"(Recommended)\" suffix. Never both.\n\u003C\u002FANTI-PATTERN>\n\nPrompt the user for a choice using the user-prompt tool from runtime context. Replace `[N]`, `[M]`, and `[B]` with actual counts from Step 2. The prompt should convey the execution mode analysis and offer two options as described above.\n### Step 5 — Record and proceed\n\n1. Call `update_session` with the selected `execution_mode` and `execution_backend: native`\n2. The tool atomically persists both fields\n3. Use the selected mode for the remainder of the session unless the user changes it\n\n### Mode-specific behavior\n\n- If `parallel` is selected and a ready batch has only one phase, execute it sequentially\n- If `sequential` is selected, preserve plan order even when phases are parallel-safe\n\n### Safety fallback\n\nIf `execution_mode` is not present in session state at the point where delegation is about to begin, STOP. Do not default to sequential. Return to this gate and resolve it. This catches any edge case where the gate was skipped.\n\n## State File Access\n\nWhen MCP state tools (`get_session_status`, `update_session`, `transition_phase`) are available, prefer them for state operations. They provide structured I\u002FO and atomic transitions.\n\nWhen MCP tools are not available, state lives inside `\u003CGEM_SWARM_STATE_DIR>` and is accessible through `read_file` and `write_file`.\n\nHelper scripts remain available for shell-injected command prompts:\n\n```bash\nnode \u003Cruntime-script-root>\u002Fread-state.js \u003Crelative-path>\nnode \u003Cruntime-script-root>\u002Fread-active-session.js\n```\n\n## Hook Lifecycle During Execution\n\nHooks fire automatically at agent boundaries. The orchestrator does not invoke them directly.\n\nThe hooks system tracks which agent is currently executing. Before each agent dispatch, a hook resolves the active agent identity from the required `Agent:` header first, then falls back to legacy env\u002Fregex detection, and injects compact session context. After completion, a hook validates that the response contains both `Task Report` and `Downstream Context`; it requests one retry on the first malformed response.\n\nThe hook state directory under `\u002Ftmp\u002Fmaestro-hooks\u002F\u003Csession-id>\u002F` is transient and separate from orchestration state.\n\n## Sequential Execution Protocol\n\nFor a sequential phase:\n\n1. Verify all `blocked_by` dependencies are completed\n2. Mark the phase `in_progress`\n3. Update `current_phase`\n4. Set `current_batch: null`\n5. Update the progress-tracking tool (use the tool names from `get_runtime_context`) before delegation\n6. Delegate to the assigned agent with the required header and full context\n7. Parse the returned handoff\n8. Update session state\n9. Mark the phase `completed` or `failed`\n10. Update the progress-tracking tool after the state update\n\n## Native Parallel Execution Protocol\n\nUse native parallel execution only for sibling phases at the same dependency depth with non-overlapping file ownership.\n\n### Batch Rules\n\n1. Verify all blocking phases for every phase in the batch are completed\n2. Slice the ready batch into the current dispatch chunk using `GEM_SWARM_MAX_CONCURRENT`\n3. Mark only the current chunk phases `in_progress`\n4. Set `current_batch` in session state for that chunk\n5. Write one in-progress todo item for the chunk\n6. In the next turn, emit only agent tool calls for that chunk\n7. Do not mix shell commands, validation commands, file writes, or narration between those agent calls\n8. `GEM_SWARM_MAX_CONCURRENT=0` means emit the entire ready batch in one turn\n\n### Native Constraints\n\n- The runtime only parallelizes contiguous agent calls in one turn\n- Native subagents currently run without user approval gates\n- `ask_user` remains available; a batch may pause while waiting for user input\n- If execution is interrupted, restart unfinished `in_progress` phases on resume instead of attempting to restore in-flight subagent interactions\n\n## Progress Context\n\nInclude the following in every delegation query body:\n\n```text\nProgress: Phase [N] of [M]: [Phase Name]\nSession: [session_id]\n```\n\nFor native parallel batches, also include the batch identifier in the required header:\n\n```text\nAgent: \u003Cagent_name>\nPhase: \u003Cid>\u002F\u003Ctotal>\nBatch: \u003Cbatch_id>\nSession: \u003Csession_id>\n```\n\n## Error Handling Protocol\n\nRecord all errors in session state with:\n\n- `agent`\n- `timestamp`\n- `type`\n- `message`\n- `resolution`\n\n### Retry Logic\n\n- Maximum retries per phase: `GEM_SWARM_MAX_RETRIES` (default `2`)\n- First failure: analyze, adjust context\u002Fscope, retry automatically\n- Subsequent failures up to the limit: continue retrying with clearer constraints\n- Limit exceeded: mark the phase `failed` and escalate to the user\n\nIncrement `retry_count` on each retry.\n\n### Timeout \u002F Termination Handling\n\nWhen a native subagent terminates early or exceeds its configured timeout:\n\n1. Record any useful partial output in session state\n2. Report what the agent was attempting\n3. Retry with narrower scope when reasonable\n4. Escalate if repeated failures continue\n\n### File Conflict Handling\n\nWhen a subagent reports a file conflict:\n\n1. Stop execution immediately\n2. Record the conflicting files and phases\n3. Do not attempt automatic merge resolution\n4. Ask the user how to proceed\n\n## Subagent Output Processing\n\nNative subagent results are wrapped. Do not assume the handoff begins at byte 0.\n\n### Parsing Rules\n\n1. Locate `## Task Report` (or `# Task Report`) inside the returned text\n2. Locate `## Downstream Context` (or `# Downstream Context`) inside the returned text\n3. Parse:\n   - status\n   - files created \u002F modified \u002F deleted\n   - downstream context fields\n   - validation result\n   - reported errors\n4. Persist the full raw output plus the parsed fields into session state\n\n### State Update Sequence\n\nAfter processing each handoff:\n\n1. Update the phase file manifests\n2. Update `downstream_context`\n3. Append any errors\n4. Aggregate token usage\n5. If validation passed, mark the phase `completed`\n6. If validation failed, trigger retry logic\n7. Update `updated`\n8. Advance or clear `current_batch` as each chunk finishes\n\n## Completion Protocol\n\nWhen all phases are completed:\n\n1. Verify there are no `failed` or `pending` phases\n2. Confirm plan deliverables are accounted for\n3. Run the final code-review gate for non-documentation changes\n4. Archive the session through `session-management`\n5. Present a final summary with deliverables, files changed, token usage, deviations, and review status\n","# Execution Skill\n\nActivate this skill during Phase 3 (Execution) of Maestro orchestration. This skill defines how Maestro executes implementation phases through native subagent delegation.\n\n## Execution Mode Gate\n\n### Step 0 — Express bypass (early return)\n\nIf `workflow_mode` is `express` in the current session, STOP HERE. Do not proceed\nto the execution mode gate. Do not prompt the user. Do not resolve execution mode.\nExpress always dispatches sequentially. Return to the Express Workflow and continue\nfrom the delegation step.\n\n### Step 0.5 — Ultrawork bypass (early return)\n\nIf `ultrawork` is `true` in the current session state (set by `\u002Fgem-swarm:ulw`), STOP HERE.\nCall `update_session` with `{ execution_mode: 'parallel', execution_backend: 'native', ultrawork: true }`.\nUltrawork always dispatches parallel with `GEM_SWARM_MAX_CONCURRENT` forced to `0` (full batch dispatch, no slicing).\nDo not prompt the user. Do not analyze parallelization ratios. Skip directly to delegation.\n\n\u003CHARD-GATE>\nThis gate MUST resolve before ANY delegation proceeds. Do not skip it. Do not defer it. Do not begin delegating to subagents until execution_mode is recorded in session state. If you reach a delegation step and execution_mode is not set, STOP and return here.\n\u003C\u002FHARD-GATE>\n\n### Step 1 — Read the configured mode\n\nRead `GEM_SWARM_EXECUTION_MODE` (default: `ask`).\n\n- If `parallel`: call `update_session` with `{ execution_mode: 'parallel', execution_backend: 'native' }` to record in session state. Skip to delegation.\n- If `sequential`: call `update_session` with `{ execution_mode: 'sequential', execution_backend: 'native' }` to record in session state. Skip to delegation.\n- If `ask`: proceed to Step 2.\n\n### Step 2 — Analyze the implementation plan\n\nBefore prompting the user, analyze the approved plan to generate a recommendation:\n\n1. Count total phases in the plan\n2. Count phases marked `parallel: true` (parallelizable phases)\n3. Count distinct parallel batches (groups of parallelizable phases at the same dependency depth)\n4. Count sequential-only phases (phases with `blocked_by` dependencies that prevent parallelization)\n5. Cross-check file ownership across all phases. If any two phases share a file in their `files` arrays, those phases CANNOT be parallel-eligible — subtract them from the parallelizable count. Report each overlap as an Overlapping-file Warning in the prompt.\n\n6. If `validate_plan` was called during planning and returned a `parallelization_profile`, use its `parallel_eligible` and `effective_batches` counts as the authoritative source for items 1-5 above. These are computed from actual dependency depths and override any manual flag-based counts. If `parallelization_profile` is not available, use the counts from items 1-5 as-is.\n\nRecord these counts — they feed into the prompt.\n\n### Step 3 — Determine the recommendation\n\n- If parallelizable phases ≤ 1 → auto-select **sequential**. Call `update_session` with `{ execution_mode: 'sequential', execution_backend: 'native' }`. Inform the user: \"All phases are sequential — no parallel batches available.\" Skip to delegation. Do NOT prompt with a choice. Do NOT call `ask_user`. Do NOT present options. (Parallelism requires at least 2 phases at the same dependency depth; a single parallel-eligible phase has nothing to batch with.)\n\n\u003CANTI-PATTERN>\nWRONG — 1 parallel-eligible phase but user still prompted:\n  Parallel-eligible Phases: 1\n  → Presented choice: \"Sequential (Recommended)\" \u002F \"Parallel\"\n\nWhen parallelizable phases ≤ 1, there is NO choice to make. Auto-select sequential\nand skip directly to delegation. Do not show a picker.\n\u003C\u002FANTI-PATTERN>\n\n- If parallelizable phases > 50% of total phases → recommend **parallel**\n- If parallelizable phases ≤ 50% but > 1 → recommend **sequential** (limited benefit)\n- The recommended option appears first in the `ask_user` options list with \"(Recommended)\" appended to its label. The non-recommended option MUST NOT include \"(Recommended)\" in its label.\n\n### Step 4 — Prompt the user\n\nCall `ask_user` with `type: 'choice'` using exactly one of these option sets:\n\n**When recommending parallel:**\n  options:\n    - label: \"Parallel (Recommended)\"\n      description: \"Spawn child agents for each ready batch where file ownership does not overlap.\"\n    - label: \"Sequential (High Precision)\"\n      description: \"Spawn one child agent at a time in dependency order.\"\n\n**When recommending sequential:**\n  options:\n    - label: \"Sequential (Recommended)\"\n      description: \"Spawn one child agent at a time in dependency order.\"\n    - label: \"Parallel\"\n      description: \"Spawn child agents for each ready batch where file ownership does not overlap.\"\n\n\u003CANTI-PATTERN>\nWRONG — Both options labeled \"(Recommended)\":\n  options:\n    - label: \"Parallel (Recommended)\"\n    - label: \"Sequential (High Precision) (Recommended)\"\n\nOnly ONE option receives the \"(Recommended)\" suffix. Never both.\n\u003C\u002FANTI-PATTERN>\n\nPrompt the user for a choice using the user-prompt tool from runtime context. Replace `[N]`, `[M]`, and `[B]` with actual counts from Step 2. The prompt should convey the execution mode analysis and offer two options as described above.\n### Step 5 — Record and proceed\n\n1. Call `update_session` with the selected `execution_mode` and `execution_backend: native`\n2. The tool atomically persists both fields\n3. Use the selected mode for the remainder of the session unless the user changes it\n\n### Mode-specific behavior\n\n- If `parallel` is selected and a ready batch has only one phase, execute it sequentially\n- If `sequential` is selected, preserve plan order even when phases are parallel-safe\n\n### Safety fallback\n\nIf `execution_mode` is not present in session state at the point where delegation is about to begin, STOP. Do not default to sequential. Return to this gate and resolve it. This catches any edge case where the gate was skipped.\n\n## State File Access\n\nWhen MCP state tools (`get_session_status`, `update_session`, `transition_phase`) are available, prefer them for state operations. They provide structured I\u002FO and atomic transitions.\n\nWhen MCP tools are not available, state lives inside `\u003CGEM_SWARM_STATE_DIR>` and is accessible through `read_file` and `write_file`.\n\nHelper scripts remain available for shell-injected command prompts:\n\n```bash\nnode \u003Cruntime-script-root>\u002Fread-state.js \u003Crelative-path>\nnode \u003Cruntime-script-root>\u002Fread-active-session.js\n```\n\n## Hook Lifecycle During Execution\n\nHooks fire automatically at agent boundaries. The orchestrator does not invoke them directly.\n\nThe hooks system tracks which agent is currently executing. Before each agent dispatch, a hook resolves the active agent identity from the required `Agent:` header first, then falls back to legacy env\u002Fregex detection, and injects compact session context. After completion, a hook validates that the response contains both `Task Report` and `Downstream Context`; it requests one retry on the first malformed response.\n\nThe hook state directory under `\u002Ftmp\u002Fmaestro-hooks\u002F\u003Csession-id>\u002F` is transient and separate from orchestration state.\n\n## Sequential Execution Protocol\n\nFor a sequential phase:\n\n1. Verify all `blocked_by` dependencies are completed\n2. Mark the phase `in_progress`\n3. Update `current_phase`\n4. Set `current_batch: null`\n5. Update the progress-tracking tool (use the tool names from `get_runtime_context`) before delegation\n6. Delegate to the assigned agent with the required header and full context\n7. Parse the returned handoff\n8. Update session state\n9. Mark the phase `completed` or `failed`\n10. Update the progress-tracking tool after the state update\n\n## Native Parallel Execution Protocol\n\nUse native parallel execution only for sibling phases at the same dependency depth with non-overlapping file ownership.\n\n### Batch Rules\n\n1. Verify all blocking phases for every phase in the batch are completed\n2. Slice the ready batch into the current dispatch chunk using `GEM_SWARM_MAX_CONCURRENT`\n3. Mark only the current chunk phases `in_progress`\n4. Set `current_batch` in session state for that chunk\n5. Write one in-progress todo item for the chunk\n6. In the next turn, emit only agent tool calls for that chunk\n7. Do not mix shell commands, validation commands, file writes, or narration between those agent calls\n8. `GEM_SWARM_MAX_CONCURRENT=0` means emit the entire ready batch in one turn\n\n### Native Constraints\n\n- The runtime only parallelizes contiguous agent calls in one turn\n- Native subagents currently run without user approval gates\n- `ask_user` remains available; a batch may pause while waiting for user input\n- If execution is interrupted, restart unfinished `in_progress` phases on resume instead of attempting to restore in-flight subagent interactions\n\n## Progress Context\n\nInclude the following in every delegation query body:\n\n```text\nProgress: Phase [N] of [M]: [Phase Name]\nSession: [session_id]\n```\n\nFor native parallel batches, also include the batch identifier in the required header:\n\n```text\nAgent: \u003Cagent_name>\nPhase: \u003Cid>\u002F\u003Ctotal>\nBatch: \u003Cbatch_id>\nSession: \u003Csession_id>\n```\n\n## Error Handling Protocol\n\nRecord all errors in session state with:\n\n- `agent`\n- `timestamp`\n- `type`\n- `message`\n- `resolution`\n\n### Retry Logic\n\n- Maximum retries per phase: `GEM_SWARM_MAX_RETRIES` (default `2`)\n- First failure: analyze, adjust context\u002Fscope, retry automatically\n- Subsequent failures up to the limit: continue retrying with clearer constraints\n- Limit exceeded: mark the phase `failed` and escalate to the user\n\nIncrement `retry_count` on each retry.\n\n### Timeout \u002F Termination Handling\n\nWhen a native subagent terminates early or exceeds its configured timeout:\n\n1. Record any useful partial output in session state\n2. Report what the agent was attempting\n3. Retry with narrower scope when reasonable\n4. Escalate if repeated failures continue\n\n### File Conflict Handling\n\nWhen a subagent reports a file conflict:\n\n1. Stop execution immediately\n2. Record the conflicting files and phases\n3. Do not attempt automatic merge resolution\n4. Ask the user how to proceed\n\n## Subagent Output Processing\n\nNative subagent results are wrapped. Do not assume the handoff begins at byte 0.\n\n### Parsing Rules\n\n1. Locate `## Task Report` (or `# Task Report`) inside the returned text\n2. Locate `## Downstream Context` (or `# Downstream Context`) inside the returned text\n3. Parse:\n   - status\n   - files created \u002F modified \u002F deleted\n   - downstream context fields\n   - validation result\n   - reported errors\n4. Persist the full raw output plus the parsed fields into session state\n\n### State Update Sequence\n\nAfter processing each handoff:\n\n1. Update the phase file manifests\n2. Update `downstream_context`\n3. Append any errors\n4. Aggregate token usage\n5. If validation passed, mark the phase `completed`\n6. If validation failed, trigger retry logic\n7. Update `updated`\n8. Advance or clear `current_batch` as each chunk finishes\n\n## Completion Protocol\n\nWhen all phases are completed:\n\n1. Verify there are no `failed` or `pending` phases\n2. Confirm plan deliverables are accounted for\n3. Run the final code-review gate for non-documentation changes\n4. Archive the session through `session-management`\n5. Present a final summary with deliverables, files changed, token usage, deviations, and review status\n",{"name":5,"description":7},"main","923c514d4d5e15bbfd65ec7eaf949a997679aa3e","src\u002Fskills\u002Fshared\u002Fexecution","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":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add yqecea\u002Fgem-swarm --skill execution",{"tool":46,"command":47},"bunx","bunx skills add yqecea\u002Fgem-swarm --skill execution",{"tool":49,"command":50},"pnpm","pnpm dlx skills add yqecea\u002Fgem-swarm --skill execution","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fexecution\u002FSKILL.md",true,[],[55,66,79,90,115,132],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":28},"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",[],[57,62,24,63,64,22,27,65],"validation methodology","project","outputs","integrity",{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":28},"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",[],[73,74,75,76,77,78,21],"session management","session","management","session state","tracking","state",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":28},"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",[],[86,87,88,89],"planning","implementation","implementation planning","plans",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":106,"publishedAt":28},"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",[96,101],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[107,108,109,110,111,24,112,113,114],"design dialogue","design","dialogue","structured","conversations","tasks","guides","engineering",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":127,"publishedAt":28},"01M71C6R4RJWG3S2R26778TPD8","delegation","Agent delegation best practices for constructing effective subagent prompts with proper scoping","https:\u002F\u002Fgithub.com\u002Fyqecea\u002Fgem-swarm\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fshared\u002Fdelegation\u002FSKILL.md",[121,124],{"categoryNo":122,"categoryName":123,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":125,"categoryName":126,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发",[117,24,128,129,130,26,131],"subagent","scoping","best practices","prompts",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":144,"publishedAt":28},"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",[138,141],{"categoryNo":139,"categoryName":140,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":142,"categoryName":143,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000030","开发工程师",[145,146,147,148,149,24,150,27,110],"code","code review","review","standalone","severity","assessment"]