Factory
Open source / public proof
Inspect proof

Open-source agent skill for Claude Code + Codex

Factory / run 001 / public specimen

Your agent can write code.Factory makes it earnthe word delivered.

Give Factory a ticket, a Sentry issue, or a rough request. It isolates the work, turns the ask into testable acceptance criteria, proves each milestone, and stops with receipts. When it cannot prove the change, it says exactly why.

Run the flow Inspect the skill
Isolated worktree
Consent stays explicit
Tests fail first
Then lose the fix and fail again
Fresh-context review
Milestones and whole branch
Executable gates
Claims answer to evidence
IntakeIsolateDiagnosePlanBuildProveStop

The actual run / nine gated phases

One ticket in. One verified draft PR out.

Factory advances one phase per fresh session. The gate closes the phase; the record—not the chat—decides what may happen next.

Run the ticket / interactive specimen

See where the run stops.

Illustrative sequence. No agent or code runs in this browser.

  1. 01

    Intake

    Phase 0 → 1

    Ticket → criteria → diagnosis

  2. 02

    Human plan

    Phase 2 → 2b

    NEEDS-YOU

  3. 03

    Build

    Phase 3 → 4

    Test: red → green → red

  4. 04

    Proof

    Phase 5 → 6

    Review → matrix → terminal gate

Ready

Ticket awaiting intakeStart the sequence to see the gates.

  1. 01

    Understand

    0 Intake / 0b Isolate / 1 Diagnose

    Turn a ticket into evidence, establish a clean baseline, and find the cause before proposing treatment.

  2. 02

    Decide

    2 Human plan / 2b Grill

    You approve the plan and close the question frontier. Unanswered blockers stop the run.

  3. 03

    Build

    3 Agent plan / 4 Milestones

    Preserve approved intent, write the failing test, implement one milestone, review, and commit.

  4. 04

    Prove

    5 Proof / 6 Stop

    Review the whole change, map every criterion to proof, then let the terminal gate name the outcome.

One phase per fresh session

Only state.json crosses sessions

Stops whenever a human is needed

Explore the complete run Screen map / PDF Print edition / A4

Runnable proof / not a product demo

Watch Factory reject a false delivery.

The redacted fixture preserves the failure shape that created the gate: five open blocking questions, two invalid statuses, and a delivery claim the record cannot support.

Recorded stateNot deliveredexit=1 · GATE: BLOCKED
5 unanswered2 invalid
terminalfactory gate
[false-delivery] exit=1
GATE: BLOCKED
  state.open_questions[0] is blocking and unanswered: '[redacted blocking question 1]'
  state.open_questions[1] is blocking and unanswered: '[redacted blocking question 2]'
  state.open_questions[2] is blocking and unanswered: '[redacted blocking question 3]'
  state.open_questions[3] is blocking and unanswered: '[redacted blocking question 4]'
  state.open_questions[4] is blocking and unanswered: '[redacted blocking question 5]'
  ac-matrix.md row 'AC-1' has status 'partly met'; allowed: met, unrunnable, failed
  ac-matrix.md row 'AC-2' has status 'partly met'; allowed: met, unrunnable, failed
  terminal 'delivered' needs every acceptance criterion met; use 'delivered-with-gaps' and name each gap and its owner

Why this verdict

  1. Five blocking questions have no recorded answer.
  2. Two acceptance criteria use the invalid status partly met.
  3. The requested delivered state is unsupported by the record.
What blocked means

The evidence is insufficient. Factory refuses to call the work delivered and names what is missing.

Receiptsproof manifestfixture statecomplete gate output
Inspect every receipt

One request / seven gates

No victory lap without proof.

Each gate changes what the run is allowed to claim. Coding is only one phase of delivery.

  1. 01

    Intake

    Separate the reported symptom from evidence. Write acceptance criteria that can fail.

  2. 02

    Isolate

    Create a clean branch and worktree. Measure the baseline where the work will run.

  3. 03

    Diagnose

    Reproduce the problem, name the cause, and keep the unknowns visible.

  4. 04

    Plan

    Write the human plan first. Close blocking questions before code begins.

  5. 05

    Build

    Add the end-to-end test before implementation. Review one milestone at a time.

  6. 06

    Prove

    Remove the fix and watch the test fail. Review callers and whole-change invariants.

  7. 07

    Stop

    Run the terminal gate. Report the one state the evidence actually permits.

Read the complete delivery contract

Scars turned into gates

Every hard rule has a body behind it.

These rules came from observed delivery failures, including a bypass in Factory’s own gate.

015 + 2

Five unanswered questions still looked green

A run reached delivered with five open questions and two criteria marked partly met. Factory now permits only met, unrunnable, or failed—and the terminal gate rejects unanswered blockers.

02red → green → red

The test failed alone and passed in the suite

A concurrency test never created the real interleaving inside its own file. Factory now runs the whole test file, removes the fix, and makes the proof fail again.

03blocked ≠ delivered

The gate trusted a contradictory terminal

The old gate could validate delivered against state already recorded as blocked. The committed regression preserves the bypass and proves the current refusal.

Inspect a full Factory run

The difference

Coding is one phase of delivery.

DecisionOrdinary coding agentFactory
Starting pointPromptSource evidence + testable criteria
WorkspaceCurrent checkoutIsolated worktree and branch
TestsRun after implementationFail, pass, remove fix, fail again
ReviewLatest diffMilestones + callers + invariants
FailureRetry or summarizeBounded loops + explicit blocked state
CompletionAgent says doneExecutable gate permits a claim
HandoffChat summaryMatrix, commits, receipts, gaps

Four honest endings

“Done” is too vague to ship.

A delivery system becomes trustworthy when it can distinguish success, accepted gaps, a real blocker, and the decision not to change code.

delivered

Every acceptance criterion is proven and the terminal gate passes.

delivered-with-gaps

Named checks could not run, and the user explicitly accepted those gaps.

blocked

A missing fact, decision, failed criterion, or exhausted loop prevents correct delivery.

intentionally-unchanged

Diagnosis shows that changing code is not the right treatment.

The argument

Your software factory needs the right to say “not delivered.”

More agents create more output. The durable advantage is a quality system that can refuse shipment and show another engineer exactly why.

Read the essay

For AI agents / install

Install Factory.
Start with consult.

Add the public Factory skill to Claude Code or Codex. Begin with consultfor a read-only CTO view, or give Factory a request to start a full delivery run.

Public source Project-local install checked 2026-09-28.

# Install the verified project-local skill for both agents
npx --yes skills add oleg-koval/factory -a claude-code -a codex -y

# Claude Code
/factory consult "Review this change request"

# Codex
$factory consult "Review this change request"

Consult answers in chat and does not write files. Start a full run with a ticket, Sentry URL, or plain-language request.

Already have a user-wide factory skill? Tell Codex: “Use .agents/skills/factory/SKILL.md specifically.”

Read the install and verification guide
OK

Built by Oleg Koval

Failures I no longer wanted to supervise twice.

Oleg is a lead engineer and fractional CTO with more than ten years of experience across fintech, e-commerce, mobility, automation, AI, and open source. Factory turns his operating principles—explicit contracts and observable failures—into an agent workflow.

More from Oleg

Your agent does not need a longer prompt.

It needs a delivery contract.

Watch Factory earn “delivered”