Skip to main content

apply

Implement a change's tasks.md against real code, checking off tasks as they complete. Use once a change has been proposed. Optionally takes a change name as an argument, e.g. "/sdd:apply add-dark-mode".

Source facts

Repository
rohaquinlop/pi-sdd
Last source activity
September 6, 2026 at 19:52
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
apply
description
Implement a change's tasks.md against real code, checking off tasks as they complete. Use once a change has been proposed. Optionally takes a change name as an argument, e.g. "/sdd:apply add-dark-mode".
# Apply Implement the tasks for an existing change. 1. Determine the target change: - If the user's request names a change, use `.sdd/changes/<name>/`. - Otherwise, infer it from conversation context or the most recently modified directory under `.sdd/changes/`. - If ambiguous, list the available `.sdd/changes/*/` directories and ask the user to pick one. 2. If `.sdd/changes/<name>/tasks.md` doesn't exist, stop and tell the user to run `/sdd:propose` first — this command never creates missing artifacts. 3. Read `proposal.md`, `design.md`, `tasks.md`, and `specs/*.md` in the change directory to load full context before writing code. 4. Work through the unchecked tasks in `tasks.md` in order: - Implement each task in the real codebase, following existing project conventions. - Check off the task (`- [x]`) in `tasks.md` immediately once it's done and verified (run tests/build where applicable). - If implementation reveals a fork the plan didn't anticipate — a genuinely ambiguous choice with real alternatives, not a trivial detail — ask the user with the clarification UI (the `clarification_ui` tool) before proceeding. List the recommended option first, marked "(Recommended)", plus up to three genuine alternatives; the UI's free-text option covers anything else. - If implementation reveals that `design.md` or `proposal.md` needs to change (a flawed assumption, a missed edge case, or the resolution of a fork above), edit that artifact directly and keep going — don't restart or ask permission for small course corrections, but do flag any change that alters the original scope. 5. Only edit files that are either planning artifacts under `.sdd/changes/<name>/` or code required by a task — don't scope-creep into unrelated files. 6. Once all tasks are checked off, before declaring the change ready, self-review: - Review the full diff against `design.md`, `proposal.md`, and existing project conventions. - Report the findings (bugs, convention drift, leftover comments, duplicated helpers, unused code) — even if the list is empty, say so. - Fix/address each finding in the same pass. Don't wait for the user to ask for a review — this step runs by default. 7. Tell the user the change is ready for `/sdd:archive`.
View on GitHub