01
Automatic code review
A reviewer checks each change before it can ship. The review covers the changed code and its system impact. You see exactly what was caught and why, and decide what to do about it.
apexyard v5.6.3 — just shipped
open source · built for founders shipping with AI
apexyard
Use AI coding agents with a controlled engineering process.
ApexYard is an SDLC framework for AI-assisted software development. It adds gates, reviews, and records to each change. It governs its own development; check the log. See a day with it →
Built by me2resh
01 / WHAT YOU GET
What ApexYard does
Run /setup once. No new dashboard is required. You get three controls from the first day.
The v5.6 release line adds framework-level adapter defaults for Codex, OpenCode, Pi, and Cursor. v5.6.3 adds centralized hook dispatch, stricter Rex review validation, and migration coverage.
02
Launch-readiness checks
Before release, run one command to check security, performance, accessibility, monitoring, and documentation. Find missing work before users report it.
03
One view for all your products
One inbox lists each project you manage. Pull requests that need review, blocked issues, and other actions appear in one screen.
02 / WHO THIS IS FOR
Who can use ApexYard
ApexYard supports three common team types. Read the section that matches your work.
Solo founders shipping with AI
You are building the product alone, with Claude Code, Codex, OpenCode, Pi, or Cursor doing most of the typing. You need the controls that a larger engineering team would provide.
Non-technical founders running contractors
You are 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 have 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.
304
PRs reviewed & merged · last 90 days
36
Releases shipped (v0.1.0 → v5.6.3)
144
Technical decisions on record (released to main)
8 / 48 / 21
Features / fixes / improvements in v5.5.0
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" does not 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 are not 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" cannot 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 cannot 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 does not authorize the merge buried inside step four. Every merge needs a named human to look at that specific pull request and say so. That is 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
Read how it works for the short explanation. Use this replay when you need to inspect the commands, checks, and evidence behind one governed change.
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?
Start with a fork and one project. Run /setup, answer its three questions, and create the first governed ticket. No separate service or account is required. Read how it works first if you want to see the complete daily loop.
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
Choose the entry point that matches your project. /handover records the shape of an existing repository and adds it to the registry. /idea records a new product concept and keeps it available for later planning.
/handover <repo-url> # existing project → assessment + registry + architecture stub /idea # new concept → ideas-backlog.md, optional GitHub issue
And when apexyard ships a new version, you do not fall behind for having forked it. A session-start check flags the moment you are behind upstream/main — so you never have to remember to look — and /update does the sync for you: it previews the incoming diff, merges it on a dedicated sync branch instead of hand-patching your main, then walks you through each release's migrations in order. Staying current is one governed command, not a merge weekend.
08 / WALKTHROUGHS
Three real situations, three real outcomes
Each walkthrough starts with a common delivery problem. It then shows the command, the control that runs, and the evidence that remains. Use the captions to check the technical path.
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
The framework carries one change from idea to release. Rex reviews the code, you approve the release, and the merge gate checks both records before the change can ship.
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
The portfolio view combines every managed project. The same registry powers the stakeholder update from recorded activity, so the report does not depend on memory.
03 - TRUST risky change, 5pm Friday
migration gate
# "Just drop a column. Cannot 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."
A database change stops until its plan and rollback path are recorded. The review also checks the systems that depend on the database.
09 / WHAT IS IN THE BOX
What is in the toolbox
Section 01 explains the result. This section explains the controls that produce it. Each row names one control, the problem it prevents, and the part of the framework that enforces it.
reviews like a real team
Reviews from specialised engineering roles
The review role follows the change. A security-sensitive change gets a security review. A data change gets a review of migration and rollback risk. Each role has a defined scope and checklist.
one prompt, one job
Tools for every step of shipping software
Want to adopt a project you have inherited? /handover. Want to capture an idea before it evaporates? /idea. Want to know what is waiting on you across every product? /inbox. Want a launch-readiness check before customers see it? /launch-check. 66 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 must have a ticket. Every database change must have a rollback plan. Every merge must have a review. Secrets in code get caught before they are committed. Mechanically enforced — 60 small scripts that fire at the right moments, so you do not have to remember to check.
reviewers that do not 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 23 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 are 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 is 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. Get in touch and we'll scope it to what you are actually bringing.
Runs on your laptop or a cheap 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 are 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 vendor 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.