Six months ago I was shipping multiple products alone with Claude Code, and I kept running into the same wall. New session, new context, the plan drifted. The session grew, the context filled up, the agent got overwhelmed, and things I had already decided got quietly redecided. Rules I had written into CLAUDE.md would be read in one session and ignored in the next.
At some point I stopped trying to fix the prompt. The answer wasn't a better prompt. The answer was to stop treating the agent as a tool and start treating it as an engineering team.
So I built the team.
Chief of Staff, Head of Engineering, Backend engineer, Frontend engineer, QA engineer, Code reviewer, Product manager. Each one is a role file the agent reads and adopts, with its responsibilities, its boundaries, and who it hands off to when the work crosses a discipline. Around the roles I put the same SDLC a grown-up company would use.
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.
The other piece I leaned on heavily is Agent Decision Records. Every time the agent picks a library, an architecture pattern, or an implementation approach, it writes a short AgDR capturing the options considered, the decision, and the trade-offs, committed next to the code. Without the rest of the stack those decisions evaporate after each session. With the stack in place they accrue into a searchable trail. I can open a six-month-old project, ask "why did we do it this way?", and the answer comes from a file instead of a reconstruction from the diff. In practice AgDRs are the highest-leverage primitive in the whole thing. They turn the agent's amnesia from a liability into a documented audit trail.
That system now has a name: ApexYard.
What's in it
ApexYard is an open-source stack of role definitions, slash commands, shell hooks that enforce the rules mechanically, and a registry file that lists every project under management.
The important part isn't any of the counts. It's that ApexYard runs as an ops repo above your projects, not inside them. You fork the stack, clone your fork, and treat that fork as your portfolio's command centre. Your actual product repos sit under workspace/ inside the fork, gitignored, each one keeping its own GitHub remote. The fork holds the registry, the role files, the hooks, and the skills. Every managed project gets its own projects/<name>/ folder for ApexYard-specific docs like roadmap, handover assessments, and stakeholder updates.
Tickets live in each project's own GitHub repo. The registry keeps that boundary without any effort from me, so nothing bleeds between projects by accident, and nothing has to be reformatted into a central tracker to stay visible.
Adopting an existing codebase: /handover
When I inherit a codebase or want to bring an old project under governance, I run /handover <repo-url>. The skill clones the repo into workspace/, reads the tree, and detects the tech stack (Node, Python, Rust, Dockerfile, Terraform, CI workflows, the works). It checks commit velocity, open-issue volume, and contributor history, and optionally attempts a build to flag a broken baseline before anything else happens.
It then writes a handover assessment to projects/<name>/handover-assessment.md covering where the code came from, what it's built on, what the quality risks are (stale dependencies, known CVEs, missing tests, abandoned linters), and a concrete integration plan: which ApexYard roles should activate for this repo based on its stack, which hooks to enable, which CI templates to copy in from golden-paths/pipelines/. The new project gets appended to the registry with status: handover. First assessment takes about ten minutes of back-and-forth. After that the project behaves identically to anything I started from scratch.
The first time I ran /handover on a five-year-old contractor codebase, the assessment flagged three hardcoded API keys, an abandoned Webpack config, and two dependency CVEs I had no idea about. That's now the default first pass whenever a repo enters the org.
Greenfield work: /idea
For new ideas I run /idea <one-liner>. It asks a few quick questions (category, submitter, one-line description), dedup-checks against the shared projects/ideas-backlog.md (a fuzzy-match heuristic so I stop filing the same idea twice in different words), assigns the next IDEA-NNN, and appends a row to the backlog. If the idea survives triage a week later, /write-spec picks it up and drafts a PRD with the Product Manager role active. The PRD hands off to the Tech Lead for breakdown, and from there the usual SDLC applies.
Both skills share a design principle: low-ceremony capture at the top of the funnel, heavy structure the moment something looks real.
A day running it
Morning: /inbox
I run /inbox at the ops-repo root and see every PR, issue, and unanswered comment across five repos in one view:
🔴 PRs awaiting review (3)
🟢 Your PRs ready to merge (1)
📬 Issues assigned to you (4)
💬 New comments on issues you opened (2)I pick the green one and cd workspace/curios-dog. The active-ticket marker is per-project, so the hook already knows I'm on curios-dog without me having to say it. I run gh pr merge, and the hook refuses because I haven't written the per-PR merge-approval marker. It prompts me with an explicit "approved?" question that names the specific PR. I answer, the marker gets written, and the merge goes through.
Midday: picking up a feature
I switch to the ApexYard repo itself and run /start-ticket 92. A different marker gets written, scoped to apexyard. The Product Manager role activates, drafts the problem statement, and hands off to the Tech Lead, who breaks it into sub-tickets with acceptance criteria. The Backend engineer role then picks up the implementation. Rex, the code-reviewer agent, runs on every push and stamps a marker file bound to the current commit SHA.
Two gates fire that I never police manually. The first catches an edit to a migration file when there is no labelled migration ticket or rollback AgDR, and blocks it at the Edit tool call rather than after the PR lands. The second catches a commit message closing #47 when #47 doesn't exist, and refuses the commit. Both hooks are about ten lines of shell each, sitting in the repo from session to session, without my having to remember that they are there.
Afternoon: switching projects
cd workspace/apexscript. The active-ticket marker changes automatically. Rex knows to apply apexscript's conventions rather than ApexYard's. None of the morning's context follows me into the afternoon: the role definitions, hooks, and skills are shared across the portfolio, but the tickets, branches, PRs, and AgDRs stay with the project they belong to. If I decided to spin apexscript out tomorrow, everything it needs to stand on its own is already inside its own repo.
At the end of the day, /stakeholder-update weekly reads every registered project and produces a rollup of what shipped, what's in flight, and what's stuck across the whole portfolio. One pass, one summary I can paste into a team email.
Try it
ApexYard is MIT-licensed, open source, built on plain markdown and shell, and designed to run natively inside Claude Code. There is no SaaS and no lock-in.
- GitHub: github.com/me2resh/apexyard
- Landing: yard.apexscript.com
Fork it and register a single project, then run /inbox. The rules you write down today will still be enforced six months from now by a shell script that does not forget.
Related: Agent Decision Records · How Much Autonomy Are You Giving Your Most Reckless Engineer?