publish-linear
Sync local pipeline state to Linear. Reads standalone docs + issue files from feature folder, creates or updates Linear project, documents, and issues. Safe to run multiple times — idempotent.
Starting
Determine feature to publish:
- If arg given: read
./plans/<arg>/feature folder - Else: list
./plans/*/, ask viaAskUserQuestion(header: "Feature", options: each folder name, mark most recently modified "(Recommended)")
If feature folder not found: stop with error.
Read .pipeline.md from project root for linear-team value. If missing, ask via AskUserQuestion (header: "Team", options: team names from list_teams). Save choice to .pipeline.md.
Sync
Use mapping tables in assets/linear-mapping.md for all field mappings.
1. Project
Extract feature name from # Scope: <name> heading in scope.md, or from the folder name if no scope brief exists.
Check for <!-- linear-project: <id> --> in pipeline.md:
- Has ID:
list_projects, verify project exists by ID. If gone, treat as new. - No ID:
list_projectswithquery=<feature name>andteam=<linear-team>. Match by exact name.
If project exists: note its ID.
If not: save_project with name=<feature name>, addTeams=[<linear-team>]. Write <!-- linear-project: <id> --> into pipeline.md.
2. Documents
Read the feature folder. For each standalone doc that exists, sync as a Linear document:
| File | Linear document title |
|---|---|
scope.md |
Scope Brief |
prd.md |
Product Requirements |
spec.md |
Design Specification |
tdd.md |
Technical Design |
plan.md |
Implementation Plan |
For pipeline.md, extract sections and sync separately:
## Decisions Logcontent → document titled "Decisions"## Statuscontent → document titled "Pipeline Status"
For each document:
- Read file/section content
list_documentswithprojectId=<project-id>, find by matching title- Exists:
update_documentwithid=<doc-id>,content=<content> - Missing:
create_documentwithtitle=<title>,project=<project-id>,content=<content>
3. Project status
Read ## Status table in pipeline.md. Find last row with a verdict. Map stage to Linear project state per assets/linear-mapping.md.
save_project with id=<project-id>, state=<mapped state>.
4. Issues
Check if ./issues/<feature-name>/ exists (kebab-case matching feature folder name). If not, skip.
Ensure labels exist: list_issue_labels with team=<linear-team>. If Auto or HITL missing, create_issue_label for each.
Read each NN-slug.md file in order. For each:
- Parse title from
# <Title>heading - Parse
Type: AutoorType: HITLfrom header - Parse
## Blocked byreferences (extract filenames like01-slug.md) list_issueswithproject=<project-id>,query=<title>. Match by exact title.- Exists:
save_issuewithid=<issue-id>,description=<full file content>(only if changed) - Missing:
save_issuewithtitle,team=<linear-team>,project=<project-id>,description=<full file content>,labels=[<type>]
Store mapping of NN-slug.md → Linear issue identifier as you go.
Wire blockedBy (second pass): For each issue that has ## Blocked by references, save_issue with id=<issue-id>, blockedBy=[<resolved issue identifiers>].
5. Project update
Build summary: "Published after / — , status: , issues: ."
save_project with id=<project-id>, summary=<summary text>.
Finish
Print confirmation: "Published to Linear. Project: , status: , documents: , issues: ."
More from michaelmerrill/skills
design
Design specification interview → standalone spec.md (flows, screens, states, components, responsive, a11y). Triggers: 'design this,' 'what screens,' 'how should users interact,' post-product. Not for: technical design (engineering), requirements (product). Skip for API-only, CLI, backend, or infra features.
8plan
Decompose technical design into agent-sized implementation issues → numbered markdown files + standalone plan.md. Triggers: 'plan this,' 'break into issues,' 'create tasks,' 'ready to implement,' post-engineering. Not for: designs without file paths/phases (run engineering first).
7design-ux
MUST USE when a user wants to design user flows, interaction patterns, or screen-level UX for a feature that has defined requirements. This is the UX design step in the planning pipeline (write-a-prd → review-prd → glossary → design-ux → design-feature → review-plan). Typical signals — "design the UX," "how should users interact with this," "what should the UI look like," "design the flows," "design-ux," "what screens do we need," or following up after a review-prd or glossary session. Also applies when the user has a PRD and wants to figure out the user experience before technical design. Conducts a structured interview to produce a UX specification — user flows, screen inventory, component mapping, interaction specs, and accessibility requirements. Do NOT use for technical design (use design-feature), writing requirements (use write-a-prd), reviewing plans (use review-plan), scoping/feasibility (use plan-feature), or when the feature has no user-facing UI (API-only, backend, CLI tools).
6plan-feature
Scoping interview for new features -> scope doc with go/no-go. Triggers: user wants to add/build/implement any new capability. First pipeline step. Not for: bugs, PRDs (write-a-prd), design (design-feature), executing existing specs.
6define
Product requirements → living doc Requirements section + quality gate + domain glossary. Stateful: detects existing sections and resumes where needed. Triggers: 'define this,' 'write a PRD,' 'define requirements,' 'spec this out,' post-explore. Not for: scoping (explore), UX (design), technical design (architect).
5explore
Scope and assess new feature ideas → living doc with go/no-go. Elaborates vague ideas into clear concepts. First pipeline step. Triggers: user wants to add/build/implement any new capability. Not for: bugs (triage-issue), requirements (define), design (design/architect).
5