Projects Open source · Claude Code plugin

genesis

A Claude Code plugin with three modes: build a project from an empty folder, bring an existing repository up to a stated standard, or audit the setup that loads in every session.

View on GitHub Three modes

Install

  1. /plugin marketplace add gabrieldabbah/genesis
  2. /plugin install genesis@genesis-marketplace

two lines, at the Claude Code prompt

What it is

Most scaffolders open with “which framework?” and hand you a folder of files. genesis opens with the problem, and picks the stack fourth — deriving it from the design instead of assuming it.

What keeps its three modes coherent is one document, the standard, that each of them measures against. It asks a repository two things in the first two lines of its manual: what it is, and who is exposed. The first decides which rules apply at all; the second, how much rigour they demand. Everything runs on your machine, on your own Claude subscription.

BrandCrafter, the brand-asset generator elsewhere in these projects, was built with genesis from an empty folder.

Three modes

You have an empty folder

create

Researches the problem, designs the architecture, derives a stack from it, plans the work, then builds and tests the project item by item.

  • The task list is a contract in both directions: genesis builds everything on it, and nothing that is not on it.
  • Anything that needs your accounts, keys, or money never interrupts the build — it accumulates as a deployment checklist waiting at the end.
  • The run checkpoints after every task, so a usage limit or a closed laptop costs the task in flight and nothing else.

You have a codebase already

transition

Brings an existing repository up to the same standard — removing what instructs the model’s conduct, keeping what states a property the code must have.

  • Much of an older agent manual was written to push a weaker model around: verify before claiming done, send a second agent to check the first, never leave a placeholder. Current models already do the first two and don’t do the third.
  • Not deleting the wrong thing is the harder half. Verification ritual is re-derivable from any document; the fact that one query silently truncates past a thousand rows exists in exactly one place.
  • genesis will not delete a line it cannot explain — and it checks what the file claims against the repository rather than taking it at face value.

You have neither

system

Reads the user-level configuration that loads into every Claude Code session, reports what it costs you, and proposes changes one at a time.

  • Every run opens with this check, because that layer loads in every session — a repository fixed underneath a stale one has the fix undone on the next turn.
  • It names the two worst offenders specifically: one hook that stops a turn from ending, another that stops a question from being asked. Install both and you have an agent that can neither stop nor ask.
  • Nothing in your home directory changes unless you say so.

The order is the point

genesis never starts with the framework. The stack is chosen in phase 4 — after the problem is understood and the architecture is designed — with the reasoning for every choice written into the project’s decision log.

  1. CaptureYour goal, in plain English.
  2. FoundationThe project manual, a docs skeleton, secret denials, the archive hook.
  3. ResearchThe domain and the candidate approaches, with sourced claims.
  4. ArchitectureThe design, written down before anything is installed.
  5. StackChosen here, derived from the design, rationale logged.
  6. PlanA dependency-ordered task list, each item with a way to prove it is done.
  7. BuildOne item at a time, running the project’s own test command after each.

Guardrails

Secrets are denied

.env files, SSH keys and cloud credential stores are blocked from Claude’s file-reading tool — and genesis checks the denial actually holds rather than trusting the config.

Pushing is yours

Committing, pushing, merging and deploying stop and ask, however autonomous the build has been up to that point. Creating accounts does too.

No OS sandbox by default

One strict enough to matter also blocks a package manager writing to its shared store, and a control that breaks ordinary work gets switched off — taking the useful protections with it. The network stays open for the same reason. A real sandbox gets set up when a project asks for one.

One hook, and it checks a fact

A hook may check a fact and report it. One that removes the ability to stop, or the ability to ask, does not ship — genesis used to have both and deleted them.

Services it wires in

Eleven services, one file each — domains, environment-variable names, CLI, docs and a security checklist, wired in when the design calls for them. Adding your own is a pull request, not a fork.

  • Stripe
  • Supabase
  • Vercel
  • Fly.io
  • Render
  • Clerk
  • Resend
  • Cloudflare R2
  • Sentry
  • OpenAI
  • Google Gemini

Three modes. One standard.

Every line genesis ships is read literally by a model on someone else’s machine, so the repository holds itself to what it asks of others: one gate, one command, run identically by hand and by CI.

Built with

  • Claude Code plugin
  • Markdown skills
  • Node.js hooks
  • YAML service registry
  • GitHub Actions
  • MIT license

Engineering

The standard is one file

All three modes measure against the same document, so they cannot drift into three different ideas of what good looks like.

skills/genesis/standard.md is the rubric; SKILL.md routes to create.md, transition.md or system.md, and each runbook cites the standard rather than restating it — one definition, three entry points.

A defect becomes a check

When something slips through, the fix is a check in the gate rather than a note to remember it next time.

One script runs seven categories: unit discovery, machine-readable parse, script syntax, hook inertness outside a build, relative-link resolution, README coverage to depth 2, and asserted properties — no agents directory, no prohibited emphasis vocabulary, every hook command quoting its path variables, every registry reference naming a file that exists.

Hooks check facts, not decisions

The one hook that ships watches for a build declaring itself done early. Outside a build it does nothing at all.

The Stop hook exits immediately unless .scratch/acceptance.json exists, which only a running build writes. CI exercises the block path as well as the inert path, so “it stays quiet” is tested rather than assumed.

Stopping is not losing

A usage limit, a closed laptop or a crash costs the task in flight and nothing else.

A checkpoint is written after every task; a relaunch that finds it re-enters at the resume phase and leaves the foundation, research, design and plan on disk rather than clobbering them. It deliberately makes no estimate of remaining plan allowance — no API exposes one, and a wrong guess stops a build that had room.

No agent roster

genesis defines no subagents and installs none. Whether an item is worth delegating is decided per item, and a second agent is never sent to check the first.

The knowledge a roster would have carried moved into the integrations references and the design skill, read at the moment it applies. The gate asserts no agents directory exists, so the roster cannot return by accident.

One file per service

Each registry entry is one YAML file carrying domains, env-key names (never values), CLI, docs and a security checklist, with an optional reference to a longer gotchas document — and the gate fails if that reference names a file that does not exist.

Have a dream project?

Tell me your idea and I’ll send you a quote.