Module 6 of 6 · The capstone
Your Hub in action
There is no new primitive today. That is the point. The capstone does not add a part; it shows you that the parts already compose. You tour a Hub at full scale, present one workflow you now run without thinking, and learn the closing ritual that makes the system outlive every conversation.
- Read a working Hub at system level: how the standing brief, skills, agents, routines, and memory compose into one daily operating system
- Present one workflow you now run without thinking, trigger to destination, to an actual audience
- Close a session the way you will close every session from now on: log, commit, push, continuation prompt
- Know what your Hub needs next, and where the discipline you built goes at scale
The Module 5 pre-work converges here. You arrive with three sentences about the workflow you run without thinking. Today you present it, and then you close the session for real.
Watch
The two videos
Compounding: six artifacts, each making the next cheaper. The workflow statement as the test of a real system, and why conversations end but the system persists.
scripts/M6-hub-concept-script.mdThe five-stop tour of Linda’s real Hub, recorded from her workspace, ending with a live /ship: the log entry, the commit, the push, and the continuation prompt on screen.
scripts/M6-hub-build-with-me-script.mdConcept
Six artifacts ago
Count what exists in your repo that did not exist six modules ago. A standing brief that makes every session start already knowing you (M2). Notes flowing in every evening and a brief flowing out every morning (M2, M5). A skill you have run on real work at least three times (M3). A specialist you designed and dispatched (M4). A routine that works while you sleep (M5).
None of those artifacts is impressive alone. A markdown file. A sixty-line spec. A two-sentence schedule. What is impressive is the slope: each one made the next one cheaper. The skill took an evening; the second skill took a third of that. The agent reused the anatomy from M1 and the meta-prompting loop from M3. The routine reused the agent. You were not collecting artifacts; you were compounding them.
If some of those artifacts are thinner than you’d like (the agent dispatched once, not three times; the routine you let lapse), the capstone will show you exactly which one to build this week. That is the point of showing your work: not to perform completion, but to find the gap.
That compounding has a name, and you have been living it since M2: your Hub gets faster at your domain. Not at writing in general or research in general. At your accounts, your voice, your weekly motions, your definition of done. A fresh chat starts from zero every time. Your Hub has not started from zero in a month. That gap widens every week you work in it, and it is the honest answer to “why not just use the chat app?” The system is the moat.
Conversations end. The system persists.
Here is the quiet test of whether you actually built a system: what survives when the conversation closes? Every session you have run since M1 ended the same way: the context window closed and everything in it evaporated. What survived is exactly what got written to a file and committed. The notes scribe filed survived. The skill you refined survived. The decision you made and did not write down did not survive, and you have probably already paid for one of those.
So the last habit the curriculum teaches is a closing ritual. At the end of a working session, you do four things: write down what the session did, commit, push, and print the prompt that starts the next session where this one stopped. Linda’s version is a skill called /ship. Yours ships in the BlueRock plugin: /bluerock:wrap-up, ready since you installed it.
The continuation prompt is the part to notice. It is markdown-is-memory run in reverse: instead of files feeding a session, the session distills itself into a few lines of file-ready text. The next session, maybe weeks from now, maybe on a different machine, picks up the thread because the thread was never in the conversation. It was in the repo.
Show your work
The capstone assignment is a presentation, and that is not ceremony. Explaining your Hub to another person is the only test that catches what the checklists miss. A success criterion can confirm the file exists. Only an audience asking “wait, why does the agent not send you the brief?” confirms you know why the system is shaped the way it is. If you can walk someone through one workflow, trigger to destination, and answer the why at each step, you own the system. If you find yourself saying “I’m not sure, the guide said to,” you found this week’s take-home.
The workflow you present is the one from your M5 pre-work: the one you now run without thinking. You already jotted three sentences about it: what runs, what it produces, what you stopped doing by hand. Call those three sentences your workflow statement; they are your opener. The third sentence is the demo. Nobody is impressed that an agent ran; everybody understands “I stopped writing follow-up emails from scratch.”
Beyond your Hub: the thread from M5
M5 left a question hanging: the day your agents stopped waiting for you, “what ran last night, and what did it touch?” became a real question. At the scale of one Hub, you already have the answer, because you built it. The tools line you can defend. The fallback that refuses to invent. The destination named in the spec. The manual fire before trust. The wrap ritual that leaves a trail. That is operational discipline for agentic work, and you now practice it without thinking about it.
At company scale the same question does not have a habit-sized answer. Hundreds of agents, schedules, and tool connections, run by people with varying discipline, touching systems that matter. Seeing what agentic systems actually do at runtime, and controlling it, is infrastructure work, and it is the world BlueRock builds in. You do not need that infrastructure for your Hub this week. But you should notice what just happened: you spent six modules learning, hands-on, why it has to exist. The builders who run agents are the ones who understand why agents need rails.
Worked example
Linda's Hub, toured
The artifact is Linda’s Hub itself, toured at system level, ending with a live close. You are not meant to copy it; you are meant to recognize it. Every stop on the tour is a scaled-up version of something already in your repo.
marketing-hub/ ├── CLAUDE.md # the standing brief ├── 01-strategy/ 02-devrel/ 03-content/ ... ├── .claude/commands/ # 40 skills ├── .claude/agents/ # the specialist bench └── memory/ # what the system has learned
1Stop 1: the root.
CLAUDE.md is the file you customized in M2, grown to carry a company’s positioning, terminology, and working conventions; every session in the repo starts already knowing all of it. The domain folders are organized by workstream, not by date, so agents can find things by meaning. Nothing at the root is a new concept. It is your M2 file after a year of real use..claude/commands/ ├── blog/ # writes a post the way Linda wants ├── reddit/ # drafts in the community manager's voice ├── ship/ # closes a session: log, commit, push, handoff └── ... 37 more
2Stop 2: the skills shelf.
/ship is one of those, and it is where the tour ends..claude/agents/ # researchers, reviewers, reactors memory/ ├── MEMORY.md # the index, one line per fact └── feedback_*.md # one file per learned fact
3Stop 3: the bench and the memory.
memory/ is the multi-layer memory you met in M4: one file per learned fact, indexed by a single MEMORY.md the way your notes are templated by _TEMPLATE.md. The system does not remember; the files do.> /ship sprint-log.md +1 entry (this session) git commit "M6 slice: capstone guide + page" git push origin · done ── continuation prompt → printed, ready for next session
4Stop 4: the live close.
/ship, and the session wraps itself on screen: the log gains an entry describing the session, the commit message is proposed and confirmed, the push lands, and the skill prints a continuation prompt — a few lines that will start the next session exactly here. Conversations end; the system persists. You just watched it happen.**Wait for my go-ahead before committing.** "Wrap up" starts the ritual; it is not yet permission to commit.
5Stop 5: the close, run as-is.
/bluerock:wrap-up — it is /ship at learner scale. You run this one as-is, not fork it: it powers your dashboard, so we keep its data format correct for you. Read the confirm gate closely: invoking the ritual is not authorizing the commit, the same rule your standing brief set in M2. And read the log shape: four lines, not a diary. A log entry longer than that is friction, and a ritual you skip on busy days is not a ritual.The whole seed, ready to read (and customize — that is the finish-early move below):
---
name: wrap-up
description: >-
End-of-session ritual: log what this session did, refresh my BlueRock
dashboard, then (with my go-ahead) commit, push, and hand me a continuation
prompt for next time. Use when I say "wrap up", "done for today", "end
session", "ship it", or "save my progress". Not for mid-session saves; only
when the session is actually ending.
---
Wrap up this working session. Conversations end; the work persists. Make sure
everything this session produced survives into the next one: my dashboard
refreshed, the story logged, and — once I say so — committed and ready to pick
back up.
## Steps, in order
### 0. Anchor to the Hub
Everything below reads and writes inside the builder's Hub — the repo they cloned from
the starter: `today.md`, `session-log.md`, the Hub's `.bluerock/runs.json`, and
`design/dashboard-data.js` — and `git` and the dashboard server both run from the Hub
root. In an SSH/cloud container the session usually starts in the **home folder**, with
the Hub one level down. The builder named it when they cloned (`maria-hub`, `alex-hub` —
don't assume a fixed name like `hub-starter`); identify it by its signature, not its
name. Confirm first: run `ls`. See `CLAUDE.md` and `design/` side by side? You're in the
Hub. If not, find it: `ls */CLAUDE.md`, then `ls ~/*/CLAUDE.md`, else
`find ~ -maxdepth 3 -path '*/design/dashboard.html'`. **`cd` into that folder and stay
there for the rest of the wrap-up**, and capture its absolute path with `pwd` so every
write below targets the full path (e.g. `/home/you/maria-hub/design/dashboard-data.js`).
Skipping this writes the dashboard and log to the home folder and runs `git` against the
wrong repo (or none). Can't find it? Ask the builder where they cloned their Hub before
wrapping up. (`session-metrics.py` below is the one exception — it's read via
`${CLAUDE_PLUGIN_ROOT}`, so it runs correctly from anywhere.)
### 1. Review the session
Look back over this conversation and identify what got done (finished things,
not attempts), which files were created or changed, any decision I made that
future sessions should know about, and what's unfinished. Don't ask me to
summarize — you were here.
### 2. Refresh my dashboard
Real numbers, not guesses. First read this session's tokens + time honestly from
the Claude Code transcript:
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/wrap-up/session-metrics.py"
```
(If it returns `{"ok": false}`, continue with zeros and note "metrics unavailable
this session.") Then:
- **Build this session's run atom(s)** — one per agentic run, contract shape:
`{ ts, sessionId, agent, target, outputFile, runTimeSec, success, tokens,
toolsCalled, filesRead, model, costUsd, guardrailEvents }`. Quantitative fields
from the script; qualitative (agent, target, output) from the session. `model`
= the canonical undated alias from the usage payload (e.g. `claude-sonnet-4-6`).
- **Append the atom(s) to the run history** — the Hub's own `.bluerock/runs.json`
(keep all atoms). Note this is the Hub-local `.bluerock/`, distinct from the home
`~/.bluerock/` workspace facts read below.
- **Tally today's priorities.** Read `today.md` and count Focus items: `set` (total),
`closed` (`[x]`), `carried` (`[>]`). Offer to check off anything I finished this
session that's still `[ ]`. This feeds the dashboard's "priorities set vs. closed."
- **Roll up the sections and overwrite the dashboard data file** so my dashboard
repaints — match the pinned contract exactly, all keys present:
`window.__BR_DASH__ = { meta, productivity, cost, actions, guardrail, perf, brag, priorities, runs }`
(write it to the starter's `design/dashboard-data.js`). The renderer just paints —
roll the sections up here, don't make the browser re-aggregate.
Provenance is a trust claim. Beta has **no BlueRock sensor pipeline**, so the label
is **"From your sessions,"** never "sensor-sourced." Specifically:
- `guardrail` = `{ wired: false, events: [] }`.
- `cost` only if a pricing table is present (tokens × price); otherwise zeros / placeholder — never a fabricated number under a trust label.
- `meta` (builder, workspace, region, trial) comes from the **workspace facts file** — the home `~/.bluerock/workspace.json` (Eng-provisioned, workspace-level; NOT the Hub's `.bluerock/`). Compute `meta.trialDaysLeft = trial_days − (today − provisioned_at)`; take `builder` / `workspace` / `region` from the same file. **If the file is absent, degrade honestly:** omit the trial countdown (neutral "Trial," no number), generic builder name — never scrape boot time or file timestamps for the provision date (the container suspends/resumes, so those are wrong).
- `meta.outputsSince` is **singular "you," single user (not a team)**; `count` = outputs this week from `runs[]` (not a last-visit anchor); 0/unknown → greeting only, no fabricated number.
- `priorities` = `{ set, closed, carried }` for this week, counted from `today.md` (the closure loop). Derived "from your sessions," not sensors.
- `actions` = `{ total, byAgent: [{ name, count, tone, timeMin }] }` — agent actions this week from `runs[]`, grouped by `agent`. `name` = the agent's name (required — labels the bar), `count` = its action total, `tone` = a stable palette key (`coral`/`plum`/`composer`/`sage`) for the bar (omit → defaults to coral; reuse the same tone per agent across weeks), `timeMin` = wall-clock minutes for that agent this week (from `runs[].runTimeSec`, rolled up). For a multi-agent **team** (e.g. Account Research = researcher + signal-scanner + composer), emit one entry for the team plus `members: [{ name, count, timeMin }]` (members sum to the team's `count` and `timeMin`); use the same team label in `runs[]` so it reads consistently across the Actions card and section 04.
- `perf` = `{ successRate, runs:{successful,total}, avgSessionMin, avgSessionDeltaMin, outputsShipped }` — the honest set only. **No** output-quality/reader-rating and **no** cache-hit rate (dropped — no honest source / operator metric). `success` is your judgment (a run that completed without error or guardrail block); `avgSessionMin` from `session-metrics.py`; delta is neutral (shorter ≠ better).
- `resume` chapter comes from curriculum progress, not the transcript.
The source of truth for the shape + renderer is the builder's own design — the
data contract (`design/dashboard-data-contract.md`) and `dashboard.html`. Target
that contract; do not invent or restyle the dashboard.
**Then open it for me — one step, no fuss.** The Hub runs in a cloud workspace, so
`file://` won't render `design/dashboard.html` (the file is on the container, not my
machine). Serve it and hand me a link instead. Do this now, and any time I say
**"open my dashboard"**:
```bash
(cd design && nohup python3 -m http.server 8137 >/tmp/br-dashboard.log 2>&1 &) ; echo "Dashboard → http://localhost:8137/dashboard.html"
```
Cursor auto-forwards the port — tell me to click the link (or the "port forwarded"
popup) and my dashboard opens in my browser. Works the same if I'm ever fully local.
If port 8137 is busy, pick another and tell me the URL. To stop it later:
`lsof -ti:8137 | xargs kill`.
### 3. Update the session log
Append an entry to `session-log.md` at the project root (create it with a one-line
title if it doesn't exist). Newest at the bottom, short — a trail, not a diary:
```markdown
## YYYY-MM-DD — [what this session was about, in a few words]
**Did:** [1-3 lines]
**Files:** [paths created or changed]
**Decided:** [only if a real decision was made; otherwise omit]
**Next:** [what the next session should pick up]
```
### 4. Show me what's about to be saved
Run `git status` and show me a plain summary: which files, new or changed, and a
proposed one-line commit message that says what the session accomplished (not
"updates"). **Wait for my go-ahead before committing.** "Wrap up" starts the
ritual; it is not yet permission to commit.
### 5. Commit and push (only after I confirm)
Once I confirm: stage the files, commit with the agreed message, push. If the
push fails (usually authentication), tell me plainly what happened and what to
click. Don't retry silently.
### 6. Hand me the continuation prompt
Last, print a short prompt I can paste into my next session:
```
I'm continuing work in my Hub.
Last session (YYYY-MM-DD): [one sentence: what got done]
Next up: [what to work on]
Read session-log.md for context.
```
That's the whole point of the ritual: the next session starts already knowing
what this one knew — and my dashboard already shows the work.
## Rules
- Never commit without my explicit go-ahead in this conversation.
- Never push anything that looks like a credential or a private key; flag it.
- If nothing changed this session, say so, still refresh the dashboard and log
the session if I want the record, and skip the git steps.
You build
Present one workflow
The audience does not need to be a room. Working self-paced: record a 3–5 minute screen walkthrough. Post it to the Builders community thread once you have community access, or simply watch it back yourself; hesitating on a why-question is the same signal a live audience gives you. In a cohort, or have a teammate or your manager handy: present live. Either way the format does not change: one workflow, live tooling, no slides. (If you want to tour your whole Hub the way Linda toured hers, do that afterward, for fun. The assignment is one workflow, done well.)
Your workflow statement, by example. The three sentences from your M5 pre-work, written down properly. For the default path: “Every evening I tell scribe what happened, and every weekday at 7am a routine dispatches daily-brew. By the time I sit down there is a morning brief committed to my repo, built from yesterday’s notes. I stopped reconstructing my week from memory and chat scrollback.”
/bluerock:wrap-up is the artifact.- 1Finalize your workflow statement. Three sentences, like the example above: what runs, what it produces, what you stopped doing by hand. The third sentence is the one that carries. Nobody is impressed that an agent ran; everybody understands what you stopped doing by hand.
- 2Walk the workflow live, trigger to destination. Say your workflow statement, then show it being true: fire the trigger (dispatch the agent, run the skill, or “Run now” the routine), and end at the destination — the real file, with today’s content in it. A few minutes, no rehearsal needed; the tooling does the talking.
- 3Collect the gaps. Live audience: notice which questions you cannot answer crisply, because those are your gaps, not theirs. Recording: watch it back once and notice where you hesitated. Same signal. Either way you walk away knowing the next thing your Hub needs.
- 4Close the session with
/bluerock:wrap-up. This is the artifact. Run it, read the proposed log entry, confirm the commit, watch the push land, and keep the continuation prompt it prints. Every module’s Your Turn leaves something durable committed to your repo; M6’s is your first session-log entry and the prompt that will start your next session. Today’s session is the first one that ends the way every session ends from now on.
You are done when
Checkmarks save in this browser onlyIf you finish early: ship one more skill of your own. You run /bluerock:wrap-up as-is — it feeds your dashboard, so don’t fork it — but build a fresh one in .claude/commands/: maybe a Monday planning skill, or one that preps tomorrow from today’s leftovers. It is skill number two, or three, and after M3 you know exactly how.
Use it for real
The 30-day commitment
/bluerock:wrap-up from now on: the ritual is the habit that keeps the other four honest.The bridge
Checkmarks save in this browser onlyThe meta-layer
How Linda does this
The capstone is the one module where the honest answer is: all ten patterns from How I work with AI are now operating in your Hub. The three that carry today:
The tour is this pattern, walked. The repo is the operating system; Cursor is the interface; Claude Code is the agent. Six modules ago that was a slogan. Today it is a thing you can present.
The wrap ritual is this pattern made into muscle. Decisions that are not written down do not exist; sessions that are not committed did not happen. The log, the commit, and the continuation prompt are the same idea at three timescales.
The advanced stop on the tour, deliberately not a Your Turn step. When your Hub grows enough domains that one standing brief gets noisy, rules can load per-folder; that is when this matters, and not before. File it under “the next thing your Hub needs,” for the 30-day list.
The program
Register as a Builder