Skip to main content

Next steps

You built a harness for a fictional bank. The question now is how much of it your own repository needs, and in what order. The short answer: all of the layers, in roughly the order of the labs, starting with the measurement.

Taking this to your own repo​

Larkspur's specifics don't transfer. Its invariants, its protected paths and its eight tasks are Larkspur's. The method transfers completely:

  1. Measure before you change anything.
  2. Write down what the senior engineers carry in their heads.
  3. Enforce the few things that must never happen.
  4. Measure again, and look for what got worse.

The files transfer as templates. Copy the shape of harness-reference/ from the companion repo, not its contents.

The order to do it in​

Each step is useful on its own, and each makes the next one cheaper. Don't skip to hooks. A hook for an invariant nobody has written down is a hook nobody can maintain.

StepWhat you doTime for a typical serviceLab
1Run /readiness-report. Note the level and the top failing criteria.15 minLab 0
2Pick five to eight tasks from your real backlog, each with an automatic check. Include one task where the right answer is to stop. Run them three times each. That's your baseline.Half a dayLab 0
3Sit with your most senior engineer for an hour. Write down the invariants, the protected paths and the things that are "obviously" never done.1 hourLab 2
4Write AGENTS.md: commands, layout, invariants that name helpers, a never-list, when to stop, how to verify. Re-run the baseline.2 hoursLab 2
5Set sessionDefaultSettings.autonomyLevel and write permission rules, with tests, for the commands that must need a human or never run. Check them with droid rules check.1–2 hoursLab 4
6Add hooks for your protected paths: a PreToolUse guard and a Stop check on the outcome. Try to break them.Half a dayLab 5
7Add a CI check that fails a pull request with an unapproved protected-path change.2 hoursLab 9
8Only now: skills for your recurring procedures, a read-only reviewer droid, MCP for the facts Droid keeps guessing.OngoingLabs 6–8
9Missions, once the readiness report says Level 4 or higher, or once you've decided consciously why it's fine not to be.When readyLab 10

Spec mode (Lab 3) is a habit, not a step. Start using it on day one for anything near a protected path.

The times are guesses for a single well-tested service. Step 3 is the one teams underestimate. The invariants are rarely written down anywhere, and the conversation that finds them is worth having even if you never use an agent.

Keep the baseline honest

Your first scoreboard will have tasks that are too easy and a check or two that is wrong. Fix the checks before you celebrate the numbers. When a task passes every run for two weeks, replace it with a harder one. Lab 10's advice applies to you too: a perfect score means it's time to write the next task.

Thirty repositories: the plugin path​

Dana's real job isn't one repository. It's thirty. Copying .factory/ into each one works for a month, then thirty copies drift apart.

A plugin packages the parts of the harness that are the same everywhere. Factory's plugin format bundles:

ComponentPath in the plugin
Skillsskills/<name>/SKILL.md
Slash commandscommands/<name>.md
Custom droidsdroids/<name>.md
Hookshooks/hooks.json plus the scripts
MCP serversmcp.json
Output stylesoutput-styles/<name>.md

A native plugin has a .factory-plugin/ directory holding plugin.json. The docs say Droid doesn't require or read the fields in that file: a plugin's identity comes from its marketplace entry. Keep the component folders at the plugin root, not inside .factory-plugin/. Hook commands in a plugin refer to their scripts with ${DROID_PLUGIN_ROOT}, so they work wherever the plugin is installed.

installing a plugin
droid plugin marketplace add https://github.com/your-org/droid-plugins
droid plugin install payments-harness@droid-plugins --scope project

marketplace add accepts owner/repo, a GitHub URL, a Git URL or a local path, and you can follow a branch or tag with #<ref> or pin an exact commit with @<40-character-sha>. For a regulated team, pin. A harness that changes under a repository without a pull request is a harness Model Risk can't sign. A pin becomes part of the registered marketplace name (your-org/droid-plugins#v1.2.0 registers as droid-plugins@v1.2.0), so run droid plugin marketplace list and use the name it prints in plugin install. Teams distribute plugins with the extraKnownMarketplaces and enabledPlugins settings keys, and an organization can limit marketplace sources to an approved list with strictKnownMarketplaces in managed settings. There is no droid plugin enable command.

What goes in the plugin, and what stays in each repo​

Shared, in the pluginPer repo, in .factory/
The hook scripts, parameterized by a list of protected pathsThe list of protected paths for this repo
The money-change and flaky-test-triage skills, if every repo handles money the same wayAGENTS.md: this repo's commands, layout and invariants
The money-reviewer droidPermission rules and autonomy defaults (they live in settings.json; the plugin format doesn't bundle settings, and the docs say plugins are not a source for permission rules)
The change-control MCP serverAnything specific to one codebase's history

Permission rules that must hold in every repository belong one level higher, in organization settings through Enterprise Controls. Org rules claim their IDs before project and user rules do.

Read Factory's plugin docs before you build one. To test a plugin locally, wrap it in a marketplace (.factory-plugin/marketplace.json) and add the marketplace from a local path.

What Factory Academy would teach next​

This workshop is the first on the platform track. The Academy blueprint sketches three tracks, each for a different reader.

TrackForWhat it would cover
DevelopersEngineers delegating their own workDelegating well, reading a session, Spec mode as a daily habit, reviewing agent diffs, knowing when to stop and do it yourself
PlatformThe people who build the harness (this workshop)Readiness, AGENTS.md, rules, hooks, skills, droids, MCP, CI, Missions, and the next workshop: shipping a harness to many repos as plugins
Engineering leadersThe people who sponsor it and answer for itWhat to measure, what a control is, how to present agent use to risk and audit, and what a credible throughput number looks like

These are proposals. The blueprint explains how each workshop would be built from the same template as this one, and the authoring kit is that template.