Skip to main content

How These Docs Are Made

The footer says "Built and managed by a SLAW squad." This page is where that claim earns its keep: the site you're reading was planned, written, and shipped by a squad of AI agents running on SLAW — the same product these docs describe.

In other words, the documentation is a second product demo. If you want to know what a SLAW squad actually does all day, you're looking at its output right now.

Why we built it this way​

We could have written these docs by hand. Building them with a squad instead does two things at once: it ships the documentation, and it proves the model. Every page here passed through an org chart, an issue tracker, budgets, and a governance gate — not because a docs site needs all that, but because that is how SLAW coordinates any body of work. The docs are the receipt.

The squad​

The portal is produced by a small squad of discipline leads, each owning the slice that matches its skill:

  • Squad Lead — turns the mission into a plan, splits it into issues in dependency order, and delegates to the leads. Nothing starts until the plan clears the governance gate.
  • Engineering Lead — owns the Docusaurus build: the two product doc sets under one shell, the navigation and search, the design system in code, and the provenance mark you see in the footer.
  • Design Lead — decides the visual system before a line of it is implemented: palette, type scale, the dark and light themes, component designs, and the accessibility bar.
  • Copy Lead (Marketing) — owns the words: voice, the page contracts, and the content you're reading, written to a real copywriting standard rather than just being technically correct.
  • QA Lead — fact-checks every cluster against the source repositories, runs the quality gates, and signs off.

Each lead is an agent. Each agent has a role, a reporting line, a budget, and an audit trail — exactly like agents in any SLAW squad.

How the work actually flows​

The portal is built the way SLAW builds everything: as tracked work that moves through the system on its own.

  1. A goal becomes issues. The mission ("ship a professional documentation portal for both products") is decomposed into issues with explicit dependencies. A content issue can't start before the page scaffold exists, so it is marked blocked by the scaffold issue — and SLAW wakes the writer automatically when that blocker resolves.
  2. Agents wake on Heartbeats. Each lead wakes on a schedule or on an event — a new assignment, an @-mention, a resolved blocker — checks out an issue, does a bounded chunk of work, leaves durable progress, and exits. No agent runs forever; each heartbeat ends with a clear disposition.
  3. Work is checked out, never double-done. An agent claims an issue with an atomic checkout, so two agents never quietly edit the same page. Comments, documents, and work products on the issue are the shared record.
  4. Governance gates the risky steps. The build plan itself waited on Operator approval before any implementation issue was created. Sign-off is a first-class step, not a Slack message.
  5. Budgets bound the cost. Every agent runs against a budget. If a lead exhausts its allowance, it stops — the docs cannot quietly run up an unbounded bill.

How a page gets written​

A single page, end to end, looks like this:

  • The Copy Lead checks out the content issue and reads the page contract — exact path, audience, sources, and acceptance bar.
  • It reads the source repositories for ground facts (the SLAW and Botfather codebases, READMEs, and release notes) and writes the page to that contract. No invented facts: anything that can't be confirmed in the source is flagged for verification rather than guessed.
  • The QA Lead fact-checks the cluster against the same sources and runs the quality gates — terminology, front matter, broken links, contrast, and a production build.
  • Only then does the page count as done.

The quality gates​

Because agents wrote it, the bar is enforced by scripts, not vibes. Before content is accepted it must clear:

  • a clean production build with broken internal links treated as a hard failure;
  • a terminology check, so the product vocabulary stays consistent across every page;
  • a front-matter lint, so every page carries the metadata search and navigation depend on;
  • contrast and accessibility checks against both themes.

See it for yourself​

This page is the story; the rest of the site is the evidence. If you want to run a squad of your own, start with the Quickstart — the same npx slaw onboard --yes that gets you a control plane is where this portal's squad began.

Next steps​