Execute a spec-driven feature's implementation phase while syncing taskmaster status after each task or batch, so the taskmaster tag mirrors real progress without driving execution order itself. Use when user says 'execute feature', 'run tasks for this feature tag', 'implement this taskmaster feature', or 'continue executing the spec and keep taskmaster in sync'.
Installs into .claude/skills of the current project.
Are you the author of Sd Execute?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/majiayu000-sd-execute)
---
name: sd-execute
description: "Execute a spec-driven feature's implementation phase while syncing taskmaster status after each task or batch, so the taskmaster tag mirrors real progress without driving execution order itself. Use when user says 'execute feature', 'run tasks for this feature tag', 'implement this taskmaster feature', or 'continue executing the spec and keep taskmaster in sync'."
model: claude-sonnet-5-5[1m]
metadata:
author: Ronnasayd Machado - github.com/Ronnasayd
version: "2.0.0"
---
# Execute Feature Tasks
Taskmaster is a mirror, not a driver. This skill does not reimplement execution -- it calls tlc-spec-driven's Execute phase exactly as documented in its own references/implement.md (auto-sized: inline for Small/Medium, sub-agent batching of ~7-8 tasks for Large/Complex, single always-on Verifier at the end), and layers one thing on top: syncing task status to taskmaster after each unit of work completes, so the taskmaster tag stays an accurate read-only log of what's done.
No wave-parallel dispatch, no worktree isolation, no adversarial per-task evaluator loop -- tlc-spec-driven's own batching and Verifier already cover reliability; duplicating that logic here only causes drift between the two.
## Steps
Add the following steps as tasks using the `TaskCreate`, `TaskUpdate`, `TaskGet`, and `TaskList` tools. Update the status as you progress through each step to keep the user informed.
| # | Step | Action | Output / Gate |
| --- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | Validate tag | Confirm `.specs/features/{TAG}/spec.md` exists (design.md/tasks.md optional per auto-sizing) and a matching tag exists in `.taskmaster/tasks/tasks.json` | Missing spec.md -> report, stop. Missing taskmaster tag -> tell user to run `sd-insert-taskmaster` first, or proceed without sync if they prefer |
| 2 | Read spec-driven skill | Read `skills/tlc-spec-driven/SKILL.md` and its `references/implement.md` once | Execution conventions loaded -- auto-sizing, batching threshold, Verifier contract |
| 3 | Run Execute phase | Invoke tlc-spec-driven's Execute exactly as documented -- no modification. Sub-agent batching offer, atomic commits, gate-before-done, Verifier at the end all apply unchanged | Feature implemented and verified per tlc-spec-driven's own contract |
| 4 | Sync taskmaster after each completed unit | As each task (inline mode) or batch (sub-agent mode) finishes and its commit lands, call `set_task_status` for the corresponding taskmaster id(s) -- `tag` is required, omitting it silently no-ops | Taskmaster tag reflects real progress incrementally, not batched at the very end |
| 5 | Sync on Verifier outcome | Verifier PASS -> tasks stay `done`. Verifier flags a gap that becomes a fix task -> sync that task back to `pending` (or `blocked` if user chooses not to fix now), then re-sync to `done` once the fix commit lands | Taskmaster reflects fix-loop iterations, not just the first pass |
| 6 | Sync docs | Invoke `generate-docs` skill in **update mode**, scoped to the diff/commits produced by this run, if the changes warrant a docs update | `docs/` reflects the implemented feature -- skip silently if `generate-docs` determines no doc-worthy changes occurred |
| 7 | UI test gate | If any task touched a UI component or screen, test it with Playwright MCP (or similar E2E tool) before marking done -- cover golden path and edge cases, watch for regressions in other features | UI change verified in a real browser -- skip silently for non-UI tasks |
| 8 | Summary | Report what tlc-spec-driven reported, plus taskmaster sync confirmation (ids updated) and docs sync outcome | User does the final commit/push -- tlc-spec-driven's own contract, unchanged here |
| 9 | Save permanent memory | At the end of the session, evaluate whether there is anything worth saving as permanent memory. Save only what the next session will need and cannot rediscover by reading the code, Git, or CLAUDE.md -- such as the _reason_ behind a decision, a non-obvious invariant, or a user preference; if it is already in the repo or only matters for this specific conversation, do not save it. Use the `ai-memory-durable-pages` skill to persist it. | Durable page written when warranted, or nothing when not |
## Status mapping
| Outcome | `set_task_status` value |
| ----------------------------------- | ------------------------------ |
| Task committed and gate passed | `done` |
| Verifier found a gap, fix pending | `pending` (revert from `done`) |
| User chose not to fix / deferred | `deferred` |
| Task skipped by user decision | `cancelled` |
| Task blocked on external dependency | `blocked` |
## Reference files
- [troubleshooting.md](./references/troubleshooting.md) -- common failure symptoms and fixes
- [diagram.md](./references/diagram.md) -- diagram of the flow.
