Takazudo

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.

Report bugs and improvement ideas found in Takazudo's own upstream packages as GitHub issues on the upstream repo. The current project depends on packages built by the user under github.com/takazudo and github.com/zudolab (e.g. zudolab/zudo-doc, Takazudo/zudo-front-builder, the @takazudo/* npm scope). Use when: (1) User invokes /dev-upstream-report — with a description to report something now, or with no args to enable upstream-watch mode for the rest of the session, (2) During development a bug, limitation, or missing feature is traced to one of these upstream packages rather than the current project, (3) User says 'report upstream', 'upstream issue', 'file it on the package repo', or blames one of these packages for a problem.

Start a development workflow as a draft PR. Creates a NEW branch from the current branch, empty start commit, draft PR targeting the current branch, then implements. ALWAYS creates a new branch by default — produces a nested PR-on-PR when the current branch already has one. Use when: (1) User says 'dev as pr', (2) User wants a PR-first workflow before coding, (3) User passes -s/--stay to reuse the current branch instead of nesting, (4) User passes a GitHub issue URL to implement, (5) User passes --make-issue/--issue to create an issue first. Logs progress via issue comments when an issue is linked.

Project-specific CSS and component rules for zudo-doc. Must be consulted before writing or editing CSS, Tailwind classes, color tokens, or component markup in this project. Covers: component-first strategy, design token system, three-tier color architecture, and palette index convention. Triggered by 'design system', 'zudo-doc-design-system', 'zudo-doc-css-wisdom' (old name).

Translate zudo-doc documentation between English and Japanese with project-specific conventions.

Writing and formatting rules for MDX articles in zcss. Use when: (1) Writing or editing MDX docs in src/content/docs/, (2) Creating new articles, (3) User says 'writing rules' or 'article format'. Auto-load when working on MDX content.

Run before-push quality checks for the zudo-css project. Use when: (1) User says 'b4push', 'before push', or 'run checks', (2) Before pushing to remote, (3) After completing implementation work.

Create or convert CSS best-practices articles into "deep articles" with sub-pages in the zcss Astro site. Use when: (1) An article topic has enough depth to warrant "see more" reference sub-pages, (2) Converting a flat .mdx article into a category with index + child pages, (3) Adding deep reference content to an existing article, (4) User says 'deep article', 'add sub-pages', 'expand article', or 'add reference pages'.

Translate English docs to Japanese for the Astro i18n locale. Use when: (1) User wants to translate en docs to ja, (2) User says 'translate', 'ja version', 'Japanese translation', (3) User wants to check for missing ja docs.

Guidance for using CssPreview component in zcss documentation articles. Use when: (1) Writing or editing CssPreview demos in MDX articles, (2) Deciding whether to use defaultOpen={true} or false, (3) User asks about demo component usage patterns.

Run comprehensive pre-push validation covering code quality, build, production server, and smoke e2e tests. Use when: (1) Completing a PR or feature implementation, (2) Before pushing significant changes, (3) After large refactors, (4) User says 'b4push', 'before push', 'check everything', or 'ready to push'.

Capture screenshots of all manual pages at high resolution for translation verification. Use when verifying that translations match page images, checking layout correctness, or inspecting for content mismatches.

Run the complete PDF processing pipeline to convert the manual PDF into Next.js application data. This command executes all steps automatically: split, render, extract, translate, build, and manifest.

Capture all manual pages and verify translations match page images using AI-powered checking. Identifies extraction failures and can regenerate extracted text from images.

Datasheet-aware schematic review for this USB-PD power-supply board. Exports the KiCad schematic to a compact netlist, walks a power-supply checklist (VBUS sense paths, regulator EN/feedback dividers, dropout headroom, polarity, decoupling, abs-max), and writes a review report whose findings are LEADS to verify against the datasheet — never ground truth. Use when the user says 'review the schematic', 'schematic review', 'pd-schematic-review', 'check the design', or 'audit the circuit'. READ-ONLY against all *.kicad_sch / *.kicad_pcb.

Bump the X digit of this project's X.Y.Z version — a real product release. Use when the user says 'bump version x', 'product release', 'l-bump-version-x'. Resets Z to 0, KEEPS Y (lifetime JLCPCB-order counter), commits, tags, and creates a GitHub release.

Bump the Y digit of this project's X.Y.Z version — a new JLCPCB PCBA order. Use when the user says 'bump version y', 'new JLCPCB order', 'l-bump-version-y', or is placing the next PCB order. Resets Z to 0, commits, tags, and creates a GitHub release.

Bump the Z digit of this project's X.Y.Z version — a local checkpoint tag. Use when the user says 'bump version z', 'tag a checkpoint', 'l-bump-version-z'. Commits and creates a git tag ONLY (no GitHub release).

