← All field notes
PROCESS OUTLINEPlanned

How we use specs, RFCs, and ADRs

A coding agent can move quickly. The repository still needs to explain what the product means, which decisions are durable, and what evidence supports each public claim.

This is an editorial outline.

It documents the intended story structure; it does not claim that every workflow outcome is complete.

Proposed story beat

Ready Together treats the repository as shared memory for humans and agents. Specs define testable product behavior, RFCs examine broad or risky changes, and ADRs preserve decisions that future work must understand.

IssueSpecRFC when neededADRCode + testsEvidence
  1. Start from a bounded problem.The issue names the outcome, constraints, and owner decisions.
  2. Make behavior testable.The spec converts intent into requirements and explicit non-goals.
  3. Debate only what needs debate.An RFC is for cross-cutting choices, not ceremony for every change.
  4. Preserve durable decisions.An ADR records the chosen trade-off and the alternatives that were rejected.
  5. Publish from evidence.Build-in-public copy is generated from merged work, reproducible tests, and owner-approved media—not chat memory.

Evidence still required before final copy

  • One complete issue-to-merge example with public-safe links.
  • A compact diagram of which artifact answers which question.
  • A failure or changed decision that demonstrates why traceability mattered.
  • Owner approval for repository screenshots and agent-workflow details.