task-execution-simple
GitHub用于在任务准备完成后，通过独立分支路径执行具体代码实现。负责分支隔离、代码修改、测试验证及文档更新，确保在审查后安全关闭分支，严格遵循现有规范与测试要求。
Trigger Scenarios
Install
npx skills add NeverSight/learn-skills.dev --skill task-execution-simple -g -y
SKILL.md
Frontmatter
{
"name": "task-execution-simple",
"description": "Use when task-local spec or plan work is complete and a concrete docs\/tasks task should be implemented through the repository's simple direct execution path."
}
Task Execution Simple
Use after task-preparation has finished task-local docs and routine follow-up, and the task is ready for straightforward direct execution.
Owns branch/worktree isolation, readiness, implementation edits, verification, docs/status updates caused by implementation, implementation review, and branch closing. Does not own roadmap decomposition or task-local spec.md and plan.md authoring.
Required Gates
| Gate | Required behavior |
|---|---|
| Branch | Default never implement on the current branch; create a dedicated task branch by default unless the user explicitly chooses otherwise or a worktree workflow is specifically needed. |
| Readiness | Handle branch/worktree isolation and any other pre-code readiness work before implementation edits. |
| Verification | Verify implementation and update docs/status in the same round when behavior, API shape, or task state changed. |
| Review | Stop for implementation review before destructive cleanup or branch deletion. |
| Closing | Resolve only any remaining hard gate such as branch deletion or destructive cleanup after implementation review. |
After an implementation review pause, treat any clear forward-motion message as approval to follow the recommended non-destructive next step. Ask a separate approval question only for hard gates.
Branch Isolation
- Default to creating a dedicated task branch in the current workspace.
- Use a worktree workflow only when the user explicitly wants one or when parallel or high-conflict execution makes a separate workspace specifically valuable.
- User explicitly asks to stay on current branch: proceed only with explicit user choice.
Branch Closing
- Use
superpowers:finishing-a-development-branchfor merge/PR/keep/discard options. - Use
superpowers:using-git-worktreescleanup rules; removing a worktree does not remove its task branch. - Confirm before deleting any branch or worktree. If merge plus cleanup is chosen, confirm whether cleanup includes deleting the fully merged task branch.
- If the user asks to move forward, keep moving through non-destructive wrap-up steps, but stop before deleting a branch or worktree.
Testing and Verification
- Follow the task-local
spec.mdand optionalplan.mdfor testing and verification expectations. - If relevant existing automated tests fail during the task, do not ignore them just because the task did not require adding new unit tests.
- Prefer fixing production code so existing tests keep expressing the same behavior.
- If existing tests need semantic changes because the task intentionally changes behavior, explain the reason and get user confirmation before changing what those tests assert.
- Small test-file repairs that preserve the original assertion intent do not need separate confirmation.
Docs Boundaries
Code is source of truth when code and docs diverge. If implementation changes behavior, API shape, task status, architecture assumptions, or stable constraints, update the relevant docs in the same round. Move stable rules out of docs/context/.
Detailed Rules and References
Use the existing execution references when needed:
references/task-execution-detailed-rules.md
Workflow
- Receive handoff context from
task-preparation. - Create branch/worktree isolation and complete readiness work before code edits.
- Implement one concrete task.
- Verify behavior and update docs/status affected by implementation.
- Stop for implementation review.
- Resolve branch closing and cleanup hard gates only when explicitly confirmed.
When To Use
Use when a concrete task already has its task-local spec.md and optional plan.md, and the next work is direct implementation through the repository's simple execution path rather than delegated or specialized execution. Do not use before task-local docs are ready.
Do not use when:
- milestone/module/task structure is still being decided; use
milestone-planning - task-local
spec.mdorplan.mdwork still needs to be written or reviewed; usetask-preparation - the repository needs a delegated or specialized execution path instead of the simple direct path
Common Mistakes
- Starting implementation before branch/worktree isolation is complete
- Treating a normal forward-motion message as approval for destructive cleanup
- Rewriting roadmap or task structure here instead of routing back to
milestone-planning
Version History
- e0220ca Current 2026-07-05 23:26
