package-removal
Skill412 starsChanged 4 months agoApache-2.0View on GitHub
10-step checklist for safely removing one or more packages from the Cacti monorepo. Covers inventory, dependency scan, TypeScript import audit, CI workflow cleanup, tsconfig references, test-tooling helpers, directory deletion, lockfile regeneration, tracking-doc update, and verification pass.
- Deletes or force-pushes
- Commits and pushes
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- ci-triageSkill
- codeql-scanningSkill
- code-reviewSkill
- doublecheckSkill
- refactor-planSkill
- <skill-name>Skill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 58
Run once per package name, separately:
- Distinctive: line 75
Run once per package name.
- Very specific: line 89
If found, remove the corresponding { "path": "./packages/<pkg-name>/tsconfig.json" } entry.
- Very specific: line 93
Check whether packages/cactus-test-tooling/src/main/typescript/ contains a package-specific Docker/container helper, then verify surviving …
- Distinctive: line 129
Add removed packages to the "Packages Approved for Removal" table with today's date.
- Very specific: line 133
Update Decision Summary counts: Remove/Archive +N, No Vote −N.
- Distinctive: line 141
All checks must return empty/clean output before the task is complete:
- Distinctive: line 167
After completing all steps, provide:
- Very specific: line 175
Run grep with one package name per call — never combine multiple names in a |-alternation pattern on macOS.
- Very specific: line 177
Never edit files under generated/ directly.
- Very specific: line 178
Do not remove cactus-test-tooling helpers that have surviving consumers.
- Distinctive: line 179
Treat any Step 2 or Step 3 blocker as a hard stop — resolve it before deleting the package directory.
- Distinctive: line 181
Do not git commit or git push — report what changed and let the user review, stage, and commit.
- Very specific: line 183
After completing, hand off to the code-reviewer agent to audit: no stale imports, no stale package.json deps, CI jobs removed, …
≈ “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.
Files
Cacti Package Removal Skill
Safe, complete procedure for removing one or more packages from the
Hyperledger Cacti Yarn 4 monorepo without leaving stale imports, dangling
CI jobs, or broken tsconfig.json references.
Repo Facts
- Yarn 4 monorepo,
nodeLinker: pnpm— no rootnode_modules/.bin/; useyarn <binary>in husky hooks, nevernpx. lerna.jsonautodiscovers packages via globs (packages/cactus-*) — no edits needed when removing packages.- Root
tsconfig.jsonhas explicit project references — always remove entries for deleted packages. - macOS
grepfails with "maximum repetition exceeds 255" on long|-alternation patterns — run one package name pergrepcall.
Input
You will receive:
- Package name(s): one or more
packages/<pkg-name>directories to remove - Context (optional): issue number, cleanup tracking doc path, branch name
Procedure
Step 1 — Inventory
List every directory targeted for removal and confirm current state:
find packages/ -maxdepth 1 -name "<pattern>" -type d | sort
ls packages/<pkg-name>/A prior partial cleanup may have removed source files but left dist/ and
node_modules/; that is fine — rm -rf in Step 7 handles it.
Step 2 — Cross-package package.json dependency check
For each removed package name, run separately (one term per call):
find packages/ examples/ extensions/ -name "package.json" \
-not -path "*/node_modules/*" \
-exec grep -l "<pkg-name>" {} \;Any hit outside the package's own directory is a blocker — remove that dependency declaration before proceeding.
Step 3 — TypeScript import check
Run once per package name, separately:
grep -r "<pkg-name>" packages/ --include="*.ts" --exclude-dir=node_modules
grep -r "<pkg-name>" examples/ --include="*.ts" --exclude-dir=node_modules
grep -r "<pkg-name>" extensions/ --include="*.ts" --exclude-dir=node_modulesAny import/require in a surviving package is a blocker — resolve it
first.
Step 4 — CI workflow audit
grep -rl "<pkg-name>" .github/Run once per package name. For each match:
| Match type | Action |
Job block in a grouped workflow (e.g. keychain-packages-workflow.yaml) | Delete the entire job block for the removed package; keep blocks for retained packages |
workflow_call reference in a parent workflow (e.g. packages-workflow.yaml) | Leave it — an empty grouped workflow is harmless |
| Standalone workflow file dedicated to the removed package | Delete the entire file |
Step 5 — Root tsconfig.json project references
grep "<pkg-name>" tsconfig.jsonIf found, remove the corresponding { "path": "./packages/<pkg-name>/tsconfig.json" } entry.
Step 6 — cactus-test-tooling helpers
Check whether packages/cactus-test-tooling/src/main/typescript/ contains a
package-specific Docker/container helper, then verify surviving consumers:
grep -r "<HelperClassName>" packages/ --include="*.ts" --exclude-dir=node_modules \
| grep -v "cactus-test-tooling\|<removed-pkg>"| Result | Action |
| No surviving consumer | Delete the subdirectory; remove its export { … } from packages/cactus-test-tooling/src/main/typescript/public-api.ts |
| Has a surviving consumer | Keep it — do not touch the helper or its export |
Example:
CactusKeychainVaultServerhad no surviving consumer → removed.VaultTestServerwas used bycactus-plugin-ledger-connector-fabric→ kept.
Step 7 — Delete package directories
rm -rf packages/<pkg-name>This removes everything including leftover dist/, node_modules/, and
.tgz pack artifacts.
Step 8 — Regenerate yarn.lock
yarn install --mode=update-lockfileRemoves stale workspace: entries for deleted packages from yarn.lock
without re-linking all dependencies.
Step 9 — Update docs/docs/cleanup-4025.md
- Add removed packages to the "Packages Approved for Removal" table with today's date.
- In the Review Tables, flip each removed package's
keep?cell from−→❌and set action columns toN/A. - Update Decision Summary counts:
Remove/Archive+N,No Vote−N. - Append a completion line to the footer:
**<Label> Completed:** YYYY-MM-DD — `<branch-name>`
Step 10 — Verification pass
All checks must return empty/clean output before the task is complete:
# No live TypeScript imports
grep -r "<pkg-name>" packages/ --include="*.ts" --exclude-dir=node_modules
# No package.json dependency declarations
find packages/ examples/ extensions/ -name "package.json" \
-not -path "*/node_modules/*" -exec grep -l "<pkg-name>" {} \;
# No CI workflow references
grep -rl "<pkg-name>" .github/
# No yarn.lock workspace entries
grep "<pkg-name>" yarn.lockAcceptable remaining hits: CHANGELOG.md files (auto-generated git history),
docs/ tracking documents, and dist/ build artifacts (stale until next
yarn tsc).
Step 11 - Extra verifications
Verify references to package being removed, for instance in the docs, CONTRIBUTING.md, tools/custom-checks/check-dependency-version-consistency, jest.config.js, openapi-generator-ignore, package.json. Notably, the reference to the package being removed should be removed from the root tsconfig.ts as well as from the tsconfig from packages depending on it. Do not remove references from the changelog.
Output Format
After completing all steps, provide:
- Summary: which packages were removed and any blockers resolved
- Verification: results of the Step 10 checks
- Residual risk: anything deferred or not verified (e.g. integration tests not run locally)
Constraints
- Run
grepwith one package name per call — never combine multiple names in a|-alternation pattern on macOS. - Never edit files under
generated/directly. - Do not remove
cactus-test-toolinghelpers that have surviving consumers. - Treat any Step 2 or Step 3 blocker as a hard stop — resolve it before deleting the package directory.
- Do not
git commitorgit push— report what changed and let the user review, stage, and commit. - After completing, hand off to the
code-revieweragent to audit: no stale imports, no stalepackage.jsondeps, CI jobs removed,tsconfig.jsonreferences cleaned,yarn.lockupdated, tracking doc updated.
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
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.

