Agent Codeyard

Autonomous coding. Accountable engineering.

The engineering workflow around your coding agents, from requirements to reviewed pull request. Claude Code and Codex do the work; the workflow adds the review, the evidence and the limits, and the merge stays yours.

Get startedSource on GitHubHow the workflow runs

Reviewed by another providerEffort follows riskEvidence for every acceptance criterionNo script merges

The route of one feature

risk
profile
The route of one feature from Issue to merge, with its loops, a clarification stop and a review bypass that applies only to low risk under the light profile.checks fail: repairfindings fixed: checks, review againunclear: you answerlow risk, light profile: no review, and the merge needs your approvalIssuefrom the roadmapImplementclaude opusChecksverify.shReviewcodex, read-onlyFindingsfull triageCommitcompletion gatePull requestCI checksMergeby youapproval required
  1. Issuefrom the roadmap
  2. Implementclaude opus

    If a decision that matters is unclear, the implementer stops with its questions and you answer.

  3. Checksverify.sh

    If a check fails, the implementer repairs it.

  4. Reviewcodex, read-only
  5. Findingsfull triage

    Fixes are checked and reviewed again.

  6. Commitcompletion gate
  7. Pull requestCI checks
  8. Mergeby you
Medium risk. Claude implements and Codex reviews, so the reviewer always comes from another provider, and the merge stays with you.

Generation is no longer the bottleneck

Claude Code and Codex produce working changes in minutes. What they do not settle on their own is whether the change does what was asked, whether someone other than its author checked it, whether the checks ran on exactly that code, and who decided it may ship.

Agent Codeyard is the workflow around the agents. It does not write code. It turns an approved plan into Issues, has one agent implement and an agent of another provider review, records the evidence for every acceptance criterion, and leaves the merge to you. Everything runs from your repository with shell scripts and plain files; there is no platform to host.

The agents

  • Write the code and the tests
  • Review a change, read-only
  • Propose what to do with each finding

Codeyard

  • Computes the risk level of each change
  • Picks the agent and model for the level
  • Refuses a review by the implementer's own provider
  • Commits only verified, reviewed, complete work

You

  • Approve the plan
  • Answer what the agents cannot decide
  • Approve protected changes
  • Merge

Plan once, then one line per feature

Every step on the workflow page.

Planning runs once: idea, requirements, plan, plan review, your approval. From the approved plan, each feature runs its own line from Issue to merge.IdeaRequirementsProject GrillPlanarchitecture, roadmapPlan reviewanother providerYou approveFeature IssueRunbuild, check, reviewMerge
  1. Idea
  2. RequirementsProject Grill
  3. Planarchitecture, roadmap
  4. Plan reviewanother provider
  5. You approve

    Then, per feature:

  6. Feature Issue
  7. Runbuild, check, review
  8. Mergeby you

A planning change, a new requirement or a changed roadmap, goes back through the plan review and your approval before features are built on it. Each feature runs step by step, with you approving the triage, or in one unattended command, run-feature.sh, which stops whenever it needs you.

More risk, more evidence

Configured in risk.conf and agents.conf.

Each change gets a risk level, computed from what it touches, and each project picks a workflow profile. They are separate settings: the level describes the change, the profile describes how much ceremony the project wants for low and medium risk.

settingdecided byvalues
Risk levelThe changed paths, fixed escalations (a policy, prompt or schema; removed or changed lines in an existing test; shared test fixtures; the verification configuration), and what the agents assess. You can raise it with the Issue label risk: high or --risk, but nobody can lower it.low · medium · high
Workflow profileOne line in risk.conf. Without it, the project keeps the policy it has.standard · light
Agent permissionsThe role: implementers write, reviewers only read, unattended sessions ask nothing.write · read-only · unattended
Under both profiles every commit needs the full verification and only you merge. The light column shows what changes from standard.
levelstandardlight
low

Reviewed by another provider; full triage.

As shipped there is no low class: changes start at medium.

changed Documentation and process files are low. No review: the commit says so, and the merge needs your approval.

medium

Reviewed; full triage.

Implementer: Claude opus.

changed Reviewed; light triage: minor findings and suggestions can be accepted or deferred without a fix round.

high

Reviewed; full triage.

Implementer: Claude fable.

Unchanged: reviewed, full triage, the stronger model. No profile can remove these.

The agent that writes the code does not judge it

Enforced by review-feature.sh.

The reviewer is always an agent of another provider than the implementer: the script reads which provider implemented the feature from its run records and refuses a reviewer of the same one. The reviewer can only read.

Implementer

  • Reads the Issue, your comments, the requirements and the architecture
  • Asks before it builds when a decision is unclear
  • Writes the code and the tests
  • Runs the checks and records evidence for each criterion

Reviewer

  • Reads the same Issue, the requirements and the diff
  • Reviews exactly the content the checks passed for
  • Reports findings by severity and the impact on the architecture
  • Cannot change a file

Automation stops where ownership begins

Every gate on the workflow page.

You are not asked everywhere. You decide at fixed points, and the run stops for you when it cannot go on safely.

  1. Approve the requirementsProject Grill drafts them from your description; nothing is planned before you approve.
  2. Approve the planArchitecture and roadmap, after a review by another provider; you merge the planning pull request.
  3. Answer when askedAn implementer that finds a decision unclear stops with its questions instead of guessing.
  4. Decide on the findingsStep by step you approve the triage; unattended, the triage is recorded for you to read.
  5. MergeEvery pull request; a protected change or a review that sees major impact on the architecture asks for your approval by name.

Every claim has a record

From the pull request of #222, written by finish-feature.sh.

