behavior-driven-template

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.

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.