Skills make judgement reusable

Data access is not operating knowledge

Most AI rollouts start by wiring models into systems of record: Slack, GitHub, Jira, the service catalog, observability tools, CRM notes, and internal docs. That work matters. An agent that cannot see the estate is guessing.

But raw access has a ceiling. A model can read every incident ticket and still write a postmortem that confuses symptoms with causes. It can inspect every deploy and still miss the migration that made rollback unsafe. It can summarize every customer thread and still fail to notice the one sentence that turns a small support issue into an executive escalation.

The missing ingredient is not another connector. It is the way experienced people frame the work before they touch the connector.

What a skill actually captures

A prompt is a request for this moment. A skill is a reusable work pattern for a class of moments. It tells an agent when the pattern applies, what inputs to gather, how to reason through the task, what mistakes to avoid, and what a finished output must include.

A useful skill usually has six parts:

• Trigger: the situations where the agent should load the skill.
• Inputs: the records, metrics, docs, ownership data, or tool results that must be present before reasoning starts.
• Procedure: the ordered path an expert normally follows.
• Judgement checks: the trade-offs, thresholds, red flags, and disqualifiers that separate good work from plausible output.
• Examples: short cases showing what good, weak, and unsafe responses look like.
• Quality bar: the evidence and handoff format required before the task is done.

That structure is why skills matter more than a longer system message. The goal is not to make an agent sound more like your team. The goal is to make it run the same decision routine your team already trusts.

Example: incident triage as a skill

Consider an on-call agent that receives an alert for elevated checkout latency. Without a skill, it may paste together logs, recent deploys, and generic advice. With an incident triage skill, it follows a narrower path:

1. Classify customer impact before chasing root cause.
2. Pull the service owner, dependency map, active incidents, and recent changes.
3. Compare symptoms against deploy timing, saturation, vendor status, and queue depth.
4. Separate confirmed facts from hypotheses.
5. Recommend the next reversible action, owner, and verification signal.

The judgement checks are where the value lives: do not assume the latest deploy is guilty just because it is nearby in time; do not suggest rollback if the migration is irreversible; do not page the database team until the dependency graph and saturation signals support that handoff; do escalate customer communication when impact crosses the status-board threshold, even if root cause is still unknown.

That is not generic incident advice. It is a reusable slice of how a specific organization wants production triage to run.

Example: rollback readiness as a skill

Rollback sounds simple until the agent touches real systems. A rollback skill should not say "revert the deploy if errors rise." It should encode the questions a careful release engineer asks before recommending any change:

• Was there a schema migration, data backfill, or one-way queue event after the release?
• Are feature flags available to isolate the behavior without reverting the whole build?
• Which canary or synthetic checks prove the rollback improved customer experience?
• Who must approve rollback for this service tier, region, or customer segment?
• What should be written to the incident timeline before execution?

This is where skills connect to the harness. The skill can teach the agent how to assess rollback. The harness decides whether the action is allowed, routes approvals, runs dry checks, and records the audit trail.

A skill file should feel operational, not literary

The best skills are boring in the same way good runbooks are boring: specific, testable, and easy to update. A skill does not need a grand theory of the business. It needs enough structure to make repeated work come out consistently.

name: production-rollback-assessment
when_to_use:
  - User asks whether to roll back a production release
  - Error budget burn or customer-facing latency spikes after deploy
required_context:
  - service owner and tier
  - release diff, migration notes, feature flags
  - current incident state and change-freeze policy
  - canary, synthetic, and customer-impact signals
steps:
  1. State confirmed impact before root-cause guesses
  2. Check whether rollback is technically reversible
  3. Prefer feature-flag disablement when it narrows blast radius
  4. Identify approval requirements before proposing execution
  5. Define verification signal and rollback stop condition
judgement_checks:
  - Do not recommend rollback across irreversible migrations
  - Do not treat deploy timing as proof without supporting signal
  - Require human approval for tier-0 or regulated workloads
done_when:
  - Recommendation includes action, risk, owner, evidence, and audit note

Notice the shape: the skill is not trying to be clever. It preserves the constraints that experts remember under pressure and newcomers often learn the hard way.

Better examples make better skills

Weak skills describe an ideal path. Strong skills include the awkward cases. If the only example is clean, the agent learns to expect clean work.

The strong examples teach the agent what your organization notices. They also make review easier: a human can point at the skill and say which judgement check was missing instead of rewriting the entire answer by hand.

Skills sit between context and control

Skills do not replace retrieval, tools, or policy. They organize them. A production agent still needs live context from the service catalog, CI/CD, Kubernetes, observability, and incidents. It still needs a governed action layer that blocks unsafe changes. The skill tells the agent which parts of that world matter for this type of work and how to weigh them.

That is why skills pair naturally with progressive disclosure. Keep lightweight skill metadata available, load detailed instructions only when the task calls for them, and let the harness measure cost per completed workflow rather than stuffing every rule into every turn.

How to build the first three

Start where expert judgement already changes outcomes. The right first skill is rarely "summarize docs." It is a workflow where two people with the same data produce very different results.

1. Pick one repeated workflow with visible stakes: incident triage, release readiness, support escalation, security review, customer handoff, or capacity change.
2. Replay three real cases: one clean, one messy, one that went wrong. Extract the decision points, not just the steps.
3. Ask the owner what would make them stop: missing evidence, approval requirements, untrusted source, customer impact, irreversible action, or ambiguous scope.
4. Write the smallest skill that would have improved those cases. Add examples and a quality bar before adding more prose.
5. Run it in review mode first. Let the agent propose, let humans correct, and fold corrections back into the skill.

A team does not need a giant skill library to see value. Three well-owned skills in high-leverage workflows will outperform fifty vague templates.

Closing frame

The durable AI advantage is not only which model you buy or how many systems it can read. It is how much of your organization's way of working you can turn into reusable, reviewable, improvable skills.

Documents make facts available. Tools make actions possible. Harnesses make actions safe. Skills make judgement reusable.