One feature, from the finding that started it to the merged pull request. Each step left a record that anyone can open.

  1. FindingThe analysis of 41 runs: a fixed finding came back as unresolved in five runs.
  2. Issue#217Six acceptance criteria.
  3. Completion recordThe implementer's claim, criterion by criterion, with evidence.
  4. Review findingson #217Five rounds, each review and triage published.
  5. VerificationRecorded for exactly the content that was reviewed.
  6. Pull request#222Merged by the owner.
github.com/taspinar/agentic-coding-template/pull/222 · excerptCompletion: complete
- met: A complete review in round 3 or later, started
  by run-feature.sh or by hand without --changes,
  receives the decisions of every approved triage …

Verification:
- ./scripts/verify.sh passed

Review: round 5, PASS WITH MINOR FINDINGS,
by codex (gpt-6-luna); triage published on #217

Risk: high
- .agents/prompts/reviewer.md: a policy, an agent
  contract, or a schema is changed

Merge approval:
- required from the project owner, for exactly
  this commit
  1. Completion recordThe implementer's claim, criterion by criterion, with evidence. A session that ends is not a finished Issue.
  2. VerificationA recorded run on exactly this content; reused while nothing changes, never a partial check.
  3. Independent reviewAnother provider, read-only. Every later round gets the earlier decisions; a re-raised finding names the one it continues.
  4. Risk levelComputed again at every step from the diff and the rules of the base branch, with its reasons.
  5. Your approvalProtected changes wait for you; the approval is bound to the commit.

Codeyard enforces

  • The risk level, and that no agent lowers it
  • A reviewer of another provider than the implementer
  • Verification before review and before commit
  • A current review of the complete feature before commit
  • The completion gate and the triage rules
  • Read-only reviewers and sandboxed implementers
  • Rules read from the base branch, so a change cannot loosen its own checks

Your GitHub settings enforce

  • A ruleset on main that requires a pull request and the CI check
  • Code-owner review for protected paths
  • Who may bypass the rules
  • An approval the agent cannot give itself: needs a separate agent identity, not built yet

Codeyard builds Codeyard

Recent changes to this repository, made with its own workflow. Followed in detail.

From the run records and the reviews published on each Issue. Verification is one full run of verify.sh on the maintainer's server.
issuechangeriskimplementerreview roundsverifyresult
#217Give every later review round the earlier decisionshighclaude opus5: two majors fixed, one minor accepted1046 sPR #222
#193Treat performance budgets as measurementshighclaude fable4: a major re-raised as unresolved, then fixed761 sPR #199
#189Compute the risk level from one policyhighclaude fable3, after a defect the owner found572 sPR #194
#16Stop for questions before implementinghighclaude opus1, no findings849 sPR #213
#157Detect workflow complexity creephighclaude fable13 over two attempts, a finding open at the end of each–parked

Learn from your runs

With report-runs.sh, show-experience.sh and analyze-runs.sh. The records in detail.

Every run leaves a record: the review rounds and their findings, what the triage decided, the checks that failed, why a run stopped, and the time and tokens of each step. After a number of features you ask a read-only analyst what keeps costing rounds, and it proposes what to change.

The run records of several features run into one analysis. Its proposals pass your decision, and each goes to its own place with the review that applies there.the last n featuresrun recordsAnalysisanalyze-runs.shread-onlyYou decideADR, instruction, skill, docsa check in a scriptan Issue, here or in the templateeach with the review that applies there
  1. Run recordsof the last n features: rounds, findings, triage, stops, time and tokens
  2. Analysisanalyze-runs.sh --last 10

    A read-only agent; it changes nothing.

  3. You decide
  4. Each proposal in its placean ADR, an agent instruction, a skill, the documentation, a check in a script, or an Issue, here or in the template

    with the review that applies there

  • A finding needs two runs. One observation stays a hypothesis, and “not enough evidence” is a valid outcome.
  • Every conclusion cites its records, and says which differences in task size, model and workflow version it considered.
  • Nothing changes by itself. Each proposal names its place, and you take it through the review and approval there.
  • Repeatable, and nothing counted twice. Each analysis keeps its input and sources; evidence an earlier analysis used is marked as such.

Codeyard ran it on itself on 28 October 2026: 41 runs of 19 features. Among the findings: in five runs the reviewer raised a fixed finding again as unresolved; six of seven failed runs recorded no reason for the stop; the self-test suite had grown from 463 s to 915 s in two days. Five proposals became Issues, all merged:

issuechangeresult
#216Record the step and the reason of every stopPR #223
#217Give every later review round the earlier decisionsPR #222
#218Stop a false partial completion in the handoff notePR #221
#219Time every check and budget the self-test suitePR #224
#220Warn about calls of models that agents.conf does not declarePR #225

You start an analysis by hand; running it periodically is an open Issue (#131).

Start a project

The full getting-started guide.

# a new repository from the template
$ gh repo create my-project --template taspinar/agentic-coding-template --private --clone
$ cd my-project
$ ./scripts/doctor.sh
# plan once: requirements, architecture, roadmap; you approve
$ ./scripts/start-planning.sh --description idea.md
# then each feature, from Issue to pull request
$ ./scripts/create-feature-issue.sh F01
$ ./scripts/run-feature.sh 1

You need Git, the GitHub CLI, jq, Claude Code and Codex: as shipped, Claude implements and Codex reviews, and a review by the implementer's own provider is refused. doctor.sh checks all of it, including the Codex sandbox and your Git identity.

Build with agents. Ship with evidence.

Get startedSource on GitHub

Open source, MIT licence. Runs on your machine with Claude Code and Codex.