agent-llm
Skill1 starsChanged 4 months agoMITView on GitHub
Patterns for building on the Claude/Anthropic API — agent loops, tool design, prompt structure, structured output, context management, prompt caching, and evals. Use when writing code that calls Claude, designing an agentic loop, defining tools for an LLM, building RAG or an LLM-judge, or debugging refusals, truncation, streaming, or tool-call failures.
In this repository10 other files it gives its agents.
- .claude/CLAUDE.mdCLAUDE.md
- dataSkill
- debugSkill
- doc-coauthoringSkill
- frontend-designSkill
- git-opsSkill
- loop-verifySkill
- refactorSkill
- securitySkill
- testingSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Put stable, cacheable content first (system prompt, tool defs, long context).
- Distinctive: line 25
Prefer returning structured data over prose from a tool.
- Distinctive: line 36
Don't dump whole files/tables into context — retrieve the relevant slice.
- Distinctive: line 48
Use an LLM-judge only for fuzzy criteria.
≈ “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.
Files
Agent & LLM Patterns (Claude)
Guidance for writing application code that calls Claude well. This is about how to structure the integration, not the API surface.
Before writing any code that names a Claude model, calls the Anthropic SDK, or picks a model tier, load the claude-api skill — it has current model IDs, pricing, limits, and parameter details. Do not hardcode model IDs or pricing from memory; they go stale.
Prompt structure
- Put stable, cacheable content first (system prompt, tool defs, long context); put the variable turn last. This maximizes prompt-cache hits.
- Be explicit about the output contract. If you need JSON, say the exact shape and provide one example. Don't ask for "JSON" and hope.
- Give the model an escape hatch ("if you cannot determine X, return
null") so it stops fabricating to satisfy the format. - Separate instructions from data with clear delimiters (XML tags work well). Never interpolate untrusted user text directly into an instruction sentence — treat it as data inside a tag.
Tool design
- One tool = one capability with a crisp verb name. Overlapping tools cause the model to dither.
- The
descriptionis the prompt the model reads to decide when to call — write it for that decision, not as API docs. State when to use it and when NOT to. - Make schemas strict: enums over free strings, required fields marked, no ambiguous optional soup. A tight schema removes a class of retries.
- Return errors the model can act on.
{"error":"row not found","hint":"check the id"}beats a stack trace. The model reads tool results as its next observation. - Prefer returning structured data over prose from a tool; let the model narrate.
Agentic loops
- The loop is: model → tool_use → you execute → tool_result → model, until it stops calling tools. Keep executing until there are no more tool calls, then surface the final text.
- Bound the loop (max iterations / token budget) so a confused model can't spin forever. Log each step's tool + args for debuggability.
- For structured final output, force a terminal tool call (a
submit/finishtool with the result schema) rather than parsing prose — validation happens at the tool layer and the model retries on mismatch. - Isolate side-effecting tools (writes, sends, deletes) behind confirmation or a dry-run flag when the loop is autonomous.
Context management
- Don't dump whole files/tables into context — retrieve the relevant slice. More context is slower, costlier, and dilutes attention.
- For long-running agents, summarize prior steps into a compact running state rather than carrying the full transcript.
- RAG: retrieve, then cite. Have the model quote the source span it used so answers are checkable; return
null/"not found" when retrieval is empty instead of guessing.
Prompt caching
- Cache the system prompt, tool definitions, and any large shared context (5-minute TTL). Structure calls so the cached prefix is byte-identical across requests.
- A single changed byte early in the prompt busts the whole downstream cache — keep volatile content (timestamps, user turn) at the end.
Evals — don't ship a prompt you haven't measured
- Build a small labeled set of real inputs with expected outputs before tuning the prompt. "It looked good in the playground" is not a signal.
- Use an LLM-judge only for fuzzy criteria; for anything checkable (JSON valid? field present? number in range?) assert it in code.
- Track a regression set. When you change the prompt or model, re-run it — prompt changes have non-local effects.
- Measure cost and latency alongside quality; the cheapest model that passes the eval wins.
Common failure modes
- Refusals / cutoffs / streaming / tool-call bugs: load
claude-apiand check the model's limits and the exact request shape before assuming a logic bug. - Truncated output: the response hit
max_tokens— raise it or ask for less, don't retry blindly. - Model ignores the format: your instruction and your example disagree, or the format is buried mid-prompt. Move it to the end and make the example match exactly.
- Non-determinism in tests: set
temperature: 0for eval runs; assert on structure/invariants, not exact wording.
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
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.

