skills/cleanup-resources/SKILL.md
End-of-workflow audit of touched GitHub issues, PRs, and branches via a Sonnet subagent. Use when: (1) /big-plan, /x-as-pr, or /x-wt-teams finishes its main work and needs to verify every touched resource is in the right state (closed when done, kept when ongoing, deleted when dead), (2) User says 'cleanup resources', 'audit cleanup', or 'check what should be closed', (3) A long workflow ends and the manager wants a structured paper trail of what it closed/kept/deleted. Auto-execute by default — the Sonnet agent proposes, the manager (you) executes safe actions and prints a final report.
npx skillsauth add takazudo/claude-resources cleanup-resourcesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
End-of-workflow audit for GitHub issues, PRs, and branches the calling workflow touched. Long workflows (big-plan, x-as-pr, x-wt-teams) tend to drop the trailing "close the source issue" / "delete the dead local branch" steps because context drifts. This skill forces an explicit checkpoint: gather a manifest of every touched resource, hand it to a fresh Sonnet agent for audit, then execute the safe actions and report.
This skill is invoked at the end of a parent workflow — never mid-flight. Typical callers:
/big-plan — at Step 10 (Close source issues). Manifest: source issues passed to the planning session./x-as-pr — after Session Report / Requirements Verification. Manifest: tracking issue (if --make-issue), the working branch (if the PR was auto-merged via -m / Merge Mode), unrelated-findings issues raised mid-workflow./x-wt-teams — replaces the old "Close Tracking Issue" + Step 16 cleanup. Manifest: tracking issue, sub-issues (if epic), root PR, base branch, topic branches, auto-merged status (the caller's -m flag).Note on flag naming: this skill's own -a / --auto-merged flag means "the caller auto-merged the root PR." In the calling workflows that signal is their -m / --merge flag (their -a is the autonomy/auto-chain flag and does NOT imply a merge) — callers pass -a here iff -m was on their invocation.
Other callers can use it the same way: build a manifest, invoke, execute the returned plan.
Before invoking the Sonnet agent, gather every resource the parent workflow created or touched. The manager (you) already knows these from session state — you do not need to grep git or scan the org. Build the manifest from memory of what the workflow did.
Structure the manifest as a single markdown block. Use this exact shape so the agent can parse consistently:
## Workflow context
- workflow: <big-plan | x-as-pr | x-wt-teams>
- auto-flag (-a): <true | false>
- epic-mode: <true | false> # true when the parent dealt with a [Epic] issue from /big-plan
- root-PR: <url-or-"none">
- root-PR-merged: <true | false>
- parent-branch: <branch-name-or-"none">
## Resources
### Issues
- #<number> — <role> — <one-line context>
- ...
### PRs
- <url> — <role> — <merged|open|draft>
- ...
### Branches
- <branch-name> — <role> — <local|remote|both> — <pr-merged: true|false>
- ...
## Notes for the agent
<any free-form context: e.g. "issue #45 has follow-up work tracked separately, KEEP it open">
Roles to use (consistent vocabulary helps the agent):
source (existed before; the workflow superseded it), tracking (created by the workflow as a spec/log), epic, sub (under an epic), fix (review-fix issue), unrelated-finding (side-effect issue raised mid-workflow), claimed-existing (user-supplied, not created here).root (the main PR for the workflow), topic (sub-PR merged into a base branch), fix (delegated fix PR).base (the base branch of an x-wt-teams session), topic (child branch under a base), working (the single x-as-pr working branch), fix (an agent-fix/<slug> branch from the -fix auto-fix step), parent (the branch the parent workflow targeted).If a resource doesn't fit, invent a short role label and explain in Notes for the agent.
Use the Agent tool to spawn a general-purpose agent with model: sonnet. The agent's job is analysis only — it must NOT close, delete, or edit anything. The manager executes actions in Step 3.
Prompt template (substitute the manifest):
You are auditing resources from a just-completed Claude Code workflow. The manager (parent session) handed you a manifest of every issue, PR, and branch touched during the workflow. Your job is to decide which should be CLOSED, KEPT, or DELETED, and return a structured plan. **Do not take any action yourself — only propose.**
Manifest:
<paste the full markdown manifest here>
Audit procedure:
1. For every issue in the manifest, run `gh issue view <number>` to read its current state, body, and recent comments. Check:
- Is it already closed? → action: keep, reason: "already closed".
- Does its body declare a TODO checklist with unchecked items? → action: keep, reason: "TODO checklist has open items".
- Was its work superseded by another issue/PR in the manifest (e.g. source issue replaced by an epic, fix issue replaced by a merged PR)? → action: close, with a one-line comment referencing the superseder.
- Is it an `unrelated-finding`? → action: keep, UNLESS it was already closed by `-fix` (the `/x-as-pr` or `/x-wt-teams` auto-fix step closes the ones it fixed and links the fix PR). An already-closed `unrelated-finding` stays closed (action: keep, reason: "already closed by -fix"). Open ones are intentional follow-ups — never close them here.
- Is it a `tracking` issue whose root PR is now merged (or the workflow ended cleanly)? → action: close.
- Is it a `sub` issue whose corresponding PR is merged into the base? → action: close.
- Is it an `epic` whose root PR is merged AND all sub-issues are closed? → action: close. Otherwise → keep.
2. For every PR in the manifest, run `gh pr view <url>` to read its state. PRs that are still open and intentional → keep. PRs already merged → keep (no action; they're done). PRs closed without merge (`state: CLOSED`, `merged: false`) → also keep, but add reason "manually closed without merge — investigate if the workflow expected it to merge". Do NOT propose closing open PRs unless the manifest's "Notes for the agent" explicitly asks for it.
3. For every branch in the manifest:
- Check remote state: `gh api repos/{owner}/{repo}/branches/{name}` or `git ls-remote --heads origin <branch>`.
- Check local state: assume the manager will check with `git branch --list <name>` before deleting.
- If pr-merged=true and the branch's role is `topic`, `working`, `base`, or `fix` → action: delete (both local and remote where applicable). Reason: "PR merged, branch is a dead pointer."
- If the remote has already been deleted (e.g. by `gh pr merge --delete-branch`) but the local still exists → action: delete-local-only.
- If pr-merged=false → action: keep.
- NEVER propose deleting `parent` branches — those belong to other work.
4. When the workflow's `auto-flag` is true (the caller auto-merged via its `-m` / `--merge` flag, passed to this skill as `-a` / `--auto-merged`) AND root-PR-merged is true, be more aggressive about deleting working/base/topic branches. The user explicitly opted into full auto-cleanup.
5. When in doubt about any resource, choose KEEP and explain in the reason. The manager will surface ambiguous cases to the user.
Return the plan as a single markdown block in this exact shape:
## Cleanup plan
### Close
- issue #<n> — <reason> — comment: "<one-line supersedes comment, or omit if no comment needed>"
- ...
### Delete (branches)
- <branch-name> — scope: <local|remote|both> — <reason>
- ...
### Keep
- <resource> — <reason>
- ...
### Ambiguous (manager: surface to user)
- <resource> — <why it's unclear>
- ...
End the response with one line: `Audit complete. <N> close / <M> delete / <K> keep / <A> ambiguous.`
Spawn the agent via the Agent tool with:
subagent_type: general-purposemodel: sonnetdescription: Audit workflow resources for cleanupprompt: the prompt above with the manifest filled inWait for the agent to return.
Read the agent's plan. Execute each action only when it is unambiguously safe. The agent already filtered out unsafe cases into "Ambiguous", but the manager re-checks before acting.
Close issues:
for each "Close" entry:
# Skip if already closed (defensive — agent may have raced with an external close)
state=$(gh issue view <n> --json state -q '.state')
if [ "$state" = "OPEN" ]; then
if [ -n "<comment>" ]; then
gh issue comment <n> --body "<comment>"
fi
gh issue close <n>
fi
Delete branches:
for each "Delete (branches)" entry:
case "<scope>" in
local)
# Use -d (NOT -D). If unmerged, surface as a loud failure rather than silently destroy work.
git branch -d <branch> 2>&1 || echo "WARN: local branch <branch> not deleted — unmerged commits or already gone"
;;
remote)
git push origin --delete <branch> 2>/dev/null || echo "WARN: remote branch <branch> not deleted — already gone"
;;
both)
git branch -d <branch> 2>&1 || echo "WARN: local branch <branch> not deleted — unmerged commits or already gone"
git push origin --delete <branch> 2>/dev/null || echo "WARN: remote branch <branch> not deleted — already gone"
;;
esac
Currently checked-out branch — switch off before deleting. git branch -d cannot delete the current branch. If the manager is on a branch that's in the delete list, check out a safe parent (the parent-branch from the manifest, or the repo default) first:
CURRENT=$(git branch --show-current)
if [ "$CURRENT" = "<branch-to-delete>" ]; then
git fetch origin --prune
git checkout <parent-branch>
git pull origin <parent-branch>
fi
Never use -D (force delete). If -d refuses, that's the safety net working — surface the warning, do not retry with -D.
Print a concise human-readable summary to the chat. Format:
## Cleanup complete
### Closed
- #<n> — <title> — <reason>
- ...
### Deleted branches
- <branch-name> (local + remote) — <reason>
- ...
### Kept
- #<n> — <title> — <reason>
- ...
### Warnings
- <any failed close/delete with the warning message>
- ...
### Ambiguous (please review)
- <resource> — <agent's reason>
- ...
If there are no actions (everything was already in the right state), print just: Cleanup audit: all resources in expected state — nothing to do.
If the Ambiguous section is non-empty, do NOT auto-resolve. Surface to the user and let them decide. The agent's job was to filter the obvious cases; the manager's job is to act on those AND show the unclear ones.
gh issue reopen exists. Default to closing when the agent is confident.git branch -d (without force) refuses, trust the refusal — there are unmerged commits.-fix. They are explicitly opt-in follow-up work, so the audit never closes an open one. The exception is the -fix / --auto-fix auto-fix step in /x-as-pr / /x-wt-teams: it closes the agent-found issues it actually fixed (linking the fix PR) before cleanup runs. The audit leaves those already-closed and keeps every still-open one. The agent's prompt enforces this; the manager doesn't second-guess.-m / --merge flag (passed here as -a / --auto-merged) is the signal for aggressive cleanup. Without it, prefer keeping branches around — the user may want to inspect locally before deleting. With it and root-PR-merged, the user opted in to full cleanup including local dead branches (this is the specific bug the skill fixes: --delete-branch removes remote, the old workflow left local behind)./x-as-pr with --no-issue and no merged PR) — the manifest would be empty.In all other cases, the parent skill should invoke /cleanup-resources at its STOP point. The audit either confirms everything is already correct (nothing to do, fast) or it catches a missed close/delete.
Skill tool: skill="cleanup-resources", args="workflow:x-wt-teams -a"
The manager (parent skill) then continues in the same turn by building the manifest and following Steps 1–4 above. The args are advisory — they tell the cleanup skill which workflow flavor invoked it, so any workflow-specific hints in this SKILL.md apply.
development
Link Claude Code skill names mentioned in a CodeGrid article (data/{series}/{n}.md) to the author's public claude-resources repo, pinned to the latest commit hash so links don't rot. Use when: (1) user says 'linkify cc resources', 'link the skills', 'link skill names', or invokes /dev-linkify-cc-resources; (2) editing a CodeGrid article that mentions `/commits`, `/pr-complete`, `/skill-creator` or other Claude Code skills and they should point to claude-resources. Only links skills that actually exist in the public repo; skips hypothetical examples and code blocks.
development
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd / /gco-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
tools
AI-based testing via subagent + a per-task test-flow skill. Use when the user wants to verify something that mechanical assertions can't fully capture — image recognition, visual size/position comparison, animation smoothness, multi-step manual flows that need AI judgment. Triggers: 'AI-based test', 'AI test', 'visual verify', 'image recognition test', 'manual operation test', 'human-eye check', 'verify visually', 'compare screenshots', 'looks the same', 'looks correct'. The skill's job is to (1) author a focused test-flow skill that captures the exact procedure + verdict criteria, then (2) dispatch a verification subagent via the Agent tool that loads BOTH the test-flow skill AND a browser-driving skill (/verify-ui primary, /headless-browser fallback) so the subagent has clear context and consistent verdicts. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.
tools
Solve a complex bug or design problem by building a tiny isolated prototype first, instead of patching the production system in place. Trigger PROACTIVELY when (1) the same bug has resisted 2+ in-place fix attempts (fail-retry loop), (2) the user mentions "minimal prototype", "from zero", "from scratch", "simple script", "sandbox", "standalone", "isolate", "play around", or "try a sandbox version", (3) you find yourself ranking a list of suspects and ruling them out via source-grep on a runtime/visual bug, (4) the user is brainstorming many design options for a UI surface and wants speed (e.g., "make 20 patterns of the top page"), (5) the next reasonable step would be "instrument the existing complex code" — pause and consider this skill instead. Build the prototype in the repo-scoped Dropbox-synced cclogs dir (`$DROPBOX_CCLOGS_DIR/<repo>/<descriptive-name>/`) so it survives switching between Mac and WSL; the exception is a prototype that must import the repo's production code or use its workspace/Vite tooling — keep that one in `__inbox/<descriptive-name>/` in the project root (in-repo, gitignored) so relative imports resolve. Match the project's tech stack (HTML+CSS+vanilla JS for static sites, Vite+React for React apps, Node script for CLI/utility logic). Don't commit it — its value is the learning, not the artifact. **Variant for repeated regression cycles (8+ in-place fixes on the same bug class):** keep the prototype as a committed sub-package named `packages/prototype-<topic>/` — see the "Variant: project-level reference prototype" section below.