/akka:specify

Creates a new feature specification from a natural-language description. The short description is converted to kebab case and used as both the spec directory name and git branch name (e.g., 001-core-users).

The prompt should define exclusively the what and why of the feature, excluding technical implementation details.

Feedback you give to /akka:specify is captured as an exit condition and an auditor that proves it, never left as prose. When you refine what the feature must do, the command records the requirement through the akka_ec_capture tool and binds a check to it. The check is one of the three auditor kinds: an introspective check that runs in the project’s own tree (a compiler, a test runner, a linter), a provisioned check against a generated harness asset, or a delegated check resolved by an attestation. Which kind fits follows from where the requirement can be proven — see Requirement analysis and Auditors.

A requirement that cannot be stated as a binary, falsifiable check is not turned into an invented check. Instead it routes to a clarifying question, and the condition stays open with reason needs-user-action until you supply an answer that can be checked.

Every new or changed check is run through an adversarial self-check — the command constructs an input where the check would pass while its invariant is false — and is then surfaced at the exit-condition level for your veto. You approve, adjust, or skip each check. A developer-authored introspective auditor does not execute until a first-run approval is recorded through the akka_ec_approve tool — the approval is the SHA-256 of the exact command the check runs, so an unreviewed command cannot run silently; corporate-authored auditors are trusted without this step. Approval is presented as "here are the checks and how I will verify each," which covers both the check’s design and the command it runs. The reviewed set is submitted through akka_ec_adequacy_submit so the adequacy review gate stays current. See The adequacy review and The coverage gate.

Capture-as-exit-conditions and the adversarial review run the same way in both conformance modes. Only the ship gate differs: enforced mode blocks ship while a gate is red; à la carte mode computes the gates as advisory and you drive the phases (see /akka:mode).

You reply to /akka:specify normally — no slash prefix is required on each turn. The gates are state-based: a reply that is not recorded as an exit condition or auditor stalls the relevant gate rather than letting it pass by default.