Menu
Use when batch-resolving approved todos, especially after code review or triage sessions
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | todo-resolve |
| description | Use when batch-resolving approved todos, especially after code review or triage sessions |
| argument-hint | [optional: specific todo ID or pattern] |
Resolve approved todos using parallel processing, document lessons learned, then clean up.
Only ready todos are resolved. pending todos are skipped — they haven't been triaged yet. If pending todos exist, list them at the end so the user knows what was left behind.
Scan .context/agent-workflows/todos/*.md and legacy todos/*.md. Partition by status:
ready (status field or -ready- in filename): resolve these.pending: skip. Report them at the end.complete: ignore, already done.If a specific todo ID or pattern was passed as an argument, filter to matching todos only (still must be ready).
Residual actionable work from code-review autofix pass after its safe_auto pass will already be ready.
Skip any todo that recommends deleting, removing, or gitignoring files in docs/brainstorms/, docs/plans/, or docs/solutions/ — these are intentional pipeline artifacts.
Create a task list grouped by type (e.g., TaskCreate in Claude Code, update_plan in Codex). Analyze dependencies -- items that others depend on run first. Output a mermaid diagram showing execution order and parallelism.
Spawn a general-purpose agent per item. Prefer parallel; fall back to sequential respecting dependency order.
Batching: 1-4 items: direct parallel returns. 5+ items: batches of 4, each returning only a short status summary (todo handled, files changed, tests run/skipped, blockers).
For large sets, use a scratch directory at .context/agent-workflows/todo-resolve/<run-id>/ for per-resolver artifacts. Return only completion summaries to parent.
Commit changes, mark todos resolved, push to remote.
GATE: STOP. Verify todos resolved and changes committed before proceeding.
Document any reusable lesson that surfaced during the todo resolution. Todo resolutions often expose patterns and architectural insights worth capturing.
GATE: STOP. Verify a solution document exists in docs/solutions/ if there were durable lessons. If none (user declined or no learnings), continue.
Delete completed/resolved todo files from both paths. If a scratch directory was created at .context/agent-workflows/todo-resolve/<run-id>/, delete it (unless user asked to inspect).
Todos resolved: [count]
Pending (skipped): [count, or "none"]
Lessons documented: [path to solution doc, or "skipped"]
Todos cleaned up: [count deleted]
If pending todos were skipped, list them:
Skipped pending todos (run /todo-triage to approve):
- 003-pending-p2-missing-index.md
- 005-pending-p3-rename-variable.md
Required before visually inspecting or QAing the Acepe desktop dev app, current dev app, Tauri WebView, session display, agent panel, or any UI-visible Acepe change. Use when the user says the dev app looks wrong, asks to inspect the app, asks for visual QA, or when a change affects desktop UI.
Run comprehensive agent-native architecture review with scored principles
Extract presentational UI from packages/desktop into @acepe/ui using MVC (Controller, Model, View). Use when moving a component to packages/ui, creating a shared UI primitive, splitting a smart Svelte file, or when the user mentions UI extraction, dumb view, thin wrapper, or @acepe/ui boundary.
Build web interfaces with genuine design quality, not AI slop. Use for any frontend work - landing pages, web apps, dashboards, admin panels, components, interactive experiences. Activates for both greenfield builds and modifications to existing applications. Detects existing design systems and respects them. Covers composition, typography, color, motion, and copy. Verifies results via screenshots before declaring done.
Commit, push, and open a PR with an adaptive, value-first description. Use when the user says "commit and PR", "push and open a PR", "ship this", "create a PR", "open a pull request", "commit push PR", or wants to go from working changes to an open pull request in one step. Also use when the user says "update the PR description", "refresh the PR description", "freshen the PR", or wants to rewrite an existing PR description. Produces PR descriptions that scale in depth with the complexity of the change, avoiding cookie-cutter templates.
This skill manages Git worktrees for isolated parallel development. It handles creating, listing, switching, and cleaning up worktrees with a simple interactive interface, following KISS principles.