| name | spx-discussion |
| description | Resumable product and technical discussion for advanced coding models. Use when a rough idea needs durable decisions and options before formal specification. |
SPX Discussion
Read references/project-learning.md and apply its consume-capture policy.
Read references/workflow-runtime.md; its feature-state rules apply only after
this discussion is bound to a resolved FEATURE_DIR.
Read references/project-cognition.md, using cognition intent plan, and
references/discussion-contract.md. Read references/consequence-gate.md on
its triggers.
Read references/ui-quality-gate.md when product experience, interface
direction, screen hierarchy, or interaction behavior is part of the decision.
Discover or create the session with the project launcher-backed
{{specify-subcmd:specify-runtime discussion list --json}} and
{{specify-subcmd:specify-runtime discussion init <slug> --json}} helpers. Resume existing
state with {{specify-subcmd:specify-runtime discussion resume <slug> --json}} instead of
reconstructing it from chat memory.
Use the live repository only to ground product boundaries, current behavior,
technical options, and constraints. Keep the visible conversation natural:
surface one decision cluster at a time, explain meaningful tradeoffs, and
distinguish confirmed decisions, working assumptions, rejected options, and
unresolved user choices.
Run a Truth Pass before source-grounded technical advice or affected-surface,
implementation-path, or verification claims. For cross-project work, lock
target_project_root before technicalizing and verify facts in that target.
Persist compact semantic checkpoints only when meaning changes; do not store a
transcript. Stay in discussion until the user explicitly requests a handoff.
Do not treat an already-active discussion as a new automatic workflow entry;
topical acknowledgements and follow-ups continue this stage without requiring
the user to repeat $spx-discussion. A contextual confirmation such as yes,
ok, or 可以 authorizes handoff only when it directly answers a named handoff
action, and authorizes readiness only when it confirms the displayed digest.
Then draft exactly one agent-only contract and write it with
{{specify-subcmd:specify-runtime discussion write-handoff <slug> --input <draft-json-path> --json}}.
Run {{specify-subcmd:specify-runtime discussion validate-handoff <slug> --mode draft --json}},
review its boundary against confirmed decisions, and ask the user to confirm
that exact revision. Then run
{{specify-subcmd:specify-runtime discussion confirm-handoff <slug> --digest <review-digest> --json}}
before {{specify-subcmd:specify-runtime discussion mark-ready <slug> --json}}. Before every
final response that names sp-specify, read canonical status and withhold the
downstream invocation unless it is handoff-ready.
Do not create feature state, a spec, plan, tasks, or production changes. A ready
handoff continues through $spx-specify; mark it consumed only after the
specification successfully incorporates it. This invocation authorizes only
this workflow stage; do not invoke another workflow in this run.
