spec:do-next
9
总安装量
7
周安装量
#32617
全站排名
安装命令
npx skills add https://github.com/ikatsuba/skills --skill spec:do-next
Agent 安装分布
claude-code
6
codex
5
opencode
4
cursor
4
kiro-cli
3
Skill 文档
Execute Next Task
Executes the next pending task from a specification’s tasks document. This skill finds the first incomplete task and implements it.
When to use
Use this skill when the user needs to:
- Implement one task at a time with review between tasks
- Continue work on a partially completed specification
- Execute tasks incrementally with manual control
Specification Files Structure
All specification documents are located in .specs/<spec-name>/ directory:
| File | Description |
|---|---|
.specs/<spec-name>/requirements.md |
Requirements and acceptance criteria |
.specs/<spec-name>/design.md |
Technical design and architecture |
.specs/<spec-name>/tasks.md |
Implementation tasks with checkboxes |
Always read all three files to understand the full context before executing tasks.
Instructions
Step 1: Locate and Read Specification Documents
- If
<args>contains a spec name, look in.specs/<spec-name>/ - If no spec name provided, list available specs in
.specs/and ask user to choose - Read and parse all specification documents:
requirements.md– understand what needs to be builtdesign.md– understand how it should be builttasks.md– get the list of tasks to execute
Step 2: Find the Next Task
- Scan the document for checkbox markers
- Find the first task that is:
- Marked as
[-](in progress) – resume this task first - Or marked as
[ ](pending) – start this task
- Marked as
- Skip tasks marked as
[x](completed) - If all tasks are complete, inform the user
Step 3: Execute the Task
- Mark as in-progress – Update the checkbox to
[-]in tasks.md - Show task info – Display to the user:
- Task number and description
- Files to create/modify
- Requirements being addressed
- Read context – Load relevant files mentioned in the task
- Implement the task – Follow the task description:
- Create new files as specified
- Modify existing files as described
- Follow project patterns and conventions
- Verify implementation – Ensure the change is correct
- Mark as complete – Update the checkbox to
[x]in tasks.md - Commit the changes – Create a git commit for the completed task (see Committing Changes section)
Step 4: Handle Checkpoint Tasks
If the next task is a checkpoint:
- Run any verification commands specified
- Report the verification results
- Mark as complete if all checks pass
- Report issues if any checks fail
Step 5: Report Completion
After completing the task:
- Summarize what was implemented
- Show the next pending task (if any)
- Ask if the user wants to continue with the next task
Committing Changes
After completing the task, create a git commit unless the user has specified otherwise:
- Stage the changed files related to the task
- Create a commit with a descriptive message referencing the task number
- Do NOT include Co-Authored-By in commit messages
Commit message format (Conventional Commits):
<type>(<spec-name>): <description>
Types: feat, fix, refactor, test, docs, chore, etc.
Examples:
feat(user-auth): add login form component
fix(payment): resolve checkout validation error
refactor(api): simplify request handling
test(user-auth): add unit tests for login service
Skip committing if:
- The user explicitly asked not to commit
- The task only modified the tasks.md file (checkpoint tasks)
Error Handling
- If the task fails, keep it marked as
[-] - Report the issue to the user
- Suggest fixes or ask for guidance
Arguments
<args>– The spec name (e.g., “user-auth”, “payment-flow”)
If not provided, list available specs and ask the user to choose.