git:20261024.215cdfd to git:20261029.3c6f053

---

name: specify

description: Specify one bounded feature, bug fix, refactor, or other change with intended behavior, scope, acceptance criteria, and explicit TDD policy. Use whenever intended behavior, scope, or acceptance needs clarification or revision; use investigate to establish an unknown cause.

---

# Specify

Apply [core loading rules](../../README.md#loading-rules) for your role, including all

required shared sections unless their current text is already supplied or loaded.

Read linked procedures only when their operation applies. Read the relevant

product context if available and any existing spec, issue, or ticket for this change.

Persona: change analyst, focused on one verifiable outcome. Use the capability map for mapped

capabilities; a bug fix or direct bounded request does not require product definition first.

- Establish the user, problem, scope boundaries, constraints, and observable acceptance

criteria. Include relevant failure or boundary behavior without enumerating speculative cases.

Give saved criteria stable IDs such as AC1 and AC2; preserve existing IDs when reordering

or refining them. Existing criteria without IDs can be referenced exactly without a rewrite.

- For a bug fix, distinguish expected behavior from observed behavior. Record reproduction

steps and environment when known, impact, and evidence; label reported behavior separately

from a reproduced failure. Keep suspected causes as hypotheses. If an unknown cause or

reproduction gap blocks a useful plan, route that question to [investigate](../investigate/SKILL.md)

without making diagnosis a prerequisite for recording the bug. A confirmed cause needs no

repeated investigation. Acceptance criteria describe corrected behavior and relevant regressions.

- For a refactor, specify the structural outcome and observable behavior to preserve; do not

invent a behavior change to fit the template.

- Recommend the smallest useful scope. Ask about consequential ambiguity; resolve routine

details from the request and existing constraints, labeling assumptions that matter.

- For visual work, capture supplied references and concrete required or excluded visual patterns

in the agreement. Clarify missing preferences only when they materially affect the outcome;

a clear visual request does not require a design interview.

- Create or update `docs/lusona/specs/<change-id>.md` from

[the spec template](../../templates/spec.md) when saved definition is needed and authorized,

under the [naming rules](../../references/naming.md). Reuse existing specs or legacy feature

documents. A small change can stay in the conversation; an already clear request can proceed

directly to authorized implementation. Link an external issue or ticket when provided; do not

create one or copy a full ticket into a second maintained specification by default.

- Propose `none`, `targeted`, or `strict` under the [TDD rules](../../references/tdd.md).

Record the user's choice or standing preference if supplied; otherwise leave it unset and ask

through the permitted native question tool.

- Define observable outcomes, not a proposed implementation. Preserve user-required or established

technical constraints with their source; do not turn a design proposal into an acceptance

criterion. Include technical detail only when it clarifies scope or resolves uncertainty.

Continue into architecture or planning when useful and authorized.

- Keep the spec concise: link existing product context, constraints, architecture, and legacy

execution records instead of repeating them. Keep agreement, optional execution, evidence, and

current handoff in one change record; preserve existing execution details and separate plans.

- Before handing off the definition, make one inline check for contradictions, ambiguous

requirements, and unresolved decisions that block the selected work. Fix routine omissions

from known evidence; preserve unknowns as explicit questions rather than inventing answers.

This check does not add a review cycle or another approval gate.

- For work needing workflow tracking, the coordinator adds or updates the selected item under

the [queue rules](../../references/queue.md) and agrees what completion means, including whether

human acceptance or delivery is required. Recovery recording alone does not require tracking.

Keep workflow state in the queue.

- The coordinator moves an existing queue item to Ready only when the user has accepted its

scope and criteria and selected its TDD policy, with no blocking definition questions. Existing explicit authorization counts,

including delegated routine decisions within batch authority after required reconciliation;

it does not supply a missing TDD choice or authorize consequential scope changes.

Report remaining decisions together; do not force a separate approval round for each field.

Apply [Context budget](../../README.md#context-budget) at the definition handoff.

## Next action

Return the spec path or concise agreement and any unresolved decisions together. Ask a blocking

behavior, scope, or TDD question; otherwise name the next action from unmet criteria or

uncertainty: an experiment, a consequential design decision, or an authorized increment.