[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JDC082R162YTMPQMJCMK9N":3,"skill-same:01M6JDC082R162YTMPQMJCMK9N":71},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6JDC082R162YTMPQMJCMK9N","plan-orchestrate",null,"Read a plan document, decompose it into steps, design a per-step agent chain from the ECC catalogue, and emit ready-to-paste \u002Forchestrate custom prompts. Generative only — never invokes \u002Forchestrate itself. Use when the user has a multi-step plan and wants to drive it through orchestrate without composing chains by hand.","S3YED\u002Fappie-kit","S3YED","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F62743867?v=4","01M6JBKBRRVP6KMS0VWZ27T3R6","01M6JBKBX0KG30284PW1DBYJT1",14,"MIT","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fplan-orchestrate\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"orchestrate","plan","plan orchestrate","custom","design","hand","paste","it","multi","chain","document","drive","prompts","decompose","ready","only","never","use","user","read","2026-11-10 10:12:30",false,"---\nname: plan-orchestrate\ndescription: Read a plan document, decompose it into steps, design a per-step agent chain from the ECC catalogue, and emit ready-to-paste \u002Forchestrate custom prompts. Generative only — never invokes \u002Forchestrate itself. Use when the user has a multi-step plan and wants to drive it through orchestrate without composing chains by hand.\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":48,"description":7},"ECC","master","8ec37df6d71fb664ea19d32c079e7d3ff931a8e0","skills\u002Fecc\u002Fplan-orchestrate",3,"https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit","https:\u002F\u002Fweblyfe.ai","https:\u002F\u002Fgithub.com\u002FS3YED","2026-08-27 01:54:02",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add S3YED\u002Fappie-kit --skill plan-orchestrate",{"tool":63,"command":64},"bunx","bunx skills add S3YED\u002Fappie-kit --skill plan-orchestrate",{"tool":66,"command":67},"pnpm","pnpm dlx skills add S3YED\u002Fappie-kit --skill plan-orchestrate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fecc\u002Fplan-orchestrate\u002FSKILL.md",true,[],[72,103,137,162,193,217],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":85,"publishedAt":43},"01M6JFD4M6N4DSGC7TXEJ5R3J2","ai-music","AI music generation and audio tools: HeartMuLa lyrics-to-music generation, songwriting craft (+ Suno prompts), and audio spectrogram\u002Ffeature visualization.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fwethlete\u002Fai-music\u002FSKILL.md",[78,81,84],{"categoryNo":79,"categoryName":80,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[86,87,88,89,90,91,92,93,94,95,96,35,97,98,99,100,101,102],"music","ai music","humanizer","visualization","Tools","Audio","hermes","hermes agent","songwriting","suno","lyrics","heartmula","craft","generation","feature","ai music generation","music generation",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":117,"publishedAt":43},"01M6JFCZE4XNFQFMNZDHKHT5V5","agentic-webdesign-design-system-ingestion","Use v0 Design Systems 2.0, Bolt Design System Agents, or Lovable to generate production UI from a client's real design system components — not generic Tailwind. Use when building a client website where brand consistency matters.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-design-system-ingestion\u002FSKILL.md",[109,112],{"categoryNo":110,"categoryName":111,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[27,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136],"agentic","design system","system","ingestion","webdesign","agentic webdesign design system ingestion","components","generate","design systems","website","ui","Tailwind","bolt","lovable","v0","design-system","wed","design system components","appie",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":145,"publishedAt":43},"01M6JFCVPX3913CFAS6QQJ33ZB","agentic-webdesign-agent-elements","Use 21st.dev Agent Elements — 25 shadcn\u002Fui components purpose-built for AI agent UIs. Tool cards (Bash, Edit, Search, Plan, Subagent, MCP), chat, input, streaming. Open source, shadcn-registry install, no runtime lock-in.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fweb-design\u002Fagentic-webdesign-agent-elements\u002FSKILL.md",[143,144],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},[118,146,122,147,148,149,124,150,151,152,153,154,155,24,156,157,158,159,160,161],"elements","agentic webdesign agent elements","MCP","ai agent","registry","search","streaming","open source","open","Bash","subagent","edit","install","input","lock","source",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":43},"01M6JFCQC7H65M9QJ6TRE71BS1","vercel-deployment","Deploy static sites and frontends to Vercel — handles both CLI and REST API paths, including the CLI token sanitization workaround.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fvercel-deployment\u002FSKILL.md",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192],"deployment","vercel deployment","vercel","macos","cli","linux","windows","deploy","vercel deploy","REST","api","site","deploy to vercel","token","rest api","host","sites","paths","sanitization","static site",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":43},"01M6JFCM4SMTXBM5A01BK2YQG1","software-quality-workflows","Umbrella workflow for TDD, debugging, code simplification, spikes, pre-commit review, and debugger-assisted investigation.","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Fsoftware-quality-workflows\u002FSKILL.md",[199],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[201,202,203,204,205,206,207,208,209,210,211,212,213,214,41,215,216],"workflows","quality","software","software quality workflows","review","tdd","workflow","commit","debugging","code","debugger","pre-commit","investigation","code simplification","simplification","for",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":230,"publishedAt":43},"01M6JFCGD0M6CEATY01W7YN6DB","react-component-refactoring","Safely refactor large React components into smaller, maintainable pieces using proven patterns","https:\u002F\u002Fgithub.com\u002FS3YED\u002Fappie-kit\u002Fblob\u002Fmaster\u002Fskills\u002Fsoftware-development\u002Freact-component-refactoring\u002FSKILL.md",[223,226,229],{"categoryNo":224,"categoryName":225,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":227,"categoryName":228,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[231,232,233,234,235,236,237,238,176,239,240,124,241,179,242,210,243,244,245,246],"react","component","refactoring","component refactoring","react component","react component refactoring","frontend","writing","safe","typescript","react components","modular","refactor","simplify","patterns","test-driven-development"]