Skip to main content
Compendium · Compositions · Onboarding

Onboarding

Items
16
of 1002 total

Full-featured composed scenes — one per row so each design has room to breathe. Click for the live render, the spec, and the source.

Featured 14 Atoms 762 Compositions 240
№ 131

First Spec Walkthrough

Scene STA do
Onboarding · 01 ~4 min read

Write your first spec.

Four steps. The card on the right writes itself as you go.

  1. 1

    Frontmatter

    Pin identity. Every spec is uniquely named, versioned, and owned.

    ---
id: SPEC-014
version: 1.0.0
owner: @auth-team
---
  2. 2

    Intent

    One paragraph. What we want and why — never how.

    ## Intent
Issue sessions for verified
Google identities only.
  3. 3

    Acceptance criteria

    Checkboxes the AI can grade itself against. Include negatives.

    ## Acceptance Criteria
- [ ] Verified emails get session
- [ ] Unverified rejected silently
  4. 4

    Constraints

    The boundaries. Speed, security, scope — what cannot move.

    ## Constraints
- p95 latency < 300ms
- No PII in logs
Compositions / onboarding

Four-step keyboard-navigable walkthrough for writing your first DoCoDeGo spec — each step adds a section to a live miniature spec card that grows as the reader advances.

open ↗
№ 132

Framework Tour

Scene STA
Onboarding · 02 5 stops · 60s

The framework, in five stops.

Stop 1 / 5

/
Overview
Role
You · the adopter

A post-Agile framework for intent-driven engineering.

Four pillars. Four human roles. One loop that closes only when intent and reality match.

Compositions / onboarding

Five-stop guided tour of the DoCoDeGo framework — Overview → DO → CO → DE → GO — with a progress dot trail, keyboard arrow navigation, and a stop-card that swaps content per step.

open ↗
№ 133

Adoption Checklist

Scene STA
Onboarding · 03 8 items · team rollout

Adoption checklist.

Progress
0 / 8
  1. 01 DO Nominate a spec owner per stream
    What

    Each work stream gets one named author. They own the specs end-to-end.

    Why

    Specs without owners drift. Drift kills the loop.

    How

    Add a CODEOWNERS-style file. Owner handle appears in every spec frontmatter.

  2. 02 DO Write one spec for an active work item
    What

    Pick one ticket. Author its spec before any code change.

    Why

    You learn the format by using it once for real, not by reading.

    How

    Use the framework spec template. Land it as a PR. Treat the spec as the ticket.

  3. 03 CO Wire the AI to read specs
    What

    Your AI coding assistant must ingest spec files as primary context.

    Why

    Otherwise the AI re-derives intent and gets it subtly wrong.

    How

    Point your tool at /specs. Add a project rule: "specs are source of truth."

  4. 04 CO Establish a human architect
    What

    One person owns the architecture per service. AI does not vote.

    Why

    Architecture is the work that compounds — you cannot delegate it.

    How

    Architect signs off on the spec's "Constraints" block before any CO work begins.

  5. 05 DE Make acceptance criteria executable
    What

    Each criterion maps to a test or a manual check with a clear pass signal.

    Why

    Validation that lives in someone's head is not validation.

    How

    Run the ics-scorer against your spec. Below 60? Rewrite the criteria.

  6. 06 DE Gate merges on acceptance pass
    What

    No merge unless every acceptance criterion has a green run.

    Why

    A passing CI is the only honest signal that intent met reality.

    How

    Wire the github-action-ics into your repo. Required check on the default branch.

  7. 07 GO Run AAR / GTR on every shipped spec
    What

    After-action review on incidents; green-to-red on degrading specs.

    Why

    The loop is only closed when the team learns from what shipped.

    How

    Use the aar-gtr-tracker tool. Land a one-page review per spec, monthly.

  8. 08 GO Publish a governance manifest
    What

    A short doc naming kill switches, audit trails, agent boundaries.

    Why

    Autonomy without accountability is the failure mode the framework exists to prevent.

    How

    Use the threat-validator tool. Manifest sits in /docs/governance.md.

// Tick as you go. Local only — nothing is sent anywhere.
Compositions / onboarding

An eight-item adoption checklist for a team rolling out DoCoDeGo — each item is a collapsible disclosure with What / Why / How sections and a progress counter at the top.

open ↗
№ 134

DoCoDeGo Cheatsheet

Scene STA
Cheatsheet · 04 Print to A4

DoCoDeGo, on one page.

docodego.com / cheatsheet

v1.0 · 2026

