[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PET8B44WPYMSS38Y6CABZ2":3,"skill-same:01M6PET8B44WPYMSS38Y6CABZ2":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6PET8B44WPYMSS38Y6CABZ2","ralplan",null,"Consensus planning entrypoint that auto-gates vague ralph\u002Fautopilot\u002Fteam requests before execution","r3dlex\u002Foh-my-githubcopilot","r3dlex","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F291373160?v=4","01M6PEFNGGBVB7SHAPWXFFX933","01M6PEFNMNKPP8K3C881MDS722",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fskills\u002Fralplan\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30],"planning","execution","team","ralph","consensus","auto","gates","omp","autopilot","false","requests","entrypoint","vague","2026-11-10 10:12:30",false,"---\nname: ralplan\ndescription: Consensus planning entrypoint that auto-gates vague ralph\u002Fautopilot\u002Fteam requests before execution\ntrigger: \"\u002Fomp:ralplan\"\nautoinvoke: false\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is a shorthand alias for `\u002Fomp:plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).\n\n## Usage\n\n```\n\u002Fomp:ralplan \"task description\"\n```\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit\u002Fintegration\u002Fe2e\u002Fobservability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth\u002Fsecurity, migrations, destructive changes, production incidents, compliance\u002FPII, public API breakage).\n\n## Usage with interactive mode\n\n```\n\u002Fomp:ralplan --interactive \"task description\"\n```\n\n## Behavior\n\nThis skill invokes the Plan skill in consensus mode:\n\n```\n\u002Fomp:plan --consensus \u003Carguments>\n```\n\nThe consensus workflow:\n1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:\n   - Principles (3-5)\n   - Decision Drivers (top 3)\n   - Viable Options (>=2) with bounded pros\u002Fcons\n   - If only one viable option remains, explicit invalidation rationale for alternatives\n   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit\u002Fintegration\u002Fe2e\u002Fobservability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles \u002F Drivers \u002F Options summary** before review (Proceed to review \u002F Request changes \u002F Skip review). Otherwise, automatically proceed to review.\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.\n\n   > Adopt the Architect role: \"Review this plan for architectural soundness. Provide the strongest steelman antithesis against the favored option, at least one real tradeoff tension, and a synthesis path where possible.\"\n\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing\u002Fweak pre-mortem or expanded test plan.\n\n   > Adopt the Critic role: \"Evaluate this plan. Verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification.\"\n\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n   a. Collect Architect + Critic feedback\n   b. Revise the plan with Planner\n   c. Return to Architect review\n   d. Return to Critic evaluation\n   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n   f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options:\n   - **Approve and implement via team** (Recommended) — proceed via `omp:team`\n   - **Approve and execute via ralph** — proceed via `omp:ralph`\n   - **Clear context and implement** — compact context first, then `omp:ralph` with the saved plan file\n   - **Request changes** — return to step 1\n   - **Reject** — discard the plan entirely\n   Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups).\n   Otherwise (non-interactive), output the final plan and stop.\n7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject\n8. *(--interactive only)* On approval: invoke `omp:team` for parallel team execution (recommended) or `omp:ralph` for sequential execution — never implement directly\n\n> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent reviews in the same parallel batch. Always await the Architect result before issuing the Critic evaluation.\n\nFollow the omp-plan skill's full documentation for consensus mode details.\n\n---\n\n## Pre-Execution Gate\n\n### Why the Gate Exists\n\nExecution modes (omp:ralph, omp:autopilot, omp:team, omp:ultrawork) spin up heavy multi-agent orchestration. When launched on a vague request like \"ralph improve the app\", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.\n\nThe ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:\n- **Explicit scope**: A PRD defines exactly what will be built\n- **Test specification**: Acceptance criteria are testable before code is written\n- **Consensus**: Planner, Architect, and Critic agree on the approach\n- **No wasted execution**: Agents start with a clear, bounded task\n\n### Good vs Bad Prompts\n\n**Passes the gate** (specific enough for direct execution):\n- `ralph fix the null check in src\u002Fhooks\u002Fbridge.ts:326`\n- `autopilot implement issue #42`\n- `team add validation to function processKeywordDetector`\n- `ralph do:\\n1. Add input validation\\n2. Write tests\\n3. Update README`\n- `ultrawork add the user model in src\u002Fmodels\u002Fuser.ts`\n\n**Gated — redirected to ralplan** (needs scoping first):\n- `ralph fix this`\n- `autopilot build the app`\n- `team improve performance`\n- `ralph add authentication`\n- `ultrawork make it better`\n\n**Bypass the gate** (when you know what you want):\n- `force: ralph refactor the auth module`\n- `! autopilot optimize everything`\n\n### When the Gate Does NOT Trigger\n\nThe gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:\n\n| Signal Type | Example prompt | Why it passes |\n|---|---|---|\n| File path | `ralph fix src\u002Fhooks\u002Fbridge.ts` | References a specific file |\n| Issue\u002FPR number | `ralph implement #42` | Has a concrete work item |\n| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |\n| PascalCase symbol | `ralph update UserModel` | Names a specific class |\n| snake_case symbol | `team fix user_model` | Names a specific identifier |\n| Test runner | `ralph npm test && fix failures` | Has an explicit test target |\n| Numbered steps | `ralph do:\\n1. Add X\\n2. Test Y` | Structured deliverables |\n| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |\n| Error reference | `ralph fix TypeError in auth` | Specific error to address |\n| Code block | `ralph add: \\`\\`\\`ts ... \\`\\`\\`` | Concrete code provided |\n| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |\n\n### End-to-End Flow Example\n\n1. User types: `ralph add user authentication`\n2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)\n3. Gate redirects to **ralplan** with message explaining the redirect\n4. Ralplan consensus runs:\n   - **Planner** creates initial plan (which files, what auth method, what tests)\n   - **Architect** reviews for soundness\n   - **Critic** validates quality and testability\n5. On consensus approval, user chooses execution path:\n   - **omp:team**: parallel coordinated agents (recommended)\n   - **omp:ralph**: sequential execution with verification\n6. Execution begins with a clear, bounded plan\n\n### Troubleshooting\n\n| Issue | Solution |\n|-------|----------|\n| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |\n| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |\n| Gate does not fire on a vague prompt | The gate only catches prompts with \u003C=15 effective words and no concrete anchors; add more detail or use `\u002Fomp:ralplan` explicitly |\n| Redirected to ralplan but want to skip planning | In the ralplan workflow, say \"just do it\" or \"skip planning\" to transition directly to execution |\n","# Ralplan (Consensus Planning Alias)\n\nRalplan is a shorthand alias for `\u002Fomp:plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).\n\n## Usage\n\n```\n\u002Fomp:ralplan \"task description\"\n```\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit\u002Fintegration\u002Fe2e\u002Fobservability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth\u002Fsecurity, migrations, destructive changes, production incidents, compliance\u002FPII, public API breakage).\n\n## Usage with interactive mode\n\n```\n\u002Fomp:ralplan --interactive \"task description\"\n```\n\n## Behavior\n\nThis skill invokes the Plan skill in consensus mode:\n\n```\n\u002Fomp:plan --consensus \u003Carguments>\n```\n\nThe consensus workflow:\n1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:\n   - Principles (3-5)\n   - Decision Drivers (top 3)\n   - Viable Options (>=2) with bounded pros\u002Fcons\n   - If only one viable option remains, explicit invalidation rationale for alternatives\n   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit\u002Fintegration\u002Fe2e\u002Fobservability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles \u002F Drivers \u002F Options summary** before review (Proceed to review \u002F Request changes \u002F Skip review). Otherwise, automatically proceed to review.\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.\n\n   > Adopt the Architect role: \"Review this plan for architectural soundness. Provide the strongest steelman antithesis against the favored option, at least one real tradeoff tension, and a synthesis path where possible.\"\n\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing\u002Fweak pre-mortem or expanded test plan.\n\n   > Adopt the Critic role: \"Evaluate this plan. Verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification.\"\n\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n   a. Collect Architect + Critic feedback\n   b. Revise the plan with Planner\n   c. Return to Architect review\n   d. Return to Critic evaluation\n   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n   f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options:\n   - **Approve and implement via team** (Recommended) — proceed via `omp:team`\n   - **Approve and execute via ralph** — proceed via `omp:ralph`\n   - **Clear context and implement** — compact context first, then `omp:ralph` with the saved plan file\n   - **Request changes** — return to step 1\n   - **Reject** — discard the plan entirely\n   Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups).\n   Otherwise (non-interactive), output the final plan and stop.\n7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject\n8. *(--interactive only)* On approval: invoke `omp:team` for parallel team execution (recommended) or `omp:ralph` for sequential execution — never implement directly\n\n> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent reviews in the same parallel batch. Always await the Architect result before issuing the Critic evaluation.\n\nFollow the omp-plan skill's full documentation for consensus mode details.\n\n---\n\n## Pre-Execution Gate\n\n### Why the Gate Exists\n\nExecution modes (omp:ralph, omp:autopilot, omp:team, omp:ultrawork) spin up heavy multi-agent orchestration. When launched on a vague request like \"ralph improve the app\", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.\n\nThe ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:\n- **Explicit scope**: A PRD defines exactly what will be built\n- **Test specification**: Acceptance criteria are testable before code is written\n- **Consensus**: Planner, Architect, and Critic agree on the approach\n- **No wasted execution**: Agents start with a clear, bounded task\n\n### Good vs Bad Prompts\n\n**Passes the gate** (specific enough for direct execution):\n- `ralph fix the null check in src\u002Fhooks\u002Fbridge.ts:326`\n- `autopilot implement issue #42`\n- `team add validation to function processKeywordDetector`\n- `ralph do:\\n1. Add input validation\\n2. Write tests\\n3. Update README`\n- `ultrawork add the user model in src\u002Fmodels\u002Fuser.ts`\n\n**Gated — redirected to ralplan** (needs scoping first):\n- `ralph fix this`\n- `autopilot build the app`\n- `team improve performance`\n- `ralph add authentication`\n- `ultrawork make it better`\n\n**Bypass the gate** (when you know what you want):\n- `force: ralph refactor the auth module`\n- `! autopilot optimize everything`\n\n### When the Gate Does NOT Trigger\n\nThe gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:\n\n| Signal Type | Example prompt | Why it passes |\n|---|---|---|\n| File path | `ralph fix src\u002Fhooks\u002Fbridge.ts` | References a specific file |\n| Issue\u002FPR number | `ralph implement #42` | Has a concrete work item |\n| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |\n| PascalCase symbol | `ralph update UserModel` | Names a specific class |\n| snake_case symbol | `team fix user_model` | Names a specific identifier |\n| Test runner | `ralph npm test && fix failures` | Has an explicit test target |\n| Numbered steps | `ralph do:\\n1. Add X\\n2. Test Y` | Structured deliverables |\n| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |\n| Error reference | `ralph fix TypeError in auth` | Specific error to address |\n| Code block | `ralph add: \\`\\`\\`ts ... \\`\\`\\`` | Concrete code provided |\n| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |\n\n### End-to-End Flow Example\n\n1. User types: `ralph add user authentication`\n2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)\n3. Gate redirects to **ralplan** with message explaining the redirect\n4. Ralplan consensus runs:\n   - **Planner** creates initial plan (which files, what auth method, what tests)\n   - **Architect** reviews for soundness\n   - **Critic** validates quality and testability\n5. On consensus approval, user chooses execution path:\n   - **omp:team**: parallel coordinated agents (recommended)\n   - **omp:ralph**: sequential execution with verification\n6. Execution begins with a clear, bounded plan\n\n### Troubleshooting\n\n| Issue | Solution |\n|-------|----------|\n| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |\n| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |\n| Gate does not fire on a vague prompt | The gate only catches prompts with \u003C=15 effective words and no concrete anchors; add more detail or use `\u002Fomp:ralplan` explicitly |\n| Redirected to ralplan but want to skip planning | In the ralplan workflow, say \"just do it\" or \"skip planning\" to transition directly to execution |\n",{"name":5,"trigger":36,"autoinvoke":32,"description":7},"\u002Fomp:ralplan","main","55294682936bc69473eba70e93ffa88ede018e81","skills\u002Fralplan",0,"https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot","https:\u002F\u002Fgithub.com\u002Fr3dlex","2026-10-31 18:57:35",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add r3dlex\u002Foh-my-githubcopilot --skill ralplan",{"tool":50,"command":51},"bunx","bunx skills add r3dlex\u002Foh-my-githubcopilot --skill ralplan",{"tool":53,"command":54},"pnpm","pnpm dlx skills add r3dlex\u002Foh-my-githubcopilot --skill ralplan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fskills\u002Fralplan\u002FSKILL.md",true,[],[59,65,71,77,82,90],{"skillNo":60,"name":61,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":31},"01M6PF2CTFS0AEXQXF2NFYT8J2","wiki","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Fwiki\u002FSKILL.md",[],[61],{"skillNo":66,"name":67,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":31},"01M6PF2BFXJ97M6NKH7N42XZVZ","ultrawork","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Fultrawork\u002FSKILL.md",[],[67],{"skillNo":72,"name":73,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":31},"01M6PF2A38Y1CE5BVJ5HMTMBP6","trace","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Ftrace\u002FSKILL.md",[],[73],{"skillNo":78,"name":20,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":31},"01M6PF28P7S19AK5XJA41WS9V8","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Fteam\u002FSKILL.md",[],[20],{"skillNo":83,"name":84,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":31},"01M6PF278EADT8W3EWDYA3C2H0","swe-bench","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Fswe-bench\u002FSKILL.md",[],[88,89],"SWE","swe bench",{"skillNo":91,"name":92,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":31},"01M6PF25XW1TMP5Z1N89ZVJQDY","swarm","https:\u002F\u002Fgithub.com\u002Fr3dlex\u002Foh-my-githubcopilot\u002Fblob\u002Fmain\u002Fvscode-omp\u002Fresources\u002Ftemplates\u002F.copilot\u002Fskills\u002Fswarm\u002FSKILL.md",[],[92]]