define-change

Files (1)

• SKILL.md

SKILL.md (first lines)

Follow `~/.agents/sdlc/READING.md`; reuse required documents already read in
full, unchanged and retained in context. A skill transition does not reload them.

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.

Work on the project's recorded primary branch under `GIT.md` and
`DELIVERY.md`. Do not create a feature branch during definition. Primary's
`docs/work.org` is the ticket authority; synchronize it and publish a minimal
reservation under `DELIVERY.md` before treating a number as allocated. Record,
review and publish the definition on primary. Branching for code belongs to
admitted delivery, not ticket creation.

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.

Use the work number reserved on primary under `DELIVERY.md`. Create
`specs/WNNN-descriptor/spec.org` from
`~/.agents/sdlc/templates/v3/spec.org`. Include context, falsifiable acceptance
criteria, traced AT/RT/UT/OT test definitions (including at least one meaningful
UT under TESTING.md), edge cases, solution design,
mandatory security impact, and a context-independent delivery handoff. Apply
`~/.agents/sdlc/ORG-SCHEMA.md`: every AC carries `:ac:` and every test `:testdef:`.
Create `validation.org` by delivery admission; do not invent execution states
in definition. Record reviews in `audits.yaml` under `AUDIT-RECORD.md`;
do not create parallel audit documents. 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.

Identify affected documentation in Delivery Handoff. Where neither AT nor RT is justified,
record why OT/UT evidence suffices for definition review; this permits delivery
to skip test-code review, not to omit the final delivery-code gate.

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. Load `~/.agents/skills/definition-audit/SKILL.md` and conduct
the composite review internally in this session. Address **every** finding as a batch:
remediate valid findings and challenge incorrect or out-of-scope findings with
evidence under `~/.agents/sdlc/AUDITS.md`. Raise doubtful or unresolved disputes
to the operator; never silently waive findings or expand scope to obtain a PASS.
Do not launch an external reviewer.

After current internal PASS is recorded in `audits.yaml`, move the work
item to `REVIEW`. Self-review requires no external verdict; an explicitly requested independent
review uses the same canonical record with its actual method.
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 `APPROVED YYYY-MM-DD` in `OPERATOR_SIGNOFF`, adding scope
only where approval is limited; follow `DOCUMENTATION.md`, not conversation narration.
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.

Review orchestration and evidence ownership follow `AUDITS.md`; current-session
review uses `SELF-AUDIT.md`. No external call or new reviewer is authorized.

From tigger-developer/sdlc, Apache-2.0.

More from tigger-developer/sdlc