From dstoic
Implement OpenSpec change proposals. Use when: implementing approved changes, working through task lists, or checking implementation progress.
npx claudepluginhub digital-stoic-org/agent-skills --plugin dstoicThis skill is limited to using the following tools:
Implementation engine for approved OpenSpec proposals. Turns tasks.md checkboxes into working code.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Implementation engine for approved OpenSpec proposals. Turns tasks.md checkboxes into working code.
CRITICAL: After EVERY AskUserQuestion call, check if answers are empty/blank. Known Claude Code bug: outside Plan Mode, AskUserQuestion silently returns empty answers without showing UI.
If answers are empty: DO NOT proceed with assumptions. Instead:
flowchart LR
A["Read task"] --> B["Explore context"]
B --> C["Implement"]
C --> D["Mark ✅ in tasks.md"]
D --> E{"More tasks\nin section?"}
E -->|Yes| A
E -->|No| G{"Gate exists?"}
G -->|No| H{"More sections?"}
G -->|Yes| I["🚧 Checkpoint prompt"]
I --> J["STOP"]
H -->|Yes| A
H -->|No| F["Report complete"]
classDef action fill:#C8E6C9,stroke:#388E3C,color:#000
classDef decision fill:#FFF9C4,stroke:#FBC02D,color:#000
classDef gate fill:#FFE0B2,stroke:#F57C00,color:#000
class A,B,C,D,F action
class E,G,H decision
class I,J gate
Critical: Mark checkbox immediately after each task. Enables crash recovery.
Autonomous (no confirmation needed):
Ask-first (pause and confirm):
Scope check: Before creating files not mentioned in proposal.md, count affected files. If >20% more than proposal's "Affected files", ask:
⚠️ Scope expansion detected
Proposal mentions: {n} files
Implementation needs: {m} files ({percent}% more)
Proceed with expanded scope? [y/N]
Implement all pending tasks from tasks.md, pausing at gates.
Input: $ARGUMENTS = change-id
Workflow:
openspec/changes/{change-id}/tasks.md**Design**: header → read openspec/changes/{change-id}/design.md for BC scope, invariants, ubiquitous language, and ADRs## N. Section Name)- [ ] → - [x]
b. After all section tasks complete, check for ### GATE N: line
c. If gate exists and not [PASS]: output checkpoint prompt, stop processing
d. If no gate or already [PASS]: continue to next sectionGate checkpoint (stops processing):
🚧 GATE {n}: {description}
Section {n} tasks: {done}/{total} complete
→ Run checkpoint: /openspec-test checkpoint {change-id} {n}
→ Skip gate: /openspec-develop section {change-id} {n+1}
All complete:
✅ All tasks complete for {change-id}
Progress: {done}/{total} tasks
Ready for: /openspec-test {change-id}
Implement a specific task by number.
Input: $ARGUMENTS = change-id task-number (e.g., add-feature 1.3)
Workflow:
1.3)implementAlready complete:
⏭️ Task {number} already complete
Description: {task description}
Implement all tasks in one section only.
Input: $ARGUMENTS = change-id section-number (e.g., add-feature 3)
Workflow:
## {section-number}. ...Section complete (with gate):
🚧 GATE {n}: {description}
Section {n} tasks: {done}/{total} complete
→ Run checkpoint: /openspec-test checkpoint {change-id} {n}
→ Skip gate: /openspec-develop section {change-id} {n+1}
Section complete (no gate):
✅ Section {n} complete: {section-name}
Progress: {done}/{total} tasks in section
→ Next: /openspec-develop section {change-id} {n+1}
Show implementation progress.
Input: $ARGUMENTS = change-id
Run:
openspec show {change-id}
Display task completion progress from CLI output.
Before implementing, read openspec/project.md → Execution Philosophy → mode.
During implementation, flag anti-patterns for current mode:
⚠️ Philosophy check ({mode} mode):
- Anti-pattern detected: {anti-pattern}
- Current action: {what you're about to do}
- Question: {is this necessary or gold-plating?}
Proceed anyway? [y/N]
Examples by mode:
garage: Flag premature abstractions, over-engineering, excessive documentationscale: Flag missing tests, undocumented decisions, cowboy changesmaintenance: Flag unnecessary refactors, feature creep, risky upgradesParse tasks.md format:
## 1. Section Name
- [ ] 1.1 Task description here
- [x] 1.2 Already complete task
- [ ] 1.3 Another pending task
Match pattern: - \[([ x])\] (\d+\.\d+) (.+)$
Parse section headers and gate markers in tasks.md:
Section header: ## (\d+)\. (.+)$
Gate line: ### GATE (\d+): (.+?)(?:\s+\[(PASS|PARTIAL|BLOCKED)\])?$
Group tasks by their parent section header. Gates are optional markers between sections.
Gate states:
[PASS] = checkpoint verified[PARTIAL] = some failures, needs attention[BLOCKED] = cannot proceed without resolutionAfter completing task, edit tasks.md:
- [ ] {task-number} {description}- [x] {task-number} {description}Use Edit tool for surgical update. Never rewrite entire file.
After checkpoint passes, mark gate in tasks.md:
### GATE {n}: {description}### GATE {n}: {description} [PASS]Use Edit tool. Gate state drives crash recovery — on resume, develop skips [PASS] gates and re-prompts unmarked gates after completed sections.
Before implementation, consult openspec/project.md → Exploration Strategy section:
primary files (project.md, proposal.md, specs)