From dstoic
Revises OpenSpec change tasks when blocked or scope drifts >20%. Analyzes impact, proposes minimal revisions with blocker details, and applies after user approval.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dstoic:openspec-replansonnetThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Adaptive refinement skill for blocked or drifted changes. Proposes revised tasks or pivots.
Adaptive refinement skill for blocked or drifted changes. Proposes revised tasks or pivots.
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["Analyze blocker/drift"] --> B["Read context"]
B --> C["Propose revisions"]
C --> D{"User approval?"}
D -->|Yes| E["Apply changes"]
D -->|No| F["Discard"]
E --> G["Document blocker"]
classDef action fill:#C8E6C9,stroke:#388E3C,color:#000
classDef gate fill:#E1BEE7,stroke:#7B1FA2,color:#000
classDef discard fill:#FFCDD2,stroke:#D32F2F,color:#000
class A,B,C,E,G action
class D gate
class F discard
Critical: Always wait for user confirmation before applying changes (ask_first trust zone).
Trust Zone: ask_first (all changes require human approval)
Always ask before:
Scope deviation threshold: >20%
Minimal change preference:
Revise tasks when implementation is blocked.
Input: $ARGUMENTS = change-id [blocker-description]
Workflow:
openspec/changes/{change-id}/tasks.md, proposal.md, specsProposal format:
## Replan Proposal for {change-id}
### Blocker
{blocker description}
### Affected Tasks
- {task-number}: {original} -> {revised}
- {task-number}: REMOVED (blocked)
- NEW {task-number}: {new task}
### Impact
{n} tasks modified, {m} removed, {p} added
Approve these changes? [y/N]
After approval:
Replan applied for {change-id}
Modified: {n} tasks
Removed: {m} tasks
Added: {p} tasks
Blocker documented in tasks.md
Handle major scope shifts when direction changes.
Input: $ARGUMENTS = change-id [reason]
Workflow:
Proposal format:
## Pivot Proposal for {change-id}
### Current Direction
{summary of existing proposal}
### New Direction
{proposed new approach}
### Reason
{why pivot is needed}
### New Tasks
{numbered task list}
Approve this pivot? [y/N]
After approval:
Pivot applied for {change-id}
Old proposal archived: proposal.md.bak
New proposal: {brief summary}
New tasks: {count} items
Before proposing revisions, read openspec/project.md → Execution Philosophy → mode.
Apply mode principles to revised plan:
Philosophy check ({mode} mode):
- Principles: {list applicable}
- Trade-offs accepted: {from mode config}
- Anti-patterns avoided: {list}
Examples by mode:
garage: Accept minimal revisions, avoid over-planning, defer optimizationscale: Document decision rationale, ensure test coverage for new tasksmaintenance: Minimize blast radius, prefer conservative changesWhen replan completes, add comment to tasks.md:
<!-- REPLAN: {date}
Blocker: {description}
Resolution: {how revised tasks address it}
Tasks affected: {list}
-->
Insert after section header of first affected task.
Before replanning, consult openspec/project.md → Exploration Strategy section:
primary files (project.md, proposal.md, specs)Calculate deviation when triggered by reflect:
Deviation = (|planned - actual| / planned) * 100%
Where:
- planned = tasks in original tasks.md
- actual = completed + new tasks needed
Example:
- Original: 10 tasks
- Completed: 4 tasks
- New tasks needed: 5 tasks
- Deviation = (|10 - 9| / 10) * 100% = 10% (under threshold)
Trigger replan suggestion at >20% deviation.
npx claudepluginhub digital-stoic-org/agent-skills --plugin dstoicImplements tasks from an OpenSpec change, guiding you through selecting a change, reading context files, and marking tasks complete.
Creates OpenSpec change proposals by analyzing codebase for affected files, dependencies, and risks. Generates tasks and test strategies from proposals. Use for planning features in OpenSpec projects.
Handles mid-track requirement changes by analyzing impact on spec, plan, HLD, LLD, and code before proposing amendments. Useful when scope shifts during active development.