Design Discussion

Understand $ARGUMENTS, relate it to existing governance, and produce only the design artifacts justified by the discussion.

Operational Baseline

Discovery

Start from repository context rather than a blank design:

govctl status
govctl search <topic>
govctl rfc list
govctl adr list

Read relevant current artifacts with show; use --history only when prior content matters. Use govctl <resource> --help for current authoring syntax. In the govctl repository itself, invoke the development binary as cargo run --quiet --.

Hard Stops

• This is a design workflow: do not implement code or create Work Items.
• Do not perform lifecycle or destructive artifact mutations here, including acceptance/rejection, phase or version changes, deprecation, supersession, and deletion.
• Do not issue raw VCS commands; use the commit skill when drafts should be recorded.
• RFCs own obligations, ADRs own design rationale, and Work Items own execution. Do not use one artifact to compensate for missing content in another.
• Stop and ask when requirements conflict, a breaking consequence is unacknowledged, or the available evidence cannot resolve a material ambiguity.

Decision Policy

Classify The Outcome

Question answered	Result
What behavior or invariant must be true?	RFC or RFC amendment
Why was one design chosen over alternatives?	ADR
What does an existing artifact mean?	Discussion or clarification
What work should be executed now?	Hand off to gov; no Work Item here

Not every discussion needs an artifact. Prefer clarification in conversation when no durable obligation or decision changes.

Explore Before Concluding

Identify constraints from existing RFCs and ADRs, then compare plausible options. Ask only questions whose answers materially change the design. For high-risk or difficult trade-offs, use decision-analysis.

When drafting:

• use rfc-writer for normative Clause quality;
• use adr-writer and establish alternatives before the decision;
• use root govctl clause commands for every Clause operation;
• use [[artifact-id]] references in governed prose; and
• keep implementation details out unless they are an external contract.

Draft lifecycle operations belong to the later spec or gov handoff. A behavior-changing amendment needs governed implementation; a clarification with no implementation can use spec.

Review And Validate

Run govctl check after substantive artifact edits. Use rfc-reviewer for an RFC draft, adr-reviewer for an ADR draft, and wi-reviewer for a Work Item when independent semantic review is warranted. Resolve critical findings before presenting the artifact as ready. Reviewer isolation is for semantic quality; govctl remains responsible for structural validation.

Completion Evidence

Conclude with:

• the problem and constraints understood;
• options considered and the current recommendation;
• draft artifacts created or changed, with status;
• unresolved questions and material risks;
• validation and reviewer results; and
• the correct handoff: continue discussion, spec, gov, or commit.

Leave artifacts in draft/proposed state until the user authorizes the owning lifecycle transition.