dependency-changes

Name: dependency-changes
Author: UnpaidAttention

84stars18forks

How to install dependency-changes?

unpaidattention/fable5-methodology/dependency-changes

$npx -y skills add UnpaidAttention/fable5-methodology --skill dependency-changes

Installs into the current project.

Summary

Add, upgrade, or migrate third-party dependencies safely — read the changelog for the exact version jump, isolate the change, run full verification, and keep rollback ready. Trigger this when the task involves bumping a package version, adding a new dependency, replacing one libr

Files · 1

View on GitHub

SKILL.md

1	# Dependency Changes
2
3	A dependency change is a change to code you didn't write and didn't review, arriving with its
4	own bugs and behavior shifts. Treat every bump as a code change requiring verification, never
5	as routine housekeeping.
6
7	## Step 1: Know exactly what version moves where
8
9	1. Read the lockfile for the CURRENT installed version — not the manifest range, the actual
10	resolved version. That's your "from".
11	2. Determine the "to" and classify the jump by semver: patch (x.y.Z), minor (x.Y.z), or major
12	(X.y.z). Major jumps carry breaking changes by definition — budget accordingly.
13	3. Note transitive impact: does this bump drag peer/transitive dependencies with it? `npm ls
14	<pkg>` / `cargo tree -i` / `pip show` reveals who else is affected.
15
16	## Step 2: Read the changelog for the SPECIFIC range
17
18	1. Read the CHANGELOG / release notes for every version between from and to — not just the
19	target. Bugs and breaking changes accumulate across the intermediate releases you're
20	skipping.
21	2. For a major jump, find the migration guide. Search the notes for "BREAKING", "removed",
22	"deprecated", "renamed". List each breaking item that touches an API your code actually
23	uses (grep your code for the symbols).
24	3. This is version-sensitive external knowledge — do not rely on training memory of the
25	library's API (see the research-and-verification skill). Read the notes for the real
26	versions, fetched this session.
27
28	## Step 3: Isolate the change
29
30	1. One dependency change per commit/branch. Never bundle a version bump with feature work —
31	when something breaks, you must know whether it was the bump or your code, and a mixed diff
32	destroys that signal.
33	2. If bumping several dependencies, do them one at a time with a full verification between
34	each. A batch bump that fails gives you N suspects; sequential bumps give you one.
35	3. Record the pre-change lockfile state (it's your rollback target — commit it or copy it).
36
37	## Step 4: Apply and adapt
38
39	1. Update the manifest, regenerate the lockfile with the project's tool (`npm install`,
40	`cargo update -p`, `uv lock` / `pip-compile`) — never hand-edit a lockfile.
41	2. Address each breaking item found in Step 2: update call sites for renamed/removed APIs,
42	migrate deprecated usage. Grep to find every site; don't fix only the ones you remember.
43	3. If the new version needs a config or peer-dependency change, do it in the same commit.
44
45	## Step 5: Full verification (broader than usual)
46
47	A dependency touches code paths your unit tests may not cover directly. Escalate breadth:
48	1. Reinstall from the lockfile clean (`rm -rf node_modules && npm ci`, fresh venv) — confirm
49	it resolves and installs reproducibly, not just on your incremental state.
50	2. Build + full test suite + lint + type-check. Type errors after a bump often ARE the
51	breaking changes surfacing — read them, don't suppress them.
52	3. Run the app / a smoke path — some breakages (behavioral, not type-level) only appear at
53	runtime.
54	4. Re-run the security audit (`npm audit` etc.) — confirm a security-motivated bump actually
55	cleared the advisory, and didn't introduce a new one.
56
57	## Step 6: Rollback readiness
58
59	If verification fails and the fix isn't quick: revert to the recorded lockfile state (Step 3),
60	confirm green is restored, and report — "bump X 2.x→3.x blocked: it removes `Y` which the auth
61	module depends on; needs migrating `Y`→`Z` first (est. N sites). Staying on 2.x meanwhile."
62	A clean revert plus a clear blocker report beats a half-migrated broken tree.
63
64	## Worked example
65
66	Task: "Upgrade `axios` to fix the CVE."
67
68	1. Lockfile: current `0.27.2`. Target: latest `1.x` clearing the advisory → `1.7.x`. Major jump.
69	2. Changelog 0.27→1.0: BREAKING — default export/interceptor changes, `axios.get` error shape
70	changed. Grep code: 14 call sites, 2 use the changed error shape.
71	3. Isolated branch `chore/axios-1.x`; lockfile copied as rollback target.
72	4. `npm install axios@^1.7`; update the 2 error-handling sites; grep confirms the other 12 are
73	compatible.
74	5. `npm ci` clean → build → full suite → RED: one test asserted the old `error.response`
75	path; it's testing real behavior that changed → update the assertion (legitimate — the
76	contract changed), NOT silenced. Green. Smoke: live request works. `npm audit` → advisory
77	clea

