~/apexyard · how it works
apexyard / how it works one realistic day, in plain English

How it works

This page describes one day with ApexYard. It uses plain language and no terminal output. It shows what the tool does and when you use it.

What ApexYard is ApexYard supports a daily workflow. You review work, respond to findings, check release readiness, and record the result. What ApexYard does ApexYard adds review, guardrails, and process to each change made with Claude Code. What you need to start Fork apexyard, run /setup, register your projects. The page below is a narrative; see quickstart for the install steps.

See also: overview · skills · architecture

The shape of a day with ApexYard

You are building software with an AI coding assistant. You may work alone or with contractors. You need a repeatable way to review changes, prepare releases, and keep decisions available after the work is complete.

ApexYard works with the coding assistant you already use. It adds review, guardrails, and records around each change. The workflow stays in your repositories and tracker. The following example shows one working day.

Morning

Open your inbox

You start the day by asking ApexYard for the portfolio inbox.

The response lists the projects you manage, the pull requests that need review, blocked issues, unanswered comments, and checks that are still open.

You can start with one view instead of searching across several repositories and message channels. Items are grouped by the action they need.

What is new here: the inbox is generated from the registered repositories. It is a view of current tracker data, not a second list that you must maintain.

You choose the highest-priority item and continue the work in the coding assistant.

Mid-morning

The AI writes — the framework reviews

You describe the change. The AI writes the code. ApexYard records the ticket that authorises the edit.

When the change is ready, ApexYard runs the configured code review against the diff and its surrounding system impact. The reviewer checks quality, tests, security, and required decisions.

The review can identify a missing edge-case test, a data exposure in an error log, and a question about whether a new endpoint requires authentication.

You resolve each finding. The AI adds the test, you correct the logging issue, and you record the authentication decision. The review is then submitted again.

What is new here: the review is part of the merge path. It does not depend on a customer finding the problem after release.
Lunch

A contractor finishes their piece

A contractor finishes work on another project. A new pull request appears in the portfolio inbox.

The review has already run. It reports two quality findings, one copy question, and no security findings.

The contractor can resolve the quality findings. You answer the copy question because it is a product decision. The contractor then updates the branch.

The review runs again against the new commit. When the findings are resolved, you approve the pull request.

What is new here: the review handles the engineering checklist while you make the product decision.
Afternoon

Getting ready to launch

The billing change is ready for release. Before customers see it, you run a launch-readiness check.

The check produces a structured report for security, accessibility, performance, privacy, monitoring, documentation, and other configured dimensions.

The report identifies three missing items: a privacy policy, error monitoring, and a contrast issue on one button.

You publish the privacy policy, add error monitoring, and correct the button contrast.

You run the check again. The report now shows the release criteria as complete.

What is new here: release checks surface gaps before deployment instead of after users report them.
End of day

Nothing gets lost

You finish the day. The framework has recorded the work that matters.

Technical decisions are stored with their reasons. Reviews, launch checks, approvals, and contractor changes remain part of the project history.

When someone later needs to understand why a choice was made, the record is available. The team does not need to repeat a decision because its context was lost.

At the end of the week, you request a stakeholder update. It summarises recorded activity across the portfolio. You review it, edit it if needed, and send it.

What is new here: the framework preserves engineering context and produces reports from recorded activity.

Fork apexyard.
Run /setup.
Start your first day.

Free and open source. Plain markdown and shell. No SaaS, no monthly fee, no vendor lock-in. Fork it, edit anything to match how you work, and ship with a repeatable process.

fork on github → see the technical quickstart → back to overview ↑