update-deps

Name: update-deps
Author: backnotprop

7.2kstars517forks

How to install update-deps?

backnotprop/plannotator/update-deps

$npx -y skills add backnotprop/plannotator --skill update-deps

Installs into the current project.

Summary

Audit and update npm/Bun dependencies with supply chain integrity checks — verifies maintainers, publish age, tarball diffs, and provenance before bumping. Defers risky packages to ~/.supply-chain/notes/.

Files · 1

View on GitHub

SKILL.md

1	# Update Dependencies
2
3	Audit outdated packages, verify supply chain integrity, bump what's safe, defer what needs review, and log everything.
4
5	This process has three phases: discovery, integrity audit, and execution. The integrity audit is the most important — every package gets checked before it touches the lockfile.
6
7	## Phase 1: Discovery
8
9	Run `bun outdated` to get the full list of packages with available updates.
10
11	```bash
12	bun outdated
13	```
14
15	Parse the output into a structured list. For each package, note:
16	- Package name
17	- Current version
18	- Available update version
19	- Whether it's age-gated (indicated by `` in the output — the footnote "The indicates that version isn't true latest due to minimum release age" confirms this)
20	- Whether it's a runtime dep, dev dep, or peer dep
21
22	Also check whether any packages are blocked entirely by the age gate (like `@pierre/diffs` was when its minimum semver range couldn't resolve). Flag these separately — they may need `minimumReleaseAgeExcludes` in `bunfig.toml`.
23
24	## Phase 2: Integrity Audit
25
26	This is the core of the process. Spawn one Sonnet sub-agent per package to run the integrity check in parallel. Sonnet is used here because these are independent, structured verification tasks that don't need heavier reasoning.
27
28	Each sub-agent receives the package name, current version, and target version, and performs the following checks:
29
30	### Sub-agent prompt template
31
32	For each outdated package, spawn a Sonnet agent with this task:
33
34	```
35	You are auditing the npm package "{package}" for a version bump from {current} to {target}.
36
37	Run these checks and report back with a JSON object:
38
39	1. Maintainer verification: Check if maintainers changed between versions.
40	npm view {package}@{current} maintainers --json
41	npm view {package}@{target} maintainers --json
42	Compare the two lists. Flag any additions or removals.
43
44	2. Publish date and age: Get the publish timestamp.
45	npm view {package} time --json
46	Extract the date for version {target}. Calculate days since publication.
47	Flag if younger than 7 days.
48
49	3. Provenance: Check if the package has registry signatures or attestations.
50	npm audit signatures (if not already run this session)
51	Note whether the package has provenance attestations.
52
53	4. Tarball diff: Show what actually changed in the published package.
54	npm diff --diff={package}@{current} --diff={package}@{target}
55	Summarize the changes:
56	- How many files changed
57	- Are changes limited to version bumps, deps, and rebuilt dist? Or are there meaningful source changes?
58	- Any new runtime dependencies added?
59	- Any suspicious patterns (obfuscated code, eval(), network calls in unexpected places)
60
61	5. Release notes: Try to find what changed.
62	Check the package's repository for release notes or changelog:
63	npm view {package}@{target} repository.url
64	gh release view v{target} --repo <owner/repo> (try with and without v prefix)
65	Summarize the changelog if found.
66
67	Report your findings as JSON:
68
69	{{
70	"package": "{package}",
71	"from": "{current}",
72	"to": "{target}",
73	"age_days": <number>,
74	"maintainers_changed": <boolean>,
75	"maintainers_added": [],
76	"maintainers_removed": [],
77	"provenance": <boolean>,
78	"new_runtime_deps": [],
79	"files_changed": <number>,
80	"has_source_changes": <boolean>,
81	"changelog_summary": "<brief summary>",
82	"suspicious_patterns": [],
83	"verdict": "safe" \| "review" \| "defer",
84	"verdict_reason": "<one sentence explanation>"
85	}}
86
87	Verdict guidelines:
88	- "safe": Same maintainers, no new runtime deps, changes match what changelog describes, no suspicious patterns
89	- "review": Minor concerns (e.g., new maintainer who is clearly from the same org, small new dep from known publisher)
90	- "defer": Maintainer changes from unknown accounts, new runtime deps with unclear purpose, suspicious code patterns, substantive API changes that need integration testing
91	```
92
93	### Collecting results
94
95	As sub-agents complete, collect their JSON reports. If a sub-agent fails or times out, mark that package as "defer" with reason "audit failed".
96
97	### Tier classification
98
99	After collecting all results, classify packages into tiers. This helps the user understand the risk profile at a glance:
100
101	\| Tier \| Description \| Typical action \|
102	\|------\|-------------\|----------------\|
103	\| Runtime, high surface \| Libraries your code calls directly (parsers, diff engines, UI libs) \| Check provenance, review diff, run tests \|
104	\| SDK/API deps \| Third-party service SDKs (agent SDKs, platform integrations) \| Read changelog for API changes, test integration \|
105	\| Dev-only \| Type definitions, build tools, test frameworks \| Update freely — these don't ship \|
106	\| Build toolchain \| Bun itse

People who liked this also viewed

6 picks

Type

update-deps

7.2kstars517forks

View on GitHub

How to install update-deps?

backnotprop/plannotator/update-deps

$npx -y skills add backnotprop/plannotator --skill update-deps

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Update Dependencies
2
3	Audit outdated packages, verify supply chain integrity, bump what's safe, defer what needs review, and log everything.
4
5	This process has three phases: discovery, integrity audit, and execution. The integrity audit is the most important — every package gets checked before it touches the lockfile.
6
7	## Phase 1: Discovery
8
9	Run `bun outdated` to get the full list of packages with available updates.
10
11	```bash
12	bun outdated
13	```
14
15	Parse the output into a structured list. For each package, note:
16	- Package name
17	- Current version
18	- Available update version
19	- Whether it's age-gated (indicated by `` in the output — the footnote "The indicates that version isn't true latest due to minimum release age" confirms this)
20	- Whether it's a runtime dep, dev dep, or peer dep
21
22	Also check whether any packages are blocked entirely by the age gate (like `@pierre/diffs` was when its minimum semver range couldn't resolve). Flag these separately — they may need `minimumReleaseAgeExcludes` in `bunfig.toml`.
23
24	## Phase 2: Integrity Audit
25
26	This is the core of the process. Spawn one Sonnet sub-agent per package to run the integrity check in parallel. Sonnet is used here because these are independent, structured verification tasks that don't need heavier reasoning.
27
28	Each sub-agent receives the package name, current version, and target version, and performs the following checks:
29
30	### Sub-agent prompt template
31
32	For each outdated package, spawn a Sonnet agent with this task:
33
34	```
35	You are auditing the npm package "{package}" for a version bump from {current} to {target}.
36
37	Run these checks and report back with a JSON object:
38
39	1. Maintainer verification: Check if maintainers changed between versions.
40	npm view {package}@{current} maintainers --json
41	npm view {package}@{target} maintainers --json
42	Compare the two lists. Flag any additions or removals.
43
44	2. Publish date and age: Get the publish timestamp.
45	npm view {package} time --json
46	Extract the date for version {target}. Calculate days since publication.
47	Flag if younger than 7 days.
48
49	3. Provenance: Check if the package has registry signatures or attestations.
50	npm audit signatures (if not already run this session)
51	Note whether the package has provenance attestations.
52
53	4. Tarball diff: Show what actually changed in the published package.
54	npm diff --diff={package}@{current} --diff={package}@{target}
55	Summarize the changes:
56	- How many files changed
57	- Are changes limited to version bumps, deps, and rebuilt dist? Or are there meaningful source changes?
58	- Any new runtime dependencies added?
59	- Any suspicious patterns (obfuscated code, eval(), network calls in unexpected places)
60
61	5. Release notes: Try to find what changed.
62	Check the package's repository for release notes or changelog:
63	npm view {package}@{target} repository.url
64	gh release view v{target} --repo <owner/repo> (try with and without v prefix)
65	Summarize the changelog if found.
66
67	Report your findings as JSON:
68
69	{{
70	"package": "{package}",
71	"from": "{current}",
72	"to": "{target}",
73	"age_days": <number>,
74	"maintainers_changed": <boolean>,
75	"maintainers_added": [],
76	"maintainers_removed": [],
77	"provenance": <boolean>,
78	"new_runtime_deps": [],
79	"files_changed": <number>,
80	"has_source_changes": <boolean>,
81	"changelog_summary": "<brief summary>",
82	"suspicious_patterns": [],
83	"verdict": "safe" \| "review" \| "defer",
84	"verdict_reason": "<one sentence explanation>"
85	}}
86
87	Verdict guidelines:
88	- "safe": Same maintainers, no new runtime deps, changes match what changelog describes, no suspicious patterns
89	- "review": Minor concerns (e.g., new maintainer who is clearly from the same org, small new dep from known publisher)
90	- "defer": Maintainer changes from unknown accounts, new runtime deps with unclear purpose, suspicious code patterns, substantive API changes that need integration testing
91	```
92
93	### Collecting results
94
95	As sub-agents complete, collect their JSON reports. If a sub-agent fails or times out, mark that package as "defer" with reason "audit failed".
96
97	### Tier classification
98
99	After collecting all results, classify packages into tiers. This helps the user understand the risk profile at a glance:
100
101	\| Tier \| Description \| Typical action \|
102	\|------\|-------------\|----------------\|
103	\| Runtime, high surface \| Libraries your code calls directly (parsers, diff engines, UI libs) \| Check provenance, review diff, run tests \|
104	\| SDK/API deps \| Third-party service SDKs (agent SDKs, platform integrations) \| Read changelog for API changes, test integration \|
105	\| Dev-only \| Type definitions, build tools, test frameworks \| Update freely — these don't ship \|
106	\| Build toolchain \| Bun itse

People who liked this also viewed

6 picks

Type