{
    "kind": "meta",
    "name": "meta-migration-assistant",
    "always": false,
    "triggers": [
        "migration plan",
        "migration checklist",
        "practical migration checklist",
        "migrate from",
        "migrate",
        "upgrade from",
        "CommonJS to native ESM",
        "CommonJS to ESM",
        "CJS to ESM",
        "native ESM",
        "rollout risks",
        "升级指南",
        "迁移方案",
        "迁移步骤"
    ],
    "provenance": {
        "origin": "opensquilla-original",
        "license": "Apache-2.0"
    },
    "composition": {
        "steps": [
            {
                "id": "migration_intake",
                "kind": "llm_chat",
                "with": {
                    "task": "Extract the requested migration source, target, version context, and\nrepository scope from the user request. Set NEEDS_CLARIFICATION: yes\nonly when the source or target stack is absent or the request is too\ngeneric to classify safely.\n\nUser request:\n{{ inputs.user_message | xml_escape | truncate(1400) }}\n\nReturn exactly:\nSOURCE_STACK: <source stack\/version, or MISSING_SOURCE_STACK>\nTARGET_STACK: <target stack\/version, or MISSING_TARGET_STACK>\nVERSION_CONTEXT: <version\/runtime\/package context, or unknown>\nREPO_SCOPE: <current diff|current branch|named repo|not specified>\nNEEDS_CLARIFICATION: <yes|no>\nMISSING_FIELDS:\n  - <source_stack|target_stack|none>\nCLARIFY_REASON: <one concise reason, or none>\n",
                    "system": "You extract migration request boundaries and decide whether clarification is required."
                }
            },
            {
                "id": "migration_clarify",
                "kind": "user_input",
                "when": "'NEEDS_CLARIFICATION: yes' in outputs.migration_intake",
                "clarify": {
                    "mode": "form",
                    "intro": "迁移目标还不够明确。请补齐源技术栈和目标技术栈，我再生成可执行迁移清单。\n",
                    "fields": [
                        {
                            "name": "source_stack",
                            "type": "string",
                            "prompt": "源技术栈\/版本 \/ Source stack or version",
                            "required": true,
                            "max_chars": 160
                        },
                        {
                            "name": "target_stack",
                            "type": "string",
                            "prompt": "目标技术栈\/版本 \/ Target stack or version",
                            "required": true,
                            "max_chars": 160
                        },
                        {
                            "name": "version_context",
                            "type": "string",
                            "prompt": "运行时、框架或包版本 \/ Runtime, framework, or package versions",
                            "max_chars": 240
                        },
                        {
                            "name": "repo_scope",
                            "type": "string",
                            "prompt": "仓库范围 \/ Repository scope",
                            "max_chars": 200
                        }
                    ],
                    "nl_extract": true,
                    "timeout_hours": 24,
                    "cancel_keywords": [
                        "算了",
                        "取消",
                        "cancel",
                        "stop",
                        "abort"
                    ]
                },
                "depends_on": [
                    "migration_intake"
                ]
            },
            {
                "id": "classify",
                "kind": "llm_classify",
                "with": {
                    "text": "User said: {{ inputs.user_message | xml_escape | truncate(1400) }}\n\nMigration intake:\n{{ outputs.migration_intake | truncate(1200) }}\n\nClarification answers (may be empty when not needed):\n{{ inputs.get('collected', {}).get('migration_clarify', {}) | tojson }}\n\nIdentify the migration kind.\nIgnore benchmark wrappers, timestamps, locale hints, and generic\n\"return inline\" instructions. The actual user request may appear\nafter benchmark constraints; classify from the explicit source and\ntarget migration words, not from the preamble.\n\nDecision rules:\n- PY2_TO_PY3        → mentions Python 2 → 3 \/ py2 → py3\n- VUE2_TO_VUE3      → mentions Vue 2 → Vue 3 \/ options → composition\n- REACT_CLASS_TO_HOOKS → React class component → hooks\n- OPENAI_V0_TO_V1   → openai SDK v0 → v1, ChatCompletion → chat.completions.create\n- CJS_TO_ESM        → any mention of CommonJS, CJS, native ESM,\n  require(), module.exports, exports.*, import\/export migration,\n  \"from CommonJS to native ESM\", or \"CJS to ESM\"\n- OTHER             → any other migration request\n\nIf the text contains \"CommonJS\" and \"native ESM\", return exactly\nCJS_TO_ESM even if other benchmark\/context words appear first.\n"
                },
                "depends_on": [
                    "migration_intake",
                    "migration_clarify"
                ],
                "output_choices": [
                    "PY2_TO_PY3",
                    "VUE2_TO_VUE3",
                    "REACT_CLASS_TO_HOOKS",
                    "OPENAI_V0_TO_V1",
                    "CJS_TO_ESM",
                    "OTHER"
                ]
            },
            {
                "id": "fetch_guide",
                "kind": "skill_exec",
                "with": {
                    "query": "Authoritative migration guide for the user's actual migration.\nClassifier verdict: {{ outputs.classify }}.\nMigration intake:\n{{ outputs.migration_intake | truncate(1000) }}\nClarification answers:\n{{ inputs.get('collected', {}).get('migration_clarify', {}) | tojson }}\nIf the request mentions CommonJS, CJS, native ESM, require(),\nmodule.exports, or import\/export migration, search specifically for\ncurrent CommonJS to native ES Modules migration guidance covering\npackage.json type\/exports, extension rules, directory imports,\nJSON imports\/import attributes, createRequire interop, TypeScript\nNodeNext, test runners, dual publish, and consumer compatibility.\nIgnore benchmark preambles, timestamps, and unrelated local context.\n\nUser request:\n{{ inputs.user_message | xml_escape | truncate(500) }}\n",
                    "engines": [
                        "duckduckgo",
                        "brave"
                    ],
                    "max_results": 8
                },
                "skill": "multi-search-engine",
                "depends_on": [
                    "classify",
                    "migration_clarify"
                ]
            },
            {
                "id": "repo_context",
                "kind": "skill_exec",
                "when": "(\n  'current diff' in (inputs.user_message | lower)\n  or 'this diff' in (inputs.user_message | lower)\n  or 'current branch' in (inputs.user_message | lower)\n  or 'pull request' in (inputs.user_message | lower)\n  or 'merge request' in (inputs.user_message | lower)\n  or 'already changed' in (inputs.user_message | lower)\n  or 'worktree' in (inputs.user_message | lower)\n  or '当前 diff' in inputs.user_message\n  or '当前分支' in inputs.user_message\n)\n",
                "with": {
                    "mode": "cached_fallback_worktree"
                },
                "skill": "git-diff",
                "depends_on": [
                    "classify"
                ]
            },
            {
                "id": "write_plan",
                "kind": "llm_chat",
                "with": {
                    "task": "Migration kind: {{ outputs.classify }}\nMigration intake:\n{{ outputs.migration_intake | truncate(1200) }}\nClarification answers:\n{{ inputs.get('collected', {}).get('migration_clarify', {}) | tojson }}\nUser request:\n{{ inputs.user_message | xml_escape | truncate(1200) }}\n\nHard override before writing:\n- If the user request contains CommonJS, CJS, native ESM,\n  require\/module.exports, or import\/export migration wording, set\n  EFFECTIVE_KIND=CJS_TO_ESM.\n- If EFFECTIVE_KIND=CJS_TO_ESM, the Summary heading and every\n  section must be about CommonJS to native ES Modules. Do not write\n  about timezone, cloud, Python, Vue, React hooks, OpenAI SDK, or\n  any unrelated migration.\n- If classifier output conflicts with explicit source\/target words\n  in the user request, ignore the classifier output.\n\nAuthoritative guide excerpt:\n{{ outputs.fetch_guide | truncate(2000) }}\n\nOptional repository diff context:\n{{ outputs.repo_context | truncate(3000) }}\n\nTask lock:\n- The user's requested migration kind is authoritative. Do not let\n  repository diff context or unrelated local changes redefine the\n  migration. If the user asks for CommonJS\/CJS to native ESM, the\n  final answer must be a CommonJS-to-ESM migration checklist.\n- Apply this final-layer classifier override: if the user request\n  contains CommonJS, CJS, native ESM, require\/module.exports, or\n  import\/export migration wording, treat the effective migration\n  kind as CJS_TO_ESM even if `outputs.classify` says OTHER.\n- Do not expose classifier labels such as OTHER, CJS_TO_ESM,\n  VUE2_TO_VUE3, or internal routing decisions in the final answer.\n- Repository context is optional and only evidentiary. If it does\n  not explicitly show files relevant to the classified migration,\n  ignore it and say repository files were not verified.\n- Do not invent repo-specific files, package names, scripts, or\n  changes. Use grep commands for discovery instead.\n- Do not include write\/commit commands such as `git add`,\n  `git commit`, `eslint --fix`, or codemods inside validation\n  sections. Validation commands are read-only.\n- Benchmark\/no-write constraint: the final answer must not include\n  file creation or mutation commands in validation or smoke-test\n  sections. Forbidden examples include heredocs, shell redirection\n  (`>`, `>>`), `cat >`, `tee`, `touch`, `mkdir`, `cp`, `mv`,\n  `rm`, `npm init`, config generators, codemods, and `python -c`\n  \/ `node -e` snippets that write files. If a smoke test normally\n  needs a temporary fixture, describe it as a manual implementation\n  step, not as a validation command.\n- Do not use unverified concrete entrypoint paths such as\n  `index.js`, `server.js`, or package-specific test commands unless\n  they came from repository evidence. Use discovery commands first\n  and phrase path-specific commands as templates.\n- If the authoritative guide excerpt is about a different migration\n  domain, ignore it completely. Do not mention that it was ignored.\n- Do not wrap the whole response in ```markdown fences.\n\nProduce a concrete migration checklist as Markdown with these sections:\n## Summary\n## Evidence boundary\n## Breaking changes\n## Step-by-step\n## Repository discovery checklist\n## Files likely affected (grep patterns the user can run)\n## Validation (tests\/checks to confirm the migration)\n## Rollout and rollback\n\nQuality contract:\n- Keep the answer dense and complete in one response. Target\n  1,200-1,800 words; prefer compact tables and bullets over long\n  explanations or large config snippets.\n- If repository context is empty, unreadable, or generic, say so\n  clearly; do not invent files or package names.\n- If repository context is present but about another migration,\n  ignore it and explicitly state that it is unrelated to the user's\n  requested migration.\n- Prefer `rg` commands for grep patterns and make them copyable.\n- For CJS_TO_ESM discovery, include these command families:\n  `node -v`, `npm pkg get type main exports scripts`,\n  `git grep -nE \"require\\(|module\\.exports|exports\\.\"`,\n  `git grep -nE \"require\\([^'\\\"\\`]+\\)\"`,\n  `git grep -nE \"from ['\\\"]\\.\/[^'\\\"]+['\\\"]|import\\(['\\\"]\\.\/[^'\\\"]+['\\\"]\\)\"`,\n  `git grep -nE \"\\b(__dirname|__filename)\\b\"`,\n  `git grep -nE \"require\\.(resolve|cache|main|extensions)\"`,\n  `git grep -nE \"require\\(['\\\"][^'\\\"]+\\.json['\\\"]\\)\"`,\n  `git ls-files '*.cjs' '*.mjs'`, and\n  `git ls-files '**\/package.json' | xargs grep -l '\"main\"\\|\"type\"\\|\"exports\"'`.\n- Validation should be hypothesis-driven: include separate checks\n  for happy path package load, dynamic require replacement,\n  extension\/index-resolution failures, JSON import behavior,\n  test-runner ESM behavior, and downstream consumer import\/require\n  smoke tests.\n- Express validation commands as read-only probes against existing\n  repository files. For example, use `node --check <existing-file>`,\n  `node --input-type=module -e \"import('package-name-or-path')\"`,\n  `npm test -- --runInBand` only when scripts exist, and\n  `git grep`\/`npm pkg get` discovery before any path-specific\n  command. Never ask the user to create `tmp-smoke.*` files.\n- Include package\/publication validation commands when relevant:\n  `npm pack --dry-run`, `npx publint`, and\n  `npx @arethetypeswrong\/cli --pack .` for published packages with\n  TypeScript types. Label these as optional if the package is not\n  published.\n- For rollout, include decision points: ESM-only versus dual publish,\n  semver-major trigger, consumer compatibility scan, canary\/internal\n  package release, package-tarball inspection, rollback to previous\n  package version, and keeping `.cjs` escape hatches for tooling.\n- For CJS_TO_ESM, cover at minimum: `type: module`, extension rules,\n  directory `index.js` imports, `__dirname`\/`__filename`, JSON\n  imports, CJS interop\/default export shape changes, `exports` map\n  subpath whitelisting and precedence, TypeScript `NodeNext`,\n  Jest\/Vitest or node:test, dual-package hazards, downstream\n  consumer smoke tests, release sequencing, and rollback.\n- Do not say that `exports` deprecates `main`; say that `exports` takes precedence for runtimes that support it and can restrict deep imports.\n- Mark all validation commands as commands for the user to run; do\n  not imply they were executed.\n- Include version caveats for Node\/tooling-specific behavior.\n- For JSON imports, avoid claiming one universal syntax. Say that\n  behavior differs by Node version\/tooling; verify the target\n  runtime's current JSON-module\/import-attributes support, and keep\n  `createRequire(import.meta.url)` as the conservative fallback when\n  needed.\n- Avoid invented loader placeholders such as\n  `node --loader <your-loader>` unless the repository evidence\n  shows an existing loader. Prefer concrete discovery commands.\n- Avoid write-implying validation examples such as `eslint --fix`;\n  validation should be read-only unless clearly labeled as a\n  separate codemod\/fix step.\n- Avoid file-creation or config-generation examples unless they are\n  explicitly labeled as implementation work, not validation. Keep\n  the checklist concise and decision-oriented instead of filling it\n  with large generic config snippets.\n- Do not include brittle placeholder commands such as\n  `node --loader <your-loader>` or `node --check <existing-file>`;\n  write discovery-first templates with clear placeholders only where\n  unavoidable.\n- Avoid obsolete Node flags such as `--experimental-modules`; prefer\n  current LTS-compatible commands and call out when a command is\n  version-specific.",
                    "system": "You write migration checklists. Answer the user's requested\nmigration only. Do not change the migration domain based on locale,\ntimezone, unrelated repository diffs, or general environment\ncontext. If the request mentions CommonJS, CJS, native ESM,\nrequire\/module.exports, or import\/export migration, the answer must\nbe exclusively about CommonJS to native ESM. Return Markdown directly;\ndo not wrap the entire answer in a fenced code block.\n"
                },
                "depends_on": [
                    "classify",
                    "migration_clarify",
                    "fetch_guide",
                    "repo_context"
                ]
            }
        ]
    },
    "description": "Use this meta-skill instead of answering directly when the user needs a concrete migration plan that benefits from multi-skill orchestration across migration classification, authoritative guide lookup, optional repo diff inspection, and step-by-step validation planning.",
    "meta_priority": 50,
    "final_text_mode": "step:write_plan"
}