RepoChicken / Agent governance auditREPORT FORMAT
ILLUSTRATIVE EXAMPLE
WHAT YOUR AGENTS KNOW. WHAT THEY MAY CHANGE. WHO CHECKS THEIR WORK.
See how your agents
are governed today.
A governance audit answers five questions about the coding agents working in your repository: what they know, what they may change, who reviews their work, what waits for your approval, and what proves a task is done. Each finding ends in a recommendation with an acceptance check.
This is an illustrative example of the deliverables, not a completed audit or proof of results. The repository, scenarios, file references, and snippets below are fictional. They show the report format, not findings about a real repository.
- FICTIONAL SCOPE
- One web-app repository, two coding-agent tools, three workflows
- LENSES
- Review, approvals, knowledge, rules, evidence, roles, audit trail, cost, portability, conflicting documentation, continuity, tool loading
- STATUS
- Illustrative only
Governance scorecard
The scorecard summarizes the current state against a governed target. Ratings in this sample are fictional.
Illustrative ratings, not an assessment of a real repository| Area | Current state (fictional) | Rating | Governed target |
|---|
| Independent review | The agent session that writes a change also approves it | Gap | A separate reviewer checks work before acceptance |
| Owner approvals | Instructions allow migrations and releases without sign-off | Gap | Named risky actions wait for an owner |
| Project knowledge | Conventions live in chat threads and a stale setup guide | Partial | Indexed, sourced knowledge in the repository |
| Rules across tools | Each tool has its own instruction file, and they disagree | Gap | One canonical rule set every tool reads |
| Evidence of completion | “Done” is reported without the checks that were run | Partial | Recorded checks; untested work labelled unverified |
| Agent roles | Several overlapping custom agents with unclear triggers | Partial | The smallest set of distinct, scoped roles |
| Audit trail | No record of who approved what, or why a change was accepted | Gap | Reviews, approvals, and checks recorded in the repository |
| Cost discipline | Agents re-read the whole repository and retry without limit | Partial | Right-sized context, bounded retries, escalation to a person |
| Portability | Rules and knowledge are tied to one tool and one model | Gap | Tool- and model-neutral rules you can carry anywhere |
| Conflicting documentation | Setup guides disagree, with no source resolving the conflict | Gap | Source-linked guidance with unresolved conflicts visible |
| Continuity between sessions | Decisions and unfinished work exist only in the previous chat | Gap | Saved task context checked in a fresh-session restart |
| Observed tool loading | Instruction files exist, but loading has not been checked | Unverified | Observed loading and workflow checks, with limits recorded |
ILLUSTRATIVE EXAMPLEEX-01 / INDEPENDENT REVIEW
Agents approve their own changes.
Imagine that the instructions tell an agent to merge its own work once tests pass, so the same session writes, judges, and accepts each change.
Fictional snippet, not repository evidence:
AGENTS.md "When the tests pass, mark the task done and merge to main."
WHY IT COULD MATTER
An author checking its own work tends to confirm its own assumptions. Passing tests show that the tests ran, not that the change matches the request, stays in scope, or respects project conventions.
RECOMMENDATION AND CHECK
Require a separate reviewer, with fresh context, to check each change against its acceptance criteria before it is accepted; authors never approve their own work. Check: a representative change shows a distinct review before merge.
Evidence a real audit would need: the applicable instructions, branch and merge settings, and a sample of recent agent-authored changes with their review history.
ILLUSTRATIVE EXAMPLEEX-02 / OWNER APPROVALS
Risky actions have no approval point.
Fictional snippet, not repository evidence:
AGENTS.md "Run database migrations and publish releases as needed."
WHY IT COULD MATTER
Irreversible or outward-facing actions, such as migrations, releases, and merges to the main branch, could happen without anyone deciding they should. Written rules guide agents; tools and access controls enforce permissions.
RECOMMENDATION AND CHECK
Name the actions that wait for owner approval, state them in the working rules, and align tool permissions where the platform supports it. Check: the rules list each action, and an agreed test task shows the agent stopping to ask.
Evidence a real audit would need: instruction files, tool permission settings, CI and deployment configuration, and the owner's list of high-risk actions.
ILLUSTRATIVE EXAMPLEEX-03 / PROJECT KNOWLEDGE
Key conventions live outside the repository.
Fictional snippets, not repository evidence:
docs/setup.md "Start the app with npm run dev." (no dev script exists)
team chat "Always use the shared API client." (not written in the repository)
WHY IT COULD MATTER
Agents cannot read team chat, and a stale guide is worse than none. The same context gets re-explained every session, and decisions drift because nobody can see where they came from.
RECOMMENDATION AND CHECK
Move durable facts into the repository as linked, focused documents behind a knowledge index, using Open Knowledge Format (OKF), with each fact pointing to its source and owner. Check: every concept is reachable from the index, and the setup command is verified in an agreed environment.
Evidence a real audit would need: existing documentation, configuration that contradicts it, and owner confirmation of conventions currently held outside the repository.
ILLUSTRATIVE EXAMPLEEX-04 / RULES ACROSS TOOLS
Two tools, two diverging rule sets.
Fictional snippets, not repository evidence:
CLAUDE.md "Use pnpm. Put tests next to the source."
.github/copilot-instructions.md "Use npm. Put tests in /tests."
WHY IT COULD MATTER
The same task can produce different results depending on which tool a teammate opens. Each copy is edited separately, so the disagreement grows over time.
RECOMMENDATION AND CHECK
Keep one canonical rule set and have each tool's file point to it, adding only tool-specific notes. Confirm what each tool actually loads in your setup. Check: no tool file contradicts the canonical rules.
Evidence a real audit would need: every instruction file each tool loads in the agreed environment, its precedence, and the owner's choice where rules conflict.
ILLUSTRATIVE EXAMPLEEX-05 / EVIDENCE OF COMPLETION
“Done” arrives without proof.
Fictional agent summary, not repository evidence:
"Refactor complete. All tests pass." (no commands or results recorded)
WHY IT COULD MATTER
A confident summary is not evidence. Reviewers either re-run everything themselves or accept claims they cannot see, and untested work looks the same as tested work.
RECOMMENDATION AND CHECK
Require completion to record the checks actually run and their results, and to label anything untested as unverified. Check: a representative task record shows the commands, results, and open uncertainty.
Evidence a real audit would need: recent agent task summaries, CI results for the same changes, and the team's definition of done.
ILLUSTRATIVE EXAMPLEEX-06 / AGENT ROLES
Overlapping agents, unclear routing.
Suppose the repository defines several custom agents, such as a “frontend helper”, a “UI expert”, and a “code fixer”, with overlapping descriptions and no stated scope.
WHAT CAN BE CONCLUDED
Overlap is visible in the definitions. Which agent a tool actually selects remains unverified without agreed task checks; overlap alone does not prove misrouting.
RECOMMENDATION AND CHECK
Decide explicitly, for each existing agent, whether to keep, merge, or retire it, and keep the smallest set with distinct triggers and scopes. Nothing is silently overwritten. Check: each retained role has a unique purpose, scope, and trigger.
Evidence a real audit would need: agent definitions, tool configuration, and representative tasks run in the agreed setup.
ILLUSTRATIVE EXAMPLEEX-07 / AUDIT TRAIL
No record of who approved what.
Fictional snippet, not repository evidence:
git log "agent: update billing rules" (no reviewer, no approval, no linked checks)
WHY IT COULD MATTER
When agents author a growing share of changes, a team may be unable to answer a customer, auditor, or new engineer asking who reviewed a change, who approved it, and what was checked. This sample makes no claim about any regulation or certification.
RECOMMENDATION AND CHECK
Record review outcomes, approvals, and the checks run alongside each change, in the repository where the team already works. Check: a representative change can be traced from request to review to approval.
Evidence a real audit would need: recent agent-authored changes, pull-request settings, and what your customers or auditors actually ask of you.
ILLUSTRATIVE EXAMPLEEX-08 / COST DISCIPLINE
Agents spend effort where it does not help.
Fictional snippet, not repository evidence:
AGENTS.md "Read every file in the repository before starting each task."
WHY IT COULD MATTER
Loading everything on every task and retrying failures without limit can raise usage costs and slow work without improving results. This sample does not estimate any saving.
RECOMMENDATION AND CHECK
Route each task to the smallest relevant context, cap rework, and escalate to a person when a task keeps failing, without relaxing review or verification. Check: a representative task shows scoped context and a stated retry limit.
Evidence a real audit would need: instruction files, representative task logs, and your tools' usage reports where available.
ILLUSTRATIVE EXAMPLEEX-09 / PORTABILITY
Your governance is locked to one tool.
Fictional snippet, not repository evidence:
.vendor-tool/config "All project rules, memory, and agents live in this tool's format."
WHY IT COULD MATTER
Tools and models change quickly. If your rules and knowledge live only in one vendor's format, switching or adding a tool means starting over, and teammates on different tools work from different rules.
RECOMMENDATION AND CHECK
Keep rules and knowledge as plain, tool-neutral files in your repository, with thin tool-specific pointers. Check: a second tool, configured from the same files, reads the same rules in an agreed test.
Evidence a real audit would need: every tool in use, where each stores rules and memory, and your plans to add or change tools.
ILLUSTRATIVE EXAMPLEEX-10 / CONFLICTING DOCUMENTATION
Two setup guides disagree.
Fictional snippets, not repository evidence:
README.md "Use Node 22 and pnpm."
docs/development.md "Use Node 20 and npm."
WHY IT COULD MATTER
A teammate or agent can follow either guide and still miss the intended setup. Document presence does not establish which claim is current, and silently choosing one hides the uncertainty.
RECOMMENDATION AND CHECK
Compare the claims with current configuration, lockfiles, CI, and owner decisions. Link the resulting guidance to those sources; keep unresolved conflicts visible with an owner and a next check. Check: Each conflicting setup claim is either resolved with a current source or explicitly marked unresolved. The agreed setup steps are tried in the scoped environment, with results and limits recorded.
Evidence a real audit would need: the conflicting documents, repository configuration and lockfiles, CI setup, relevant owner decisions, and results from trying the agreed setup steps.
ILLUSTRATIVE EXAMPLEEX-11 / CONTINUITY BETWEEN SESSIONS
The next session loses the unfinished work.
Fictional session summaries, not repository evidence:
Session one "Keep the existing API. Tests still need to run; migration needs approval."
Session two "What was decided, and where should I start?"
WHY IT COULD MATTER
Decisions, incomplete checks, and pending approvals can disappear with the previous conversation. A new session may repeat work or treat an unfinished change as ready.
RECOMMENDATION AND CHECK
Keep concise task notes alongside the work: decisions and their sources, what remains unfinished, pending approvals, and the next step. Refresh the notes at handover and check them against the actual project state before resuming. Check: In an agreed restart exercise, a fresh session recovers the decisions, unfinished work, pending approvals, and next step from the saved notes. Record any missing context before continuing.
Evidence a real audit would need: an agreed interrupted task, its saved notes and change state, the relevant decisions and approvals, and observations from a fresh-session restart.
ILLUSTRATIVE EXAMPLEEX-12 / OBSERVED TOOL LOADING
Instruction files exist, but loading is unverified.
Fictional inventory, not repository evidence:
AGENTS.md Shared working rules are present.
Tool settings An instruction-file link is configured.
Check record No observed loading or workflow check is recorded.
WHY IT COULD MATTER
Files on disk and links in settings show that instructions were prepared. They do not establish that the chosen tool loaded them or applied them to a task.
RECOMMENDATION AND CHECK
Run agreed representative workflows in the customer-chosen coding-agent tools. Record the tool versions and settings, source-loading evidence where available, observed behavior, and anything the tool does not expose. Keep file presence, observed loading, and observed behavior distinct. Check: For each agreed tool and workflow, the record shows what was observed and what remains unverified. A tool with no usable loading evidence stays unverified for loading; successful behavior alone does not prove it read a particular file. Results apply only to the tested setup.
Evidence a real audit would need: the instruction files, tool versions and settings, available loading diagnostics or session records, and observations from the agreed workflows.
An example action plan
This order is illustrative. A real plan would rank changes by supported risk, dependencies, and your team's agreed workflows.
Suggested actions, not completed work| Example order | Action | Acceptance check |
|---|
| 1 / EX-01, EX-02 | Introduce independent review and named owner approvals | A representative change shows a distinct review, and risky actions stop for approval |
| 2 / EX-04, EX-12 | Align tool instructions and observe agreed workflows | Rules agree; loading evidence, observed behavior, and unverified limits are recorded for each agreed tool |
| 3 / EX-03, EX-10 | Build source-linked knowledge and resolve conflicting claims | Concepts are indexed and sourced; conflicts are resolved or visible, and agreed setup steps are checked |
| 4 / EX-05 | Define evidence required before “done” | Task records show checks run and open uncertainty |
| 5 / EX-11 | Preserve decisions and unfinished work between sessions | A fresh session recovers decisions, unfinished work, pending approvals, and the next step |
| 6 / EX-06 | Keep, merge, or retire each existing agent | Each retained role has a distinct purpose, scope, and trigger |
| 7 / EX-07 | Record reviews, approvals, and checks with each change | A representative change is traceable from request to approval |
| 8 / EX-08 | Scope task context and bound retries | A representative task shows scoped context and a retry limit |
| 9 / EX-09 | Move rules and knowledge to tool-neutral files | A second tool reads the same rules in an agreed test |
Why this matters now
Coding agents are no longer one assistant in one editor. Teams now run several tools, each with its own instruction files, while agents author more of the code and the models underneath keep changing. Three gaps follow, and an audit looks for each:
- Accountability. Agents move faster than informal review. Who checked a change, and what proved it, needs to be written down.
- Fragmentation. Rules and knowledge scattered across tools and chat threads diverge. One source of truth stays consistent.
- Lock-in and cost. Governance that lives inside one vendor's tool, or that wastes effort on every task, becomes expensive to change.
These are observations about how teams work, not statistics, and the sample makes no claim about any specific company or outcome.
From audit to a governed project
Proposed next steps — hypothetical, not completed results. The audit is the discovery stage of RepoChicken onboarding. Governed onboarding would put the approved plan in place, in stages, with owner approval at each one, preserving current code, tools, and conventions.
- Self-approved changes → independent review: a separate reviewer checks work against acceptance criteria before it is accepted, and rework is bounded before a person steps in.
- Unguarded actions → an approval map: merges, releases, migrations, and other risky actions wait for an owner.
- Scattered context → a knowledge index: Open Knowledge Format (OKF) organizes durable, sourced project knowledge into linked documents that agents and teammates can find.
- Diverging tool files → one source of truth: shared rules that Claude Code, Codex, Gemini CLI, and Copilot read, confirmed in your setup.
- Unproven “done” → recorded evidence: completion shows the checks that ran; anything untested stays labelled.
- Overlapping agents → right-sized roles: the smallest set of specialists your codebase needs.
- No record → a traceable trail: reviews, approvals, and checks recorded where your team already works.
- Wasted effort → cost discipline: scoped context and bounded rework, with verification intact.
- Tool lock-in → portable governance: plain files any tool can read, so you can change tools or models.
- Conflicting documents → visible uncertainty: source-linked guidance, with unresolved claims clearly marked until the evidence or owner resolves them.
- Lost session context → resumable work: saved decisions, unfinished work, pending approvals, and the next step, checked in an agreed restart exercise.
- Files present → observed tool checks: agreed workflows tried in your chosen tools, with loading evidence, observed behavior, versions, settings, and limits recorded separately.
Everything would be delivered as plain files in your repository, with a practical handover to resume tasks, update knowledge, and repeat agreed checks. Verification would cover only the agreed workflows, tool versions, and settings; untested behavior would stay unverified. After handover, nothing would depend on RepoChicken files or tooling. Written rules do not enforce permissions, and no automatic correctness or performance gain is promised.
Your audit would be specific to your repository
A real audit would identify the agreed repository version and agent setup, map the instructions each tool actually loads, and connect supported findings to specific evidence. It would distinguish a governance gap from a prediction about agent behavior. Ratings and priorities would reflect the evidence, not a preset issue count.
The sample demonstrates a format, not delivery history, completed fixes, customer outcomes, or performance gains. Your report would include only findings supported by the agreed evidence. If no actionable problems are found, it would say so. No booking or payment is taken on this website; each engagement requires a written agreement.
How are your agents governed today?
Email us to discuss an audit or onboarding. Tell us which coding tools you use and where agent work goes wrong. Please do not send private code or credentials.
Start a conversation ↗