OpenSpec Continue Change
SkillMediaUse this skill at Step 3 (after openspec-new-change) to expand proposal / design / specs into implementation-ready content. Iteratively fills out the technical approach, data model, contract specs, test strategy, and risk table. Stop when the change is "implementation-ready": every spec has acceptance criteria, design covers all PRD scope items, and the Compliance Design section is fully populated. Chinese trigger examples: "继续 OpenSpec", "OpenSpec 续写", "完善 design.md", "specs 填充". Do NOT use for task decomposition (next step), do NOT use to write code. Success = design.md covers 100% of in-scope PRD items, every spec has acceptance criteria, openspec validate passes.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the OpenSpec Continue Change skill
What this skill tells your AI
The instructions your AI receives, as published by charliehzm/medharness in .claude/skills/openspec-continue-change/SKILL.md and read by ahel’s review.
The "make it implementation-ready" expansion. After openspec-new-change scaffolds, this fills.
Quality bar — when to stop
The change is ready when every PRD in-scope item maps to ≥ 1 spec row, and every spec row has acceptance criteria.
Workflow
- PRD ↔ Spec mapping — list every in-scope item in PRD §3; ensure each has a spec id.
- Design body — technical approach for each spec, in design.md:
- Data model (tables / messages / contracts)
- API/IPC contracts
- Component interaction diagram (mermaid acceptable)
- Failure modes + recovery
- Performance budgets
- Compliance Design — refine the section seeded in
openspec-new-change:- Mark every L3/L4 field's flow path
- Specify desensitization points
- Specify audit log entries this change introduces
- Specs — for each spec row:
- one-line behavior description
- acceptance criteria (Given/When/Then or list)
- test hook (which test type, what data)
- Risks — top 3 risks + mitigation (in design.md)
- Validate — run
openspec validate(oropenspec-ff-changefor fast path) — must pass.
Common failure modes
- PRD item without spec — silent drop. Mitigation: explicit PRD↔Spec matrix at the top of design.md.
- Acceptance criteria as wishes — "the system should be fast". Mitigation: "P99 < 200ms on stage-mock data".
- Compliance afterthought — fill at the end. Mitigation: refine section every time you add a data-touching spec.
- Premature implementation — code samples in design.md > 30 lines. Mitigation: design says what, code says how (later).
Signals
- GitHub stars
- 86
- Forks
- 8
- Last commit
- Jun 2026
Advanced
- Catalog kind
- skill
- Gateway key
openspec-continue-change-charliehzm- Source
- github.com/charliehzm/medharness