xAI's Grok Build Workshop Repo: Inside the Ledgerly Demo App

xAI's GitHub organization has published customer-education-workshops, an Apache-2.0 repository of "public demos for customer education workshops." Its first and so far only app, Ledgerly, is a fictional billing dashboard seeded with intentional bugs and wired with agents, skills and rules, built to teach Grok Build in three tracks: 101, 201 and 301. The repo had zero stars when we looked, but it is useful as a window into how xAI teaches teams to work with coding agents.

This guide covers what is in the repository, how to run it, what each track teaches, and where it fits with our earlier coverage of Grok Build going open source and the Grok Build budget controls.

Quick answers

What is in the repo

According to the repository README, each top-level folder is a standalone app. Demos do not share lockfiles or UI. The root also carries standard hygiene files: a gitleaks config, a pre-commit config, a security policy, an AGENTS.md, and .cursor/rules for the repo itself.

The Ledgerly README describes the app as "fictional B2B billing ops," operated by a made-up user, with a catalog of Starter at $49, Growth at $99 and Scale at $249. Pages are Dashboard, Invoices, Collections, Disputes and Settings. Prices and customer names come only from three source files, which matters because several prompts instruct the agent to cite them.

Under .cursor/agents/ there are five subagents: a read-only reviewer, an API instrumenter that handles one route per parallel worker, a dispute verifier, a change reviewer that inspects diffs but is told not to edit, and a preflight checker that reports whether a track's dependencies are ready. Under .cursor/skills/ there are skills to start the app, stage Linear issues, choose a workflow, dispatch subagents, hand work to a cloud agent, and reset demo state. A disk plugin, standard-bug-fix, pulls one Linear issue and fixes only that bug. The README also lists built-in skills called autopilot (a PR-to-merge-ready skill formerly named babysit) and automate (drafts a scheduled or event-triggered Grok Build automation).

How to run it

The README says Node 20 and nothing else global. From the ledgerly folder:

npm i
npx prisma generate
npx prisma db seed
npm run dev

Open http://localhost:43173. If the port is busy, stop the old dev server; if the dashboard is empty, run npm run db:reset. For demos, npm run demo:reset restores state, and an agent can run the start-ledgerly skill, which starts the app, seeds only when the database is missing or empty, and opens a runbook page in a canvas.

On a clean tree npm test should show 1 failed and 32 passed. That is by design.

The planted bugs

The repo is unusual because it ships broken code on purpose, and says so:

• Suggested credit. A test in tests/suggested-credit-api.test.ts fails because the library still calls the deprecated v1 suggested-credit endpoint. The UI shows $400 for one dispute while v2 and the stored credit cap at the $249 Scale price. The README tells presenters not to edit the test, the routes or the seed to make the suite green.
• Filter pills. Status pills on Invoices and Disputes write state= while the pages read status, so clicking a filter does nothing. It is described as a separate UI bug, not a second red test.
• Keyboard trap. A plan file tells a task to add a document-level keydown listener that blocks the Tab key everywhere. The README says a change reviewer should flag it as high severity and that it must never ship outside demos.
• Accessibility. npm run test:a11y checks WCAG items such as 4.5:1 text contrast and missing labels. It currently fails on contrast for status badges and some muted text.

These are good teaching devices because each tests a different agent skill: finding a root cause through an API-version mismatch, noticing a silent mismatch between a writer and a reader, and having a reviewer agent catch a harmful instruction hidden in a plan.

What the three tracks teach

101 covers the basics: Ask, Plan and Build in Agent mode, debugging, checking models, a run-mode allowlist, verifying a feature, redacting, stopping and steering an agent, reviewing diffs and restoring from a checkpoint. It also introduces governing an agent by writing and testing a rule and a skill, using a canvas, and connecting MCP such as Figma.

