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 v2.3
open source · built for founders shipping with AI
apexyard
Ship AI-built software like a real engineering team — without hiring one.
ApexYard adds the reviews, guardrails, and process behind every change you make with Claude Code. Catch the mistakes before your customers do — automatically, without checking every commit yourself. 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
13
Production releases shipped (v0.1 → v2.3)
29
Technical decisions on record (released to main)
13
Bugs caught and fixed before users hit them
04 / 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.
05 / QUICKSTART
How do I get started?
From fork to first command. Everything is public; no invite needed. 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
06 / 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.
07 / 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/.
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.