agentleFS
markoblogomarkoblogo/abvx-agent-skills/skills/agent-tool-contract-review/SKILL.md

agent-tool-contract-review

Skill16 starsChanged 5 months agoMITView on GitHub

Review tools, MCP functions, CLI commands, SET inputs, and AGENTS.md generator outputs as agent-facing contracts. Use when a tool description, schema, workflow input, or generated instruction may be ambiguous, unsafe, noisy, or hard for agents to call correctly.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to make a tool easier and safer for agents to call.

    line 12
  2. Very specific:

    Before writing an adapted external skill, classify each material source fragment in templates/adaptation-delta.yaml:

    line 24
  3. Very specific:

    Every entry requires a stable ID and source fragment reference.

    line 31
  4. Distinctive:

    Check whether the name, description, schema, and examples make the safe path obvious.

    line 47
  5. Distinctive:

    Check whether the output can be consumed without reading a large log.

    line 48
  6. Distinctive:

    Check error paths and retry semantics.

    line 49
  7. Distinctive:

    Do not redesign the whole tool when a schema or description change is enough.

    line 65
  8. Distinctive:

    Do not hide write or destructive behavior behind friendly wording.

    line 66
  9. Distinctive:

    Do not require agents to infer defaults that can be encoded in schema.

    line 67
  10. Distinctive:

    Do not make logs the primary machine interface when structured output is feasible.

    line 68
  11. Distinctive:

    Do not silently omit or rewrite upstream behavior during adaptation.

    line 69

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Tool Contract Review

Use this skill to make a tool easier and safer for agents to call.

Use When

  • designing or reviewing MCP tools, CLI wrappers, GitHub Actions inputs, or SET planner outputs;
  • changing AGENTS.md generator templates that tell agents which commands or tools to use;
  • a tool has ambiguous parameters, hidden side effects, noisy output, or weak error messages;
  • agent runs repeatedly misuse a command or need human intervention after avoidable failures.
  • adapting an external skill, contract, or workflow into the local skill network.

Adaptation Delta

Before writing an adapted external skill, classify each material source fragment in templates/adaptation-delta.yaml:

  • KEEP: retain source mechanics or schema without semantic change;
  • ADAPT: change paths, tools, authority, terminology, or environment assumptions;
  • ADD: introduce local guardrails, routing, verification, or project boundaries;
  • REJECT: exclude a fragment and record the reason plus source reference.

Every entry requires a stable ID and source fragment reference. Present the complete delta to the owner before writing. Record APPROVED, REVISE, or REJECTED; silence is not approval. Preserve attribution and license constraints independently of the classification.

Review Dimensions

  • purpose: what job the tool owns and what it does not own;
  • schema: required fields, optional fields, enums, defaults, and validation;
  • authority: read-only, proposal-only, write, destructive, external side effect;
  • output: compact, structured, parseable, and stable enough for downstream agents;
  • errors: actionable messages with the smallest useful recovery step;
  • idempotency: safe retries, duplicate handling, and idempotency keys when needed;
  • auditability: logs, dry-run mode, preview mode, and human approval boundary.

Workflow

  1. Identify the agent-facing tool surface and its intended caller.
  2. Classify the authority level: read, plan, proposal, write, or destructive.
  3. Check whether the name, description, schema, and examples make the safe path obvious.
  4. Check whether the output can be consumed without reading a large log.
  5. Check error paths and retry semantics.
  6. Recommend the smallest contract change: rename, tighter schema, dry-run, better error, structured output, or approval gate.

Output Shape

Use:

  • verdict: CONTRACT_OK, CONTRACT_AMBIGUOUS, or CONTRACT_UNSAFE;
  • tool surface reviewed;
  • authority level;
  • contract findings;
  • smallest contract changes;
  • tests or smoke checks.

Guardrails

  • Do not redesign the whole tool when a schema or description change is enough.
  • Do not hide write or destructive behavior behind friendly wording.
  • Do not require agents to infer defaults that can be encoded in schema.
  • Do not make logs the primary machine interface when structured output is feasible.
  • Do not silently omit or rewrite upstream behavior during adaptation.

Provenance

Adapted from tool-design patterns in muratcankoylan/Agent-Skills-for-Context-Engineering, plus MakerSkills' explicit keep/adapt/add porting report. Narrowed for SET, AGENTS.md generator, MCP, CLI, and provider-neutral skill adaptation, with an added REJECT disposition and owner gate.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.