01
Automatic code review
Every change you make — or that a contractor makes — gets reviewed by a senior-engineering-level reviewer before it ships. You see exactly what was caught and why, and decide what to do about it.
apexyard v4.0 — just shipped
open source · built for founders shipping with AI
apexyard
Ship AI-built software like a real engineering team — without hiring one.
ApexYard is the SDLC framework that makes AI agents ship production software — with the same gates, reviews, and receipts a real engineering org runs on. It governs its own development; check the log. See a day with it →
Built by me2resh
01 / WHAT YOU GET
What it actually does for you
No setup beyond /setup. No new dashboards to learn. Three things you start getting from day one.
02
Launch-readiness checks
Before you push to customers, run one command and find out what's still missing — security, performance, accessibility, the lot. No surprise emails from users telling you about it.
03
One place for all your products
Every project you're building shows up in one inbox. Pull requests that need a look, issues someone's stuck on, anything that needs your attention — all in one screen, no tab-juggling.
02 / WHO THIS IS FOR
Who this is for
Three shapes of person we built this for. If you recognise yourself, keep reading.
Solo founders shipping with AI
You're building the product alone, with Claude Code or Cursor doing most of the typing. You need the guardrails a real team would give you — without a real team.
Non-technical founders running contractors
You're managing a small dev team or a contractor or two. You need to know the work is solid before it goes live, without reading every commit yourself.
Small teams with no process yet
You've shipped your first version. Now you need real review, real testing, real release discipline — before things get harder to fix than they already are.
03 / PROOF
We use it on ourselves
ApexYard is built using ApexYard. These are real numbers from the framework's own GitHub history — every change you see here went through the same review and guardrails the tool installs in your fork.
175
PRs reviewed & merged · last 90 days
20
Production releases shipped (v0.1 → v3.2)
29
Technical decisions on record (released to main)
13
Bugs caught and fixed before users hit them
04 / THE PROOF MOMENT
A real merge, from the log
Not a mockup. This is PR #787 in ApexYard's own history — a change to the framework's own trust chain, replayed exactly as it happened. Every line below links to something you can check yourself.
apexyard · #787 · trust-chain change
$ gh pr merge 787 --squash
✗ BLOCKED: PR #787 has no recorded code-reviewer (Rex) approval.
role-triggers #777: diff touches the trust chain
(.claude/settings.json + a new PreToolUse hook) —
Security Auditor review required, regardless of author.
→ security-reviewer checks 512d253 ... APPROVED
settings.json diff: 55 → 56 hooks, zero removed or altered
new hook exits 0 on every path — cannot block or allow
no marker writes, no injection surface, no secret read
→ code-reviewer (Rex) checks 512d253 ... APPROVED
verified independently — fetched from upstream, ran the
test suite, shellcheck, and diff scope myself
→ me2resh approves PR #787 by name
a plan-level "go" doesn't count — this has to name the PR
$ gh pr merge 787 --squash
Check it yourself — the gate that blocked the first attempt, the hook the security review checked, and the PR itself, reviews and all.
05 / READ THE HOOKS YOURSELF
Rules shipped as code, not policy docs
These aren't guidelines an agent is asked to remember. Each one is a small script that runs at the moment it matters and refuses to let the risky thing happen. Four of them, named, with the actual source.
"No direct pushes to main."
An agent's shortcut push during a "quick fix" can't land: the hook blocks it before it reaches the branch, whether a human or an agent is holding the keyboard. Every change goes through a PR, zero exceptions for "just a typo."
.claude/hooks/block-main-push.sh ↗"A build agent cannot review its own work."
The agent that writes the code and the agent that reviews it run in separate contexts, so an author can't quietly approve its own PR. If a build agent tries to fake that separation by writing its own approval marker, this hook catches it before the merge gate ever sees it.
.claude/hooks/warn-review-marker-write.sh ↗"Plan-level 'go' is not merge approval."
Saying "go" to a six-step plan doesn't authorize the merge buried inside step four. Every merge needs a named human to look at that specific pull request and say so. That's exactly what you watched happen in the PR #787 replay above.
.claude/hooks/block-unreviewed-merge.sh ↗"Every significant decision gets a record."
Pick a library, a pattern, or an architecture without writing down why, and review flags it. Not busywork: the next engineer, human or agent, inherits the reasoning instead of just the code six months later.
.claude/hooks/require-agdr-for-arch-pr.sh ↗
06 / FOR THE TECHNICALLY CURIOUS
What one day looks like, in real terminal
If you'd rather skim the plain-English version, read how it works. The replay below is for the technical friend you'll show this to.
Inbox:
#58 · Add CSV export to reports · P1 · your-org/billing-api
Picking up #58...
✓ branch feature/GH-58-csv-export
Tech Lead role: planning
Plan for #58:
1. CsvExporter service (domain layer)
2. GET /reports/:id/export endpoint
3. 12 unit + 1 integration test
Approve plan? (y/n)
> y
Backend Engineer role: implementing
✓ src/domain/csv-exporter.ts
✓ src/handlers/export-report.handler.ts
✓ tests pass locally
Detected decision: papaparse vs csv-stringify
Decision recorded · chose csv-stringify (zero deps)
Local checks:
✓ lint ✓ types ✓ 147 tests ✓ 1.2mb build
Ready to push PR #84?
> y
Pushed · Opened PR #84 · feat(#58): add CSV export
Rex reviewing a3f9c21...
Architecture · PASS (domain clean)
Tests · 94% coverage
Decision log · linked
Glossary · 5 terms
Verdict · APPROVE - deferring to CEO
Waiting for CEO 👍
CEO 👍
✓ squashed as 8b2f4c1
✓ branch deleted
✓ #58 → QA state (not Done yet)
Pipeline on main:
✓ lint ✓ test ✓ build ✓ deploy-staging
QA Engineer role: verifying on staging
✓ AC1 · export button renders
✓ AC2 · CSV columns + escaping correct
✓ AC3 · 10k rows in <5s
✓ regression clean
QA sign-off: #58 ready for Done
Done · #58 · 14m 32s dev + 3m 10s QA
$
professional setup
→
gh repo fork me2resh/apexyard --clone
One command forks apexyard into your org and clones the fork locally. The fork is your ops repo — no nested installs, no symlinks. Want the plain-English version of what happens next? Read how it works. Want the technical setup? Jump to the quickstart.
Works with what you already use · TypeScript + AWS Lambda · Next.js web apps · Chrome extensions · native Swift macOS apps. The framework cares about review, gates, and process — not your stack.
Every pull request ties to a ticket.
Every ticket has acceptance criteria.
Code review validates against those criteria, and QA verifies the result in a separate pass before the ticket closes.
07 / QUICKSTART
How do I get started?
From fork to first command. Everything is public; no invite needed. This is the real path, not a highlight reel — three commands, three /setup questions, and you're wired into your first ticket. No separate install, no waitlist, no trial account. If you'd rather see a day with it before installing, read how it works first.
01 - star, fork, clone
Pull it to your machine
One command via the GitHub CLI. Rename to your-org/ops if you prefer - GitHub handles the rename cleanly. Adding upstream lets you sync later via /update.
gh repo fork me2resh/apexyard --clone cd apexyard git remote add upstream \ https://github.com/me2resh/apexyard.git
02 - claude, /setup
Open Claude Code and run /setup
Everything loads automatically from CLAUDE.md. On first run, a session-start hook checks upstream drift. Then run /setup once - three exchanges to configure company, team, and tech stack.
cd apexyard claude /setup # three questions → onboarding.yaml is configured
03 - bring a project in, or capture an idea
Adopt, or originate
Two entry points depending on what you walked in with. /handover takes an existing repo and generates an assessment of its shape, plus a starter architecture diagram, plus the registry entry. /idea captures a new product concept to the shared backlog so it doesn't evaporate.
/handover <repo-url> # existing project → assessment + registry + architecture stub /idea # new concept → ideas-backlog.md, optional GitHub issue
08 / WALKTHROUGHS
Three real situations, three real outcomes
Each walkthrough starts with a moment you'll recognise — and shows what apexyard does about it. Below the screens are technical captions for the friend who's vetting this with you.
01 - FEATURE idea to production
full SDLC
# "I have an idea. Ship it without forgetting a step." › /idea → /write-spec → /decide Idea captured · spec drafted · decision recorded › /start-ticket 178 (labels the session) # code, tests, push… › gh pr create auto-code-review.sh: "Rex REQUIRED before merge" › invoke Rex on PR #178 APPROVED at c8b736f · marker written › /approve-merge 178 (per-PR CEO nod) › gh pr merge 178 ✓ merged · #178 → QA state, not Done yet
From idea to live feature, with a real code review and a real launch sign-off in the middle. The reviewer is a senior-engineering-level AI agent (Rex) and the sign-off is yours — both have to happen before anything ships, and the framework refuses to merge until they do.
02 - PORTFOLIO 5 products, 1 inbox
cross-project
# "Monday. Where do I look first?" › cd ~/apexyard ApexYard: 3 commits behind upstream/main. Run /update to sync. › /inbox curios-dog · 2 PRs awaiting Rex billing-api · CEO approval pending · #203 sharppick · stale PR #89 (14 days) marketing-site · clear internal-tools · 1 P1 bug · unassigned # Friday afternoon… › /stakeholder-update weekly Drafted projects/updates/2026-04-17.md - rollup across all 5 projects
One screen for every project you're building. No tab-juggling, no five different GitHub repos. The same registry powers the Friday stakeholder update — generated from the actual week's activity, not from what you remember.
03 - TRUST risky change, 5pm Friday
migration gate
# "Just drop a column. Can't be that hard." › edit prisma/schema.prisma BLOCKED: database changes need a real plan first apexyard: rollback plan + tested first › /migration billing-api → rollback plan? (required, non-empty) → estimated downtime? → other services that read this? → data volume? → how will you know it worked? ✓ Decision recorded · ticket #214 created ✓ Plan is complete — edit allowed › /start-ticket #214 · retry the edit ✓ all checks pass · safe to proceed Rex: "analytics job reads this column every night — confirm it skips the missing column before you ship."
The "I forgot to think about rollback" mistake gets caught at 5pm on Friday instead of at 2am on Saturday. The framework refuses to let you touch the database until the plan is real — and the reviewer catches the downstream system you forgot about.
09 / WHAT'S IN THE BOX
What's in the toolbox
Section 01 told you what ApexYard does for you. This section is the inventory — the actual reviews, audits, ticketing, and portfolio surfaces you get when you fork it. Outcome on the left of each row, technical detail (counts, names, file paths) on the right.
reviews like a real team
Reviews from a full engineering team — without hiring one
The reviewer changes based on what you're working on. Touching auth code? A security reviewer takes a look. Touching the database? Someone who specialises in database changes walks you through the rollback plan. Behind the scenes: 20 role definitions across 5 departments, each with its own checklist and boundaries.
one prompt, one job
Tools for every step of shipping software
Want to adopt a project you've inherited? /handover. Want to capture an idea before it evaporates? /idea. Want to know what's waiting on you across every product? /inbox. Want a launch-readiness check before customers see it? /launch-check. 54 of these in total — each one is a focused workflow with safety rails.
guardrails that fire themselves
Guardrails that stop bad code from shipping — automatically
Every edit needs a real ticket behind it. Every database change needs a rollback plan. Every merge needs a real review. Secrets in code get caught before they're committed. Mechanically enforced — 32 small scripts that fire at the right moments, so you don't have to remember to check.
reviewers that don't rubber-stamp
A real code review on every change
The reviewer reads what changed and how the rest of the system reacts to it — not just the diff. It flags missing tests, surfaces decisions you made silently, and refuses to approve work that bypasses the team's standards. Pushing new code invalidates the previous approval, so nothing slips through after the review is done. Powered by 24 specialised reviewer agents under the hood.
one inbox across everything
Every product, one screen
Run /inbox and see every pull request waiting on you, every issue stuck, every comment unanswered — across every product you're building. Run /stakeholder-update weekly on Friday and the rollup writes itself from the actual week's activity. Backed by a one-file registry at your fork root; add a project with /handover, sync the framework with /update.
ready-made CI
CI pipelines that just work
Seven ready-made GitHub Actions pipelines you can drop into any project — code quality, security scans, dependency audits, PR-title and review checks, SEO checks. No starting from scratch, no copy-pasting from someone else's repo. Lives at golden-paths/pipelines/.
10 / PROFESSIONAL SETUP & SUPPORT
Free forever. Or set up for you.
The framework itself is MIT, forever: fork it, run it, change anything, never pay a cent. What's not free is the premium cockpit and the self-hosted Box, plus having me personally wire either one into your repos instead of doing it yourself.
Setup · one time
from £499
Solo band, up to 3 clean repos. Growth teams (more repos, messier history) start from £999, quoted by the /handover harnessability assessment. Not a guess.
Running · per product
£99/mo
Updates, new skills and hooks as they ship, and direct support. Billed per product, not per repo: a monorepo and a 5-service product cost the same.
Founding Access is onboarded personally. Every install gets me on the call, and founding customers keep their rate for life, even after the price goes up for everyone else.
Runs on your laptop or a £5/mo VPS in your own cloud, one command. You bring your own Claude subscription: we never see your code, and we never see your bill.
No checkout link anywhere in this page. Every engagement starts as an email, scoped and quoted to what you're actually bringing, not a fixed shelf price.
Ship one, add the badge
Once your repo runs under ApexYard's gates, tell people. Drop this in your README: it links straight to the framework so anyone who clicks can see exactly what "governed" means here.
[](https://github.com/me2resh/apexyard)
Ship like you finally
have the team.
Fork it, run /setup, start your first day. Free and open source — fork freely, change anything to match how you work. No SaaS, no monthly fee, no lock-in.
New here? Play You vs. the LLM — a fast, fun game on how AI actually works: tokens, embeddings, RAG, prompt injection, the agent loop. Think you can beat it? Score it, share it.