/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.

For agent features, use the description, existing requirements, policies, and configuration to define the following where they affect scope or acceptance:

Do not add controls or a governance workflow merely because a feature uses an agent.

For probabilistic behavior, use an agreed dataset, repeated trials, measurable error limits, and a defined aggregation rule.

Akka Specify reuses established requirements rather than guessing policy decisions such as thresholds, access permissions, retention periods, sensitive-data rules, or approval requirements. It records missing decisions as [NEEDS CLARIFICATION: specific question] markers in the specification. Policy markers do not count toward the limit of three routine clarification markers. Specify asks up to three questions and leaves remaining decisions for /akka:clarify. A specification with unresolved policy markers is not ready for planning.

Specify defines observable behavior; /akka:plan selects mechanisms for your installed Akka SDK version.

In the default À la carte mode, exit conditions remain dormant until requested. Specify still records requirements and clarification needs, but does not capture or review checks. See /akka:mode.

When the set is active, checkable feedback you give to /akka:specify is captured as an exit condition with an auditor that verifies it. 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.

Requirements without a binary, falsifiable check need clarification. A policy question does not itself create a machine-checked exit condition.

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.

With exit conditions active, both modes capture and review checks. Enforced mode blocks shipping on unmet gates; À la carte mode reports them as advisory.

You reply to /akka:specify normally, without a slash prefix on each turn. When the exit-condition set is active, its gates are state-based: missing required evidence leaves the relevant gate unmet rather than allowing it to pass by default.