define-change

Read ~/.agents/sdlc/MAIN.md, ISSUES.md, TESTING.md, CODING.md,
ARCHITECTURE.md, GIT.md, DOCUMENTATION.md, and ORGMODE.md, then the project
profile and its selected standards and authorities.

Remain on the operator-selected branch throughout definition. Do not create,
switch, merge, or delete a feature branch. The project branch strategy applies
only when an approved specification enters delivery. Synchronize the current
branch at the definition boundaries required by GIT.md.

Definition defaults to ATTENDED. Ask the bounded clarification questions
required to make the specification safe and context-independent. If the
operator explicitly invokes HANDS-OFF definition mode, declare that mode
and assume the operator is unavailable for the remainder of the definition
window. In that mode, make sensible, reversible assumptions to keep the work
moving and record each one in the specification's decision log; do not stop for
routine status, incidental uncertainty, or approval requests. Stop only for a
genuine blocker, an unsafe or unauthorized action, the configured audit limit,
or a decision that cannot be made safely from the available evidence. An
ordinary progress report is not a handback. Any interruption or operator
response returns the skill to ATTENDED until HANDS-OFF is explicitly invoked
again.

Ask no more than three concise free-form questions needed to define product
scope. If operator direction raises unresolved test or design choices, ask no
more than three additional questions for each affected area. Do not use
multiple-choice UI.

Allocate the next never-used project work number. Create
specs/WNNN-descriptor/spec.org from
~/.agents/sdlc/templates/v3/spec.org. Include context, falsifiable acceptance
criteria, traced RT/UT/OT test definitions, edge cases, solution design,
mandatory security impact, and a context-independent delivery handoff. Create
validation.org only when needed; the harness alone creates and updates
audits.yaml. Add or update the descriptive work item in docs/work.org. Apply the
change-specific title, Org hierarchy, description-list, and semantic-emphasis
requirements in ISSUES.md; generic titles and visually unscannable drafts are
not ready for audit.

When annotations are present, apply the annotation-review contract in ISSUES.md
before audit or sign-off. Reconcile feedback as a batch, retain unresolved items,
and move resolved annotations with their dispositions to feedback.yaml before
removing them from the specification. Only the agent edits the specification body;
a question is not an instruction. Include the feedback log as audit evidence when
present. No annotation records, even resolved or empty ones, may remain at the gate.

Copy the template's #+SCHEMA: version. Keep Synopsis distinct from the
change-specific #+TITLE:, with its eight level-two categories and short bullets.
Its summary must accurately and completely represent the detail below
its section break. Invoke the composite definition audit through the installed
audit harness with --phase audit --gate definition, using audits.yaml for
the retained session mapping. Remediate all findings before resuming that
same session; never resubmit a known FAIL unchanged or remediate findings
piecemeal. On timeout, follow the harness recovery diagnostic: in HANDS-OFF,
resume automatically within its limit, using the retained session. Timeout
without a verdict does not require an artificial edit. Do not invoke individual audit skills.

After current audit evidence in audits.yaml establishes PASS or an effective
PROVISIONAL PASS, move the work item to REVIEW. Never copy the verdict into
spec metadata. Open the specification with the previewer selected by MAIN.md
and return it for operator sign-off. Preview is presentation, not a gate. After
explicit sign-off, record the authority, date and approval scope in spec.org.
Move its work item to ACTIVE unless the operator explicitly defers delivery;
retain REVIEW and the hold in that case. Design approval never lifts a hold.
Do not implement code.