governed-agent-skills

Your agent isn't careless. It's grading its own homework.

License plugin skills starters patterns

Give your AI coding agents a constitution, a working method, a minimum-sufficient implementation lens, and an enforcement layer — so the agent that builds a thing is never the agent that approves it. Four skills, two lightweight starters for surfaces with no skill mechanism, and a hook that blocks catastrophic shell commands before they run.

Governed Agent Skills

Built and maintained by Ezra Israel · X. These skills govern the agent teams in daily use.

Who this is for — and who it isn't

These skills were built to govern teams of coding agents: agents that write code, review each other's work, and change repositories. That is where the constitution and the review loop earn their keep — when an agent's mistake can reach a codebase, a deploy, or a canonical record.

If your agents do other work — marketing copy, listings, research, design, operations — most of this package is heavier than you need. Take reasoning-doctrine (the working method: verify before asserting, never build on unconfirmed facts, catch drift on long tasks — it applies to any kind of work) and leave the constitution and review loop until the day your agents touch real code.

An honest scope statement beats a broad one. If you install only one file from this repo, install reasoning-doctrine.

What a "seat" is

A seat is a role an AI agent occupies for one session — not a person, and not a job title. The humans in your life are not seats. You, the human, are the operator: the one who owns the outcome, makes the decisions, and says what "done" means. Every seat is filled by an agent working for you.

Any agent can fill any seat: Claude, ChatGPT, Codex, Gemini, a local model — whatever you use. The same product can even fill two seats, as long as it's two separate sessions with separate context. What matters is never which vendor sits down; it's that the agent that BUILT a thing is not the agent that APPROVES it.

A concrete day with one person and two agents:

  1. You tell an agent what you want (you = operator; it drafts the plan = orchestrator seat).
  2. A second agent — or just a fresh session of the first — attacks the plan before anything is built (pressure-test seat).
  3. An agent implements it (builder seat). It never approves its own work and never publishes.
  4. A different session reviews the result against the plan (reviewer seat) and returns accepted / needs revision / blocked.
  5. You verify it works on the real surface, and you press the button that ships it. Publication is always yours.

Solo mode: with one person and one agent, the constitution collapses to "operating solo: owner + orchestrator" — no ceremony, and low-stakes work passes on an honest, labelled self-check. The seats come back one at a time as the stakes rise: the first one worth adding is a fresh-session reviewer for anything you'd hate to ship broken.

Why bother? Because an agent grading its own homework misses the same things twice. Seat separation is the cheapest independent check that exists: it costs one extra session.

(The Q0–Q5 phase model elsewhere in the constitution applies only to installing doctrine or configuration across multiple surfaces — it is not a checklist for ordinary work. Ordinary work is done when you verify it on the real surface.)

What's here

Full Skills

Skill Purpose Files
skills/governed-operator/ Governance constitution — seats, 5 gates, role integrity, outcome autonomy SKILL.md
skills/reasoning-doctrine/ Working method — stage loop, re-anchor, effort dial, anti-drift SKILL.md + 3 references
skills/write-maintainable-code/ Minimum-sufficient implementation — code/no-code routes, ownership seams, speculative-concept control SKILL.md
skills/run-review-repair-loop/ Bounded self-review with 1–5 scoring before handback SKILL.md

Universal Starter (Lightweight)

File Purpose
universal-starter/governed-operator-universal-SKILL.md Core constitution, minimal ceremony
universal-starter/reasoning-doctrine-universal-SKILL.md Core working method, self-contained

Patterns (Enforcement)

Not skills — these are working code you install and wire, for the jobs instructions cannot do. The skills tell you to pair them with real enforcement; this is that enforcement.

Pattern Purpose
destructive-command-guard/ Pre-execution hook that denies catastrophic shell commands before your agent runs them. Works on Claude Code, Codex, and Antigravity from one file — it detects each surface's payload shape and answers in that surface's deny format. Python, no dependencies, with a regression suite and a built-in sentinel for proving it's live.

How to use

  1. Copy the skill directories into your agent's skills folder.
  2. Load governed-operator for governed work (planning, reviews, dispatches).
  3. Load reasoning-doctrine for any nontrivial task.
  4. After the outcome, acceptance evidence, scope, and authority are fixed, load write-maintainable-code to compare implementation routes and enforce the selected route.
  5. Load run-review-repair-loop for self-review before independent review.
  6. References load automatically when their trigger fires.

Recommended load order: constitution, method, implementation lens when a fixed result needs an implementation decision, then review loop after the change.

Progressive loading

reasoning-doctrine uses progressive loading:

  • Core mechanisms load resident
  • Situational references load on trigger, not upfront
  • This preserves context budget for the task at hand

Install as a Claude Code plugin

/plugin marketplace add Ezra144israel/governed-agent-skills
/plugin install governed@ezra-governed

Skills load namespaced (e.g. /governed:reasoning-doctrine). Manual installation — copying skills/* into ~/.claude/skills/ — still works exactly as before; see INSTALL.md.

Install in other agents

This repo also ships an Agent Plugins manifest. Install support varies by surface — these are the documented routes:

Route status — updated as surfaces are run in practice, not on documentation:

  • Claude Code (plugin route): verified in practice.
  • GitHub Copilot CLI (v1.0.78, direct repo install): verified in practice — skills invoke on-topic and reference files load from the plugin's own install directory. Note: current CLI builds mark direct repo installs as deprecated; a marketplace-based route may be required in future versions.
  • VS Code (Agent Plugins install): plugin installs and its skills list correctly; chat-side invocation could not be attributed to the plugin (probes were answered by the user's personal skills copies, which shadow same-named plugin skills). Copilot CLI, sharing the same plugin store, is fully verified.
  • Codex / ChatGPT desktop, Cursor: documented by their vendors, not yet run by the maintainer.
  • Manual copy (folders under skills/ into your agent's skills directory): verified in practice on Kimi, Grok, and Antigravity.

Confirmations and failure reports on any route are welcome.

A note on what "verified" covers: skills are invoked when a request matches their description — they are not command-level enforcement. For hard blocking of destructive commands, see destructive-command-guard/.

GitHub Copilot CLI:

copilot plugin install Ezra144israel/governed-agent-skills

VS Code (Copilot): enable the chat.plugins.enabled setting, then Command Palette → "Chat: Install Plugin From Source" → paste this repo's URL. (Preview feature; may be disabled by your organization.)

Cursor CLI: run agent, then /plugin, paste this repo's URL, choose scope.

Codex / ChatGPT desktop:

codex plugin marketplace add Ezra144israel/governed-agent-skills

then /plugins → source "ezra-governed" → install "governed" → start a new session.

Cursor desktop and ChatGPT web: not yet directly installable — these require marketplace/directory listing. Until then, manual install works everywhere: copy any folder under skills/ into your agent's skills directory.

License

MIT