openwiki

Guide · Specification publishing

Publish an Agent-generated technical specification

A specification becomes useful when a reader can verify its boundary, challenge its assumptions, and know which revision was approved. The generation session alone does not provide that contract.

Updated August 3, 2026Practical guide

Make the specification decision-ready

  1. Problem, users, and non-goals
  2. Current-state evidence
  3. Proposed behavior and public contracts
  4. Data, permissions, and failure semantics
  5. Risks, migration, rollback, and open questions
  6. Exact authority requested from the reviewer

Keep facts and proposals distinguishable

State which behavior exists in the current system, which behavior this specification proposes, and which ideas remain roadmap possibilities. A reader should never infer implementation from confident future-tense copy.

Publish a candidate for review

ow a2ui draft check ./spec
ow a2ui draft build ./spec
ow a2ui digest ./spec/document.mdw
ow publish ./spec/document.mdw --review --no-open --timeout 900

Bind implementation to the approved revision

Use the fixed version permalink in implementation notes, release evidence, or audit records. If scope changes materially, publish a new candidate instead of treating the old approval as blanket authority.

FAQ

Frequently asked questions

Should implementation link to the canonical spec or a fixed version?

Use the immutable approved version for the implementation contract. The canonical URL is useful for readers who should see the latest formal state.

Can an Agent approve its own generated specification?

OpenWiki’s review loop is designed for an explicit human decision. The Agent must treat non-approval and missing decisions as blockers.

Use the real workflow

Publish what your agent creates.

Give every report, document, or plan its own reader-ready page. Comments, review decisions, and formal revisions can flow back from there.

Choose HostedSign in