Repo-Embedded Skills for Database Teams

If the rule matters during review, it belongs in the repository where the agent can read it. Database teams carry a lot of implicit knowledge: which tables are too large for blocking DDL, which accounts are break-glass only, which dashboards prove a rollout is safe, and which rollback path is acceptable for each schema change.

Situation

Database teams carry a lot of implicit knowledge: which tables are too large for blocking DDL, which accounts are break-glass only, which dashboards prove a rollout is safe, and which rollback path is acceptable for each schema change.

The pattern matters for database, cloud, and platform teams because agents do not operate in a vacuum. They inherit repository rules, tool permissions, deployment workflows, incident history, and the quality of the evidence available to them.

Operating layer	Default approach	Better alternative
Context	Rely on a long prompt or chat history	Give the agent task-specific evidence and rules
Tooling	Expose broad tools and inspect later	Expose narrow tools with clear approval boundaries
Verification	Read the final answer	Check the artifact, trace, and final state

The Problem

Implicit knowledge does not survive agent execution. If the agent cannot read the rule, it cannot reliably follow it. Prompting the rule by hand in every session creates drift and makes review impossible.

The practical question is not whether an agent can produce a convincing response. The question is whether the engineering system around that response makes the work observable, reversible, and reviewable.

Failure point	What breaks	Why it matters
Weak boundary	Agent authority is broader than the task	A diagnostic run can become an unsafe change
Missing evidence	The agent cannot cite the state it used	Review becomes opinion instead of verification
No lifecycle	The workflow ends at a message	Ownership, audit, cleanup, and rollback disappear

Repository Skill Backbone

Store skills beside the code: migration review rules, incident triage steps, Terraform plan review guidance, test commands, and abort conditions.

flowchart TD
    A[task request — bounded intent] --> B[repository skill backbone — controls]
    B --> C[tool execution — evidence collected]
    C --> D[verification — final state checked]
    D --> E[human handoff — audit retained]

1. Define the operating boundary.
   Write down the task class, allowed tools, environment, data class, and approval mode before the agent runs.

2. Shape the evidence.
   Return compact observations instead of raw dumps. The agent should see enough to reason, but not so much that context is wasted.

3. Require proof of completion.
   Completion should be an artifact or state check: a passing test, a reviewed plan, a valid rollback, a trace, or a linked ticket.

Create a skills or AGENTS.md layer that tells the agent how this repository works, which scripts are authoritative, and what proof is required before it can claim completion.

In Practice

Context: OpenAI’s harness engineering discussion emphasizes repository skills, local scripts, and environment-specific guidance as part of the system around Codex. That makes repo-local instructions part of engineering infrastructure. Source: OpenAI, Harness engineering.

Action: Create a skills or AGENTS.md layer that tells the agent how this repository works, which scripts are authoritative, and what proof is required before it can claim completion.

Result: When the rule is versioned, every change to the agent operating model can be reviewed like code.

Learning: Store skills beside the code: migration review rules, incident triage steps, Terraform plan review guidance, test commands, and abort conditions. This is a documented pattern or a direct consequence of how the named systems behave, not a fabricated production story.

Where It Breaks

Failure mode	Trigger	Fix
Tribal policy	Only senior engineers know the rule	Move rules into repo-local instructions
Stale prompts	Different users paste different guidance	Version shared skills with the code
Script ignorance	Agent invents commands instead of using local scripts	Document canonical scripts and expected outputs
No stop conditions	Agent keeps trying unsafe alternatives	Write explicit abort conditions

What to Do Next

• Problem: Implicit knowledge does not survive agent execution. If the agent cannot read the rule, it cannot reliably follow it. Prompting the rule by hand in every session creates drift and makes review impossible.
• Solution: Store skills beside the code: migration review rules, incident triage steps, Terraform plan review guidance, test commands, and abort conditions.
• Proof: When the rule is versioned, every change to the agent operating model can be reviewed like code.
• Action: Add one repository-local agent guide for migrations: allowed commands, rollback requirements, lock-risk rules, and proof of completion.

The teams that get value from agents will not be the teams with the longest prompts. They will be the teams that turn agent work into a controlled engineering workflow.