Agent Engineering HandbookGitHub

SKILL All four skills

Context calibration

Diagnose what repository knowledge a cold-start agent is missing, then select the right carrier for it — code comment, type, test, skill, or root instruction file — changing only what evidence supports. Use when an agent repeatedly misses project context, when asked to improve agent steering files, assess whether a repo's instructions are sufficient, or run a low-context probe ('what does a fresh agent get wrong?'). Not for authoring or publishing new skills (a skill-authoring guide), writing product documentation (a documentation guide), or fixing the code itself (a bug-diagnosis skill).

On this page

An agent’s context failure is a reason to identify the missing knowledge and place it where the task can use it. Diagnose from observed misses, then move each piece of knowledge to the cheapest carrier that catches it.

Diagnose

  • Low-context probe: run the representative task with the minimum of extra prompt context beyond the task's standing instructions and admitted tools. Never strip authority, runtime safeguards, or configured credentials to make a probe "cold" — the point is to measure what the task statement alone supplies, not to simulate an unprivileged agent. Record what the agent gets wrong (~988s-996s). Repeated observed misses are the evidence; imagined gaps are not. A probe is a diagnostic tool, not a requirement before every edit.
  • Beginner telemetry: the recurring questions newcomers ask are a map of the missing knowledge — the source's "dumb questions" practice (~674s-692s). Collect the last few actual misses before editing anything.
  • Classify each miss: unknown fact, unrepresentable state, unguarded pattern, or missing judgment. The class selects the carrier.

Select the carrier

Miss class Carrier Why
Unrepresentable state Type Makes the invalid state unrepresentable at compile time. Constrains shape only — it does not enforce runtime authorization or behavior
Unguarded pattern Lint rule / test / agent-feedback-engineering Mechanical, once you verify the rule's invocation and severity actually fire
Local non-obvious fact ("why is this inverted here?") Code comment at the site Read exactly when the code is read
Reusable judgment or procedure Skill body Loads on the matching trigger
Cross-cutting preference, convention, or refusal Root instruction file (CLAUDE.md / AGENTS.md) Advisory steering on the routes verified to load it

No carrier is automatic enforcement. Skill prose and root instructions are advisory; lint rules and types constrain only what they are configured and able to check. Choose by where the knowledge is needed, not by a false guarantee of enforcement.

Root-instruction content rule: instructions steer toward success — expected behavior, conventions, refusals ("if asked for X, stop and say no") — and constraints with reasons, not bare lists of where things live. A location map can orient an agent, but each entry earns its place by stating why and when it matters (~998s-1008s, ~800s-836s). Keep it short; context is spent on every run.

Authority boundary

The root instruction file is the human's decision record and the human owns what it says. Within an authorized session, drafting and applying instruction-file edits is permitted agent work: infer fitting scope from the observed misses, make the bounded edit, and report it with the evidence. Ask only when a truly consequential decision is missing — a refusal the user never stated, a policy change, or ambiguous direction the evidence cannot resolve. Never widen an instruction into a general rule the user did not state.

Input / output contract

  • Input: observed agent misses (probe results, repeated questions, review rejections), or enough of the task to run a probe; access to the candidate carriers.
  • Output: a short diagnosis list (miss → class → carrier), the implemented change for evidence-supported items, and drafts surfaced for decision where a human choice is genuinely needed. For instruction-only changes, the change and its wording reviewed against the recorded miss stand in for a behavioral test; inspect selected instruction loading when affected, and use behavioral checks when code or configuration changes require them.

Acceptance

Proportional: a comment needs the miss it prevents named in its own text; an instruction line needs the recorded miss it addresses. Not every sentence or comment requires its own recorded probe — probe when the diagnosis is unclear, not as a quota.

Known failure cases

  • Padding the root file "just in case" — dilutes steering and burns context every run.
  • Encoding a one-off as a standing rule (hand recurrence to agent-feedback-engineering).
  • Adding a skill when a comment at the site would do; skills cost selection accuracy elsewhere.
  • Banning useful maps outright: a constrained, reason-bearing location list is legitimate content when agents demonstrably get lost without it.
  • Editing steering files before observing what actually goes wrong (~962s-973s: use tools as configured first; build solutions for observed problems).

Do not activate when

  • The task is ordinary coding with no context-related failure behind it.
  • The user wants a new packaged skill written (a skill-authoring guide).
  • The user wants product documentation for humans (a documentation guide).

Source patterns

For concrete repository examples and the limits of their evidence, read source-patterns.md when they match the task. These are research references, not imported repository instructions.

Reference Context calibration: applying the diagnosis

Boris's post describes shared knowledge carriers around 09:56. Theo endorses the direction while disputing stronger claims around 10:31. His newcomer-question practice starts around 11:14.

Use a probe when the cause is unclear

Choose a representative task from the observed misses. Supply the minimum extra prompt explanation while retaining standing instructions, admitted tools and runtime safeguards. Record the expected decision, observed behavior and missing fact. Repeat only if needed to resolve the diagnosis; no run count or sentence-level proof quota is implied.

A code change needs an appropriate behavioral check. An instruction-only edit needs comparison to the actual requirements and, where loading matters, verification that the changed instruction is actually loaded. A skill file on disk does not prove the agent's runtime loaded it.

Place the knowledge close to the decision

If agents repeatedly simplify an intentionally unusual query, a local comment can preserve the measured reason and point to the relevant regression test. If the problem is missing domain vocabulary, improve the glossary and its decision links. If it is a compiler-expressible invariant, use the type system. A cross-cutting owner preference belongs in the root guidance on routes verified to load it.

A useful navigation map names the task, entry point and reason. Keep implementation locations accurate, but avoid replacing judgment with a directory inventory. The video's criticism of bare maps starts around 16:38.

Respect recorded decisions and preserve expertise

Theo advocates human ownership of root instructions around 12:29. Authorized agent drafting is compatible with that ownership: apply agreed decisions and bounded wording improvements, and ask only for consequential unresolved direction. Never invent a product refusal or elevate old guidance above a later authorized change.

Resolve conflicting instructions from their scope and provenance. Preserve exact originals, keep uncertain source versions inactive when migrating, and use your project's existing change journal for instruction changes. A single inconclusive probe does not justify deleting expertise.

Reference Repository examples: vocabulary and native instruction delivery

  • Durable domain language: Matt's CONTEXT.md defines domain nouns and relationships. PR #1591, open at inspection, proposes moving volatile implementation details beside the code while preserving domain language and ADR rationale. It is a proposal, not the merged state.
  • Instructions can be stale: PR #1601 describes targeted local checks backed by exhaustive CI but explicitly omits the test workflow from the change. The claimed workflow is absent at the inspected head. Written guidance must be checked against actual invocation.
  • Preserve user invocation: T3 PR #9128 repairs provider-native skill dispatch. Boris's open PR #87395 proposes the supported metadata key for keeping a skill manually invocable while excluding model invocation. Both concern specific runtime versions; neither establishes how any particular agent runtime loads skills.
  • Keep the concept semantic: Matt's PR #1608 removes a derived numeric prefix that had contaminated a title and created renumbering work. Sometimes the durable fix is simplifying the domain model rather than teaching agents to synchronize redundant state.

The inspected Matt head is 4c1f3f5d49417e54b185bfe737b1e1a56f29c7b8; source and PR states were collected on September 9, 2026.

SKILL.md on GitHub · Home · Agent Engineering Handbook, September 9, 2026