Menu
Use OpenSpec for formal spec-driven development. Use when a feature, refactor, or product change should be proposed, designed, task-planned, validated, synced, or archived through openspec/ artifacts before or during implementation.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | openspec-sdd |
| description | Use OpenSpec for formal spec-driven development. Use when a feature, refactor, or product change should be proposed, designed, task-planned, validated, synced, or archived through openspec/ artifacts before or during implementation. |
Run a formal OpenSpec workflow so feature work has proposal, requirements, design, tasks, validation, and archive history instead of living only in chat or ad hoc docs.
openspec/, existing specs, active changes, archived changes, and OpenSpec configopenspec is installedDetect OpenSpec state.
openspec/ is missing, recommend npm install -g @fission-ai/openspec@latest or project-native equivalent, then openspec init.OPENSPEC_TELEMETRY=0 when CI or privacy-sensitive automation needs telemetry disabled.Start or continue the change.
/opsx:propose "<idea>" for the default workflow./opsx:new, /opsx:continue, /opsx:ff, and /opsx:verify only when the repo has that profile enabled.proposal.md, design.md, tasks.md, and delta specs under openspec/changes/<change-name>/.Keep artifacts executable.
assets/templates/openspec-change-notes.md.tmpl for local notes when needed.$research-first-change when the change depends on current external APIs, framework behavior, security guidance, or dependency choices.Validate and sync.
scripts/check-openspec when OpenSpec is part of the workflow.scripts/check_openspec.py for lightweight local inventory, including active changes and per-change delta spec files.openspec validate <change-name> when the CLI is available./opsx:sync or /opsx:archive according to the active workflow.Route follow-on skills.
task-planning-and-pr-protocol for implementation planning.feature-state-machine to map OpenSpec tasks to feature IDs, WIP state, verification commands, and passing evidence.tdd-playwright-workflow for red-green-refactor tasks.agent-reviewer to confirm implementation matches OpenSpec tasks and requirements../scripts/check-openspec when present.openspec list, openspec show <change-name>, and openspec validate <change-name> when the CLI is available.Diagnose failed or unreliable agent workflows by classifying bad assumptions, missing observations, tool misuse, wrapper failures, hidden repair loops, incomplete validation, handoff gaps, and repeated failure patterns. Use after a failed harness run, flaky agent output, or confusing validation loop.
Review agent-generated changes against project rules. Use when asked for a review, before opening a PR, after large Codex edits, or when checking diffs for correctness, security, architecture, tests, docs drift, dependencies, migrations, and release risk.
Generate or maintain a minimal high-signal AGENTS.md for coding agents. Use whenever a repo needs agent instructions, an existing AGENTS.md is too long or vague, or project docs/scripts need a concise routing map for Codex.
Define and mechanically enforce architecture boundaries for a repo. Use when a project needs allowed dependency rules, forbidden imports, layer documentation, dependency maps, circular dependency checks, or protection against agent-created architectural drift.
Scaffold a new TypeScript web, mobile, API, or full-stack project with Better-T-Stack, then harden it with the Pax Fullstack Harness. Use whenever the user wants a new TypeScript app scaffold, mentions Better-T-Stack, asks for a modern type-safe stack, or wants Codex to start a repo that is agent-ready from day one.
Use guided Chrome DevTools MCP setup and workflows for browser runtime debugging. Use when a web app needs console, network, DOM, accessibility, Lighthouse, performance, responsive, or live-browser investigation beyond normal tests.