ApexYard turns a Claude Code repo into a governed multi project engineering workflow

What ApexYard actually is: a repo of files, not a tool to install

The README makes the shape of this project clear early. ApexYard provides a set of plain-text files that Claude Code reads from the repo root, and no runtime or service is required.

That is the central design decision and everything else follows from it. There is no daemon, no dashboard, no API and no hosted component. What you get is a directory of Markdown rules, shell hooks, slash-command skills, role definitions and templates, and an agent reads them. The homepage is apexyard.ai, the licence is MIT, and the primary language of the repository is Shell, because the enforcement half of the system is shell scripts rather than prompts.

The framing of the problem is also specific. The README says AI can produce a working prototype in a weekend, but teams still need a way to track decisions, review changes, run checks and approve a release. ApexYard is aimed at that gap, and at the gap between a prototype and something that can be shipped.

The workflow it enforces is described in three steps. Every change starts with a ticket. An independent reviewer checks the change. A merge gate stays closed until a named human approves the exact commit.

That third point is the one that distinguishes this from a linting setup. A gate that checks the commit hash rather than the branch state is a different kind of control, because it cannot be satisfied by a later push to the same branch.

There is also a portfolio angle, which is unusual for this kind of setup. ApexYard is described as a multi-project ops repo: you fork it, register your projects, and manage the portfolio from one place, with shared rules and project records. The stated goal is governing a portfolio of repositories as one organisation, with your fork acting as the ops repo so no nested installation is needed in each project.

The inventory: roles, hooks, skills and sub-agents

The README counts the components, and the counts are the clearest description of the scope.

There are 20 roles across 6 departments, engineering, product, design, security, data and architecture, that activate on triggers. There are 60 shell hooks that mechanically enforce the software development lifecycle, including ticket-first edits, a two-marker merge gate, migration gates and secrets scanning. There are 68 slash-command skills, running from /setup, /handover and /scaffold through to /decide, /code-review, /migration and /launch-check. There are 23 sub-agents, with Rex for code review, Hakim for security, Tariq for design review, plus the department personas. And there are 22 rule files, workflow documents and document templates covering PRD, tech design, ADR, AgDR and C4 diagrams.

The full directory and component list is in docs/whats-inside.md, and the repository layout confirms the structure: roles/, skills under plugins/, templates/, workflows/, handbooks/, topologies/, golden-paths/, harness-adapters/ and a .claude/ directory alongside a .cursor/ directory.

What the roles do is worth spelling out, because the mechanism is unusual. A role file is not a persona prompt that any agent can read at will; it activates from clear triggers. The README's comparison table lists roles under the heading of repeated context, which is the problem being solved: a team that keeps re-explaining who cares about what, and to which depth, ends up with inconsistent output across sessions.

The sub-agents are the review layer. Rex reviews every pull request according to the table, and the merge approval row says that Rex and a named human approve the exact commit. A machine reviewer that can block, rather than a machine that comments, is what makes the gate meaningful.

Shell hooks as the enforcement point, and the merge gate markers

The enforcement half of ApexYard is shell, and that is what distinguishes it from a document that asks nicely.

The hooks are described as mechanically enforcing the software development lifecycle, with ticket-first edits, a two-marker merge gate, migration gates and secrets scanning among them. Mechanically is the operative word. A hook runs at commit time and can refuse the commit, so a rule that lives only in a Markdown file is advisory while a rule that lives in a hook is a gate.

The two-marker merge gate is the centrepiece. A commit needs two markers to be accepted, one from the agent's reviewer and one from a named human, and both apply to the exact commit rather than to the branch. The database migration rows follow the same pattern: a migration ticket and a rollback plan are required, which turns a high-risk edit into a thing with an artefact attached to it before it happens.

The secrets scanning hook is the other one with obvious value in an agent-built-code workflow, because an agent reading a large repository and editing it has a way of picking up a credential string and writing it into a file that did not have one before.

There is a second class of guard worth noting, in the onboarding section. The real configuration lives in a gitignored onboarding.yaml, and a commit-time guard blocks the real file if you try to add it. So the tool protects its own configuration from being committed, which is the kind of detail that shows the guards were thought about as a set rather than one at a time.

