Why this matters
Pathway C is not a tour of flags. The standard was in the pathway card: a change in a repository that runs, not a screenshot of a chat. C1 through C10 were so you could sit down, plan, isolate, permit, and review. This module is that sitting-down.
Specialist rung. If you do not write software or run agents, you can stop after C4 and still have reached repo level.
You will ship a small app. Small means one job, one way to run it, tests or a check you can repeat. You will do the work in Grok Build. If you already know how to write the app by hand and you never open the TUI, you did not take the capstone. If Grok writes 40 files and you cannot run one command, you did not ship.
What you turn in is three objects: the plan you approved, the diffs (or commits) that implement it, and a retro that says what the agent did, what you refused, and what you would do differently on Monday.
Teach
What “ship” means here
Ship means:
- A new git repo you own. Not this LMS. Not a client app. Not a fork of a giant starter kit.
- The product runs on your machine with a command you document.
- Grok Build produced the implementation after you approved a plan.
- You can point at a diff and explain every path.
It does not mean a public deploy, a domain, a login system, or “full stack.” Those are how capstones go to die. If you already have a production idea, shrink it until the first version is a CLI or a single local page.
Suggested product (default): sitebrief — a small command-line tool. Input: a JSON file with site name, date, crew, and three hazards. Output: a printable brief on stdout (and optionally a .txt next to the input). One example fixture. One automated check (a test, or a script that greps the output for the site name). Language: whatever this machine already has (Node, Python, PowerShell). Do not spend the hour installing a runtime.
If your real job suggests a better tiny tool (CSV of GPS points → bounding box, a quiz grader that reads a key file, a rename list), use that. Same bounds: one command, one fixture, one check. Same submission shape.
Plan first
C3 still applies. In the new repo:
/plan
Then a brief that names the artifact, the run command, the fixture path, and the check. The agent explores and writes plan.md in the session directory (~/.grok/sessions/<encoded-cwd>/<session-id>/plan.md). It must not edit product files while plan mode is on — including under always-approve.
Read the plan in the preview. j/k to scroll. c to comment a line. s if the plan grew a web framework. a to approve (or approve with comments).
A plan that passes this capstone has:
- Context — who runs this, on what machine
- Approach — one, not four alternatives
- Paths — the files it will add
- Reuse — stdlib only unless you justify one dependency
- Verify — the exact commands you will run after implement
Copy or export that plan into the repo as SHIP_PLAN.md after approval so it lives next to the code. The session file can disappear. The submission cannot.
Build in the TUI, not around it
After approval, stay in the same session if you can. Ask mode. One job per prompt: scaffold, then fixture, then check, then README.
Use C8 if a piece is separable (explore to read your own half-written tree; a worktree if you want a risky rewrite you might throw away). Do not spawn a pyramid.
Use C7 only if the app truly needs an MCP server. Most capstones do not. A leftover practice-fs from C7 is fine; do not add Linear “for completeness.”
Use C9 grok -p for a check, not for the whole implementation:
grok -p "Run the project's check command. Do not edit. Report pass or fail with the command output." --output-format json --no-auto-update
Always-approve belongs on that one-shot if you have a deny list (C10), not on the TUI session that is still inventing files.
Diffs you can defend
Before you commit:
git status
git diff
Read every path. If Grok added .env, a second framework, or rewrote SHIP_PLAN.md to match the code it wished it had written, revert that part. Your name is on the commit.
Commit in small, boring slices if you want (feat: parse fixture, test: site name in output). Or one commit if the whole app is 80 lines. Either way the reviewer (you, or us) can git show.
/rewind will not save you from a bad write. git checkout -- and a clear “undo that file” prompt will.
Retro
A retro is not a compliment. Five headings, short:
- What I asked for — the job in one sentence
- What Grok Build did well — a specific edit or catch
- What I refused — a tool call, a path, always-approve, a dependency. If you refused nothing, you were not looking
- What I would change — brief, isolation, or a deny I should have added first
- How I know it runs — the command and the result
Write the retro yourself, or dictate it to Grok after the app runs and require it to use only facts you supply. A retro that invents a test run is a fail.
Bounds
- Time box: about 90 minutes of Grok time, not a weekend rewrite.
- No secrets. No real client names if they are sensitive. Fixture data is fake and obviously fake.
- No jailbreak, no “ignore deny,” no disabling managed policy.
- Do not open a PR against
RussellTechWebsite/learn.
Worked example
A learner on Windows, Node already installed.
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\src\sitebrief" | Out-Null
Set-Location "$env:USERPROFILE\src\sitebrief"
git init
grok from that folder. /plan, then:
Job: CLI sitebrief that reads a JSON fixture and prints a one-page tailboard.
Reader: a crew lead on a laptop, no browser.
Run: node src/sitebrief.js fixtures/example.json
Fixture fields: site, date, crew (array of names), hazards (exactly three strings).
Check: node src/sitebrief.js fixtures/example.json | findstr /C:"Hughes County Line"
(or a tiny test file that asserts the site name appears).
Constraints: no extra packages, no HTTP, no always-approve in this TUI session.
Stop: I can run the command and see the site name, the date, three numbered hazards.
Plan comes back with src/sitebrief.js, fixtures/example.json, README.md, maybe src/sitebrief.test.js. She comments out a proposed Express server. Approves.
Implementation: three prompts, three diffs, all read. She refuses a package.json that added chalk. Check command prints Hughes County Line. She copies plan.md to SHIP_PLAN.md, commits, writes RETRO.md with one refusal (the extra dependency) and the exact command output.
That packet — plan, diff, retro, plus a running command — is the capstone. A generated SaaS landing page is not.
Your turn
Do c11-l01-e1. New repo. Plan mode first. App runs. Packet is SHIP_PLAN.md, the diffs or commits, RETRO.md. Grok Build has to be on the critical path.
Common failure
Skipping the plan. You “already knew” the design. The agent invents a stack. You now own it. /plan is cheaper than revert.
Shipping the LMS or a tutorial dump. Forty files, none of them the job. Delete the repo and start with the default sitebrief bounds.
No refusal. The retro says “Grok did great.” Then the diff contains a token, a second app, or a deleted deny rule. Read the patch.
Headless-only implementation with always-approve and no deny list. Unattended generation of an app you never opened. Use the TUI in ask mode to build; use grok -p to verify.
Retro written before the command runs. You described a test you did not run. Run it. Paste the output.
What’s next
Pathway C ends when the app runs and the packet is honest. If you have a job that needs this on Monday, Pathway D (applied) is the tracks — education, field/GIS, business — not another installer. If you stay on Build, the daily habit is the same: plan when it is ambiguous, isolate writes you might throw away, ask mode at the desk, deny what must never run, review the diff, then ship.