The four pillars

  • DO Author
    DOcument

    Specification is the only source of truth.

  • CO Architect
    COmpose

    Human owns architecture; AI implements.

  • DE Gatekeeper
    DEmonstrate

    Value flows at the speed of validation.

  • GO Governor
    GOvern

    Autonomy without accountability is catastrophe.

Core statutes

  1. 01

    Intent precedes implementation. No code without a spec.

  2. 02

    Acceptance criteria are executable. Otherwise they are wishes.

  3. 03

    The human reviews what the AI produced. Always.

  4. 04

    A green run is the only signal to ship. Calendars do not override evidence.

Acronyms

ICS
Intent Completion Score — 0–100 quality grade for a spec.
AAR
After-Action Review — post-incident learning loop.
GTR
Green-To-Red — tracking specs that started passing and degraded.
RC
Runbook Checklist — automated operational playbook step list.
DDL
Data Definition Language — SQL source for spec extraction.
SPEC-NNN
Canonical spec identifier. Globally unique inside a repo.

ICS rubric

0 – 100
  • 80–100 Approved

    Ship. AI has enough signal to compile against this.

  • 60–79 Provisional

    Workable. Tighten criteria before high-stakes work.

  • 40–59 Draft

    Do not implement against this. Rewrite intent.

  • 0–39 Reject

    Not a spec. A note. Start over.

// Screenshot · pin to Slack · print to A4 DOcument · COmpose · DEmonstrate · GOvern
Compositions / onboarding

A single-page, print-friendly reference: the four pillars, the four core statutes, key acronyms, and the ICS scoring rubric — laid out as a four-zone broadsheet you can screenshot or print.

open ↗
№ 135

Example Spec Anatomy

Scene STA do
Onboarding · 05 Read a spec fluently

Anatomy of a spec.

Six regions. Hover a number to highlight what it means. 

---
id: SPEC-014
version: 1.3.0
status: approved
owner: @auth-team
---

# Authenticate via OAuth

## Intent
Issue a session for verified Google
identities. Reject everything else
without disclosing why.

## Acceptance Criteria
- [x] Verified emails create a session
- [x] Unverified emails rejected silently
- [ ] Sessions expire after 24h

## Constraints
- p95 latency < 300 ms
- No PII in logs
- No third-party tracking
// The numbers are the map. Memorise the regions, not the order.
Compositions / onboarding

Anatomy diagram of a real DoCoDeGo specification — numbered callouts point at id, version, owner, intent, criteria and constraints with one-line explanations beside each.

open ↗
№ 1221

Day One Checklist

Scene STA do
Onboarding · day-1 12 items · ~90 min

Your first 90 minutes.

Four blocks, three actions each. Tick as you go.

Progress
0 / 12
90 min remaining

Install

DO
  • Clone the framework starter repo 10m
  • Install the spec-linter and ics-scorer 5m
  • Verify pnpm and python toolchains 5m

Configure

CO
  • Point the AI assistant at /specs as primary context 5m
  • Add a CODEOWNERS file and pick a spec owner 10m
  • Wire the ics-scorer as a pre-commit hook 5m

Author

DE
  • Write your first spec from the template 15m
  • Translate acceptance criteria into executable checks 10m
  • Run the ics-scorer and beat 60 5m

Ratify

GO
  • Open a PR; require the ICS check on the branch 10m
  • Add the spec id to your tracker 5m
  • Schedule a 7-day AAR review on the calendar 5m
// Day-one bootstrap. Local-only — nothing is sent anywhere.
Compositions / onboarding

A scannable, four-zone Day One checklist that walks a fresh adopter through the first 90 minutes of DoCoDeGo — install, configure, author, ratify — with live progress tracking and time estimates per item.

open ↗
№ 1222

First Week Roadmap

Scene STA de
Onboarding · week-1 5 days · 5 gates

Five days. Five outcomes.

One pillar lands per day. Each closes a gate before the next opens.

Day 1 of 5 · click to focus

Arrow keys cycle days

Compositions / onboarding

A five-day horizontal roadmap that pins one outcome per weekday — Monday installs, Friday ships — with each day expanding to show its three concrete actions and the gate that closes it.

open ↗
№ 1223

Team Readiness Assessment

Scene STA go
Onboarding · readiness 9 questions · ~10 min

Are you ready for DoCoDeGo?

Rate each statement. Be honest — the verdict gets sharper.

Readiness score
0 / 27
Not yet

