DayZ Feature Spec

The DayZ-adapted spine of spec-driven development: define what done means and how it will be verified before touching code, then gate the artifacts for consistency before spending an in-game test cycle.

This is the local adaptation of GitHub's spec-kit specify → clarify → analyze → implement flow. The generic app scaffolding (TDD red-green, contract tests, user-story-as-independent-MVP slicing, the specify CLI, GitHub-issue export, extension marketplace) is intentionally dropped — see "What this drops" below. What is kept is the discipline that already maps to R7/R8/R8-extended and G1–G3, plus one thing they lack: an explicit artifact-level consistency gate.

When to use / when to skip

Use before implementing:

• a new mod feature, or any change touching >1 file (aligns with R3),
• anything data-critical (persistence, progression) — then also invoke rigorous-data-audit,
• anything where "done" is not self-evident, or where a later phase/consumer reads this phase's output (R8-extended forward contract).

Skip for: 1-line typos, trivial reversible tweaks (default keybind, stringtable key, path slash). R3's small-reversible-changes-go-direct rule wins — a spec here would be ceremony.

The flow