Ops capstone: your operating layer

What you ship

The capstone is not a new build - it is making everything from the last six weeks production-real on your actual company, then documenting it so it survives you being on vacation.

• The company brain: the repo, a current root CLAUDE.md, self-describing folders, and the checked-in .claude/settings.json guardrails.
• Three working workflows from this track - typically meeting-followup, the document factory, and inbox-triage or data-clean, but pick the three your company feels weekly.
• One scheduled report running without you: the weekly KPI report as a Routine, with the dead-man's switch and the stale-data guard in its prompt.
• The ops manual: the document that lets a teammate run all of it.

The bar for each piece: it has run on real data at least twice, its output went to the people who actually use it, and its failure mode is visible.

The build order

Work the capstone in this order - guardrails before workflows, workflows before schedule, schedule before manual. Each step assumes the previous one held.

1. Audit the brain first (20 min): is the root CLAUDE.md still under 200 lines and current? Is the current-best list true? Does every client folder self-describe? Is anything sitting unprocessed in _intake/? Is the search index rebuilt and the memory index under 200 lines? Fix what you find.
2. Verify the guardrails (15 min) - all three layers: CLAUDE.md rules current (shapes), the .env read-deny holds and send-shaped tools sit behind ask rules (enforces), the audit hook is writing lines and finance connections are read-only (guarantees).
3. Run each of your three workflows end to end on real input (45 min) and check every output system. Fix the skill, not the output, wherever it stumbles.
4. Confirm the Routine: read the latest run transcript - not just the green status - and confirm the report posted, the as-of timestamp printed, the row counts moved, and the cost was logged.
5. Write the ops manual (30 min, structure below).
6. Hand the manual to a teammate and have them run one workflow with zero verbal help. Their friction points are your final edit list.

The ops manual

Write it as docs/ops-manual.md in the brain repo. It is short, because the system self-describes.

• The map: what the brain is, the folder tour in ten lines, and where the skills live.
• The workflows: each of the three, with its trigger, its skill name, its approval gate, and its owner.
• The schedule: the jobs registry - every scheduled job with tier, timing, owner, and output location.
• The rules: the do-not-automate list, the draft, don't send doctrine, who approves what, and where the keys live (named location, never the keys themselves).
• When it breaks: the failure runbook from last lesson, linked or inlined.

Two stretch builds

If the core four are solid, two advanced builds turn the operating layer from "automated" into "self-maintaining."

The self-healing report: harden the KPI routine with structured output (--json-schema if you run it headless), an explicit failure path that posts "REPORT FAILED: <reason>" to Slack, cost logging on every run, and a monthly routine that reviews the audit log itself and summarizes what your automation did all month. The report becomes a system that watches itself.

The brain gardener: a weekly Routine that sweeps the repo for stale CLAUDE.md headers, unfiled _intake/ items, and contradictory rules - and opens a pull request with proposed fixes. A human merges. Git becomes the approval gate, and the brain maintains itself with you as editor rather than janitor. This is the top rung of the ladder - an agent with judgment - and the prettiest pattern in the track: the knowledge system gardening its own knowledge, with every change reviewed.

Graduation: run it, grow it, know its limits

You now operate a layer: knowledge that compounds, procedures that run themselves, reports that arrive, and failures that announce themselves. You have climbed the whole ladder - chat once, skill, scheduled Routine, agent with judgment - on your own company. The remaining skill is knowing what belongs in the layer at all.

• Stays in Claude Code: judgment-heavy work, variable inputs, document generation, anything living next to the brain.
• Graduates to n8n or engineering: a flow that has become fully deterministic, runs at high volume, and touches revenue on every execution - your Claude Code version is now the working spec for the hardened build.
• Stays human forever: the do-not-automate list. It does not shrink as the tools improve; it is a values decision, not a capability gap.

Do this now

Sources and further reading

• Claude Code Routines docs
• Claude Code hooks guide
• How Anthropic teams use Claude Code