migration-advisor

Name: migration-advisor
Author: AdamBien

40stars10forks

How to install migration-advisor?

adambien/airails/migration-advisor

$npx -y skills add AdamBien/airails --skill migration-advisor

Installs into the current project.

Summary

Front door for legacy migrations — assess a legacy system from shallow read-only signals (repo probe, git history, a reachable running instance) plus a short interview, then recommend an entry path (rehost, replatform, rearchitect) and an ordered sequence of migration skills to i

Files · 1

View on GitHub

SKILL.md

1	# Migration Advisor
2
3	The triage front door. Legacy migration is judgment-heavy and the entry-path choice is a human decision — this skill gathers the cheap signals that inform that choice, recommends a path and a sequence, and hands off. It routes, never executes: every step it recommends is invoked explicitly by a human, and each produces a reviewable artifact.
4
5	Stay shallow. The value is finishing in under a minute on a repo you have never seen. Deep vocabulary mining is `/concept-extractor`; behavior capture is `/characterization-tests`. Those are steps in the plan, not prerequisites to producing it.
6
7	## Data Sources
8
9	Use whatever is present; state in the plan which were available — a plan built without git or a runnable instance is more heuristic, and must say so.
10
11	### Repo probe (always)
12
13	Read-only counts and pattern hits, never comprehension:
14
15	- Platform / age — build files: `javax.` vs `jakarta.`, servlet/EJB/JSF/Spring versions, target JDK; or `package.json` with jQuery/AngularJS/Backbone.
16	- Size / shape — module, package, and file counts; LOC order of magnitude; density of `Manager`/`Impl`/`Util`/`Facade` names (overengineering signal → concept pipeline pays off; small and clean → rearchitect directly).
17	- External dependencies — count and identity of libraries with Java SE or platform equivalents (the replatform/simplifier signal).
18	- Test coverage — presence and size of a test source tree (near-zero → characterization must come first; "1:1 lift" is risky).
19	- Surfaces — JAX-RS resources, `web.xml` mappings, queue config, batch jobs; whether a runnable artifact exists (is characterization feasible, on which surface).
20
21	### Git history (if `.git` present)
22
23	Aggregate `git log` / `shortlog` / `--numstat`, not per-file blame:
24
25	- Liveness — last commit date, commit frequency: frozen (experts likely gone → lean on recorded behavior and async questionnaires) vs. active (strangle alongside ongoing work).
26	- Bus factor — `git shortlog -sne`: contributor count and whether the top authors are recent. Pre-fills the interview's expert-availability question with names.
27	- Hotspots — churn per file/package: where behavior is volatile and characterization should concentrate.
28	- Temporal coupling — files that change together: empirical evidence that latent structure exists and the carve path will pay off. Note it; do not carve — that is `/bc-carver`.
29	- Code age — old untouched code is safe to lift; recently churned code is where lift risk concentrates.
30
31	Distrust the signal when history is shallow-cloned, squashed/rebased, dominated by reformatting or dependency-bump commits, or broken by large file moves. Say so rather than presenting distorted churn as fact.
32
33	### Running instance (if reachable)
34
35	Confirm a surface responds; note base URL and health. Do not exercise it — that is characterization's job.
36
37	## Interview
38
39	The routing-critical facts live in people's heads. Ask 3–4 enumerable questions with `AskUserQuestion`, pre-filled from the probes so the human confirms or corrects rather than starts blank:
40
41	- Must the system keep running during migration? → rehost/replatform first vs. rearchitect directly.
42	- Is a domain expert available? (offer the git bus-factor names) → concept path viability; live vs. async clarification.
43	- Goal: clean modern runtime, or full BCE? → replatform-terminal vs. carve to sbce.
44	- Platform EOL / compliance deadline? → urgency; favors lift-first.
45
46	## Output
47
48	Write `migration/PLAN.md`:
49
50	- Findings — the gathered signals, each with its source and the caveats that apply. Spot-checkable, never trust-based.
51	- Recommended path — rehost, replatform, or rearchitect — with the reasoning (which signals drove it), so a human who knows the system can override a bad inference.
52	- Sequence — the ordered skills to invoke (`/characterization-tests record` → … ), with steps marked skippable and why, and the decision points that need a human call flagged.
53	- Reference, don't restate — link each step to its own skill README for detail; keep the plan thin so it does not drift from the skills.
54
55	The plan is a recommendation with its evidence shown, not a verdict — candidates-not-verdicts applied to the routing decision itself. The human edits it before step one.

