القائمة
Use when reviewing pending todos for approval, prioritizing code review findings, or interactively categorizing work items
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
| name | todo-triage |
| description | Use when reviewing pending todos for approval, prioritizing code review findings, or interactively categorizing work items |
| argument-hint | [findings list or source type] |
| disable-model-invocation | true |
Interactive workflow for reviewing pending todos one by one and deciding whether to approve, skip, or modify each.
Do not write code during triage. This is purely for review and prioritization -- implementation happens in /todo-resolve.
.context/agent-workflows/todos/ and legacy todos/ directoriesFor each pending todo, present it clearly with severity, category, description, location, problem scenario, proposed solution, and effort estimate. Then ask:
Do you want to add this to the todo list?
1. yes - approve and mark ready
2. next - skip (deletes the todo file)
3. custom - modify before approving
Use severity levels: 🔴 P1 (CRITICAL), 🟡 P2 (IMPORTANT), 🔵 P3 (NICE-TO-HAVE).
Include progress tracking in each header: Progress: 3/10 completed
yes: Rename file from pending -> ready in both filename and frontmatter. Fill the Recommended Action section. If creating a new todo (not updating existing), use the naming convention from the todo-create skill.
Priority mapping: 🔴 P1 -> p1, 🟡 P2 -> p2, 🔵 P3 -> p3
Confirm: "✅ Approved: {filename} (Issue #{issue_id}) - Status: ready"
next: Delete the todo file. Log as skipped for the final summary.
custom: Ask what to modify, update, re-present, ask again.
After all items processed:
## Triage Complete
**Total Items:** [X] | **Approved (ready):** [Y] | **Skipped:** [Z]
### Approved Todos (Ready for Work):
- `042-ready-p1-transaction-boundaries.md` - Transaction boundary issue
### Skipped (Deleted):
- Item #5: [reason]
What would you like to do next?
1. run /todo-resolve to resolve the todos
2. commit the todos
3. nothing, go chill