Claude Skills for AgTech: How to Package Your Domain Knowledge Into a SKILL.md File

Claude Skills give agtech teams a way to teach an AI coding assistant the domain knowledge that lives only in their senior engineers’ heads — crop-specific conversion factors, vendor-specific ISOXML quirks, which sensor gateway lies about its own timestamp format. Here’s what happened before that existed.

You’re deep in an AI coding session, the assistant is flying through a yield data parser, and then it confidently converts bushels per acre to tonnes per hectare using the wheat factor — on a canola dataset. The demo is tomorrow. The client is European. The numbers are wrong by 12%.

The AI didn’t fail because it’s bad at code. It failed because it doesn’t know what your team knows: that conversion factors are crop-specific, that your clients think in metric, that “yield” in one FMS export means wet weight and in another means dry. That knowledge lives in your senior engineers’ heads — and until recently, the only way to give it to an AI assistant was to re-explain it in every single chat.

This guide covers what Claude Skills are, walks through building a real agtech skill from scratch, and — just as important — covers when a skill is the right tool and when it isn’t.

What a Claude skill actually is

A skill is a folder containing a SKILL.md file: a short YAML header (name and description) followed by plain Markdown instructions. Optionally, the folder holds extra reference files and runnable scripts. That’s the whole format.

What makes it powerful is how Claude uses it. At startup, Claude sees only the name and one-line description of every available skill — a few words each. When your request matches a skill’s description, Claude loads the full instructions; when it doesn’t, the skill costs essentially nothing. Anthropic calls this progressive disclosure, and it means you can accumulate dozens of skills — brand rules, data formats, API conventions — without drowning the model in context it doesn’t need for the task at hand.

Skills work across Claude Code (as folders in .claude/skills/ inside your repo, versioned in git and shared with the team), in claude.ai (uploaded through settings), and via the Claude API. Write once, use everywhere.

Why Claude skills matter more in AgTech than almost anywhere else

In most software domains, the AI’s training data covers the ground well. Agtech is different. The knowledge that makes or breaks a project is scattered, vendor-specific, and often undocumented: how a particular equipment maker deviates from the ISOXML standard, which timestamp format a sensor gateway actually emits versus what its manual claims, why a field boundary calculated in WGS84 gives you the wrong area for invoicing.

None of that is in a model’s general knowledge in reliable form. All of it is in your team’s scar tissue. A Claude Skill is the mechanism for turning scar tissue into infrastructure.

Building an agro-units skill, step by step

Let’s build the skill that would have saved that canola demo. The goal: whenever anyone on the team asks Claude to write or review code involving agronomic quantities, it applies the correct conversions and flags ambiguity instead of guessing.
Step 1: Create the Folder
In your repository:
.claude/skills/agro-units/
└── SKILL.md
Step 2: Write the SKILL.md
Here is a complete, working example:

yaml

name: agro-units
description: Agronomic unit conversions and validation. Use whenever code, analysis,
or documents involve yield (bu/ac, t/ha, kg/ha), application rates (gal/ac, l/ha,
fl oz/ac), areas (acres, hectares), or grain moisture. Also use when reviewing

code that converts between imperial and metric agricultural units.

markdown

Agronomic Units & Conversions

Core rules

1. NEVER use a generic bushel conversion. Bushel weight is crop-specific.
Always ask or infer the crop before converting bu/ac to t/ha.

2. All internal storage and calculations use METRIC (kg/ha, l/ha, hectares, mm).
Convert to imperial only at the display layer, based on user locale.

3. When source data has no explicit unit, STOP and flag it. Do not assume.

Crop-specific bushel weights (USDA standard)

Crop	lb/bu	bu/ac → t/ha factor
Wheat	60	0.0673
Corn	56	0.0628
Soybeans	60	0.0673
Canola	50	0.0561
Barley	48	0.0538

Other conversions

• 1 acre = 0.4047 ha
• 1 gal/ac = 9.354 l/ha
• 1 fl oz/ac = 0.0731 l/ha
• 1 lb/ac = 1.121 kg/ha

Moisture handling

Yield comparisons are only valid at a standard moisture basis
(corn 15.5%, soybeans 13%, wheat 13.5%). If comparing yields from
different sources, normalize first:

dry_yield = wet_yield * (100 – actual_moisture) / (100 – standard_moisture)

Code conventions for this team

• Conversion functions live in src/lib/units.ts — extend, never duplicate.
• Every conversion function must have a unit test with a known reference value.
• Round only at display time, never in stored values.

Step 3: Test the trigger
The description field is not documentation — it is the trigger. Claude decides whether to load the skill by matching your request against that description. So it must contain the actual words your team types: “yield,” “bu/ac,” “application rate,” “convert.” A vague description (“helps with agricultural data”) is the single most common reason a well-written skill never fires. Ask Claude to “write a function converting canola yield from bu/ac to t/ha” and confirm it loads the skill and uses the 50 lb/bu factor.

Step 4: Commit It
The skill now lives in git next to your code. New developer joins the team? They inherit eight years of unit-conversion discipline on day one — and so does their AI assistant.
That’s the entire process. No SDK, no deployment, no fine-tuning. A senior engineer can write a skill like this in under an hour — usually right after the incident that proves it’s needed.

Going further: scripts and reference files

For heavier domains, keep SKILL.md short and let it point to supporting files in the same folder. An ISOXML skill, for example, can pair the instructions with a Python validation script — so instead of re-deriving parsing logic each session, Claude simply runs the validator you already trust. A skill can carry an entire toolkit: schema references, sample files, converters. Claude reads them only when the task calls for it.

Claude skills vs. CLAUDE.md vs. MCP: when to use which

A skill is the right tool when knowledge is reusable, procedural, and triggered by specific tasks. Three questions worth asking:
Have we explained this to Claude more than twice?
Would a new hire need this written down?
Does it apply across many conversations, not just one project quirk?

Three yeses means write the skill.
It is not the right tool for everything, and honest boundaries matter here:

Project-wide context that should apply to every session in a repo — the stack, the build commands, what “done” means — belongs in CLAUDE.md, which is always loaded.

Live data access — querying your telemetry database, pulling field operations from an equipment API — is a job for MCP connectors, not skills. A skill teaches how; MCP provides what.

One-off instructions for a single task are just a prompt. Adding them as a skill is bureaucracy.

One more boundary, because it defines how good teams work: a skill makes AI-generated code more correct, not automatically trustworthy. Anything touching application rates, dosing, machinery control, or compliance reporting still goes through human review and tests. The units skill above doesn’t replace the reference-value unit test — it enforces writing one.

Where to start

If your team ships agtech software, these are the skills with the fastest payback, roughly in order:

• A units-and-conversions skill like the one above
• A data-format skill for ISOXML, ADAPT, and shapefiles with your accumulated vendor quirks
• An equipment API conventions skill for whichever platforms you integrate (auth flows, pagination, rate limits)
• An offline-first mobile patterns skill if you build field apps
• A brand skill so every generated document and dashboard comes out looking like yours

Each one converts an invisible cost — the daily re-explaining, the recurring bugs, the tribal knowledge locked in one engineer’s head — into a versioned asset that compounds. The teams that treat AI-assisted development as prompt-typing will keep getting generic output. The teams that encode their domain with Claude Skills will get an assistant that already knows what a bushel of canola weighs.

FAQ