201 covers context and scale: renaming agents, checking each agent's context window, asking across chats, creating a personal skill and promoting it to the project, connecting Linear through MCP with an allowlist, adding the local standard-bug-fix plugin, and parallelizing work with subagents and a multitask command.

301 covers orchestration: building an accessibility reviewer subagent, pointing it at a faster, cheaper model, optionally moving to a cloud agent, going from plan to code and consolidating into a pull request, scaling review with a change-reviewer subagent and optional automated review, and "sharing ownership safely" by turning findings into rules, skills, tests, subagents or a person.

What this tells us about Grok Build

The curriculum is a useful read of what xAI considers essential for teams: guardrails (rules and allowlists) come before parallelism, review is a first-class step, and external tools are connected through MCP with explicit allowlists. The repo also leans on workflow features familiar from other coding agents, such as subagents, skills, rules and plugins. For comparison, see our guide to what an agent harness is and the agent harness tier list reaction, plus xAI's Grok Build cross-session memory.

The starter prompts, and why they are written that way

The README includes copy-paste prompts for presenters, and the wording is instructive for anyone writing prompts for a coding agent. The first Ask prompt requires the agent to cite three named files for prices and overdue invoices, which makes hallucinated answers easy to spot. The dispute-flow prompt asks what is intentionally unfinished and says "do not edit any files," which keeps the agent in read-only mode. The suggested-credit prompt tells the agent to diagnose first, switch from v1 to v2, preserve both routes and the existing test, and verify the page shows $249 from v2.

The design prompt is the most constrained: restyle four dashboard cards using only existing design tokens, no new hex colors, no layout rewrite, no price changes, two files at most, nothing under lib/ or tests/, and show the diff because the presenter will undo it. That is a good template for any task where an agent might sprawl. State the allowed files, the forbidden areas, the invariants, and the review step.

Another prompt asks the agent to create a project rule after the fact, so that future code never calls the deprecated endpoint and must use the v2 route, and to show the file before keeping it. This pairs a fix with a guardrail, the same "shift findings into a rule, skill, test, subagent, or a person" idea that the 301 track ends on.

A self-check list for any agent demo repo

If you build your own version, the Ledgerly structure suggests a checklist:

1. Freeze the clock and use synthetic data so results are reproducible and nothing sensitive leaks.
2. Plant a failing test whose cause is a configuration or version mismatch, not a typo, and forbid editing the test.
3. Plant a silent mismatch between two layers, such as a writer and a reader using different parameter names, so the agent has to read code beyond the failing test.
4. Include one hazardous instruction in a plan file and check that a reviewer agent flags it.
5. Provide a reset command and a preflight checker so every run starts from the same state.
6. Keep the runbook in one file, with a way to jump between tracks.

These steps make the demo teach judgment as well as tool use. They also make the repo a reasonable informal evaluation: run two agents through the same track and compare the diffs, the tests they leave red, and whether they respected the forbidden files.

Caveats

• It is training material, not a product. There is no release, package or benchmark. The demos assume a Grok Build environment, and some beats rely on Cursor-style canvas features and a Linear workspace.
• No contributions. The README says external contributions are not accepted.
• Security. The planted Tab-key trap and fake data are harmless, but any agent that edits the repo should run in a sandbox. See our analysis of Grok Build repository upload and secrets before pointing an agent at private code.
• Single source. We read the README and folder listing; we did not run the app.

How to use it for your own team

Even if you don't use Grok Build, the pattern is portable. Fork the repo, replace the agent commands with your own harness, and keep the planted-bug structure: one failing test with a clear root cause, one silent UI mismatch, and one risky instruction a reviewer should catch. Then measure how long a new teammate takes to find each one with and without an agent. That gives you a small, repeatable evaluation for any coding agent you are considering.

Related reading

• Grok Build goes open source
• Grok Build agent budget controls
• Grok Build cross-session memory
• Grok Build repository upload and secrets
• What is an agent harness?
• Agent harness tier list

Details are accurate as of October 29, 2026; the repository may change.