portable-agent-skills

Stage all changes (or specified files), write a descriptive commit message based on a diff review, commit, and push to origin. Use when the user invokes /commit, or says "stage and commit", "commit and push", "commit everything", "push my changes", or similar. Optional argument: a list of specific files/paths to stage instead of all changes.

Multi-pass review of recent work to catch errors, gaps, and improvements. Use when the user invokes /cyw, or asks to 'check your work', 'review what you just did', 'is this correct/complete?', 'what's missing?', 'what needs fixing?'. Runs a structured 3-phase loop: critical review, fix, verify. Repeats up to 3 times, stopping early when no issues remain.

Audit TSX files, identify non-UI logic, and extract it into custom hooks. Use when the user invokes /extract-hooks, or says "extract hooks", "move logic out of components", or "separate logic from layout".

Lightweight planning + execution in a single pass. For smaller jobs that don't warrant a full plan-init / plan-phase / plan-run workflow. Interviews the user briefly, explores the codebase, prints a checklist, executes it, runs /cyw, then commits. Use when the user invokes /plan-and-do, or says "plan and do", "just do it with a plan", "quick plan then execute". For large feature sets with multiple independently committable phases, use /plan-init + /plan-phase + /plan-run instead.

Iterative plan refinement between Claude and Codex. Each agent writes an initial plan using the plan-init methodology, then they alternately critique and incorporate the other's best ideas, with a judge checking for convergence after each round. Stops at convergence (≥8/10), stagnation (no score improvement over 3 consecutive rounds), or after 10 rounds. Writes a summary.md with a score trajectory, a pointer to the winning plan, and a breakdown of remaining differences with pros/cons. Supports resume from an interrupted run. Use when the user invokes /plan-duel, or says "duel the plans", "run plan duel", "cross-compare plans with codex". Argument: the problem statement (inline text or a file path), or the path to an existing plan-duels workdir to resume.

Create a structured project plan document for a task. Interviews the user to fill gaps, explores the codebase for context, then produces a master plan with goal, success criteria (checkable tests/conditions), technical constraints, non-goals, and affected areas. Does NOT break the plan into phases — use /plan-phase for that. Use when the user invokes /plan-init, or says "make a plan", "create a plan", "plan this out", "let's plan before we start".

Work breakdown structure: reads a plan document and breaks it into ordered phases. Proposes the phase structure to the user for approval, then creates a phase document (with checklist) for each phase and writes a new phases.md execution tracker alongside the plan. The original plan document is never modified. Use when the user invokes /plan-phase, or says "break this down into phases", "create the phase documents", "do the work breakdown", "WBS this plan". Argument: path to a plan.md file (e.g. plans/auth-refactor/plan.md). If no argument, scan plans/ for plan.md files and ask which one.

Execute a project plan produced by /plan-init + /plan-phase. Reads the master plan and phases.md execution tracker, identifies incomplete phases, and executes each phase in order: checks entry criteria, completes tasks, runs verification, runs /cyw, marks the phase done in docs, reviews the staged diff, then commits and pushes to origin. Updates phases.md status block throughout. Skips already-completed phases so it is safe to restart. Use when the user invokes /plan-run, or says "execute the plan", "run the plan", "start the plan", "continue the plan". Argument: path to a plan.md file (phases.md is inferred from the same directory). If no argument, scan plans/ and ask which plan to run.

Use when the user asks for a deep, hierarchical, or thorough security review of the codebase. Breaks the codebase into architectural components and reviews each with focused sub-agents, then synthesizes findings. Better than security-review-codebase for large or complex codebases.

This skill should be used when the user asks to 'security review the codebase', 'audit the codebase for vulnerabilities', 'run a full security audit', 'check the whole project for security issues', or similar requests for a security review scoped to the entire checked-in codebase rather than uncommitted changes.

Test-driven development workflow. Enforces red/green/refactor discipline: write failing tests first, implement the minimum code to pass, then clean up. Use when the user invokes /tdd with a feature to implement (e.g., "/tdd implement the vocab export endpoint", "/tdd add useMyHook"). Never skips ahead to implementation before confirming tests fail.