modernize-move

Name: modernize-move
Author: aptos-labs

19stars8forks

How to install modernize-move?

aptos-labs/aptos-agent-skills/modernize-move

$npx -y skills add aptos-labs/aptos-agent-skills --skill modernize-move

Installs into the current project.

Summary

Detects and modernizes outdated Move V1 syntax, patterns, and APIs to Move V2+. Use when upgrading legacy contracts, migrating to modern syntax, or converting old patterns to current best practices. NOT for writing new contracts (use write-contracts) or fixing bugs.

Files · 1

View on GitHub

SKILL.md

1	# Skill: modernize-move
2
3	Detect and modernize outdated Move V1 syntax, patterns, and APIs to Move V2+. Preserves correctness through tiered
4	transformations with test verification after each tier.
5
6	## Essential Principles
7
8	Five non-negotiable rules for every modernization:
9
10	1. Test safety net is mandatory WHY: Modernization must preserve behavior. No tests = no safety net. If no tests
11	exist, invoke `generate-tests` skill first to create comprehensive tests before making any changes.
12
13	2. Analyze before modifying WHY: The user must see exactly what will change and confirm the scope. Never
14	surprise-edit code. Present the full analysis report and wait for confirmation.
15
16	3. Tiered execution order WHY: Syntax changes (Tier 1) are zero-risk. API migrations (Tier 3) change semantics.
17	Always apply safest changes first so riskier changes build on a clean, verified foundation.
18
19	4. Verify after each tier WHY: If tests break, you know exactly which tier caused it. Revert that tier and
20	investigate before proceeding. Never apply the next tier on a broken baseline.
21
22	5. Preserve error code values WHY: Tests use `#[expected_failure(abort_code = N)]`. Changing numeric values breaks
23	tests silently. When creating named constants, the numeric value MUST match the original literal.
24
25	## When to Use This Skill
26
27	- Upgrading Move V1 contracts to V2 syntax
28	- Migrating `public(friend)` to `package fun`
29	- Converting `vector::borrow` to index notation
30	- Converting `while` loops with counters to `for` range loops
31	- Replacing manual vector iteration with stdlib inline functions (`vector::for_each_ref`, `vector::map`, `vector::fold`,
32	etc.) and lambdas
33	- Replacing magic abort numbers with named constants
34	- Migrating legacy `coin`/`TokenV1` to modern `fungible_asset`/Digital Assets
35	- Converting `EventHandle` to `#[event]` pattern
36	- Upgrading custom signed integer workarounds to native `i8`-`i256` types
37
38	## When NOT to Use This Skill
39
40	- Writing new contracts from scratch — use `write-contracts`
41	- Fixing bugs or adding features — modernization is structural, not functional
42	- Optimizing gas usage — use `analyze-gas-optimization`
43	- Auditing security — use `security-audit` (run AFTER modernization)
44
45	## Workflow
46
47	### Phase 1: Analyze Contract
48
49	Entry: User provides a Move contract or project to modernize.
50
51	Actions:
52
53	1. Read all contract source files (`.move` files in `sources/`)
54	2. Scan for V1 patterns using detection rules from [detection-rules.md](references/detection-rules.md):
55	- Grep for Tier 1 patterns (syntax) — highest confidence, most common
56	- Grep for Tier 2 patterns (visibility, errors, events)
57	- Grep for Tier 3 patterns (API migrations) — flag for manual review
58	3. Cross-reference coupled patterns (T3-09+T3-10)
59	4. Categorize each finding: line number, rule ID, pattern name, proposed change, tier, confidence
60	5. Build the Analysis Report
61
62	Exit: Analysis Report ready for presentation.
63
64	### Phase 2: Present Analysis (GATE 1)
65
66	Entry: Analysis Report complete.
67
68	Actions:
69
70	1. Present the full Analysis Report to the user in this format:
71
72	```
73	## Modernization Analysis Report
74
75	### Summary
76	- Tier 1 (Syntax): X findings
77	- Tier 2 (Visibility & Errors): X findings
78	- Tier 3 (API Migrations): X findings
79
80	### Findings
81
82	\| # \| File:Line \| Rule \| Pattern \| Proposed Change \| Tier \| Confidence \|
83	\|---\|-----------\|------\|---------\|-----------------\|------\|------------\|
84	\| 1 \| src/mod.move:15 \| T1-01 \| vector::borrow \| → index notation \| 1 \| High \|
85	\| ... \| ... \| ... \| ... \| ... \| ... \| ... \|
86
87	### Tier 3 Warnings (if any)
88	- T3-03: coin → fungible_asset migration is a major rewrite (X locations)
89	```
90
91	2. Ask the user to choose scope:
92	- `syntax-only` (Tier 1 only) — zero risk, just cleaner syntax
93	- `standard` (Tier 1 + Tier 2) — recommended default, syntax + visibility + error constants
94	- `full` (all tiers) — includes API migrations, higher risk
95	3. Highlight any Tier 3 items that require major rewrites
96	4. If scope includes Tier 3, ask the user about deployment context:
97	- Compatible — Upgrading an already-deployed contract. Breaking changes are excluded even if the scope includes
98	them. Rules marked ⚠ Breaking are skipped.
99	- Fresh deploy — New deployment or willing to redeploy. All changes in the selected scope are applied including
100	breaking changes.
101
102	Exit: User has confirmed scope (and deployment context if

People who liked this also viewed

6 picks

Type

modernize-move

19stars8forks

View on GitHub

How to install modernize-move?

aptos-labs/aptos-agent-skills/modernize-move

$npx -y skills add aptos-labs/aptos-agent-skills --skill modernize-move

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill: modernize-move
2
3	Detect and modernize outdated Move V1 syntax, patterns, and APIs to Move V2+. Preserves correctness through tiered
4	transformations with test verification after each tier.
5
6	## Essential Principles
7
8	Five non-negotiable rules for every modernization:
9
10	1. Test safety net is mandatory WHY: Modernization must preserve behavior. No tests = no safety net. If no tests
11	exist, invoke `generate-tests` skill first to create comprehensive tests before making any changes.
12
13	2. Analyze before modifying WHY: The user must see exactly what will change and confirm the scope. Never
14	surprise-edit code. Present the full analysis report and wait for confirmation.
15
16	3. Tiered execution order WHY: Syntax changes (Tier 1) are zero-risk. API migrations (Tier 3) change semantics.
17	Always apply safest changes first so riskier changes build on a clean, verified foundation.
18
19	4. Verify after each tier WHY: If tests break, you know exactly which tier caused it. Revert that tier and
20	investigate before proceeding. Never apply the next tier on a broken baseline.
21
22	5. Preserve error code values WHY: Tests use `#[expected_failure(abort_code = N)]`. Changing numeric values breaks
23	tests silently. When creating named constants, the numeric value MUST match the original literal.
24
25	## When to Use This Skill
26
27	- Upgrading Move V1 contracts to V2 syntax
28	- Migrating `public(friend)` to `package fun`
29	- Converting `vector::borrow` to index notation
30	- Converting `while` loops with counters to `for` range loops
31	- Replacing manual vector iteration with stdlib inline functions (`vector::for_each_ref`, `vector::map`, `vector::fold`,
32	etc.) and lambdas
33	- Replacing magic abort numbers with named constants
34	- Migrating legacy `coin`/`TokenV1` to modern `fungible_asset`/Digital Assets
35	- Converting `EventHandle` to `#[event]` pattern
36	- Upgrading custom signed integer workarounds to native `i8`-`i256` types
37
38	## When NOT to Use This Skill
39
40	- Writing new contracts from scratch — use `write-contracts`
41	- Fixing bugs or adding features — modernization is structural, not functional
42	- Optimizing gas usage — use `analyze-gas-optimization`
43	- Auditing security — use `security-audit` (run AFTER modernization)
44
45	## Workflow
46
47	### Phase 1: Analyze Contract
48
49	Entry: User provides a Move contract or project to modernize.
50
51	Actions:
52
53	1. Read all contract source files (`.move` files in `sources/`)
54	2. Scan for V1 patterns using detection rules from [detection-rules.md](references/detection-rules.md):
55	- Grep for Tier 1 patterns (syntax) — highest confidence, most common
56	- Grep for Tier 2 patterns (visibility, errors, events)
57	- Grep for Tier 3 patterns (API migrations) — flag for manual review
58	3. Cross-reference coupled patterns (T3-09+T3-10)
59	4. Categorize each finding: line number, rule ID, pattern name, proposed change, tier, confidence
60	5. Build the Analysis Report
61
62	Exit: Analysis Report ready for presentation.
63
64	### Phase 2: Present Analysis (GATE 1)
65
66	Entry: Analysis Report complete.
67
68	Actions:
69
70	1. Present the full Analysis Report to the user in this format:
71
72	```
73	## Modernization Analysis Report
74
75	### Summary
76	- Tier 1 (Syntax): X findings
77	- Tier 2 (Visibility & Errors): X findings
78	- Tier 3 (API Migrations): X findings
79
80	### Findings
81
82	\| # \| File:Line \| Rule \| Pattern \| Proposed Change \| Tier \| Confidence \|
83	\|---\|-----------\|------\|---------\|-----------------\|------\|------------\|
84	\| 1 \| src/mod.move:15 \| T1-01 \| vector::borrow \| → index notation \| 1 \| High \|
85	\| ... \| ... \| ... \| ... \| ... \| ... \| ... \|
86
87	### Tier 3 Warnings (if any)
88	- T3-03: coin → fungible_asset migration is a major rewrite (X locations)
89	```
90
91	2. Ask the user to choose scope:
92	- `syntax-only` (Tier 1 only) — zero risk, just cleaner syntax
93	- `standard` (Tier 1 + Tier 2) — recommended default, syntax + visibility + error constants
94	- `full` (all tiers) — includes API migrations, higher risk
95	3. Highlight any Tier 3 items that require major rewrites
96	4. If scope includes Tier 3, ask the user about deployment context:
97	- Compatible — Upgrading an already-deployed contract. Breaking changes are excluded even if the scope includes
98	them. Rules marked ⚠ Breaking are skipped.
99	- Fresh deploy — New deployment or willing to redeploy. All changes in the selected scope are applied including
100	breaking changes.
101
102	Exit: User has confirmed scope (and deployment context if

People who liked this also viewed

6 picks

Type