Take agent-built code the last mile — safely to production.
The first 80% flew — a working prototype in a weekend, features landing faster than you could test them. Then the context slipped. The codebase turned into a pile nobody could review, decisions vanished into chat history, and the thing you were so close to shipping never actually made it to production.
ApexYard is the machinery that takes agent-built code the last mile. It wraps your AI coding agent in the discipline a real engineering team runs on: every change moves through a ticket, gets an independent review, and hits a merge gate that stays shut until a named human says "ship it." So the code your agent writes is actually safe to put in front of users.
Concretely, it's a multi-project ops repo: you fork it, register your projects, and govern them all as one organisation — shared memory across the portfolio, a strict SDLC, and 42 shell hooks that enforce the rules mechanically instead of hoping everyone remembers them. Built for founders who ship alone, and for teams standing up AI-enabled squads.
Claude Code is the default driver, but the rules, hooks, and templates are plain markdown and shell. Swap the AI. Keep the forge. No SaaS. No lock-in.
Proven shipping TypeScript + AWS Lambda backends, Next.js web apps, Chrome extensions, and native Swift macOS desktop apps. The stack is process and guardrails — not a language or framework lock-in.
ApexYard was built for Claude Code — that's where everything is native. But the part that actually enforces your rules is plain bash, not tied to Claude Code, so other AI coding tools can run the exact same rules through a small adapter. We only claim what we've watched work: as of 2026-07-09, three tools — opencode, pi, and Codex — are proven, meaning a real agent turn on each was stopped by the same unmodified rule. Each needs one small setting so the agent's command actually reaches the rule. Cursor is the honest exception.
| Tool | Enforces your rules? | Setup | Good to know |
|---|---|---|---|
| Claude Code | ✅ Yes — natively. Built in; the rules fire on every command. | Nothing to install — /setup and you're done. |
On Windows, use Git Bash or WSL (the rules are bash). |
| opencode | ✅ Yes — proven. A real agent's git add -A was blocked by the same rule. |
bash bin/install-opencode-adapter.sh |
Run opencode with --auto so the agent's command reaches the rule. |
| pi | ✅ Yes — proven. Same, in a real pi session. | bash bin/install-pi-adapter.sh |
Run pi with -a (auto-approve). pi is deliberately bare-bones — ApexYard is the governance it leaves to you. |
| Codex | ✅ Yes — proven. Same, in a real Codex session. | bash bin/sync-codex-adapter.sh |
Codex has to trust the rules once — /hooks, a one-off flag, or a user-level install. |
| Cursor | 🟡 Partly. It blocks the command, but by failing safe when its rule-runner errors — not by running our rule. We don't count it as proven. | bash bin/install-cursor-adapter.sh |
Works in the Cursor IDE, not the command-line version. Install is user-level (~/.cursor/hooks.json). |
Under the hood: your rules stay one set of portable bash scripts, and every tool reads the same ones — never a separate copy that can drift out of sync. Full per-tool setup, limits, and how to add a new tool → docs/harnesses/.
Live conformance, not just a one-off proof. The 2026-07-09 dates above are single manual runs. A daily, credentialed Conformance CI job keeps proving it — one real gated turn per harness, asserted against the gate's own live output:
A badge only reads "(proven)" after 3 consecutive scheduled green runs — any red run resets that harness's streak. Cursor's badge is a static "documented-manual" entry; no scheduled run can flip it. See docs/conformance-ci.md for the secrets an operator provisions and the full rationale (AgDR-0095).
Not on Claude Code? opencode, pi, and Codex run the same gates today (Cursor partially). Install your tool's adapter — the one command in the table above — and the identical rules enforce. One honest caveat before the Quick Start below: the
/setup,/handover, and other/…commands are Claude Code skills, a convenience layer. The enforcement that actually matters — the gates — is what your tool's adapter delivers; on another tool you set up the same plain-text config files by hand (the steps note how).
ApexYard can generate a Codex-facing adapter from the canonical .claude/ runtime:
bin/sync-codex-adapter.shThe generator emits Codex-facing skills, agents, and hook wiring into .agents/ and .codex/ without embedding local clone paths. Gate decisions still run through the unmodified .claude/hooks/*.sh scripts. See docs/codex-adapter.md for the tracking policy, AgDR, and drift-check workflow.
ApexYard is a set of plain-text primitives Claude Code reads automatically — no runtime, no service:
- 20 roles across 6 departments (engineering, product, design, security, data, architecture) that activate on triggers
- 42 shell hooks that mechanically enforce the SDLC — ticket-first edits, a two-marker merge gate, migration gates, secrets scanning, and more
- 64 slash-command skills — from
/setupand/handoverto/decide,/code-review,/migration, and/launch-check - 25 sub-agents — Rex (code review), Hakim (security), Tariq (design review), plus the department personas
- 15 rule files, workflow docs, and document templates (PRD, tech design, ADR, AgDR, C4 diagrams)
Full directory tree and the complete role / hook / skill / agent breakdown → docs/whats-inside.md.
Marketing site: the site that was previously bundled here has moved to its own repo (me2resh/apexyard-site) and is deployed independently at yard.apexscript.com.
For AI coding agents: the repo root carries
AGENTS.md— universal entry doc for Cursor / Claude Code / Aider / Cline / pi. For harnesses that don't auto-loadCLAUDE.md(pi chief among them),AGENTS.md's "Operator governance bridge" section carries the same advisory SDLC governanceCLAUDE.mdgives Claude Code — seedocs/harnesses/pi.mdfor what's bridged today vs. not yet.
ApexYard governs a portfolio of repos as one organisation. You fork apexyard, clone the fork, treat it as your "ops repo", and register every project you want under management. No .apexyard/ symlinks, no nested installs — the fork IS the ops repo.
On opencode, pi, or Codex? Steps 1–3 are the same (they're just
git/gh). Then install your tool's adapter — one command, see the Harness support table above — and the gates enforce on your tool. The/setupand/handoversteps below are Claude Code skills; on another tool you set up the same plain-text config files by hand, which each step shows. The rules that get enforced are identical either way.
Visit github.com/me2resh/apexyard, Star it, then Fork it into your org. You can keep the fork named apexyard or rename to something that fits your naming convention (your-org/ops, your-org/apex, etc.).
gh repo clone your-org/apexyard
cd apexyardOr with plain git:
git clone https://github.com/your-org/apexyard.git
cd apexyardgit remote add upstream https://github.com/me2resh/apexyard.gitLater, run /update to pull the latest apexyard improvements into your fork — it previews the upstream diff, merges on a sync branch, and walks you through any per-version migrations (don't hand-merge main).
Run /setup in Claude Code. In three exchanges (describe your stack → review the proposed defaults → accept or tweak) it captures your company, team, tech stack, and quality bar and writes your config.
/setup
Your real config lives in onboarding.yaml, which is gitignored — it stays local and is never published. /setup copies it from the tracked onboarding.example.yaml placeholder and fills it in, so nothing private is committed. (A commit-time guard blocks a filled-in onboarding.yaml if you ever try to add it.)
Not on Claude Code? There's no /setup skill to run — do the same thing by hand: cp onboarding.example.yaml onboarding.yaml and fill in your company, stack, and quality bar. The gates don't depend on the skill; they read the file.
Projects join the portfolio through a skill, not hand-edited YAML. For each repo you want under management:
/handover <repo-url-or-local-path>
/handover clones the repo, scores its "harnessability" across five dimensions, seeds its per-project docs, and registers it in apexyard.projects.yaml (creating the registry on first use). /setup also offered to register your first project back in step 4.
The registry it maintains looks like this — you rarely touch it by hand:
version: 1
projects:
- name: example-app
repo: your-org/example-app
docs: projects/example-app
status: activeRegister even a single repo — the portfolio skills (/projects, /inbox, /status) work off the registry. (Not on Claude Code, or prefer to bootstrap it by hand? cp apexyard.projects.yaml.example apexyard.projects.yaml and add your repos — same registry, no skill required.)
/projects # list every managed project + status
/inbox # PRs, issues, comments needing your attention
/status # git + CI snapshot per project
/decide # make a technical decision (creates an AgDR)
The hooks fire on every git / gh command, the portfolio skills aggregate across the registry, and the Code Reviewer agent can be invoked with /code-review <pr>.
Full setup guide with directory layout, daily workflow, and FAQ: docs/multi-project.md.
Keeping a fork current — upgrade in place, when to re-fork instead, and how to preserve your portfolio data either way: docs/upgrading.md.
The problem: Claude Code is powerful, but without structure it produces inconsistent results. Every team reinvents the same processes -- role definitions, review checklists, document templates, workflow gates.
The solution: ApexYard provides that structure as a reusable, open-source stack. One config file to customize, 20 role definitions to use, battle-tested workflows to follow, and 42 shell hooks that enforce the rules mechanically.
| Feature | Without ApexYard | With ApexYard |
|---|---|---|
| Code reviews | Ad-hoc prompts | Rex agent on every PR, SHA-bound approval marker |
| Technical decisions | Lost in chat history | Documented as Agent Decision Records |
| Quality gates | Hope and pray | 42 shell hooks block bad commits, forged markers, unreviewed merges |
| Merge approval | Informal "LGTM" | Two-marker gate — Rex (code) + CEO (per-PR explicit) |
| Database migrations | Drop-column-on-Friday | Dedicated gate: labelled ticket + migration AgDR (rollback, downtime, consumers) required before schema edits |
| Architecture docs | Nobody draws them | C4 L1 + L2 Mermaid templates + /c4 skill generates stubs from a codebase |
| Portfolio visibility | Tab through 5 GitHubs | /inbox, /status, /tasks aggregate across a single registry file |
| Upstream sync | Forget for 6 months | Session-start drift banner + /update skill |
| Role consistency | Re-explain every session | Persistent role definitions, activation-triggered |
| Onboarding | Days of context-setting | /setup three-exchange config |
ApexYard ships 20 roles across 6 departments that activate on triggers, a full SDLC (Planning → Design → Build → Review → QA → Deploy → Monitor) with a dedicated migration sub-workflow, and reusable document templates (PRD, technical design, ADR, AgDR, migration AgDR, C4 diagrams).
The full role roster, workflow detail, and template catalogue live in docs/whats-inside.md. The canonical entry point Claude Code reads is CLAUDE.md.
Running your repo under ApexYard? Add a badge to its README. Every adopter repo that carries one is a backlink and a bit of social proof — and /handover will offer to drop it into the repos it onboards.
Governed by — for a repo managed under an ApexYard ops fork:
[](https://github.com/me2resh/apexyard)
Built with — for a project built out through the ApexYard workflow:
[](https://github.com/me2resh/apexyard)
ApexYard is designed to be customized. Every role, workflow, and template can be modified to fit your team:
- Add roles: Create new
.mdfiles inroles/your-department/ - Modify workflows: Edit files in
workflows/ - Add templates: Drop new templates in
templates/ - Override anything: The stack is just markdown files -- edit freely
Contributions are welcome — start with CONTRIBUTING.md for the full fork → PR → review flow, and open issues with the Bug report / Feature request templates. All participation is governed by our Code of Conduct. Security issues go through SECURITY.md (private reporting), not public issues.
ApexYard runs on its own rules, so the flow mirrors any project under ApexYard governance:
- File an issue — open a GitHub issue with the Bug report / Feature request template. If you run apexyard yourself, the
/report-apexyard-bugand/request-apexyard-featureskills file it here for you (they targetme2resh/apexyard— distinct from/bugand/feature, which file into your own managed project). - Start the ticket —
/start-ticket <number>so the ticket-first hook lets your code edits through. - Branch + commit —
{type}/GH-{number}-{short-description}, conventional commit format (type(#number): subject). - Self-check before pushing —
npm run lint/ markdownlint / shellcheck as applicable; hooks remind you atgit push. - Open a PR — title
type(#number): description+ a Glossary section in the body. - Wait for Rex — the Code Reviewer agent auto-runs on every PR.
- Merge requires two markers — Rex's approval + explicit per-PR CEO approval via
/approve-merge <pr>. Plan-level "go" doesn't count.
For larger changes (new skills, rule changes, workflow redesigns), open a discussion or draft PRD first.
Thanks to everyone who has helped forge ApexYard:
 me2resh |
 AbdElrahmaN31 |
 HishamM1 |
 tifa64 |
 hossam-96 |
This list credits every human directly, since squash-merges hide them from GitHub's contributor graph. New contributor? Open a PR and you'll be added.
MIT License. See LICENSE for details.
Built with real-world experience shipping software with Claude Code.