Govern Coding Agents by Skill

By Rogier Muller06.22.26

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

The best AI coding setup for a mixed-skill engineering team is not one magic agent. It is a small convention that says which skills are safe to reuse, which tools agents may touch, and what proof must appear in review, an approach for mixed-skill teams that keeps receipts.

Agentic coding governance is the set of team rules, review habits, and tool boundaries that make coding agents useful without making their work invisible. For Cursor users, this usually means pairing Cursor rules, AGENTS.md, review checklists, and MCP boundaries into one workflow your team can teach.

That is the practical shape of AI coding for teams: train the workflow, not just the prompt. This fits the broader agentic coding governance pattern we use in AI coding workshops and engineering team training.

Start with one shared convention

Write the convention before you tune individual tools. Cursor Claude Code and OpenAI Codex can all help in different parts of the workflow, but the team needs one common standard for what good agent work looks like.

The useful unit is a skill. A skill is a repeatable capability with a clear task, allowed context, required checks, and review evidence. That might be migrate a React component, add a database index, write integration tests, or update an API client.

Don't let each developer invent their own agent habits. Senior engineers may get great results from loose prompts, while newer engineers copy patterns they cannot evaluate yet. That makes developer productivity look better for a sprint, then shows up later as review churn.

Use one repo-level rubric for every reusable skill. Then let product-specific files point to it: Cursor rules for IDE behavior, AGENTS.md for repository boundaries, and product memory files for tool-specific reminders. That keeps the rubric consistent across mixed-skill teams without locking the team to one tool.

Scope rules where the code lives

Put global rules at the root, and local rules near the code they govern. A frontend package, data migration folder, and billing service should not share one flat instruction file if they have different risk profiles.

A practical repo shape looks like this: root AGENTS.md covers architecture, security, MCP access, and review evidence. A nested packages/web/AGENTS.md covers component conventions. A .cursor/rules/agent-review.mdc file tells Cursor when to ask for tests, diffs, and risk notes.

Watch for stuffing everything into one giant memory file. Agents will either ignore it, overfit to stale context, or apply backend rules to frontend work. Local scope keeps instructions smaller and easier to review.

For Cursor users, make the rule visible in the IDE workflow. If a change touches auth, payments, migrations, permissions, or generated code, the agent should produce a short review note before a human approves it.

Treat MCP as a boundary, not a buffet

MCP, the Model Context Protocol is a standard way for models and agents to connect to external tools and data. In an engineering repo, that might include GitHub, Jira, Slack, docs, Figma, databases, or an internal knowledge base.

Give agents the fewest tools needed for the skill. A doc-update skill may need repository search and docs access. A migration skill may need schema docs and test commands, but not production database write access.

Watch for enabling every MCP server because the demo looks better. Broad tool access turns a coding mistake into a systems mistake. Tool boundaries are part of code review guardrails, not an admin detail someone can clean up later.

Name the boundary in AGENTS.md. For example: agents may read issue trackers and internal docs, may open pull requests, may not post to customer channels, may not mutate production systems, and must ask before using any tool that writes outside the repository.

Paste this skill acceptance rubric

Use this as the first team convention. It gives senior engineers a reviewable standard, and it gives newer developers a safe path for learning agentic coding without pretending every task is equally safe.

# Agent Skill Acceptance Rubric

Owner: Engineering team
Applies to: Cursor Agent, Claude Code, Codex, and other coding agents used in this repo
Review cadence: update during architecture review or after any agent-caused incident

## Skill record

Skill name:
Primary use case:
Allowed directories:
Disallowed directories:
Allowed tools and MCP servers:
Required human approver:
Rollback plan:

## Acceptance levels

## Level 0: Not approved
- The agent may explain the task, but may not edit code.
- Use this for auth, billing, privacy, migrations, security-sensitive code, and unfamiliar production paths until reviewed.

## Level 1: Draft only
- The agent may create a draft diff.
- A human must inspect every changed file before tests or commits.
- The PR must include a short note explaining assumptions and unknowns.

## Level 2: Test-backed change
- The agent may edit code and run approved local tests.
- The PR must include changed files, commands run, test results, and remaining risks.
- The reviewer checks that tests cover the behavior, not just snapshots or generated output.

## Level 3: Routine supervised change
- The agent may perform this task when the issue matches the skill description.
- The agent must keep changes inside allowed directories.
- The reviewer samples the diff, verifies receipts, and confirms no boundary was crossed.

## Cursor rule stub

Create this file at .cursor/rules/agent-skill-review.mdc:

---
description: 'Shared Cursor skills need boundaries a reviewer can inspect, with different acceptance criteria for routine and sensitive changes.'
alwaysApply: true
---

When using an agent for code changes:
- Name the skill and acceptance level before editing.
- Stay inside the allowed directories for that skill.
- List any MCP server or external tool used.
- Before review, produce a receipt with files changed, commands run, test results, and unresolved risks.
- Ask for human approval before touching auth, billing, permissions, production data, secrets, or migrations.

## AGENTS.md boundary

Agents may:
- Read repository files and approved docs.
- Run documented local test commands.
- Propose pull requests with review receipts.

Agents may not:
- Change production data or secrets.
- Expand MCP access during a task.
- Merge their own PRs.
- Hide generated code, failing tests, or skipped checks.

## Review checklist

Before approving an agent-authored PR, confirm:
- The skill and acceptance level are named.
- The diff stayed inside allowed scope.
- The receipt lists files changed, commands run, and test results.
- Risky areas have a human approver.
- The reviewer can explain the change without trusting the agent summary alone.

Adoption is simple. A developer proposes a new skill in the rubric, the owning team reviews the level and boundaries, and the convention lives in the repo where daily work happens. For larger teams, review new Level 2 and Level 3 skills in architecture review so the standard does not drift by squad.

The enforcement rule is even simpler: no receipt, no approval. A pull request written with a coding agent should show the skill used, the acceptance level, the tools touched, the checks run, and the risks left open. For a deeper version of that review habit, see AI Code Review Needs a Receipt.

Train the team on review moves

AI coding training should not start with prompt tricks. Start with review moves: ask for a plan, constrain the edit, inspect the diff, run the check, and make the agent explain remaining risk.

This helps diverse teams because the convention separates skill growth from production permission. A newer developer can use a Level 1 draft skill to learn a subsystem. A senior developer can approve the same skill at Level 2 after tests and boundaries are clear.

Don't measure success only by lines shipped. Coding agents can increase output while lowering shared understanding. A good AI coding workshop should leave the team with fewer mystery diffs, not just faster demos.

Review the rubric monthly at first. Remove skills nobody uses, downgrade skills that caused review surprises, and promote skills only when receipts are boring and repeatable.

Make the first skill boring

Pick one low-risk task this week, add it to the rubric, and require receipts on every agent-authored PR. Once that feels boring, you can safely decide what deserves more autonomy.