People who liked this also viewed

6 picks

Type

migration-advisor

40stars10forks

View on GitHub

How to install migration-advisor?

adambien/airails/migration-advisor

$npx -y skills add AdamBien/airails --skill migration-advisor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Migration Advisor
2
3	The triage front door. Legacy migration is judgment-heavy and the entry-path choice is a human decision — this skill gathers the cheap signals that inform that choice, recommends a path and a sequence, and hands off. It routes, never executes: every step it recommends is invoked explicitly by a human, and each produces a reviewable artifact.
4
5	Stay shallow. The value is finishing in under a minute on a repo you have never seen. Deep vocabulary mining is `/concept-extractor`; behavior capture is `/characterization-tests`. Those are steps in the plan, not prerequisites to producing it.
6
7	## Data Sources
8
9	Use whatever is present; state in the plan which were available — a plan built without git or a runnable instance is more heuristic, and must say so.
10
11	### Repo probe (always)
12
13	Read-only counts and pattern hits, never comprehension:
14
15	- Platform / age — build files: `javax.` vs `jakarta.`, servlet/EJB/JSF/Spring versions, target JDK; or `package.json` with jQuery/AngularJS/Backbone.
16	- Size / shape — module, package, and file counts; LOC order of magnitude; density of `Manager`/`Impl`/`Util`/`Facade` names (overengineering signal → concept pipeline pays off; small and clean → rearchitect directly).
17	- External dependencies — count and identity of libraries with Java SE or platform equivalents (the replatform/simplifier signal).
18	- Test coverage — presence and size of a test source tree (near-zero → characterization must come first; "1:1 lift" is risky).
19	- Surfaces — JAX-RS resources, `web.xml` mappings, queue config, batch jobs; whether a runnable artifact exists (is characterization feasible, on which surface).
20
21	### Git history (if `.git` present)
22
23	Aggregate `git log` / `shortlog` / `--numstat`, not per-file blame:
24
25	- Liveness — last commit date, commit frequency: frozen (experts likely gone → lean on recorded behavior and async questionnaires) vs. active (strangle alongside ongoing work).
26	- Bus factor — `git shortlog -sne`: contributor count and whether the top authors are recent. Pre-fills the interview's expert-availability question with names.
27	- Hotspots — churn per file/package: where behavior is volatile and characterization should concentrate.
28	- Temporal coupling — files that change together: empirical evidence that latent structure exists and the carve path will pay off. Note it; do not carve — that is `/bc-carver`.
29	- Code age — old untouched code is safe to lift; recently churned code is where lift risk concentrates.
30
31	Distrust the signal when history is shallow-cloned, squashed/rebased, dominated by reformatting or dependency-bump commits, or broken by large file moves. Say so rather than presenting distorted churn as fact.
32
33	### Running instance (if reachable)
34
35	Confirm a surface responds; note base URL and health. Do not exercise it — that is characterization's job.
36
37	## Interview
38
39	The routing-critical facts live in people's heads. Ask 3–4 enumerable questions with `AskUserQuestion`, pre-filled from the probes so the human confirms or corrects rather than starts blank:
40
41	- Must the system keep running during migration? → rehost/replatform first vs. rearchitect directly.
42	- Is a domain expert available? (offer the git bus-factor names) → concept path viability; live vs. async clarification.
43	- Goal: clean modern runtime, or full BCE? → replatform-terminal vs. carve to sbce.
44	- Platform EOL / compliance deadline? → urgency; favors lift-first.
45
46	## Output
47
48	Write `migration/PLAN.md`:
49
50	- Findings — the gathered signals, each with its source and the caveats that apply. Spot-checkable, never trust-based.
51	- Recommended path — rehost, replatform, or rearchitect — with the reasoning (which signals drove it), so a human who knows the system can override a bad inference.
52	- Sequence — the ordered skills to invoke (`/characterization-tests record` → … ), with steps marked skippable and why, and the decision points that need a human call flagged.
53	- Reference, don't restate — link each step to its own skill README for detail; keep the plan thin so it does not drift from the skills.
54
55	The plan is a recommendation with its evidence shown, not a verdict — candidates-not-verdicts applied to the routing decision itself. The human edits it before step one.

People who liked this also viewed

6 picks

Type