🛡️ Playbooks, Skills, Rules, and Governance

A reusable procedure for a recurring task, written as a sequence of steps with inputs, outputs, and a completion criterion.

The playbook is what makes results repeatable across people and agents—and where the team’s knowledge stops depending on whoever is on call.

Ordered steps > generic principles · One playbook per recurring task · It evolves with feedback from practice.

Read the specification → confirm scope → map impact → create a plan → implement the smallest change → create tests → run quality gates → review → document → prepare a pull request.

It’s the standard path for new work. Writing this down eliminates the quality variation between Monday and Friday.

Confirm scope before coding · Mapping impact reveals what breaks · Documentation is part of done.

Reproduce the error → record evidence → identify the cause → create a failing test → implement the fix → run regression tests → review the impact → document.

The order matters: without reproduction, you fix what you imagine; without a test that fails first, there’s no proof the bug is gone.

Reproduction is the first step · A test that fails beforehand = proof · Regression testing closes the loop.

Map dependencies → create characterization tests → define boundary → create adapter → migrate a small module → run in parallel → compare results → release gradually.

This is Track 4 condensed into a procedure—the format in which it’s actually used day to day.

One module at a time · Compare before switching · Gradual rollout keeps rollback available.

Collect logs → classify severity → preserve evidence → identify the likely cause → create a mitigation → validate → apply the fix → record what you learned.

Under pressure, no one improvises well. The playbook keeps the first reaction from erasing the evidence of what happened.

Preserve before acting · Mitigation ≠ correction · Recorded learnings become a rule or gate.

The practice of reviewing the playbook whenever it fails in practice—and keeping it in the repository, versioned like code.

A playbook that isn’t used grows stale and gets in the way: the agent follows a procedure that no longer describes the system.

Did it fail in practice? Update it · Versioned in the repository · Few and good > many and dead.

A reusable capability that guides the agent through a specific task: analyzing a repository, generating a specification, creating a plan, reproducing a bug, generating tests, reviewing architecture or security, or preparing a PR.

A skill is the playbook in a format the agent can consume directly — so you no longer have to paste the same prompt every week.

Skill ≈ executable playbook · One task per skill · Reuse reduces variation in quality.

Objective, when to use it, inputs, tools, steps, acceptance criteria, prohibited actions, failure handling, output format, and required checks.

"When to use" and "prohibited actions" are the fields that separate a useful skill from a saved prompt — the first helps the agent choose correctly, the second prevents harm.

When to use > what it does · Output format makes the skill composable · Required verification closes the loop.

The prioritization criterion: start with the tasks you repeat often and that currently produce inconsistent quality.

A skill for a rare task is maintenance with no return. A skill for a weekly task pays for itself in the first week.

Repetition justifies packaging · More variation = greater benefit · Start with 3 to 5 skills, not 30.

Permanent or conditional rules that limit agent behavior—never change tests to hide a failure, never insert secrets, don’t deploy without approval, don’t refactor outside the scope.

Rules reduce arbitrary decisions. They don’t depend on you remembering to write the same prohibition in every task.

Skill = capability, rule = boundary · Rules apply to every task · Few and clear > many and ignored.

The hard core: don’t expose secrets, preserve public APIs, don’t remove security logs, don’t modify the production database directly, and produce evidence of the tests.

These are the rules whose violation is costly and hard to reverse—they deserve to be written down and, when possible, turned into gates.

Critical rules also become checks · Public APIs are contracts · Evidence is required, not a courtesy.

Rules that set attempt limits, cost caps, approval requirements before destructive actions, and a ban on refactoring outside the scope.

It’s where governance meets the loop: the rule is the written, permanent version of the limits you configured in Track 2.

Written limits apply to every agent · Destructive actions require a human · A rule without verification depends on obedience.

The set of controls that defines how AI can operate within the company: identity, permissions, responsibilities, auditing, logs, costs, environments, data, prohibited actions, and incident handling.

Without governance, adoption happens haphazardly—and the organization discovers its rules after the first incident.

Governance enables, it doesn’t just prohibit · Written controls > implicit norms · It needs to fit into the workflow.

Dedicated credentials, minimum access scope, declared responsibilities, and an audit trail for each action.

An agent running with someone's personal credentials makes auditing and accountability impossible—and grants access that no one reviewed.

Always use a distinct identity · Least privilege · Every action traceable to whoever authorized it.

Spending limits per team and task, authorized execution environments, which data may enter the context, and the retention policy.

Personal data or secrets in a third party’s context are a privacy incident, not a technical detail—and uncapped costs turn into a surprise when the monthly bill comes.

Sensitive data never goes into the context · Authorized environment is a short list · Cost per task is a management metric.

Level 1 assistance (only suggests) · 2 supervised execution (each important action approved) · 3 controlled execution (bounded tasks with quality gates) · 4 limited operational autonomy (complete workflows within rules and environments) · 5 critical autonomy.

Level 5 shouldn’t be adopted without extremely rigorous controls. Knowing where you are prevents confusing conversations about “whether to use AI.”

The level applies to a type of task, not a company · Moving up a level requires the previous level’s controls · Level 5 is a limit, not a goal.

The process of giving a type of task more autonomy based on metrics: approval rate without corrections, incidents caused, cost per task, and review time.

Autonomy granted in a burst of enthusiasm is taken back at the first scare — and then the team also loses what was already working.

Measure before promoting · Bounded pilot · Reverting is also a valid decision.

A short document that answers: who the agent is, what it can access, what it can do on its own, what requires approval, how much it can spend, what gets recorded, and who is accountable.

It’s the artifact that makes it possible to scale AI use to other teams without repeating the entire discussion each time.

One page, not a manual · Periodic review · Without an owner, governance doesn’t exist.