An open-source project kit for git and Claude Code

Every project leaves a stone for the next one.

Morrowcairn is what a new project starts with: record templates, patterns with the safeguard built in, leak checks that refuse, and working rules for Claude Code sessions. One person built it while directing a crew of sessions, so each new project would start with what the last one learned.

See what's in it Get it
  • MIT-0
  • Release v0.8.0
  • Since July 2026
  • Runs on Linux

mor·row·cairn

/ˈmɒr.oʊ.kɛərn/ · noun

  1. A pile of stones raised by someone who walked the path, to mark the way for whoever walks it tomorrow.
  2. A kit that hands each new project what the last one learned, at the moment it applies.

Why it exists

Lessons written down get missed at the moment they matter.

“Most ‘lessons learned’ documents fail the same way: the knowledge is written down, and then the next person — or the next agent — writes the bug anyway.”

From the kit's README

The case that started it

  1. 01

    Half the machinery

    A sibling project took part of the record-keeping. It kept a decisions log and never started an incident log.

  2. 02

    Months later

    Turning its experience into rules needed exactly the incident history it had never kept.

  3. 03

    Not recoverable

    The record was never made, so it couldn't be rebuilt. The gap had become a shape the process adapted to.

“The machinery is cheap at commit one and expensive at month six.”

So the kit delivers each lesson when it applies: starting points with the safeguard already built in, checks that refuse, and rules loaded into every session.

Who it's built for

One person, directing a crew of Claude Code sessions.

  • You decide

    Purpose, priorities and the calls only you can make. Each one goes into the decisions log with its reasons.

  • Sessions do the work

    From written briefs, every session running the same rules, loaded from the same release.

  • The record carries it forward

    Decisions, incidents and follow-ups land in append-only logs, so the next session, or the next project, starts from what's known.

That's the setup it was built in. If yours looks like it, take what helps.

What a project starts with

Five stones, stacked.

Top to bottom, the way it stands: the rules sessions load on top, the record everything rests on underneath.

  1. Stone 5 · capstone

    Session rules

    Four rule files Claude Code loads from the installed release. Two in every session: working from a brief, and running shell commands. Two when a task calls for them: test a gate with an input it must refuse before changing it, never reshape a command to get past a permission rule, and take record timestamps from the clock.

  2. Stone 4 · CI on the remote

    Checks

    Once a project has a remote, CI scans again where the code lands: the whole tree for credential shapes, plus a marker scan that names no one. It runs even when a local hook was skipped. Your identity list stays on your machine: CI only ever gets terms that identify no one.

  3. Stone 3 · commit and push hooks

    Guards

    Every commit is scanned for credentials, and every push for credentials and your own identity terms: in files, in binaries, and in commit and tag metadata. The first commit waits for the stakes frame. When a hook can't run its checks, it refuses.

  4. Stone 2 · starting points

    Patterns

    Copy-paste starting points with the safeguard already built in, each naming the failure it prevents.

    • dry-run gated runner
    • atomic deploy
    • counted-skip loader
    • repo genesis
    • local spawn
    • local upgrade
    • numbered relays

  5. Stone 1 · foundation

    Records

    Four logs, numbered and append-only: decisions with their reasons and the alternatives that lost; incidents with how each fix was verified; a follow-up queue sorted by what happens if an item never gets done; and kit feedback, written at the moment of friction. Corrections are dated notes, never quiet edits.

Day one

Before the first commit, a project answers four questions.

The answers set how careful everything after them has to be. The first commit is refused while they're blank, and the last question names the change that means it's time to answer again.

The stakes frame

  1. 1Who acts on this project's outputs: no one yet, one person, or many?
  2. 2What does a wrong output cost once it has been acted on?
  3. 3How long until anyone would notice it was wrong?
  4. 4What change would make this frame wrong (a first outside user, a first remote, money acted on for the first time)?

How it runs

Pinned, not copied.