Begin with the day-one checklist before adopting the loop.

  1. DO Q01

    We write specs before we write code.

    We write specs before we write code.
  2. DO Q02

    Every spec has a single named owner.

    Every spec has a single named owner.
  3. DO Q03

    Acceptance criteria are testable, not aspirational.

    Acceptance criteria are testable, not aspirational.
  4. CO Q04

    A human owns architecture; AI does not vote on it.

    A human owns architecture; AI does not vote on it.
  5. CO Q05

    Our AI assistant reads specs as primary context.

    Our AI assistant reads specs as primary context.
  6. CO Q06

    We review every line of AI-generated code.

    We review every line of AI-generated code.
  7. DE Q07

    A green CI run is the only signal to ship.

    A green CI run is the only signal to ship.
  8. GO Q08

    We have written kill-switches for agent actions.

    We have written kill-switches for agent actions.
  9. GO Q09

    We run an AAR on every shipped spec.

    We run an AAR on every shipped spec.
DO
0
CO
0
DE
0
GO
0
Compositions / onboarding

A nine-item team-readiness self-assessment grouped by pillar — each item rated on a four-point scale; a live readiness score and verdict card update as the team answers.

open ↗
№ 1224

Tool Install Wizard

Scene STA co
Onboarding · install 4 steps · ~5 min

Install the toolchain.

Your OS
  1. 1

    Pick OS

    Snippets below adapt to your platform.

    # Confirm prerequisites
python3 --version
node --version
pnpm --version
  2. 2

    Install Python tools

    Spec linter, ICS scorer, threat validator.

    pip install --user spec-linter ics-scorer threat-validator
  3. 3

    Wire Astro site

    Install the framework starter dependencies.

    cd website && pnpm install && pnpm dev
  4. 4

    Verify

    Confirm tools resolved and the site boots.

    spec-linter --version
ics-scorer --help
curl -s localhost:4321 | head -1
Compositions / onboarding

A four-step install wizard for the DoCoDeGo toolchain — pick OS, install Python tools, wire Astro, verify — with copyable shell snippets and a live progress rail.

open ↗
№ 1225

Spec Template Picker

Scene STA do
Onboarding · templates 6 starting points

Pick the right spec template.

Each one is opinionated. Use the one that matches the work shape.

Compositions / onboarding

A six-card spec template gallery — Feature, Bugfix, Migration, Refactor, Threat, Spike — with a live preview pane that swaps to the selected template and surfaces its fields and minimum ICS.

open ↗
№ 1226

Role Self-Assessment

Scene STA co
Onboarding · role 9 prompts · ~3 min

Which role fits you?

Author, Architect, Gatekeeper, or Governor — pick a leaning per prompt.

  1. Q01 When work starts, the first thing I produce is:

    When work starts, the first thing I produce is:

  2. Q02 I am most uncomfortable with:

    I am most uncomfortable with:

  3. Q03 My favourite review comment is:

    My favourite review comment is:

  4. Q04 AI agents should:

    AI agents should:

  5. Q05 A failed ship hurts because:

    A failed ship hurts because:

  6. Q06 I keep going back to:

    I keep going back to:

  7. Q07 I want the AI to ask me:

    I want the AI to ask me:

  8. Q08 I judge a system by:

    I judge a system by:

  9. Q09 On a bad day, I default to:

    On a bad day, I default to:
Compositions / onboarding

A nine-prompt self-assessment that maps the reader to their primary DoCoDeGo role — Author, Architect, Gatekeeper, or Governor — with a result card showing role accent, daily habits, and where to read next.

open ↗
№ 1227

Autonomy Calibration Walkthrough

Scene STA go
Onboarding · autonomy 5 levels · pick your target

Calibrate your leash.

The longer the leash, the bigger the rollback you must own.

Compositions / onboarding

A five-stop walkthrough that calibrates how much autonomy a team grants its AI agents — from suggest-only to autonomous-with-audit — with each stop showing the boundary, the failure mode, and the rollback.

open ↗
№ 1228

First Spec Grilling

Scene STA do
Onboarding · grilling 6 weaknesses · score to 100

Grill your first spec.

A yes to every question earns the spec a review-ready stamp.

  1. Weakness 01 +20

    Vague intent

    Can a stranger restate the intent in one sentence from the spec alone?

    Why this matters →

    Intent is the only thing the AI compiles against. If a human cannot restate it, the AI will hallucinate the gaps.

  2. Weakness 02 +20

    Inexecutable criteria

    Does every acceptance criterion map to a test, check, or boolean signal?

    Why this matters →

    A criterion that lives in someone's head is not a criterion — it is a hope.

  3. Weakness 03 +15

    Missing negatives

    Does the spec name at least one thing the system must NOT do?

    Why this matters →

    Negatives prevent the AI from generating clever-but-wrong solutions that pass the positives.

  4. Weakness 04 +15

    Soft constraints

    Are constraints expressed as hard bounds (numbers, time, scope)?

    Why this matters →

    "Fast" is not a constraint. "p95 latency < 300ms" is. The AI cannot negotiate with adjectives.

  5. Weakness 05 +15

    No named owner

    Is exactly one human named as the spec's accountable owner?

    Why this matters →

    Ownership prevents drift. A spec without an owner is a spec without a future.

  6. Weakness 06 +15

    No failure modes

    Does the spec enumerate at least three plausible failure modes?

    Why this matters →

    Imagining failure surfaces ahead of code is the cheapest defense the framework offers.

