菜单
Review and improve the backlog — identify vague tasks, missing priorities, broken dependencies, tasks needing specs, and stale items. Use when the user wants to groom, refine, clean up, or improve their task backlog.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Prepare a session handoff — summarize progress, annotate tasks with current status, and identify what's ready for the next session. Use at the end of a work session or when the user says they're done for now.
Pick up a task from the backlog and implement it. Reads the spec if one exists, starts the task, does the work, and marks it done. Use when the user wants to work on a specific task or the next available task.
Break down a goal into actionable tasks with dependencies, priorities, and optional specs. Use when the user wants to plan work, decompose a feature, or create a task breakdown.
Write a detailed spec document for a task before implementation begins. Use when the user wants to define requirements, acceptance criteria, or technical design for a task.
Daily standup summary — what was completed recently, what's in progress, and what's blocked. Use when the user asks for a standup, status update, or summary of recent work.
Show the current task backlog — pending, active, blocked, and overdue tasks. Use when the user asks about tasks, status, what needs to be done, or what's in progress.
| name | refine |
| description | Review and improve the backlog — identify vague tasks, missing priorities, broken dependencies, tasks needing specs, and stale items. Use when the user wants to groom, refine, clean up, or improve their task backlog. |
Review the current backlog and improve its quality. This is a grooming pass — make tasks actionable, well-prioritized, and properly connected.
Load the backlog — call task_list with filter status:pending to get all pending tasks.
Analyze each task for these issues:
Vague descriptions — tasks that are too broad or unclear. A good description starts with a verb and is specific enough that someone could implement it without asking questions. Flag tasks that need to be broken down or clarified.
Missing priorities — tasks without H/M/L priority. Suggest a priority based on the task's description and context.
Missing dependencies — tasks that logically depend on other tasks but don't have depends set. Look for ordering constraints (e.g., "write tests" should depend on the feature it tests).
Tasks needing specs — complex tasks (multi-step, architectural, or ambiguous) that don't have a doc attached. Check with task_count filter +doc status:pending and identify which tasks SHOULD have specs but don't.
Stale tasks — tasks created long ago with no activity. Check entry dates and annotations. Flag anything older than 30 days with no progress.
Urgency mismatches — tasks with high urgency scores but low priority, or vice versa. These might need priority adjustments.
Present findings — group issues by category. For each issue, show the task ID, description, and the specific problem.
Fix with permission — for each category, ask if the user wants to apply the suggested fixes. Use the UUIDs from the task_list response in step 1 for every task_modify / task_doc_write / task_annotate call — do not paraphrase or reuse UUIDs from earlier conversations. If you're unsure whether a UUID is still valid (e.g. after a long discussion), re-query with task_info before mutating.
