intent-driven-dev

How to set up and write acceptance tests for this project — specs are Markdown (spec.md) with fenced Gherkin, extracted to .feature files at test time; Cucumber runner configuration (extraction, effective-spec composition of source-of-truth and active delta specs, archive exclusion, HTML report); gherkin-lint over the extracted output; Page Object Model conventions for step definitions. Use when creating or modifying anything under acceptance-tests/, configuring the cucumber runner, writing or refactoring step definitions, linting specs, or implementing tasks from an OpenSpec change that involve acceptance tests.

Spec-first discipline and specs/code zone isolation — every code change must be driven by an active spec change, and a unit of work touches either openspec/ (specs) or code, never both (tasks.md exempt). Use when starting to implement any feature or fix, before writing or editing code, when acceptance tests fail, when code changes exist without a corresponding spec change, when the zone guard denies an edit, when planning a task that spans both specs and code, or when switching between spec work and code work.

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Archive multiple completed changes at once. Use when archiving several parallel changes.

Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.

Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.

Use when authoring or reviewing specs, requirements, design docs, ADRs, tasks, glossary entries, domain terms, technical terms, or wording consistency across artifacts

Use when rules or instructions mention "adversarial-authoring", "adversarial authoring", "must use adversarial-authoring skill", "model council", "cross-model review", or "mixture of models"; coordinates adversarial authoring and review subagents and records council notes.

Use when documenting, drafting, reviewing, or updating architectural decisions, ADRs, decision logs, tradeoffs, rationale, consequences, alternatives, or architecture decision history.

Use when explaining existing code architecture, visualizing a new system before detailed design, mapping software boundaries, or creating C4-style diagrams in ASCII or Mermaid.

Use when drafting, reviewing, or improving Gherkin, Cucumber scenarios, BDD acceptance criteria, feature examples, Scenario Outlines, Backgrounds, Rules, Doc Strings, Data Tables, tags, or Gherkin embedded in Markdown.

Use when running OpenSpec propose, continue, apply, verify, archive, or worktree workflows where proposal artifacts, branches, merges, or archive timing affect git history.

Use when multiple active OpenSpec changes should be applied concurrently in isolated worktrees with delegated verification and no merge.

Use whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update artifacts, validate/status checks, or work under openspec/changes/*. This is the Linear lifecycle overlay for OpenSpec work: bind Linear issues, maintain openspec/linear.yaml, update Linear issue business context/status, keep technical design/tasks in the repo, and mirror canonical specs into Linear Project Documents after archive.

Create or customize OpenSpec workflow schemas in this repository using `openspec schema init` and `openspec schema fork`. Use when the user wants to add, fork, or validate a schema under `openspec/schemas/`.

Use when multiple active OpenSpec changes should be applied concurrently in isolated worktrees with delegated verification and no merge.

Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.

Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.

Create or customize OpenSpec workflow schemas in this repository using `openspec schema init` and `openspec schema fork`.

Use to set up a prompt-operated TDD benchmark environment before evaluation. Trigger when the user wants to choose a stack, ensure test, branch coverage, line coverage, and mutation-testing tools are available, create the workspace conventions, or write the benchmark problem statement into a prompt file for later coder-agent evaluation.

Use inside the TDD skill evaluation harness to package coder-agent output into a uniform result bundle for evaluator scoring.

Use to orchestrate and evaluate a multi-agent TDD skill benchmark. Trigger when the user says start eval, wants junior/mid/senior coder agents on separate model tiers, parallel git worktrees, adversarial evaluation of result bundles, deterministic coverage/mutation scoring, or a consolidated parity report.

Use for language-agnostic coder-agent behavior under strict test-driven development. Trigger when implementing a task with test-first workflow, RED/GREEN/REFACTOR cycles, minimal production changes, and verifiable ordering evidence for later evaluation.