AI-based visual confirmation that a problem is resolved — Level 6 (final-resort) testing. Use ONLY when /verify-ui (mechanical computed-styles or screenshot pixel-diff) cannot reach the assertion AND writing an E2E (Playwright) is intractable — e.g. canvas-driven photo-editors, zoomable surfaces, free-form drawing tools, multi-layer compositing with resizable objects. NOT for constant or repeated verification. NEVER for CI gates. AI verdicts are non-deterministic, cost-bearing, and not reproducible across runs. The skill (1) authors a project-scope test-flow skill capturing the procedure + verdict criteria, then (2) dispatches a verification subagent via the Agent tool that loads the test-flow skill plus a browser-driving skill (/verify-ui primary, /headless-browser fallback). Triggers: 'verify ui ai', 'AI verify', 'L6 verify', 'final resort test', 'AI-based visual confirmation'. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.

Browser automation with two efficiency tiers. Tier 1: headless-check.js for quick health checks, screenshots, error detection (JSON output). Tier 2: Playwright CLI (@playwright/cli via npx) for interactive automation — click, fill, navigate, snapshots with YAML element refs (4x more token-efficient than MCP). Use when: (1) Quick page health checks, (2) Screenshots, (3) Console/network errors, (4) Form filling/navigating, (5) Multi-step interaction. Use MCP Playwright only for complex persistent context.

Verify CSS/UI changes match what the user asked for. Uses deterministic computed style checks to avoid LLM confirmation bias. Use when: (1) After CSS or layout changes the user asks to verify, (2) User says 'verify ui', 'check the result', 'confirm it works', (3) User asks to check via /headless-browser for style work. Use PROACTIVELY after CSS/layout changes when asked to verify.

Build, verify, and install CCResDoc.app locally for testing. Use when: (1) User says 'build ccresdoc', 'rebuild ccresdoc', 'install ccresdoc', 'ccresdoc-build', (2) User wants a fresh CCResDoc.app after Rust, app/, or src-tauri changes, (3) After Rust or zfb-output changes that need verification in the bundled .app.

Run comprehensive pre-push validation covering Rust formatting, Clippy lints, Rust tests, and the zfb app build. Use when: (1) Completing a PR or feature implementation, (2) Before pushing significant changes, (3) After large refactors or multi-file edits, (4) User says 'b4push', 'before push', 'check everything', 'run all checks', or 'ready to push'.

Develop, build, or fix the upstream zfb crate without disturbing $HOME/repos/myoss/zfb's working tree. Use when: (1) Editing zfb source as part of a ccresdoc task, (2) Filing a zfb PR / merging zfb fixes, (3) Bumping pinned versions (esbuild, tailwindcss, framework runtimes), (4) Anything that runs `git checkout` / `git stash` / `git commit` / `cargo install` against zfb. Mandatory because the zfb checkout at $HOME/repos/myoss/zfb is shared with other Claude Code sessions; touching its working tree races their state.

Design system reference for the mdx-formatter doc site (zudo-doc based). Use PROACTIVELY when: (1) Writing or modifying any CSS/styling in doc/, (2) Creating or editing React components in doc/src/components/, (3) Adding new pages or layouts to the doc site, (4) Reviewing UI changes in the doc site. Provides token names, spacing scales, color semantics, and typography rules. Do NOT invent custom CSS values — always use the design tokens below.

Run comprehensive pre-push validation covering code quality, builds, tests, and doc site. Use when: (1) Completing a PR or feature implementation, (2) Before pushing significant changes, (3) After large refactors or multi-file edits, (4) User says 'b4push', 'before push', 'check everything', 'run all checks', or 'ready to push'.

Search the JLCPCB electronic components database (~7 million parts) for hardware/electronics projects. Use when the user needs to: (1) Find electronic components (resistors, capacitors, inductors, ICs, connectors, diodes, transistors, MOSFETs, op-amps, microcontrollers, sensors, LEDs, etc.), (2) Look up specific part numbers, LCSC numbers (C-prefix), or manufacturer part numbers, (3) Find alternatives or equivalents for components, (4) Check component availability and stock at JLCPCB/LCSC, (5) Get component specifications (package type, footprint, description), (6) Search for parts for PCB assembly (PCBA) projects, (7) Find SMD or through-hole components, (8) Look up voltage regulators (LDO, linear, switching), audio jacks, connectors, or any other electronic parts. Keywords: JLCPCB, LCSC, electronic components, PCB parts, SMT assembly, BOM, bill of materials, component sourcing.

Search and reference documentation from the zfb (zudo-front-builder) project. Use when answering questions about zfb features, CLI usage, configuration, content collections, routing, build pipeline, or architecture decisions.

Verify the OKLCH/HSL dual-mode ColorPicker (packages/zudo-design-token-panel) renders its L (lightness), H (hue), and C/S (chroma/saturation) slider axes in the CORRECT direction — left edge = min value, right edge = max value, gradient and thumb position both aligned. Use when /verify-ui-ai dispatches a subagent for color-picker-axis-direction verification, or when a future PR changes the picker and you want to re-confirm the direction is still correct.

Run comprehensive pre-push validation covering builds, tests, and doc site. Use when: (1) Completing a PR or feature implementation, (2) Before pushing significant changes, (3) After large refactors or multi-file edits, (4) User says 'b4push', 'before push', 'check everything', 'run all checks', or 'ready to push'.