agentleFS
Sign inStart free
ryukirinryukirin/openspec-code-migration/skills/migration-strategy/SKILL.md

migration-strategy

Skill0 starsChanged 35 days agoMITView on GitHub

Migration step 2. After migration-inventory, set the migration strategy (target stack, scope, how to handle each readiness gap, whether suspected defects are kept) and prove it feasible, in migration-strategy.md. A strategy the user supplies with the request, as text or a file path, is adopted as given; only what it leaves open is asked.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. augments-labs/sdlc-skills★ 1same name
    2. Siddharth00/agent-revamp-skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository3 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the request carries a migration strategy, as text or as a file path, read it first.

    line 19
  2. Very specific:

    Ask only about what it leaves out, leaves vague, or contradicts in the inventory evidence.

    line 22
  3. Distinctive:

    If one of its choices later proves infeasible, ask the user.

    line 23
  4. Very specific:

    Run gate stage strategy --root migration-plans/<name>.

    line 31
  5. Very specific:

    Every suspected defect or security issue in the baseline gets a disposition: keep as is, fix (BUG_NOT_PRESERVED / SECURITY_FIX_REQUIRED), …

    line 35
  6. Distinctive:

    When repository evidence is not enough, cite official primary sources under Sources.

    line 39
  7. Distinctive:

    Every Unknown behaviour in the baseline needs a conclusion.

    line 40
  8. Distinctive:

    Infeasible or unresolved items: ask the user whether to change the target, accept the risk, or reduce scope, then return to step 4.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Migration Strategy

Decide the strategy and prove it feasible in one pass. The two alternate: when something proves infeasible, ask the user right away instead of going back and forth between steps.

<schema> is the path from openspec schema which code-migration --json; if the schema is not found, run the migration-setup skill first.

  • Template: <schema>/templates/migration-strategy.md
  • gate: node <schema>/scripts/migration_gate.mjs

A strategy from the user

If the request carries a migration strategy, as text or as a file path, read it first.

  • Adopt every decision it states. Record each in the Decisions table with source USER_POLICY and do not ask about it again.
  • Ask only about what it leaves out, leaves vague, or contradicts in the inventory evidence. Record those as ASKED.
  • If one of its choices later proves infeasible, ask the user. Never change it silently.

Asking

Use your agent's structured question tool if it has one (AskUserQuestion in Claude Code); otherwise ask in plain text with numbered options. Ask up to 4 questions at a time, each with 2–3 mutually exclusive options, the recommended option first and labelled "(Recommended)", with its evidence and cost. No answer, or a vague one, is not a decision.

Steps

  1. Run gate stage strategy --root migration-plans/<name>; if it fails, show the output and stop. Read the inventory and baseline and draft from the template. Take source-side facts from the inventory.
  2. Target and scope. Ask for whatever is still missing: target language, runtime, frameworks, data store, and their versions; migration scope and fidelity. For the stack, offer 2–3 candidates, each with a rough feasibility note: equivalent frameworks and libraries, whether the data store can take over the data, deployment constraints.
  3. Gaps and defects, once the target is set so the options are concrete.
    • Every GAP-### needs a strategy. For a missing database schema the usual options are: rebuild a minimal schema from code evidence (Recommended; no historical data parity); pause and recover the original schema or data; skip historical data and start from an empty or demo database. If the user chooses to pause, stop here and ask them to rerun migration-inventory once the material is available.
    • Every suspected defect or security issue in the baseline gets a disposition: keep as is, fix (BUG_NOT_PRESERVED / SECURITY_FIX_REQUIRED), or remove. Never recommend keeping a security issue.
    • LEGACY-### items not listed default to PRESERVE; do not ask about them one by one.
  4. Prove feasibility against the exact chosen versions: language and runtime semantics, framework and library equivalents, data types, encoding, constraints and transactions, interfaces and serialization, authentication and sessions, build and deployment, licences.
    • Record one COMP-### per risk. Where only a test can settle it, open an EXP-### and run it yourself where you can (a small prototype, a version probe), then record the result.
    • When repository evidence is not enough, cite official primary sources under Sources.
    • Every Unknown behaviour in the baseline needs a conclusion.
  5. Infeasible or unresolved items: ask the user whether to change the target, accept the risk, or reduce scope, then return to step 4.
  6. Set FEASIBILITY. Run gate lint --root migration-plans/<name>, then check with gate stage propose --root migration-plans/<name>. When both pass, the next step is OpenSpec's propose workflow with the code-migration schema. The migration-review skill (strategy mode) is available for an optional check first.

On a rerun, update the file in place and keep existing IDs and decisions unless the user asks to change them.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free