菜单
Reclaim disk space on a Mac dev machine by deleting regenerable dev caches (Cargo/zfb build output, node_modules, pnpm/npm caches, OS/app caches) and thinning APFS local snapshots so the space actually frees. Manual-only — invoke with /dev-clean-mac when a Mac is low on disk.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Sweep open GitHub issues — optionally narrowed by label — and drive each to completion via `/big-plan -m -a`. Collects candidates, triages out work that needs careful human judgment, confirms once, then handles the rest autonomously one issue at a time. Use when: (1) User says '/issue-sweep', 'sweep issues', 'sweep open issues', 'handle the open issues', 'clear the issue backlog', or 'do the issues', (2) The user wants to batch-process a label's worth of issues (e.g. `agent-found`, `mac`), (3) After a work round that left a pile of follow-up issues. Options: "`-f`/`--filter LABEL` keeps only issues carrying that label; `-ex`/`--exclude LABEL`" drops issues carrying it; with no options it sweeps ALL open issues. Locally-checkable "verify X" tasks are verified directly and closed (not run through `/big-plan`). Skips issues that need careful human judgment (huge multi-major version bumps, super-big epics, design calls); verification tasks that can't be auto-verified locally (auth/deploy/external/subjective) are
Generate or redesign raster images (PNG mockups, illustrations, photos, UI design polish) from inside Claude Code by driving Codex CLI's built-in $imagegen, billed to ChatGPT-included usage instead of per-image OpenAI API charges. Use whenever the user wants to create/generate an image, make a mockup or illustration, produce a photo, polish or redesign a UI from a screenshot, or get a PNG out of a session — even if they don't mention Codex or "imagegen". This is the preferred image-generation path because Anthropic models cannot generate raster images and this route avoids API billing.
Iterative visual design-polish loop for an existing or WIP web UI. Each round: capture the live page as screenshots, judge it from the rendered pixels, and apply CSS polish toward a better-looking target using /css-wisdom's tight-token strategy — then re-capture and compare. The target direction is set by codex-imagegen 'north-star' mockups generated from the current screenshot, so the loop pursues a genuinely better look instead of nudging the existing one in place. Use when: (1) user says 'design-polish-loop', 'polish loop', 'polish this page/design/UI', (2) user wants to level up / upgrade the look of a current design or WIP project, (3) user wants AI-proposed redesign directions applied to a real rendering page, (4) user calls a design plain, dated, flat, or unpolished and wants it improved. Main use case: improving the current design of a WIP project. It polishes what already renders — not brand-new-from-scratch pages.
Bump every `@takazudo/*` registry dependency in the current project to its newest version, resolving each by the channel it currently tracks. Use when: (1) User says '/dev-bump-zudo-deps', 'bump zudo deps', 'bump the @takazudo packages', 'update zfb', 'update zudo-doc', or 'update the takazudo toolchain to latest', (2) A new `@takazudo/*` prerelease or release has shipped and this project should adopt it, (3) Routine first-party dependency-update rounds. Resolution rule: a dep currently on the `next` prerelease line (`0.1.0-next.N`) → newest `next` release; a dep on the literal `latest` tag → `dist-tags.latest`; a plain stable semver → newest stable. Skips `workspace:`/`file:`/`link:` specs and leaves operator style (exact / `^` / `~`) and prerelease channel intact. A bundled script does the discovery + semver resolution; this skill drives install + verify + report.
Plan implementation by breaking work into one epic GitHub issue + child sub-issues. Use when: (1) User says '/big-plan', (2) User wants to plan an implementation before coding, (3) User wants to split a feature into small issues for parallel agent team work, (4) User references existing issues (e.g. 'implement issue #123', 'plan all open issues', 'plan recent 3 open issues'). Auto-reads project-scope l-lessons-* skills (from /retro-notes) before planning. Codex (-co) is the DEFAULT Step 5 plan reviewer — it runs even when no reviewer flag is passed; -op/-gco add more second opinions (runnable in parallel). Use -a/--auto to run the chain autonomously: skip the Step 6 confirmation wait (pausing only when something needs careful consideration), auto-create the issues, then auto-invoke the implementation skill in the same session — /x-wt-teams for a multi-sub-issue plan, /x-as-pr for a single-sub-issue plan — forwarding -a so multi-wave plans auto-chain wave after wave. Use -m/--merge to also merge the final PR i
Purge GitHub Actions caches across every non-archived repo for one or more GitHub owners (users or orgs). Use when (1) the user says "purge gh cache", "clear actions cache", "delete CI cache", or invokes /dev-purge-gh-cache, (2) the user wants to free up GitHub Actions cache storage for an account/org, (3) the user names one or more GitHub owners (e.g. "Takazudo", "zudolab") and asks to wipe their Actions caches. Handles fan-out across all repos, parallel survey, bulk delete, and real-time verification.
| name | dev-clean-mac |
| description | Reclaim disk space on a Mac dev machine by deleting regenerable dev caches (Cargo/zfb build output, node_modules, pnpm/npm caches, OS/app caches) and thinning APFS local snapshots so the space actually frees. Manual-only — invoke with /dev-clean-mac when a Mac is low on disk. |
| disable-model-invocation | true |
| argument-hint | [--keep-node-modules] |
Frees disk on a Mac dev machine by deleting caches and build artifacts that
regenerate on demand. Tuned for this layout — $HOME/repos (with myoss/zfb),
a shared Cargo target dir, pnpm/npm caches — but every step is existence-guarded,
so it runs safely on any Mac with a similar structure (e.g. a second machine).
Why a script and not ad-hoc rm: on APFS, deleting files frees nothing while
local Time Machine snapshots still reference the data — df keeps showing the old
number. The script ends by thinning those snapshots (tmutil thinlocalsnapshots),
which is what makes the reclaimed space materialize. Skipping that step is the #1
reason a cleanup "does nothing."
The script lives at scripts/clean-mac.sh in this skill directory.
Dry run first — show the user what will be freed, delete nothing:
bash "$HOME/.claude/skills/dev-clean-mac/scripts/clean-mac.sh" --dry-run
Relay the per-path sizes and the measured total to the user.
Confirm node_modules. By default the script deletes all node_modules
under $HOME/repos (reinstallable via pnpm/npm install). If the user is
mid-work on a project, pass --keep-node-modules to preserve them.
Run for real:
bash "$HOME/.claude/skills/dev-clean-mac/scripts/clean-mac.sh" --run
# or, to keep node_modules:
bash "$HOME/.claude/skills/dev-clean-mac/scripts/clean-mac.sh" --run --keep-node-modules
The deletions can take a few minutes (millions of small files); it may
auto-background. Report the BEFORE/AFTER df lines it prints.
Cargo: the shared target-dir from $HOME/.cargo/config.toml (defaults to
$HOME/.cargo-target, dominated by zfb), $HOME/.cargo/registry, and every
per-project target/ under $HOME/repos (detected by cargo's CACHEDIR.TAG).
zfb: checked-in release tarballs (zfb-*.tar.gz) and all .zfb-build/ dirs.
node_modules: every one under $HOME/repos (unless --keep-node-modules).
JS caches: pnpm store prune, npm cache clean, $HOME/Library/Caches/pnpm.
OS/app caches: ms-playwright, electron, copilot, $HOME/.cache/codex-runtimes,
Homebrew cache, Adobe/CreativeCloud logs, unavailable iOS simulators.
Downloads: *.dmg / *.pkg installers (re-downloadable).
APFS local snapshots: thinned at the end to release everything above.
Source trees, image/data stashes (e.g. zmod-image-stash), browser profiles,
and app data (Claude/Chrome/Slack containers) — only regenerable caches and
artifacts. Every path is verified to be under $HOME before removal; missing
paths are skipped silently, which is what makes it portable across machines.
First builds/installs after running are slower (caches re-download, projects
rebuild) — that's the expected trade for the space.
Safe to re-run anytime; all steps are idempotent.
Local Time Machine snapshots are convenience restore points, not your real
backup — thinning them does not affect Time Machine backups on disk/network.