Implement a selected task range

Execute the user's requested task-list boundary. sdd-manage coordinates authorization, prerequisites, and focused capabilities; an implementation request authorizes work within its established scope without repeated confirmation for routine steps. Use a current sdd-orient handoff at startup for repository instructions, Git and task state, dirty-path ownership, and environment. Read the relevant references:

For a selection-only request, use the range-selection reference and return the IDs, dependencies, and stopping point without mutations. For an implementation request, follow this protocol:

1. Push first. Using the established repository and branch, push all outstanding commits before task selection, tests, or edits, even when the worktree is clean. Confirm the remote contains the commits. Stop on an unresolved push blocker before beginning further implementation.
2. Resume before advancing. Use orientation's last task commit, owning checklist, pending changes, and existing evidence. Finish a completed task awaiting commit without repeating its implementation, or resume the identified incomplete task. Preserve valid work and resolve ambiguous ownership or task identity before the affected mutation.
3. Select the boundary. Resolve the requested TASKS or FEATURE-TASKS range, dependencies, and stopping point using the range-selection reference. Record selected task IDs and exit conditions. Establish or reuse the scoped working branch and target under sdd-manage's Branch management reference after startup pushing and before new task edits. Do not expand the range or invent requirements to bypass a blocker.
4. Check readiness and execute one task at a time. After push-first and before new task work/projection, apply sdd-manage's Document QC gates reference (skills/sdd-manage/references/document-qc-gates.md, bundled dependency) to the selected owning inputs; report missing/stale gates and coordinate focused review within scope rather than silently rewriting requirements. Selection-only remains read-only and can return candidate IDs with blocked execution eligibility. Coordinate sdd-tdd, apply production changes, maintain documentation through sdd-docs, and obtain acceptance evidence through sdd-verify. Repair failures within scope and repeat affected checks as needed.
5. Make each result durable. Mark the task complete only after its implementation, tests, documentation, and required verification are complete. Use sdd-report for its commit message, commit the result and status, and push before advancing. When hosted tracking is active, coordinate verified issue closure through sdd-forge.
6. Integrate and stop. Execute the selected explicit review/report tasks, verify milestone/phase exits, persist their reports and coordinate issue then milestone closures through sdd-forge when tracking is active. Update eligible parent checkboxes using the shared backend lifecycle. Coordinate selected feature-document incorporation when required, verify the completed boundary, then apply the workflow integration gate: main task work merges only a complete verified phase; an incomplete phase pushes and pauses. Other coherent authorized boundaries integrate explicitly under the Git protocol. Return an evidence-backed report. Stop at the requested boundary or an unresolved blocker; do not start steering or additional tasks automatically.

This skill owns executable range selection, task execution, repairs, completion updates, commits, pushes, and issue-closure coordination. sdd-tasks owns task-list creation and review; sdd-integrate-feature owns feature-delta reconciliation. Human-commanded checkpoint amendments to existing development documents and prior implementation belong to sdd-steer. Report governing-document changes needed outside the selected implementation scope to the user rather than silently rewriting the requirements.

Git commits and the owning checklist provide continuation state. No transaction journal, recovery state directory, or separate recovery skill is required. Return completed task IDs and implemented capabilities, verification evidence and gaps, commit and push results, hosted reconciliation, remaining work, and the stopping boundary through sdd-report.