The hooks are also where the multi-tool claim is tested. The rules, hooks and templates are plain Markdown and shell, and the README says Claude Code is the default driver while opencode, pi and Codex use the same rules through small adapters, and Cursor loads .claude/ natively in the IDE. For anything other than Claude Code, the harness-adapters/ directory is where that translation lives.

Fork, clone, configure: the six step path to a working portfolio

The quick start is a six step sequence, and it starts with a fork rather than an install.

The first step is to star and fork the repository on GitHub into your organisation, keeping the name apexyard or using something like your-org/ops. The second is to clone your fork, either with gh:

gh repo clone your-org/apexyard
cd apexyard

or with plain git:

git clone https://github.com/your-org/apexyard.git
cd apexyard

The third step adds an upstream remote so that later updates are possible:

git remote add upstream https://github.com/me2resh/apexyard.git

After that, upstream changes are pulled in with the /update skill, which previews the diff, uses a sync branch and guides any version migrations. The drift reporting in the comparison table is the same mechanism seen from the other direction, so you learn what has changed before you merge it rather than after.

Step four is the configuration, and it is the step that needs the tool to be running:

/setup

The skill asks about your company, team, technology and quality bar, and shows the proposed defaults before it writes anything. The result lives in the gitignored onboarding.yaml, which /setup creates by copying the tracked onboarding.example.yaml placeholder. If you are not using Claude Code, you can copy the example yourself and fill it in by hand, and the README is explicit that the gates read the file rather than the skill.

Step five registers your projects, again through a skill:

/handover <repo-url-or-local-path>

That clones the repo, scores five harnessability dimensions, seeds the project docs and registers the repo in apexyard.projects.yaml, creating the registry on first use. The registry is a small YAML file:

version: 1
projects:
  - name: example-app
    repo: your-org/example-app
    docs: projects/example-app
    status: active

Step six is simply working, with /projects, /inbox and /status reading that same registry, so the portfolio view comes from one file rather than from several browser tabs.

Where this approach does not fit

There are clear limits, and they are design limits rather than missing features.

The first is that the whole system depends on the team agreeing to the workflow. A ticket-first rule and a merge gate are organisational commitments expressed as tooling. If your team does not want a human approval step on merges, the hooks will simply be disabled or overridden, and the value of the repository collapses into a folder of good prompts.

The second is the per-commit approval requirement. Requiring approval of the exact commit is precise, and it is also friction. In a repository where commits land dozens of times a day, a named human approving each exact commit is a workflow that changes how the team ships, not one that sits alongside the existing process. The README's own comparison table names this trade by putting an informal LGTM on the without side.

The third is the fork model. Forking means your rules are your rules, which is the point for a governance repo, but it also means you own the maintenance. The upstream remote and the /update skill exist to make that manageable, and the README is clear that syncing brings version migrations that need guidance, so an unattended upgrade is not really unattended.

The fourth is that this is a Claude Code shaped system with an escape hatch for others. The rules are portable, but the slash commands, the skills and the sub-agent routing are Claude Code constructs, and the adapters for opencode, pi and Codex are described as small rather than as equivalent implementations.

For comparison, the alternative approaches differ in kind. A CI pipeline with branch protection and required reviews enforces a merge gate without asking the agent to cooperate, but it cannot enforce ticket-first edits at commit time or stop secrets scanning at the point of the write. A documentation-only approach, a CONTRIBUTING file plus an ADR template, costs nothing to adopt and is respected by nobody at commit time. A hosted governance platform gives you audit trails and role management, but the README's position is that there is no service to run and no hosted lock-in, and that is the trade ApexYard is asking you to make.

Editorial conclusion

Adopt ApexYard if several of your repositories are being modified by an AI coding agent and you need the review, the gate and the decision record to be enforced rather than remembered, since the hooks fail the command instead of asking anyone to remember the rule. Do not adopt it as a platform or a hosted service, because there is nothing to run: it is a set of files you fork and read, and if your team will not adopt ticket-first edits and a merge gate, the tooling will not create that discipline. Before you start, fork the repository, run /setup so the configuration in the gitignored onboarding.yaml is filled in, and read the note about the merge gate requiring both Rex and a named human on the exact commit. The licence is MIT, the latest release is v5.9.0 from 2026-10-15, and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. License: MIT
2. me2resh/apexyard on GitHub
3. Project website
4. README
5. Releases