[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DBP80708KCW6W4K7HKATR9":3,"skill-same:01M6DBP80708KCW6W4K7HKATR9":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":34,"commitSha":35,"skillDirectory":36,"forksCount":14,"repositoryHtmlUrl":37,"repositoryHomepageUrl":6,"ownerHtmlUrl":38,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":39,"install":40,"resources":53},"01M6DBP80708KCW6W4K7HKATR9","plan-orchestrate",null,"Use when converting a multi-step plan into dependency-aware agent chains and ready-to-run orchestration prompts without executing the plan.","Prekzursil\u002Fagent-skills-toolchain","Prekzursil","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54636077?v=4","01M6DACZ1PCQHD99SCR1YXG28B","Andrei Mihai Visalon","01M6DACZ670WZF535V3WYYSS4Z",0,"MIT","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplan-orchestrate\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"orchestrate","plan","plan orchestrate","orchestration","run","use","dependency","ready","prompts","2026-11-10 10:12:30",false,"---\nname: plan-orchestrate\ndescription: \"Use when converting a multi-step plan into dependency-aware agent chains and ready-to-run orchestration prompts without executing the plan.\"\norigin: ECC\n---\n\n# Plan Orchestrate\n\nBridge a plan document to `\u002Forchestrate custom` by emitting one ready-to-paste invocation per step. The skill is generative only — it never executes `\u002Forchestrate`. The user pastes each line when ready.\n\n## When to Activate\n\n- User has a multi-step plan document (PRD, RFC, implementation plan) and wants to drive it through `\u002Forchestrate`.\n- User says \"orchestrate this plan\", \"give me orchestrate prompts for each step\", \"compose chains for this plan\".\n- A step-by-step plan exists but the user does not want to manually pick agents per step.\n\nSkip when:\n- The work is one ad-hoc step → call `\u002Forchestrate custom` directly.\n- The plan is unreadable or empty. Lack of explicit numbering alone is not a skip condition — see the \"No clear steps\" edge case below.\n\n## Inputs\n\n```\n\u003Cplan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:\u003Cn>|range:\u003Ca>-\u003Cb>] [--dry-run]\n```\n\n- `\u003Cplan-doc-path>` — required; relative or absolute path (`@docs\u002F...` accepted).\n- `--lang` — reviewer language variant; defaults to `auto` (detected from project).\n- `--scope` — limits emitted steps; defaults to `all`.\n- `--dry-run` — print decomposition + chain rationale only; do not emit final prompts.\n\n## Authoritative `\u002Forchestrate` shape (do not deviate)\n\n```\n{ORCH_CMD} custom \"\u003Cagent1>,\u003Cagent2>,...,\u003CagentN>\" \"\u003Ctask description>\"\n```\n\nWhere `{ORCH_CMD}` is determined in Phase 0 (see below). The command string in the emitted output **always uses one concrete form** — never both, never a placeholder.\n\n- `custom` is a sequential chain; each agent's HANDOFF feeds the next.\n- Comma-separated agent list. No spaces preferred; one space tolerated.\n- No `--mode` \u002F `--gate` \u002F `--agents=...` flags exist — never invent them.\n- Agent names come from the catalogue in this skill. Embedded double quotes in the task description are escaped as `\\\"`.\n\n## ECC install form and namespacing\n\nTwo install forms determine the prefix on **both** the slash command and every agent name. The two MUST stay in sync — one form per output, never mixed:\n\nLet `\u003Cclaude-home>` denote the Claude Code home directory: `~\u002F.claude` on macOS\u002FLinux, `%USERPROFILE%\\.claude` on Windows. Resolve it the way the host platform resolves the user home directory (do not hardcode `~`).\n\n| Form | Detection | `{ORCH_CMD}` | Agent name format |\n|---|---|---|---|\n| Plugin install (1.9.0+) | `\u003Cclaude-home>\u002Fplugins\u002Fmarketplaces\u002Feverything-claude-code\u002F` exists | `\u002Feverything-claude-code:orchestrate` | `everything-claude-code:\u003Cname>` |\n| Legacy bare install | Above absent; agent files under `\u003Cclaude-home>\u002Fagents\u002F` | `\u002Forchestrate` | `\u003Cname>` |\n\nWhy this matters: under the plugin install, agents register as `everything-claude-code:tdd-guide`. Bare names force fuzzy matching, which fails intermittently under parallel calls. Under legacy, the prefixed forms are not registered and fail outright.\n\n## Available agent catalogue (must pick from these)\n\nGeneral:\n- `planner` — requirement restatement, risk decomposition, step planning\n- `architect` — architecture, system design, refactor proposals\n- `tdd-guide` — write tests → implement → 80%+ coverage\n- `code-reviewer` — generic code review\n- `security-reviewer` — security audit, OWASP, secret leakage\n- `refactor-cleaner` — dead code, duplicates, knip-class cleanup\n- `doc-updater` — documentation, codemap, README\n- `docs-lookup` — third-party library API lookups (Context7)\n- `e2e-runner` — end-to-end test orchestration\n- `database-reviewer` — PostgreSQL schema, migration, performance\n- `harness-optimizer` — local agent harness configuration\n- `loop-operator` — long-running autonomous loops\n- `chief-of-staff` — multi-channel triage (rarely a fit for plan steps)\n\nBuild error resolvers:\n- `build-error-resolver` (generic) \u002F `cpp-build-resolver` \u002F `go-build-resolver` \u002F `java-build-resolver` \u002F `kotlin-build-resolver` \u002F `rust-build-resolver` \u002F `pytorch-build-resolver`\n\nCode reviewers:\n- `python-reviewer` \u002F `typescript-reviewer` \u002F `go-reviewer` \u002F `rust-reviewer` \u002F `cpp-reviewer` \u002F `java-reviewer` \u002F `kotlin-reviewer` \u002F `flutter-reviewer`\n\nA misspelled agent name fails `\u002Forchestrate`. Cross-check against this list before emitting.\n\n## How It Works\n\n### Phase 0 — Detect ECC mode + language\n\n1. Read `\u003Cplan-doc-path>`. If missing or empty, report and stop.\n2. Detect ECC install form once and freeze it into `ECC_MODE`. Algorithm (run in order, stop at the first match):\n   1. If `\u003Cclaude-home>\u002Fplugins\u002Fmarketplaces\u002Feverything-claude-code\u002F` exists → `ECC_MODE=plugin`.\n   2. Else if `\u003Cclaude-home>\u002Fagents\u002F` exists and contains at least one ECC agent file (e.g. `tdd-guide.md`, `code-reviewer.md`) → `ECC_MODE=legacy`.\n   3. Else → default to `ECC_MODE=legacy` and emit a one-line warning at the top of the output: `> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually.`\n   4. If both markers exist (mixed install), `plugin` wins — the plugin namespace is the only one that resolves agent names without fuzzy matching.\n\n   From this point on, every emitted line uses the matching prefix on **both** the slash command and every agent name. **Never emit both forms in the same output.**\n3. Resolve `--lang`. When `auto`, run a polyglot-aware detection:\n   - Probe markers: `pyproject.toml` \u002F `uv.lock` \u002F `requirements.txt` → python; `package.json` → typescript; `go.mod` → go; `Cargo.toml` → rust; `CMakeLists.txt` or top-level `*.cpp` → cpp; `pom.xml` \u002F `build.gradle` (Java) → java; `build.gradle.kts` or top-level Kotlin → kotlin; `pubspec.yaml` → flutter.\n   - **Polyglot tie-break**: if more than one marker matches, pick the language whose source files outnumber the others (count via `git ls-files`, excluding `vendor\u002F`, `node_modules\u002F`, `dist\u002F`, `build\u002F`, `.venv\u002F`, generated files, and obvious test fixtures). On a tie or when no language exceeds 60% of source files, set `lang=unknown`.\n   - No marker matched → set `lang=unknown`.\n   - `lang=unknown` is a sentinel — it is **not** an agent name. Phase 2 rules 4 and 5 turn it into `code-reviewer` \u002F `build-error-resolver` at chain composition time.\n4. Detect a **PyTorch sub-profile**: when `lang=python` and any of `pyproject.toml` \u002F `requirements.txt` \u002F `uv.lock` declares a dependency on `torch`, set `pytorch=true`. This only affects `build` chain selection (Phase 2 rule below); the reviewer remains `python-reviewer`.\n5. **Normalize any agent names declared in the plan**: if the plan text references agents by their plugin-prefixed form (e.g. `everything-claude-code:tdd-guide`), strip the prefix to get the bare catalogue name before validating or composing chains. Re-prefixing happens only at output time per `ECC_MODE` (Phase 4). Never let a pre-prefixed name flow into chain composition — it would double-prefix in plugin mode.\n\n### Phase 1 — Decompose steps\n\nIdentify \"step units\" in priority order:\n\n1. Explicit numbering: `## Step N` \u002F `### Phase N` \u002F `## N. ...` \u002F top-level ordered list.\n2. A \"Step\" column in a table.\n3. `---`-separated blocks with verb-led headings.\n4. Otherwise treat each H2 as one step.\n\nPer step extract `id` (1-based), `title` (≤ 80 chars), `intent` (1–3 sentences), `tags`.\n\n### Phase 2 — Tag and pick chain\n\nTag by intent (multi-tag allowed; chain built from primary + stacked secondaries):\n\nTrigger words below are matched case-insensitively. Multilingual plans are supported by matching the word stems in any language as long as the meaning aligns with the listed English trigger words.\n\n| Tag | Trigger words | Default chain |\n|---|---|---|\n| `design` | architecture, design, choose, evaluate, RFC | `planner,architect` |\n| `plan` | plan, breakdown, milestone | `planner` |\n| `impl` | implement, build, add, create, port | `tdd-guide,\u003Clang>-reviewer` |\n| `test` | test, coverage, e2e, integration | `tdd-guide,e2e-runner` |\n| `refactor` | refactor, cleanup, dedupe, split | `architect,refactor-cleaner,\u003Clang>-reviewer` |\n| `migration` | migrate, upgrade, rewrite, port | `architect,tdd-guide,\u003Clang>-reviewer` |\n| `db` | schema, migration, index, SQL, Postgres, alembic, sqlmodel | `database-reviewer,\u003Clang>-reviewer` |\n| `security` | encrypt, auth, secret, OWASP, PII | `security-reviewer,\u003Clang>-reviewer` |\n| `build` | build, compile, lint failure, CI | `\u003Clang>-build-resolver` (falls back to `build-error-resolver`) |\n| `docs` | docs, readme, codemap, changelog | `doc-updater` |\n| `lookup` | lookup, reference, API usage | `docs-lookup` |\n| `review` | review, audit, verify | `\u003Clang>-reviewer,code-reviewer` |\n| `loop` | loop, autonomous, watchdog | `loop-operator` |\n\nChain composition rules:\n1. **Primary tag selection**: when a step matches multiple tags, the **first one in table order** (top of the table = highest priority) is the primary; the rest are secondaries. Composition rules 2 and 3 below handle specific multi-tag combinations explicitly; otherwise, append secondary chains in tag table order.\n2. `impl` + `security` → `tdd-guide,\u003Clang>-reviewer,security-reviewer`.\n3. `impl` + `db` → `tdd-guide,database-reviewer,\u003Clang>-reviewer`.\n4. **Deduplicate** the resulting chain (preserve first occurrence). E.g. `review` + `lang=unknown` would yield `code-reviewer,code-reviewer` after rule 5; deduplication collapses it to `code-reviewer`.\n5. `\u003Clang>-reviewer` resolves to `code-reviewer` when `lang=unknown`.\n6. `\u003Clang>-build-resolver` resolves to `build-error-resolver` when `lang=unknown`. **Special case**: if Phase 0 set `pytorch=true`, use `pytorch-build-resolver` for `build` chains regardless of `\u003Clang>`. There is no `python-build-resolver`; `--lang=python` without `pytorch=true` resolves to `build-error-resolver`.\n7. **Zero-tag steps**: if no trigger word matches, set chain to `code-reviewer` and write `no tag matched; default review-only chain` under \"Chain rationale\".\n8. Chain length ≤ 4 after deduplication. If exceeded, drop weakest tag (`lookup` and `docs` first).\n9. Do not pair `planner` and `architect` in an `impl` chain (token waste). Pair them only on `design` steps.\n10. Steps tagged `impl`, `refactor`, or `migration` end with a **reviewer-class** agent — any of `\u003Clang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`. The most domain-specific reviewer wins the tail position (e.g. rule 2's `impl+security` ends with `security-reviewer`; rule 3's `impl+db` ends with `\u003Clang>-reviewer` because `database-reviewer` already gates the migration earlier in the chain). `test` and `build` steps are gated by their own validators (`e2e-runner` and the build resolver respectively) and do not require an additional reviewer.\n\n### Phase 3 — Compress task description\n\nEach emitted `\u003Ctask description>` must:\n- Be self-contained (the first agent does not need the plan document open).\n- Start with `[Plan: \u003Cpath>#step-\u003Cid>]`.\n- Include 1–3 verifiable Acceptance criteria.\n- Include a Scope guard (`Out of scope: ...`) **only if the plan declares one for this step**. Inherit verbatim. If the plan has no out-of-scope statement, omit the clause entirely — do not invent one.\n- Be 200–600 characters; one line; embedded `\"` escaped as `\\\"`; no literal newlines.\n\n### Phase 4 — Output\n\nEmit Markdown using **the form determined by `ECC_MODE`**. The output uses one form throughout — every `{ORCH_CMD}` and every agent name is rendered with the matching prefix from Phase 0. **Do not emit both forms; do not include \"this is plugin form\" \u002F \"strip the prefix\" instructions in the rendered output.**\n\nConcrete rendering rules:\n\n- `{ORCH_CMD}` = `\u002Feverything-claude-code:orchestrate` under `plugin`, `\u002Forchestrate` under `legacy`.\n- `{AGENT(name)}` = `everything-claude-code:\u003Cname>` under `plugin`, `\u003Cname>` under `legacy`.\n- The overview-table \"Chain\" column uses the same `{AGENT(name)}` rendering.\n- Per-step bash blocks contain only the runnable command. **No `# plugin form` or `# legacy form` comments** — the form is implicit and uniform across the whole output.\n\nOutput structure:\n\n````markdown\n# Plan-Orchestrate Result\n\n**Plan**: `\u003Cpath>`\n**Lang**: `\u003Cdetected-or-given>`\n**ECC mode**: `\u003Cplugin | legacy>`\n**Steps**: \u003CN>\n**Scope**: \u003Call | step:n | range:a-b>\n\n## Steps overview\n\n| # | Title | Tags | Chain |\n|---|---|---|---|\n| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |\n| ... | | | |\n\n---\n\n## Step 1 — \u003Ctitle>\n\n**Intent**: \u003C1–3 sentences>\n**Tags**: \u003Ca, b>\n**Chain rationale**: \u003Cwhy this chain; which agent closes the loop>\n\n```bash\n{ORCH_CMD} custom \"{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}\" \"[Plan: docs\u002Ffoo.md#step-1] \u003Ccompressed task description>; Acceptance: \u003C1–3 items>; Out of scope: \u003C…>\"\n```\n````\n\n> The `{ORCH_CMD}` and `{AGENT(...)}` notation above describes the substitution this skill performs at runtime. The actual emitted Markdown contains the resolved strings, never the placeholders.\n\nAppend a final \"Batch execution\" block aggregating every step's command in order so the user can paste them all at once. **Skip the Batch block in overview-only mode** (see \"Large plan\" edge case): when only the overview table is being emitted, there are no per-step commands to aggregate.\n\n### Phase 5 — Self-check (run before emitting)\n\n- [ ] Every agent in every chain comes from the catalogue (after stripping any `everything-claude-code:` prefix that appeared in the plan; see Phase 0 step 5).\n- [ ] Resolved `{ORCH_CMD}` and every resolved `{AGENT(...)}` use the **same** form (`plugin` or `legacy`) — never mixed in one output.\n- [ ] No `# plugin form` \u002F `# legacy form` annotations and no \"strip the prefix\" instructions remain in the rendered output.\n- [ ] No invented `--mode` \u002F `--gate` \u002F `--agents=...` fields.\n- [ ] Each task description is single-line, double-quoted, with embedded `\"` escaped.\n- [ ] Each task description begins with `[Plan: \u003Cpath>#step-\u003Cid>]` and includes Acceptance (1–3 items). The `Out of scope:` clause is present only when inherited from the plan.\n- [ ] No duplicate agent in any chain after Phase 2 dedup.\n- [ ] Chain length ≤ 4.\n- [ ] Steps tagged `impl`\u002F`refactor`\u002F`migration` end with a reviewer-class agent (`\u003Clang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`). `test` and `build` are exempt — see Phase 2 rule 10.\n- [ ] Zero-tag steps emit `code-reviewer` with the rationale `no tag matched; default review-only chain`.\n- [ ] Overview table lists every step in the plan, regardless of `--scope`.\n- [ ] Per-step detail block count matches the resolved `--scope` (full plan when `--scope=all`; one block for `step:n`; range size for `range:a-b`). In overview-only mode, no per-step blocks and no Batch block are emitted.\n\n## Edge cases\n\n- **No clear steps**: prefer H2\u002FH3 splitting; if still ambiguous, report \"no structured steps detected\" with the document outline and ask the user to confirm running by outline.\n- **Large plan (>1500 lines)**: enter **overview-only mode** — emit only the overview table and ask the user to narrow with `--scope` before re-running for details. In this mode, skip per-step detail blocks and skip the Batch execution block.\n- **Step too broad** (e.g. \"complete all backend work\"): do not force a single chain. Suggest splitting into N.a and N.b and propose a split.\n- **Plan declares agents** (rare): first **strip any `everything-claude-code:` prefix** to get the bare catalogue name (Phase 0 step 5), then validate against the catalogue. Replace invalid agents and explain under \"Chain rationale\". The bare name is re-prefixed at output time per `ECC_MODE`.\n- **Polyglot project where `--lang=auto` cannot pick a winner**: set `lang=unknown`; reviewer resolves to `code-reviewer` and build resolver to `build-error-resolver`. Mention the fallback under \"Chain rationale\".\n\n## Examples\n\n### Example 1 — Plugin mode, Python plan\n\nInput:\n```\nplan-orchestrate @docs\u002Fplan\u002Fexample-feature.md --lang=python\n```\n\nExcerpt of expected output:\n````markdown\n## Step 2 — Encrypt sensitive UserProfile fields\n\n**Intent**: Introduce an `EncryptedString` SQLAlchemy type and AES-GCM encrypt `birth_datetime` \u002F `location` before persistence; load the key from an environment variable.\n**Tags**: impl, security, db\n**Chain rationale**: Security-sensitive write path, so `security-reviewer` closes the chain; `database-reviewer` validates the alembic migration; `python-reviewer` covers typing and PEP 8.\n\n```bash\n\u002Feverything-claude-code:orchestrate custom \"everything-claude-code:tdd-guide,everything-claude-code:database-reviewer,everything-claude-code:python-reviewer,everything-claude-code:security-reviewer\" \"[Plan: docs\u002Fplan\u002Fexample-feature.md#step-2] Implement EncryptedString SQLAlchemy type and migrate UserProfile.birth_datetime\u002Flocation columns; key from ENV APP_DB_KEY; Acceptance: encrypt\u002Fdecrypt roundtrip tests pass; alembic upgrade\u002Fdowngrade clean on empty DB; no plaintext in DB after migrate; Out of scope: cross-tenant profile sharing logic\"\n```\n````\n\n### Example 2 — Legacy mode, same step\n\nIf `ECC_MODE=legacy` were detected, the same step would be emitted as a single uniform command (no plugin-prefixed forms anywhere in the output):\n\n```bash\n\u002Forchestrate custom \"tdd-guide,database-reviewer,python-reviewer,security-reviewer\" \"[Plan: docs\u002Fplan\u002Fexample-feature.md#step-2] ...\"\n```\n\nThe two examples above illustrate **the two possible outputs** for two different environments. A single skill invocation produces only one of them, end to end.\n\n## Notes\n\n- Generative only. Never invoke `\u002Forchestrate` from inside this skill.\n- Match the language of the plan document for task descriptions (agent names always remain English).\n- Do not insert \"Co-Authored-By\" lines or emoji in the output unless the user explicitly asks.\n","# Plan Orchestrate\n\nBridge a plan document to `\u002Forchestrate custom` by emitting one ready-to-paste invocation per step. The skill is generative only — it never executes `\u002Forchestrate`. The user pastes each line when ready.\n\n## When to Activate\n\n- User has a multi-step plan document (PRD, RFC, implementation plan) and wants to drive it through `\u002Forchestrate`.\n- User says \"orchestrate this plan\", \"give me orchestrate prompts for each step\", \"compose chains for this plan\".\n- A step-by-step plan exists but the user does not want to manually pick agents per step.\n\nSkip when:\n- The work is one ad-hoc step → call `\u002Forchestrate custom` directly.\n- The plan is unreadable or empty. Lack of explicit numbering alone is not a skip condition — see the \"No clear steps\" edge case below.\n\n## Inputs\n\n```\n\u003Cplan-doc-path> [--lang=python|typescript|go|rust|cpp|java|kotlin|flutter|auto] [--scope=all|step:\u003Cn>|range:\u003Ca>-\u003Cb>] [--dry-run]\n```\n\n- `\u003Cplan-doc-path>` — required; relative or absolute path (`@docs\u002F...` accepted).\n- `--lang` — reviewer language variant; defaults to `auto` (detected from project).\n- `--scope` — limits emitted steps; defaults to `all`.\n- `--dry-run` — print decomposition + chain rationale only; do not emit final prompts.\n\n## Authoritative `\u002Forchestrate` shape (do not deviate)\n\n```\n{ORCH_CMD} custom \"\u003Cagent1>,\u003Cagent2>,...,\u003CagentN>\" \"\u003Ctask description>\"\n```\n\nWhere `{ORCH_CMD}` is determined in Phase 0 (see below). The command string in the emitted output **always uses one concrete form** — never both, never a placeholder.\n\n- `custom` is a sequential chain; each agent's HANDOFF feeds the next.\n- Comma-separated agent list. No spaces preferred; one space tolerated.\n- No `--mode` \u002F `--gate` \u002F `--agents=...` flags exist — never invent them.\n- Agent names come from the catalogue in this skill. Embedded double quotes in the task description are escaped as `\\\"`.\n\n## ECC install form and namespacing\n\nTwo install forms determine the prefix on **both** the slash command and every agent name. The two MUST stay in sync — one form per output, never mixed:\n\nLet `\u003Cclaude-home>` denote the Claude Code home directory: `~\u002F.claude` on macOS\u002FLinux, `%USERPROFILE%\\.claude` on Windows. Resolve it the way the host platform resolves the user home directory (do not hardcode `~`).\n\n| Form | Detection | `{ORCH_CMD}` | Agent name format |\n|---|---|---|---|\n| Plugin install (1.9.0+) | `\u003Cclaude-home>\u002Fplugins\u002Fmarketplaces\u002Feverything-claude-code\u002F` exists | `\u002Feverything-claude-code:orchestrate` | `everything-claude-code:\u003Cname>` |\n| Legacy bare install | Above absent; agent files under `\u003Cclaude-home>\u002Fagents\u002F` | `\u002Forchestrate` | `\u003Cname>` |\n\nWhy this matters: under the plugin install, agents register as `everything-claude-code:tdd-guide`. Bare names force fuzzy matching, which fails intermittently under parallel calls. Under legacy, the prefixed forms are not registered and fail outright.\n\n## Available agent catalogue (must pick from these)\n\nGeneral:\n- `planner` — requirement restatement, risk decomposition, step planning\n- `architect` — architecture, system design, refactor proposals\n- `tdd-guide` — write tests → implement → 80%+ coverage\n- `code-reviewer` — generic code review\n- `security-reviewer` — security audit, OWASP, secret leakage\n- `refactor-cleaner` — dead code, duplicates, knip-class cleanup\n- `doc-updater` — documentation, codemap, README\n- `docs-lookup` — third-party library API lookups (Context7)\n- `e2e-runner` — end-to-end test orchestration\n- `database-reviewer` — PostgreSQL schema, migration, performance\n- `harness-optimizer` — local agent harness configuration\n- `loop-operator` — long-running autonomous loops\n- `chief-of-staff` — multi-channel triage (rarely a fit for plan steps)\n\nBuild error resolvers:\n- `build-error-resolver` (generic) \u002F `cpp-build-resolver` \u002F `go-build-resolver` \u002F `java-build-resolver` \u002F `kotlin-build-resolver` \u002F `rust-build-resolver` \u002F `pytorch-build-resolver`\n\nCode reviewers:\n- `python-reviewer` \u002F `typescript-reviewer` \u002F `go-reviewer` \u002F `rust-reviewer` \u002F `cpp-reviewer` \u002F `java-reviewer` \u002F `kotlin-reviewer` \u002F `flutter-reviewer`\n\nA misspelled agent name fails `\u002Forchestrate`. Cross-check against this list before emitting.\n\n## How It Works\n\n### Phase 0 — Detect ECC mode + language\n\n1. Read `\u003Cplan-doc-path>`. If missing or empty, report and stop.\n2. Detect ECC install form once and freeze it into `ECC_MODE`. Algorithm (run in order, stop at the first match):\n   1. If `\u003Cclaude-home>\u002Fplugins\u002Fmarketplaces\u002Feverything-claude-code\u002F` exists → `ECC_MODE=plugin`.\n   2. Else if `\u003Cclaude-home>\u002Fagents\u002F` exists and contains at least one ECC agent file (e.g. `tdd-guide.md`, `code-reviewer.md`) → `ECC_MODE=legacy`.\n   3. Else → default to `ECC_MODE=legacy` and emit a one-line warning at the top of the output: `> Warning: could not detect ECC install; defaulting to legacy form. If you use the plugin install, edit the prefixes manually.`\n   4. If both markers exist (mixed install), `plugin` wins — the plugin namespace is the only one that resolves agent names without fuzzy matching.\n\n   From this point on, every emitted line uses the matching prefix on **both** the slash command and every agent name. **Never emit both forms in the same output.**\n3. Resolve `--lang`. When `auto`, run a polyglot-aware detection:\n   - Probe markers: `pyproject.toml` \u002F `uv.lock` \u002F `requirements.txt` → python; `package.json` → typescript; `go.mod` → go; `Cargo.toml` → rust; `CMakeLists.txt` or top-level `*.cpp` → cpp; `pom.xml` \u002F `build.gradle` (Java) → java; `build.gradle.kts` or top-level Kotlin → kotlin; `pubspec.yaml` → flutter.\n   - **Polyglot tie-break**: if more than one marker matches, pick the language whose source files outnumber the others (count via `git ls-files`, excluding `vendor\u002F`, `node_modules\u002F`, `dist\u002F`, `build\u002F`, `.venv\u002F`, generated files, and obvious test fixtures). On a tie or when no language exceeds 60% of source files, set `lang=unknown`.\n   - No marker matched → set `lang=unknown`.\n   - `lang=unknown` is a sentinel — it is **not** an agent name. Phase 2 rules 4 and 5 turn it into `code-reviewer` \u002F `build-error-resolver` at chain composition time.\n4. Detect a **PyTorch sub-profile**: when `lang=python` and any of `pyproject.toml` \u002F `requirements.txt` \u002F `uv.lock` declares a dependency on `torch`, set `pytorch=true`. This only affects `build` chain selection (Phase 2 rule below); the reviewer remains `python-reviewer`.\n5. **Normalize any agent names declared in the plan**: if the plan text references agents by their plugin-prefixed form (e.g. `everything-claude-code:tdd-guide`), strip the prefix to get the bare catalogue name before validating or composing chains. Re-prefixing happens only at output time per `ECC_MODE` (Phase 4). Never let a pre-prefixed name flow into chain composition — it would double-prefix in plugin mode.\n\n### Phase 1 — Decompose steps\n\nIdentify \"step units\" in priority order:\n\n1. Explicit numbering: `## Step N` \u002F `### Phase N` \u002F `## N. ...` \u002F top-level ordered list.\n2. A \"Step\" column in a table.\n3. `---`-separated blocks with verb-led headings.\n4. Otherwise treat each H2 as one step.\n\nPer step extract `id` (1-based), `title` (≤ 80 chars), `intent` (1–3 sentences), `tags`.\n\n### Phase 2 — Tag and pick chain\n\nTag by intent (multi-tag allowed; chain built from primary + stacked secondaries):\n\nTrigger words below are matched case-insensitively. Multilingual plans are supported by matching the word stems in any language as long as the meaning aligns with the listed English trigger words.\n\n| Tag | Trigger words | Default chain |\n|---|---|---|\n| `design` | architecture, design, choose, evaluate, RFC | `planner,architect` |\n| `plan` | plan, breakdown, milestone | `planner` |\n| `impl` | implement, build, add, create, port | `tdd-guide,\u003Clang>-reviewer` |\n| `test` | test, coverage, e2e, integration | `tdd-guide,e2e-runner` |\n| `refactor` | refactor, cleanup, dedupe, split | `architect,refactor-cleaner,\u003Clang>-reviewer` |\n| `migration` | migrate, upgrade, rewrite, port | `architect,tdd-guide,\u003Clang>-reviewer` |\n| `db` | schema, migration, index, SQL, Postgres, alembic, sqlmodel | `database-reviewer,\u003Clang>-reviewer` |\n| `security` | encrypt, auth, secret, OWASP, PII | `security-reviewer,\u003Clang>-reviewer` |\n| `build` | build, compile, lint failure, CI | `\u003Clang>-build-resolver` (falls back to `build-error-resolver`) |\n| `docs` | docs, readme, codemap, changelog | `doc-updater` |\n| `lookup` | lookup, reference, API usage | `docs-lookup` |\n| `review` | review, audit, verify | `\u003Clang>-reviewer,code-reviewer` |\n| `loop` | loop, autonomous, watchdog | `loop-operator` |\n\nChain composition rules:\n1. **Primary tag selection**: when a step matches multiple tags, the **first one in table order** (top of the table = highest priority) is the primary; the rest are secondaries. Composition rules 2 and 3 below handle specific multi-tag combinations explicitly; otherwise, append secondary chains in tag table order.\n2. `impl` + `security` → `tdd-guide,\u003Clang>-reviewer,security-reviewer`.\n3. `impl` + `db` → `tdd-guide,database-reviewer,\u003Clang>-reviewer`.\n4. **Deduplicate** the resulting chain (preserve first occurrence). E.g. `review` + `lang=unknown` would yield `code-reviewer,code-reviewer` after rule 5; deduplication collapses it to `code-reviewer`.\n5. `\u003Clang>-reviewer` resolves to `code-reviewer` when `lang=unknown`.\n6. `\u003Clang>-build-resolver` resolves to `build-error-resolver` when `lang=unknown`. **Special case**: if Phase 0 set `pytorch=true`, use `pytorch-build-resolver` for `build` chains regardless of `\u003Clang>`. There is no `python-build-resolver`; `--lang=python` without `pytorch=true` resolves to `build-error-resolver`.\n7. **Zero-tag steps**: if no trigger word matches, set chain to `code-reviewer` and write `no tag matched; default review-only chain` under \"Chain rationale\".\n8. Chain length ≤ 4 after deduplication. If exceeded, drop weakest tag (`lookup` and `docs` first).\n9. Do not pair `planner` and `architect` in an `impl` chain (token waste). Pair them only on `design` steps.\n10. Steps tagged `impl`, `refactor`, or `migration` end with a **reviewer-class** agent — any of `\u003Clang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`. The most domain-specific reviewer wins the tail position (e.g. rule 2's `impl+security` ends with `security-reviewer`; rule 3's `impl+db` ends with `\u003Clang>-reviewer` because `database-reviewer` already gates the migration earlier in the chain). `test` and `build` steps are gated by their own validators (`e2e-runner` and the build resolver respectively) and do not require an additional reviewer.\n\n### Phase 3 — Compress task description\n\nEach emitted `\u003Ctask description>` must:\n- Be self-contained (the first agent does not need the plan document open).\n- Start with `[Plan: \u003Cpath>#step-\u003Cid>]`.\n- Include 1–3 verifiable Acceptance criteria.\n- Include a Scope guard (`Out of scope: ...`) **only if the plan declares one for this step**. Inherit verbatim. If the plan has no out-of-scope statement, omit the clause entirely — do not invent one.\n- Be 200–600 characters; one line; embedded `\"` escaped as `\\\"`; no literal newlines.\n\n### Phase 4 — Output\n\nEmit Markdown using **the form determined by `ECC_MODE`**. The output uses one form throughout — every `{ORCH_CMD}` and every agent name is rendered with the matching prefix from Phase 0. **Do not emit both forms; do not include \"this is plugin form\" \u002F \"strip the prefix\" instructions in the rendered output.**\n\nConcrete rendering rules:\n\n- `{ORCH_CMD}` = `\u002Feverything-claude-code:orchestrate` under `plugin`, `\u002Forchestrate` under `legacy`.\n- `{AGENT(name)}` = `everything-claude-code:\u003Cname>` under `plugin`, `\u003Cname>` under `legacy`.\n- The overview-table \"Chain\" column uses the same `{AGENT(name)}` rendering.\n- Per-step bash blocks contain only the runnable command. **No `# plugin form` or `# legacy form` comments** — the form is implicit and uniform across the whole output.\n\nOutput structure:\n\n````markdown\n# Plan-Orchestrate Result\n\n**Plan**: `\u003Cpath>`\n**Lang**: `\u003Cdetected-or-given>`\n**ECC mode**: `\u003Cplugin | legacy>`\n**Steps**: \u003CN>\n**Scope**: \u003Call | step:n | range:a-b>\n\n## Steps overview\n\n| # | Title | Tags | Chain |\n|---|---|---|---|\n| 1 | ... | impl, db | `{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}` |\n| ... | | | |\n\n---\n\n## Step 1 — \u003Ctitle>\n\n**Intent**: \u003C1–3 sentences>\n**Tags**: \u003Ca, b>\n**Chain rationale**: \u003Cwhy this chain; which agent closes the loop>\n\n```bash\n{ORCH_CMD} custom \"{AGENT(tdd-guide)},{AGENT(database-reviewer)},{AGENT(python-reviewer)}\" \"[Plan: docs\u002Ffoo.md#step-1] \u003Ccompressed task description>; Acceptance: \u003C1–3 items>; Out of scope: \u003C…>\"\n```\n````\n\n> The `{ORCH_CMD}` and `{AGENT(...)}` notation above describes the substitution this skill performs at runtime. The actual emitted Markdown contains the resolved strings, never the placeholders.\n\nAppend a final \"Batch execution\" block aggregating every step's command in order so the user can paste them all at once. **Skip the Batch block in overview-only mode** (see \"Large plan\" edge case): when only the overview table is being emitted, there are no per-step commands to aggregate.\n\n### Phase 5 — Self-check (run before emitting)\n\n- [ ] Every agent in every chain comes from the catalogue (after stripping any `everything-claude-code:` prefix that appeared in the plan; see Phase 0 step 5).\n- [ ] Resolved `{ORCH_CMD}` and every resolved `{AGENT(...)}` use the **same** form (`plugin` or `legacy`) — never mixed in one output.\n- [ ] No `# plugin form` \u002F `# legacy form` annotations and no \"strip the prefix\" instructions remain in the rendered output.\n- [ ] No invented `--mode` \u002F `--gate` \u002F `--agents=...` fields.\n- [ ] Each task description is single-line, double-quoted, with embedded `\"` escaped.\n- [ ] Each task description begins with `[Plan: \u003Cpath>#step-\u003Cid>]` and includes Acceptance (1–3 items). The `Out of scope:` clause is present only when inherited from the plan.\n- [ ] No duplicate agent in any chain after Phase 2 dedup.\n- [ ] Chain length ≤ 4.\n- [ ] Steps tagged `impl`\u002F`refactor`\u002F`migration` end with a reviewer-class agent (`\u003Clang>-reviewer`, `code-reviewer`, `security-reviewer`, or `database-reviewer`). `test` and `build` are exempt — see Phase 2 rule 10.\n- [ ] Zero-tag steps emit `code-reviewer` with the rationale `no tag matched; default review-only chain`.\n- [ ] Overview table lists every step in the plan, regardless of `--scope`.\n- [ ] Per-step detail block count matches the resolved `--scope` (full plan when `--scope=all`; one block for `step:n`; range size for `range:a-b`). In overview-only mode, no per-step blocks and no Batch block are emitted.\n\n## Edge cases\n\n- **No clear steps**: prefer H2\u002FH3 splitting; if still ambiguous, report \"no structured steps detected\" with the document outline and ask the user to confirm running by outline.\n- **Large plan (>1500 lines)**: enter **overview-only mode** — emit only the overview table and ask the user to narrow with `--scope` before re-running for details. In this mode, skip per-step detail blocks and skip the Batch execution block.\n- **Step too broad** (e.g. \"complete all backend work\"): do not force a single chain. Suggest splitting into N.a and N.b and propose a split.\n- **Plan declares agents** (rare): first **strip any `everything-claude-code:` prefix** to get the bare catalogue name (Phase 0 step 5), then validate against the catalogue. Replace invalid agents and explain under \"Chain rationale\". The bare name is re-prefixed at output time per `ECC_MODE`.\n- **Polyglot project where `--lang=auto` cannot pick a winner**: set `lang=unknown`; reviewer resolves to `code-reviewer` and build resolver to `build-error-resolver`. Mention the fallback under \"Chain rationale\".\n\n## Examples\n\n### Example 1 — Plugin mode, Python plan\n\nInput:\n```\nplan-orchestrate @docs\u002Fplan\u002Fexample-feature.md --lang=python\n```\n\nExcerpt of expected output:\n````markdown\n## Step 2 — Encrypt sensitive UserProfile fields\n\n**Intent**: Introduce an `EncryptedString` SQLAlchemy type and AES-GCM encrypt `birth_datetime` \u002F `location` before persistence; load the key from an environment variable.\n**Tags**: impl, security, db\n**Chain rationale**: Security-sensitive write path, so `security-reviewer` closes the chain; `database-reviewer` validates the alembic migration; `python-reviewer` covers typing and PEP 8.\n\n```bash\n\u002Feverything-claude-code:orchestrate custom \"everything-claude-code:tdd-guide,everything-claude-code:database-reviewer,everything-claude-code:python-reviewer,everything-claude-code:security-reviewer\" \"[Plan: docs\u002Fplan\u002Fexample-feature.md#step-2] Implement EncryptedString SQLAlchemy type and migrate UserProfile.birth_datetime\u002Flocation columns; key from ENV APP_DB_KEY; Acceptance: encrypt\u002Fdecrypt roundtrip tests pass; alembic upgrade\u002Fdowngrade clean on empty DB; no plaintext in DB after migrate; Out of scope: cross-tenant profile sharing logic\"\n```\n````\n\n### Example 2 — Legacy mode, same step\n\nIf `ECC_MODE=legacy` were detected, the same step would be emitted as a single uniform command (no plugin-prefixed forms anywhere in the output):\n\n```bash\n\u002Forchestrate custom \"tdd-guide,database-reviewer,python-reviewer,security-reviewer\" \"[Plan: docs\u002Fplan\u002Fexample-feature.md#step-2] ...\"\n```\n\nThe two examples above illustrate **the two possible outputs** for two different environments. A single skill invocation produces only one of them, end to end.\n\n## Notes\n\n- Generative only. Never invoke `\u002Forchestrate` from inside this skill.\n- Match the language of the plan document for task descriptions (agent names always remain English).\n- Do not insert \"Co-Authored-By\" lines or emoji in the output unless the user explicitly asks.\n",{"name":5,"origin":33,"description":7},"ECC","main","a298c929b6cbd662e1fce54302ce520d5ceea1a5",".agents\u002Fskills\u002Fplan-orchestrate","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain","https:\u002F\u002Fgithub.com\u002FPrekzursil","2026-11-02 14:30:57",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-orchestrate",{"tool":46,"command":47},"bunx","bunx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-orchestrate",{"tool":49,"command":50},"pnpm","pnpm dlx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-orchestrate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplan-orchestrate\u002FSKILL.md",true,[],[55,75,106,133,147,162],{"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},"01M6DF7D7478R55P46REYH4QAC","clarify-requirements","Resolve genuine pre-execution ambiguity by scanning repo context, generating 1-6 grounded options, and asking 1-3 focused questions via AskUserQuestion. NOT for mid-task use (injection risk); NOT when the goal is already unambiguous; use to disambiguate vague prompts before any file edits.","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Fworkspace-hooks\u002Fskills\u002Fclarify-requirements\u002FSKILL.md",[],[62,63,64,65,66,67,27,68,69,24,70,71,72,73,74],"clarify requirements","clarify","requirements","risk","options","task","goal","scanning","context","repo","injection","execution","file",{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":86,"publishedAt":28},"01M6DF79CA4BHJS66J8EZDBPWJ","openmm-md","Run FREE, open-source, Windows-native GPU molecular dynamics via the openmm-md MCP (OpenMM + CUDA on the local NVIDIA GPU). Use for protein \u002F protein-ligand MD when you want a free stack or are on Windows without a Schrodinger license. Covers the full workflow (prepare, solvate, minimize, equilibrate, production, analyze, mmgbsa) AND an honest decision guide vs Schrodinger Desmond, including how to run Desmond legitimately on Linux or a cloud GPU with a real license. This is a deliberately LESSER free alternative and does NOT replace the schrodinger MCP tools. Do NOT use it to pick a free tool when a validated FEP+, WaterMap, IFD-MD, or Prime MM-GBSA result is actually required.","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Fmcp\u002Fopenmm-md-mcp\u002Fskill\u002Fopenmm-md\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[87,88,89,90,91,92,93,94,95,96,97,98,99,100,24,101,102,103,104,105],"openmm md","how","decision","pick","linux","analyze","tool","stack","open","NVIDIA","gpu","license","workflow","windows","free","molecular dynamics","local","do","MCP",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":118,"publishedAt":28},"01M6DF76C1MG85VEWP8VZCBNMN","visual-review","Take screenshots of web pages and UI using Playwright for visual review and iteration","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fvisual-review\u002FSKILL.md",[112,115],{"categoryNo":113,"categoryName":114,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":116,"categoryName":117,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000008","测试与质量",[119,120,121,122,123,124,125,126,127,128,88,129,130,131,132],"review","visual","visual review","pages","web","false","iteration","take","check","slides","ui","screenshot","playwright","screenshots",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":28},"01M6DF73AQVCBZKEN0YXEX9FXP","status","Diagnostic status report — shows metaswarm installation state, project setup, and potential issues","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fstatus\u002FSKILL.md",[],[135,140,141,142,143,144,145,146],"setup","report","project","installation","project setup","issues","state",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":28},"01M6DF6X6C2XB0P6GX76P7TTYV","start","Use when starting work on any task, when the user mentions metaswarm, or when the user wants to begin tracked development work","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fstart\u002FSKILL.md",[153],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},[149,155,67,156,26,157,24,158,159,160,161],"start issue","issue","work on issue","user","work","work on","development",{"skillNo":163,"name":140,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":28},"01M6DF6QMJ9AJKFKHHKRT005PQ","Interactive project setup — detects your project, configures metaswarm, writes project-local files","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fsetup\u002FSKILL.md",[],[140,142,103,168,144,169],"files","interactive"]