ApexYard

AI can build quickly. Shipping safely needs a system.

AI can produce a working prototype in a weekend. Teams still need a way to track decisions, review changes, run checks, and approve a release.

ApexYard provides that system. 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.

ApexYard is a multi-project ops repo. You fork it, register your projects, and manage the portfolio from one place. Shared rules, project records, and shell hooks keep the workflow consistent.

Claude Code is the default driver. The rules, hooks, and templates are plain Markdown and shell, so you can use another coding tool through an adapter. There is no service to run and no hosted lock-in.

The workflow has been used with TypeScript and AWS Lambda backends, Next.js apps, Chrome extensions, and native Swift macOS apps.

What makes it different

Area	Without ApexYard	With ApexYard
Code review	Ad-hoc prompts	Rex reviews every pull request.
Technical decisions	Lost in chat	Agent Decision Records preserve them.
Quality gates	Manual memory	Shell hooks block unsafe actions.
Merge approval	Informal “LGTM”	Rex and a named human approve the exact commit.
Database migrations	High-risk edits	A migration ticket and rollback plan are required.
Architecture	Scattered notes	C4 templates and the /c4 skill create a shared model.
Portfolio view	Several GitHub tabs	/inbox, /status, and /tasks read one registry.
Upstream updates	Easy to forget	/update reports drift and guides the sync.
Roles	Repeated context	Role files activate from clear triggers.
Onboarding	Manual setup	/setup collects the required configuration.

What's inside

ApexYard is a set of plain-text files. Claude Code reads them from the repo root. No runtime or service is required.

• 20 roles across 6 departments (engineering, product, design, security, data, architecture) that activate on triggers
• 60 shell hooks that mechanically enforce the SDLC — ticket-first edits, a two-marker merge gate, migration gates, secrets scanning, and more
• 69 slash-command skills — from /setup, /handover, and /scaffold to /decide, /code-review, /migration, and /launch-check
• 23 sub-agents — Rex (code review), Hakim (security), Tariq (design review), plus the department personas
• 22 rule files, workflow docs, and document templates (PRD, tech design, ADR, AgDR, C4 diagrams)

See docs/whats-inside.md for the full directory and component list.

Marketing site: the site that was previously bundled here has moved to its own repo (me2resh/apexyard-site) and is deployed independently at apexyard.ai.

Built for Claude Code first. opencode, pi, and Codex use the same rules through small adapters. Cursor loads .claude/ natively in the IDE. See Using another AI coding tool?.

For AI coding agents: AGENTS.md is the universal entry document for tools that do not load CLAUDE.md. See docs/harnesses/pi.md.

Quick Start — fork and go

ApexYard governs a portfolio of repos as one organisation. Fork and clone the repository. Use that fork as your ops repo. Register each project you want to manage. The fork is the ops repo, so no nested installation is needed.

Using opencode, pi, or Codex? Steps 1–3 use plain git and gh. Install your tool's adapter before steps 4–6. Each step also gives a manual file option. The enforced rules are the same in both paths.

1. Star + Fork on GitHub

Visit github.com/me2resh/apexyard. Star it, then fork it into your organisation. Keep the name apexyard, or use a name such as your-org/ops.

2. Clone your fork locally

gh repo clone your-org/apexyard
cd apexyard

Or with plain git:

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

3. Add upstream for future updates

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

Later, run /update to bring upstream changes into your fork. The skill previews the diff, uses a sync branch, and guides any version migrations.

4. Configure the framework — run /setup

Run /setup in Claude Code. The skill asks about your company, team, technology, and quality bar. It shows the proposed defaults before it writes the configuration.

/setup

Your real config lives in the gitignored onboarding.yaml. It stays local. /setup copies the tracked onboarding.example.yaml placeholder and fills it in. A commit-time guard blocks the real file if you try to add it.

No /setup on your tool? Copy the example and fill it in by hand: cp onboarding.example.yaml onboarding.yaml. The gates read the file, not the skill.

5. Register your projects — run /handover

Projects join the portfolio through a skill. For each repo you want to manage:

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

/handover clones the repo, scores five harnessability dimensions, seeds the project docs, and registers the repo in apexyard.projects.yaml. It creates the registry on first use. /setup can register your first project.

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: active

Register a single repo too. The portfolio skills (/projects, /inbox, and /status) read the same registry. No /handover on your tool? Copy apexyard.projects.yaml.example and add the repos by hand.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