Through v0.7.0 the kit was copied into every project, and the copies drifted apart. Since v0.8.0, each release installs once and each project points at the one it runs.

  1. 1

    One install per release

    Each release installs once per machine, read-only. If the install is edited, every commit and push stops.

  2. 2

    Each project pins one

    A small kit.pin file names the release and the hash of its file list. Before every commit and push, two stub hooks check the install file by file, then run that release's hooks.

  3. 3

    Rules load per machine

    Session rules load in every session from the one release your machine's setup names, whatever release a project pins. A project's pin picks code, never rules.

~/.local/share/morrowcairn/releases/
└── v0.8.0/          read-only, every file hashed

your-project/
├── kit.pin          v0.8.0 + manifest hash
└── hooks            stub → check install
                          → run v0.8.0 hooks

every session        machine setup → v0.8.0 rules
Illustration. The install root can be moved with KIT_INSTALL_ROOT.

The trail · July to October 2026

Every project adds a stone.

Projects file kit feedback at the moment something chafes. When there's enough of it, it becomes the next release.

  1. v0.1.0Jul 21

    Records machinery, patterns and two-layer leak detection. A first project was made from it within minutes.

  2. v0.1.1Jul 21

    A credential canary, so both scanners are proven to fire.

  3. v0.2.0Sep 23

    Hooks fail closed. A push scans exactly the commits it adds. Checks on a project's first commit.

  4. v0.2.1Sep 25

    Hook tests travel with each project. A file manifest and an upgrade pattern.

  5. v0.3.0Sep 26

    An upgrade stops on a kit file a project deleted that the kit has since changed.

  6. v0.4.0Sep 26

    Reviewed, metadata-free images can be pushed. Projects can add their own hook checks.

  7. v0.4.1Sep 27

    A patch: upgrade-test fixes, and a note that binaries are checked at push.

  8. v0.5.0Sep 29

    Reviewed, structurally plain MP4 and WebM video can be pushed.

  9. v0.6.0Oct 2

    Identity terms refused in commit and tag metadata. The first session rules.

  10. v0.7.0Oct 4

    The identity list is read as data, never run.

  11. v0.8.0Oct 7

    One read-only install per release, pinned by each project. Session rules load once per machine.

Before you clone

Built for one setup. Here's what yours needs.

Morrowcairn runs today on Linux. Mac and Windows support is being built now and tested on GitHub's own Mac and Windows machines. In the spirit of the stakes frame, here's what it assumes.

  • Linux, for now Mac · Windows in progress

    The hooks, the installer and the test suites pass on Linux. On a stock Mac the installer still stops early, and on Windows the scripts' line endings and some tests are being fixed. This page will say when each one passes.

  • bash 4+, git 2.31+, Python 3.7+, gitleaks

    gitleaks has to be on your PATH. Without it, the hooks refuse.

  • Your own identity list

    Each clone keeps its own list of terms that must never leave it. Pushes refuse until it exists.

  • For CI: GitHub and one secret

    The workflows run on GitHub and read a LEAK_PATTERN repository secret holding only terms that identify no one.

  • Session rules, wired in once

    They load through your user-level Claude Code setup. Tested on Claude Code 2.1.289 and 2.1.290; later versions may load them differently. A setup guide comes with the public release.

  • What it won't catch

    Hooks run per clone, and git's --no-verify skips them. CI still scans for credentials, but identity terms are checked only by the local hook. File names, and text a later commit removed, aren't scanned for identity terms. Treat the checks as a net, not a guarantee.

Open source

Take what helps.

Morrowcairn is licensed MIT-0. Use it, change it and ship it inside anything you like. No credit is required, though if it helped, a mention of Morrowcairn is appreciated.

It's built for one person's projects first and offered as is, with no warranty of any kind: not that it works, not that it fits your use, and not that it infringes no one's rights. You use it at your own risk.

A plain-language summary. The LICENSE file governs.

The repository opens with the first public release.

The kit is being readied for anyone's machine first: Mac and Windows support, a setup guide, and a fresh public copy. The link goes here when it's live.

MIT-0 · no account needed to read it