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".

Jump to install

Repository: rohaquinlop/pi-sdd
Last source activity: August 8, 2026 at 04:09
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.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/rohaquinlop/pi-sdd --skill apply

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

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

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

archive

Archive a completed change once all its tasks are done, folding its spec deltas into the project's main specs/. Optionally takes a change name as an argument, e.g. "/sdd:archive add-dark-mode".

2026-08-08

explore

Thinking partner for investigating an idea or problem before committing to structured spec work. Use before /sdd:propose when the user wants to discuss options, not yet produce artifacts.

2026-08-08

propose

Create a new spec-driven change with proposal, design, tasks, and spec artifacts. Use when the user is ready to commit to a direction for a feature or fix. Takes the change name/idea as an argument, e.g. "/sdd:propose add-dark-mode".

2026-08-08

View all from this repository

Apply

Implement the tasks for an existing change.

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.

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.

Read proposal.md, design.md, tasks.md, and specs/*.md in the change directory to load full context before writing code.

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.

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.

When all tasks are checked off, tell the user the change is ready for /sdd:archive.

Apply

Implement the tasks for an existing change.

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.

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.

Read proposal.md, design.md, tasks.md, and specs/*.md in the change directory to load full context before writing code.

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.

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.

When all tasks are checked off, tell the user the change is ready for /sdd:archive.

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

Source facts

Install options

Review the source files

More from this repository

Apply

Apply

More from this repository