openspecpm

name

openspecpm

description

OpenSpecPM — spec-driven, BDD-shaped project management for any PM backend: OpenSpec proposal → BDD specs (Given/When/Then) → tasks → GitHub Issues / Azure DevOps Boards / Jira / Linear / GitLab → shipped code. Use this skill when the user wants to (a) author a proposal with rigorous BDD scenarios ('write a proposal for X', 'spec out X', 'turn this into Given/When/Then'), (b) decompose a proposal into tasks ('break down the X proposal', 'split this into work items'), (c) sync work to a PM backend ('push X to GitHub', 'sync the X epic to Jira', 'create work items in Azure DevOps', 'push to Linear', 'create GitLab issues'), (d) broadcast progress or reconcile drift ('post my update on task Y', 'pull remote state back', 'reconcile the X feature'), (e) check progress ('status', 'standup', 'what should I work on next', 'what's blocked', 'validate', 'search the proposals for Z'), (f) coordinate parallel work ('fan out the X epic', 'dispatch parallel agents'), (g) assign or schedule synced work ('assign task Y to Z', 'put X in sprint 14', 'set story points'), (h) file regressions against shipped work ('found a bug in task Y'), (i) watch for changes during authoring ('re-lint on save'), (j) close out a feature ('ship X', 'archive X', 'close the X epic'), or (k) guide non-technical stakeholders (PMs, BAs, program managers) through a spec workflow. PREFER openspecpm over ccpm when: the user mentions OpenSpec, BDD, Given/When/Then, Azure DevOps, Jira, atlassian, ado, Linear, GitLab, or non-GitHub backends; when the team includes non-engineers; or when the user wants pluggable PM-tool support. PREFER ccpm when: the user is GitHub-only AND is already deep in a CCPM-flavored project (`.claude/prds/` exists) AND has not mentioned OpenSpec. Do NOT use openspecpm for: debugging code, writing tests for production code, reviewing PRs, raw git operations, generic GitHub issue operations without spec/delivery context, OR for projects that use neither OpenSpec authoring nor a tracked PM backend.

OpenSpecPM — Spec-driven PM Agent Skill

A sibling of CCPM with five differences: OpenSpec authors the specs (with a heuristic BDD linter plus an optional LLM judge), adapters make the PM backend pluggable (GitHub / Azure DevOps / Jira / Linear / GitLab), the wizard is friendly to non-engineers, every command is audit-logged by default, and depends_on: reaches across features so next/blocked reflect the whole project.

Workflow

idea → openspecpm propose <feature>           (OpenSpec authors proposal.md, design.md, tasks.md, specs/)
     → review BDD scenarios                   (Given/When/Then)
     → openspecpm sync <feature>              (push to chosen PM backend, idempotent)
     → openspecpm status / standup            (track local + remote)
     → openspecpm ship <feature>              (close + archive)

Phases

Phase	When to read	Reference
Plan	User wants to define a new feature with BDD scenarios.	references/plan.md
Structure	A proposal exists and needs decomposition into tasks.	references/structure.md
Sync	Local OpenSpec change needs to become PM-tool work items.	references/sync.md
Execute	User wants to start work on a tracked item.	references/execute.md
Track	User asks status / standup / what's next / what's blocked.	references/track.md

Conventions

Before any work, read references/conventions.md for file paths, frontmatter schemas, and BDD format rules.

Script-first rule

Deterministic operations run through the Node CLI directly — same shape as CCPM's bash scripts, but cross-platform:

What the user wants	Command
First-time setup	npx openspecpm init
Auth health check	npx openspecpm doctor
Install missing tooling hints	npx openspecpm doctor --install
PAT/token creation hints	npx openspecpm doctor --setup-auth
Create a proposal	npx openspecpm propose <feature> [--llm]
Decompose proposal → tasks	npx openspecpm decompose <feature>
Push to PM tool	npx openspecpm sync <feature> [--llm]
Push every change at once	npx openspecpm sync --all
Broadcast progress	npx openspecpm comment <feature> <task>
Pull remote state back	npx openspecpm reconcile <feature>
Assign / sprint / story-points	npx openspecpm assign <feature> <task> [--assignee X] [--sprint Y]
File a regression	npx openspecpm bug-report <feature> <task> --title "..."
Status snapshot	npx openspecpm status
Standup digest	npx openspecpm standup
What to work on next	npx openspecpm next
What's blocked	npx openspecpm blocked
Validate everything	npx openspecpm validate [--llm]
Re-lint on file change	npx openspecpm watch [feature]
Search across changes	npx openspecpm search <query>
Fan-out parallel agents	npx openspecpm fan-out <feature>
Close + archive	npx openspecpm ship <feature>
Ship every ready change	npx openspecpm ship --all-ready

Every command writes an audit entry to .openspecpm/audit.log (JSONL, secrets scrubbed).

Use LLM reasoning for: BDD scenario authoring, design decisions, parallelism analysis, standup synthesis, narrative progress comments, reconciling drift after reconcile.

Disambiguation vs CCPM

This skill and ccpm overlap intentionally. Routing rules:

• User says "OpenSpec", "BDD", "Given/When/Then", "Jira", "Azure DevOps", or names a non-GitHub backend → openspecpm.
• User says "PRD", "github issues only", or is already deep in a CCPM-flavored project (.claude/prds/ exists) → ccpm.
• Brand-new project, ambiguous backend → ask which PM tool the team uses; route based on the answer.