People who liked this also viewed

6 picks

Type

dependency-changes

84stars18forks

View on GitHub

How to install dependency-changes?

unpaidattention/fable5-methodology/dependency-changes

$npx -y skills add UnpaidAttention/fable5-methodology --skill dependency-changes

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Dependency Changes
2
3	A dependency change is a change to code you didn't write and didn't review, arriving with its
4	own bugs and behavior shifts. Treat every bump as a code change requiring verification, never
5	as routine housekeeping.
6
7	## Step 1: Know exactly what version moves where
8
9	1. Read the lockfile for the CURRENT installed version — not the manifest range, the actual
10	resolved version. That's your "from".
11	2. Determine the "to" and classify the jump by semver: patch (x.y.Z), minor (x.Y.z), or major
12	(X.y.z). Major jumps carry breaking changes by definition — budget accordingly.
13	3. Note transitive impact: does this bump drag peer/transitive dependencies with it? `npm ls
14	<pkg>` / `cargo tree -i` / `pip show` reveals who else is affected.
15
16	## Step 2: Read the changelog for the SPECIFIC range
17
18	1. Read the CHANGELOG / release notes for every version between from and to — not just the
19	target. Bugs and breaking changes accumulate across the intermediate releases you're
20	skipping.
21	2. For a major jump, find the migration guide. Search the notes for "BREAKING", "removed",
22	"deprecated", "renamed". List each breaking item that touches an API your code actually
23	uses (grep your code for the symbols).
24	3. This is version-sensitive external knowledge — do not rely on training memory of the
25	library's API (see the research-and-verification skill). Read the notes for the real
26	versions, fetched this session.
27
28	## Step 3: Isolate the change
29
30	1. One dependency change per commit/branch. Never bundle a version bump with feature work —
31	when something breaks, you must know whether it was the bump or your code, and a mixed diff
32	destroys that signal.
33	2. If bumping several dependencies, do them one at a time with a full verification between
34	each. A batch bump that fails gives you N suspects; sequential bumps give you one.
35	3. Record the pre-change lockfile state (it's your rollback target — commit it or copy it).
36
37	## Step 4: Apply and adapt
38
39	1. Update the manifest, regenerate the lockfile with the project's tool (`npm install`,
40	`cargo update -p`, `uv lock` / `pip-compile`) — never hand-edit a lockfile.
41	2. Address each breaking item found in Step 2: update call sites for renamed/removed APIs,
42	migrate deprecated usage. Grep to find every site; don't fix only the ones you remember.
43	3. If the new version needs a config or peer-dependency change, do it in the same commit.
44
45	## Step 5: Full verification (broader than usual)
46
47	A dependency touches code paths your unit tests may not cover directly. Escalate breadth:
48	1. Reinstall from the lockfile clean (`rm -rf node_modules && npm ci`, fresh venv) — confirm
49	it resolves and installs reproducibly, not just on your incremental state.
50	2. Build + full test suite + lint + type-check. Type errors after a bump often ARE the
51	breaking changes surfacing — read them, don't suppress them.
52	3. Run the app / a smoke path — some breakages (behavioral, not type-level) only appear at
53	runtime.
54	4. Re-run the security audit (`npm audit` etc.) — confirm a security-motivated bump actually
55	cleared the advisory, and didn't introduce a new one.
56
57	## Step 6: Rollback readiness
58
59	If verification fails and the fix isn't quick: revert to the recorded lockfile state (Step 3),
60	confirm green is restored, and report — "bump X 2.x→3.x blocked: it removes `Y` which the auth
61	module depends on; needs migrating `Y`→`Z` first (est. N sites). Staying on 2.x meanwhile."
62	A clean revert plus a clear blocker report beats a half-migrated broken tree.
63
64	## Worked example
65
66	Task: "Upgrade `axios` to fix the CVE."
67
68	1. Lockfile: current `0.27.2`. Target: latest `1.x` clearing the advisory → `1.7.x`. Major jump.
69	2. Changelog 0.27→1.0: BREAKING — default export/interceptor changes, `axios.get` error shape
70	changed. Grep code: 14 call sites, 2 use the changed error shape.
71	3. Isolated branch `chore/axios-1.x`; lockfile copied as rollback target.
72	4. `npm install axios@^1.7`; update the 2 error-handling sites; grep confirms the other 12 are
73	compatible.
74	5. `npm ci` clean → build → full suite → RED: one test asserted the old `error.response`
75	path; it's testing real behavior that changed → update the assertion (legitimate — the
76	contract changed), NOT silenced. Green. Smoke: live request works. `npm audit` → advisory
77	clea

People who liked this also viewed

6 picks

Type