From scaffolding
Executes tasks from an OpenSpec tasks.md file during implementation. Reads task checkboxes, applies code changes, marks progress, runs validation, and handles blockers.
How this skill is triggered — by the user, by Claude, or both
Slash command
/scaffolding:spec-developThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Guide for implementing code changes driven by `tasks.md`.
Guide for implementing code changes driven by tasks.md.
| File | Purpose | Action |
|---|---|---|
{specs_path}/tasks.md | Implementation checklist | Read, execute, mark done |
{specs_path}/design.md | Architecture decisions | Reference during implementation |
{specs_path}/proposal.md | Context and motivation | Reference if unclear on intent |
Path Enforcement: The specs_path MUST be .scaffolding/conversations/{UUID}/specs/ where {UUID} is a valid UUID (format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). NEVER use descriptive folder names.
Parse all task groups and checkboxes. Identify dependency order.
For each task (- [ ] N.M description):
- [ ] to - [x]| Stack | Validation Command |
|---|---|
| Backend | pytest |
| Frontend | npm run validate |
| Both | Run both commands |
If a task cannot be completed:
- [ ] 2.3 Implement caching layer
> BLOCKED: Redis connection config not yet available. Depends on devops setup.
Continue with unblocked tasks. Do not stop the entire chain.
| Rule | Detail |
|---|---|
| Execute in order | Respect dependency sequence |
| Mark progress | - [ ] -> - [x] as you complete |
| Reference design | Check design.md before implementing |
| Never modify specs | Only modify tasks.md checkboxes, never change spec content |
| Validate per group | Run tests after each task group |
| Note blockers | Add > BLOCKED: note, skip and continue |
| Search before write | Check core/utils/, core/exceptions.py before creating helpers |
## 2. Core Implementation
- [x] 2.1 Implement service in `./backend/service.py`
- [x] 2.2 Add Pydantic schemas in `./backend/schemas.py`
- [ ] 2.3 Add router in `./backend/router.py`
> BLOCKED: Waiting for auth middleware decision
- [x] 2.4 Run validation: `pytest`
If tasks.md has some [x] items already:
- [ ]When design.md specifies a technical choice, follow it:
| Design says | You do |
|---|---|
| "Use Repository pattern" | Create repository class, not inline queries |
| "Use Pydantic v2 model_validator" | Use @model_validator, not @validator |
| "Max 500 lines per file" | Split if approaching limit |
| "Existing utility in core/utils" | Import it, do not recreate |
| Avoid | Instead |
|---|---|
| Skipping validation steps | Run tests after every group |
| Modifying design.md content | Only reviewer or planner changes specs |
| Implementing out of order | Follow dependency sequence |
| Ignoring blocked tasks silently | Add explicit > BLOCKED: note |
| Creating duplicate utilities | Search core/ first |
npx claudepluginhub komluk/scaffolding --plugin scaffoldingGuides implementation of specification tasks with checklists, step-by-step file edits, tests, acceptance criteria validation, and progress tracking. Phase 4 of Spec Kit workflow.
Implements OpenSpec change proposals by processing tasks.md: reads tasks, explores context, edits code, marks checkboxes, pauses at gates. Use for approved changes and task lists.
Writes OpenSpec design.md and tasks.md artifacts for spec-driven features. Useful when producing technical designs or task checklists from a proposal.