nexaedge/linear-spec-plugin
Spec-driven project execution pipeline backed by Linear. Same skills and agents as spec-plugin, but writes specs, stories and validation to Linear via GraphQL while keeping reasoning artifacts on disk.
Create the project-level implementation approach as a Linear Project Document. For code projects: technology stack, schemas, API contracts, system design. For non-code projects: delivery approach, document structure, resource plan. Adapts based on the project spec. Use after /ideate.
Deep-dive architecture for a single spec. Reads the Linear spec issue, the deliverable's Architecture document, and adjacent spec issues, then writes the spec body to the issue description and creates a Spec vX.Y — Architecture Project Document. Use before /build-stories.
Break down a single Linear spec issue into executable story sub-issues. Reads the spec body, the spec architecture document, and the deliverable architecture, then creates one ordered sub-issue per story under the spec issue. Adapts to project type. Use after /architect-version.
Execute a single story sub-issue end-to-end — either a new story or a fix from validation findings. Reads the sub-issue, parent spec, and architecture, then produces working output that meets all acceptance criteria. Code goes through worktrees; execution logs and state changes go to Linear.
Build a comprehensive project specification through conversational refinement. Adapts to any project type — code, business, research, consulting. Reads workspace context to understand where it is and what kind of project this is. Use at the very start of a new project or major initiative.
Execute a Linear spec end-to-end with a coordinated agent team. Cycles through architect-version → build-stories → execute-task → validate-execution until the spec ships. Accepts a Linear identifier or text to search. A spec is shipped when the human signs off.
Design an evolutionary delivery roadmap by creating a Linear initiative (where applicable), deliverable projects, and one issue per spec. Adapts to project type — code releases, consulting milestones, research phases. Use after /ideate and /architect.
Post-spec retrospective that captures lessons learned, fixes documentation drift, and proposes skill improvements. Reads the Linear spec, story sub-issues with comments, and the Validation Report. Writes retrospective to the knowledge base on disk and posts a back-link comment on the spec issue.
Validate a Linear spec's implementation against its Definition of Done. For code projects: runs automated tests against the live application. For non-code projects: reviews deliverables against acceptance criteria. Writes a Spec vX.Y — Validation Report Project Document and comments the link on the spec issue. Runs incrementally on re-runs.