A small lifecycle for solo makers

Hatch

Keep the mess. Ship the good part.

Read the docs

01 / Boundaries

One project. Three honest places for work.

my-project/
├── hatch.toml
├── my-project-workbench/
├── my-project-product/
└── my-project-evals/
workbench / private

Drafts, experiments, notes, and the brief for what should move.

product / public-safe

The focused source repository you can share, version, and push.

evals / private

Human observations and automated evidence for one exact product commit.

02 / Commands

Only two commands to remember.

$hatch init

Start a project without turning your first day into repository housekeeping.

  1. Choose the project name and public Git identity.
  2. Create the container and three independent Git repositories.
  3. Write the workspace marker, private audit policy, version file, and changelog.
Use --dry-run to see the plan first. No remote, commit, or push.

$hatch promote

Move a selected piece of work across the public boundary without relying on a fresh prompt every time.

  1. Write and confirm a brief for what moves and what stays behind.
  2. Record the version, test the product, and commit the approved snapshot.
  3. Audit the exact commit, attach evidence, and check whether it is ready to push.
Reports READY TO PUSH, NOT READY, or NEEDS EVIDENCE. Never pushes alone.

03 / Promotion

Promotion is a small, repeatable decision.

01Brief the exact work.
02Confirm the public scope.
03Version and audit the commit.
04Connect evidence, then decide.

Start where you are

Make the product you want to show, without pretending the workbench is already clean.

Hatch keeps exploration private and makes every public snapshot explainable.

Start with Hatch