Compositions / onboarding

A six-question grilling that hardens a candidate spec — each question targets a common spec weakness; live ICS-style score rises as the author answers; final state earns a "review-ready" stamp.

open ↗
№ 1229

First Plan Approval

Scene STA co
Onboarding · plan-review 4 steps · architect ritual

Approve your first AI plan.

Read each step. Flag the risky ones. Rewrite the fuzzy ones.

Verdict
Pending
  • Approved: 0
  • Flagged: 0
  • Rewrites: 0
  1. 1

    Add OAuth provider config

    Introduce a typed Provider record and a registry under /auth/providers.

    src/auth/providers/index.ts
    Verdict for Add OAuth provider config
  2. 2

    Wire the verify-email guard

    Reject sessions for unverified emails silently; no PII in logs.

    src/auth/guards/verify-email.ts
    Verdict for Wire the verify-email guard
  3. 3

    Persist the session token

    24h expiry; sliding window refresh; cookie flags Secure + HttpOnly.

    src/auth/session/store.ts
    Verdict for Persist the session token
  4. 4

    Add the regression test

    Cover verified accept, unverified reject, expired session reject.

    tests/auth/oauth.spec.ts
    Verdict for Add the regression test
Compositions / onboarding

A four-step walkthrough that takes a fresh AI-authored plan from "proposed" to "approved" — review steps, mark risks, request rewrites, and stamp approval — with each plan step inspectable.

open ↗
№ 1230

Governance Config Walkthrough

Scene STA go
Onboarding · governance 6 sections · 1 manifest

Compose your governance manifest.

Pick the canonical answer per section. Manifest assembles itself on the right.

  1. S01 Owners

    GO
    Owners

  2. S02 Kill switches

    GO
    Kill switches

  3. S03 Audit trail

    GO
    Audit trail

  4. S04 Agent boundaries

    GO
    Agent boundaries

  5. S05 Escalation

    GO
    Escalation

  6. S06 Review cadence

    GO
    Review cadence
Compositions / onboarding

A six-section governance config walkthrough — owners, kill-switches, audit trail, agent boundaries, escalation, and review cadence — built up live into a single manifest preview as the reader fills sections.

open ↗
№ 1231

Quickstart Card Grid

Scene STA de
Onboarding · quickstart 9 next actions

Pick your next move.

Filter by effort
  • DO 30m

    Write one spec

    A real ticket lands as a spec on main.

    Action 01 Start →
  • DO 10m

    Score a spec

    Run ics-scorer; beat 60 on a real spec.

    Action 02 Start →
  • DO 10m

    Add owners

    Every spec has a single accountable handle.

    Action 03 Start →
  • CO 30m

    Wire the AI

    Assistant treats /specs as primary context.

    Action 04 Start →
  • CO 1h

    Draw the seams

    Architect signs off on Constraints before code.

    Action 05 Start →
  • DE 30m

    Wire the gate

    github-action-ics required on the default branch.

    Action 06 Start →
  • DE 1h

    Make it execute

    Every acceptance maps to a test or a check.

    Action 07 Start →
  • GO 10m

    Name a kill switch

    Agents can be stopped from one documented place.

    Action 08 Start →
  • GO half-day

    Schedule the AAR

    A recurring slot for after-action review exists.

    Action 09 Start →
9 visible · 9 total // Pick one. Land it today.
Compositions / onboarding

A nine-card quickstart grid that points an adopter at the single right next action across the four pillars — each card carries a verb, a one-line outcome, an effort tag, and a deep link.

open ↗
Alpha · Honest about it

The framework is real.
The community is forming now.

DoCoDeGo is in Alpha. The framework is documented, the practices are battle-tested at small scale, and the next release is being shaped in public.

If it produces anything, it should produce engineers and teams who think more clearly about what they are building and why.

Two doors in
Join the Discord

Discord is where specs are debated, the framework gets sharper, and decisions land in writing. The conversation is the artefact.