OpenSpec Linearized

Use this skill to run an OpenSpec change lifecycle while preserving a clear handoff boundary:

• Linear issue/card owns the business "what": business goal, use cases, personas/workflows, scope, acceptance criteria, and stakeholder-facing status. Keep its description synchronized from the business-facing content in proposal.md.
• The repo owns the technical "how": OpenSpec design decisions, tasks, implementation details, migrations, tests, and code.
• Canonical specs live under openspec/specs/. After archive succeeds, mirror those specs into Linear Project Documents for stakeholder visibility.

Linear updates are best effort once project setup exists.

Invocation Contract

• If the user asks to operate on an OpenSpec change, use this skill as the Linear lifecycle overlay.
• Also use the base OpenSpec skill that matches the request, such as openspec-propose, openspec-apply-change, openspec-archive-change, or openspec-sync-specs.
• If openspec/linear.yaml exists, run the relevant Linear hook for the current phase when possible.
• If openspec/linear.yaml is missing during proposal/setup, create it before issue hunting, story selection, or other Linear lifecycle work.
• If openspec/linear.yaml is missing outside proposal/setup, no-op the Linear hook and continue normal OpenSpec work.
• For status, validate, sync, continue, and artifact-editing work, preserve Linear binding awareness but do not move a Linear story to Done.