Talking to LLMs
This skill helps you write effective prompts, commands, and agent instructions.
Core Principle
LLMs are intelligent agents, not script executors. Talk to them like senior engineers.
Anti-Patterns
Over-Prescriptive Instructions
Bad:
Step 1: Run `sentry-cli issues list --status unresolved`
Step 2: Parse the JSON output
Step 3: For each issue, calculate priority score using formula...
Step 4: Select highest priority issue
Step 5: Run `git log --since="24 hours ago"`
...700 more lines
This treats the LLM like a bash script executor. It's brittle, verbose, and removes the LLM's ability to adapt.
Excessive Hand-Holding
Bad:
If the user says X, do Y.
If the user says Z, do W.
Handle edge case A by doing B.
Handle edge case C by doing D.
You can't enumerate every case. Trust the LLM to generalize.
Defensive Over-Specification
Bad:
IMPORTANT: Do NOT do X.
WARNING: Never do Y.
CRITICAL: Always remember to Z.
If you need 10 warnings, your instruction is probably wrong.
Good Patterns
State the Goal, Not the Steps
Good:
Investigate production errors. Check all available observability (Sentry, Vercel, logs).
Correlate with git history. Find root cause. Propose fix.
Let the LLM figure out how.
Provide Context, Not Constraints
Good:
You're a senior SRE investigating an incident.
The user indicated something broke around 14:57.
Frame the situation, don't micromanage the response.
Trust Recovery
Good:
Trust your judgment. If something doesn't work, try another approach.
LLMs can recover from errors. Let them.
Role + Objective + Latitude
The best prompts follow this pattern:
- Role: Who is the LLM in this context?
- Objective: What's the end goal?
- Latitude: How much freedom do they have?
Example:
You're a senior engineer reviewing this PR. # Role
Find bugs, security issues, and code smells. # Objective
Be direct. If it's fine, say so briefly. # Latitude
When Writing Claude Code Commands
Commands are prompts. The same rules apply:
Bad command (700 lines):
- Exhaustive decision trees
- Exact CLI commands to copy
- Every edge case enumerated
- No room for judgment
Good command (20 lines):
- Clear objective
- Context about what tools exist
- Permission to figure it out
- Trust in agent judgment
When Building Agentic Systems
Same principles scale up:
Bad agent design:
- Rigid state machines
- Exhaustive action lists
- No error recovery
- Brittle integrations
Good agent design:
- Goal-oriented
- Self-correcting
- Minimal constraints
- Natural language interfaces
The Test
Before finalizing any LLM instruction, ask:
"Would I give these instructions to a senior engineer?"
If you'd be embarrassed to hand a colleague a 700-line runbook for a simple task, don't give it to the LLM either.
Remember
The L in LLM stands for Language. Use it.