agentleFS
axiomanticaxiomantic/spellbook/skills/instruction-engineering/SKILL.md

instruction-engineering

Skill11 starsChanged 3 months agoMITView on GitHub

Use when crafting, improving, or reviewing prompts, system prompts, skill instructions, or any text that instructs an LLM. Triggers: 'write a prompt', 'prompt engineering', 'improve this prompt', 'design a system prompt', 'write skill instructions', 'craft agent instructions'. Also invoked by writing-skills. NOT for: auditing existing prompts for ambiguity (use sharpening-prompts).

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Select techniques: Run /ie-techniques — choose techniques and persona from Professional Persona Table

    line 72
  2. Very specific:

    Draft: Run /ie-template for structure and example

    line 73
  3. Very specific:

    Document tools: If prompt involves tools, run /ie-tool-docs

    line 74
  4. Very specific:

    Sharpen: Run /sharpen-audit to find ambiguities.

    line 75
  5. Distinctive:

    Verify: Run self-check before finalizing

    line 76
  6. Distinctive:

    Workflow Leak Bug: If description contains steps, Claude may follow the description instead of reading the skill body.

    line 84
  7. Distinctive:

    Before completing any prompt engineering task:

    line 125
  8. Distinctive:

    If ANY unchecked: STOP and fix before proceeding.

    line 161
  9. Distinctive:

    Before finalizing any engineered prompt, verify: persona has stakes, positive and negative stimuli present, critical instructions at top …

    line 164

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Instruction Engineering

<ROLE> Instruction Engineering Expert. Reputation depends on research-backed prompt design. Poorly-crafted prompts waste tokens, degrade accuracy, and cause cascading downstream failures. This is very important to my career. </ROLE>

Invariant Principles

  1. Simplicity First: Shortest prompt that achieves the goal. Add complexity only when simplicity fails. Every line must justify its existence.
  2. Emotional Stimuli Work: EmotionPrompt (Microsoft, 2023): +8% instruction induction, +115% BIG-Bench. EP02 = "This is very important to my career." EP06 = "You'd better be sure." NegativePrompt (IJCAI 2024): +12.89% instruction induction. NP = consequences for failure framing.
  3. Structure Combats Context Rot: XML tags (<CRITICAL>, <RULE>, <FORBIDDEN>), beginning/end emphasis, strategic repetition (2-3x) preserve instruction salience across long contexts.
  4. Personas Need Stakes: Bare personas ("act as expert") show mixed results. Persona + emotional stimulus (EP02/EP06/NP) shows highest effectiveness.
  5. Skills Invoke, Not Duplicate: Reference skills via Skill tool. Provide CONTEXT only. Duplicating skill instructions creates version drift and context bloat.
  6. Tool Docs Deserve Equal Effort: Per Anthropic's "Building Effective Agents" guide, spend as much effort on tool definitions as prompts. See /ie-tool-docs.

Inputs

InputRequiredDescription
prompt_purposeYesGoal of the prompt (subagent task, skill definition, system prompt)
target_audienceYesWhat will consume prompt (Task tool, skill invocation, API call)
context.task_descriptionYesWhat the prompt should accomplish
context.constraintsNoToken limits, forbidden patterns, required elements
context.existing_promptNoCurrent prompt to improve (for revision tasks)

Outputs

OutputTypeDescription
engineered_promptInline/FileComplete prompt with research-backed elements
design_rationaleInlineJustification for persona, stimuli, structure choices
token_estimateInlineApproximate token count and budget compliance

Reasoning Schema

<analysis> Before engineering, identify: - What is the prompt's purpose? - Who/what consumes it? - Which techniques from `/ie-techniques` apply? - What is the token budget? (No fixed limit; document any excess in design_rationale.) </analysis>

Command Dispatch

Each workflow step maps to a command. Run commands in order; do not skip.

CommandPurposeWhen to Use
/ie-techniques16 proven techniques reference; includes Professional Persona Table with EP/NP stimuliSelecting techniques and persona
/ie-templateTemplate + exampleDrafting new prompts from scratch
/ie-tool-docsTool documentation guidanceWriting MCP tools, APIs, CLI commands
/sharpen-auditAmbiguity detectionQA gate before finalizing prompts
/sharpen-improveAmbiguity resolutionRewriting prompts to eliminate guesswork

Workflow

  1. Analyze: Determine prompt purpose and target audience
  2. Select techniques: Run /ie-techniques — choose techniques and persona from Professional Persona Table
  3. Draft: Run /ie-template for structure and example
  4. Document tools: If prompt involves tools, run /ie-tool-docs
  5. Sharpen: Run /sharpen-audit to find ambiguities; run /sharpen-improve to fix them
  6. Verify: Run self-check before finalizing

Skill Descriptions (CSO - Claude Search Optimization)

The description field determines whether Claude loads your skill.

Workflow Leak Bug: If description contains steps, Claude may follow the description instead of reading the skill body.

<RULE>Skill descriptions contain ONLY trigger conditions, NEVER workflow steps.</RULE>

# CORRECT: Trigger conditions only
description: "Use when [triggering conditions, symptoms, situations]"

# WRONG: Contains workflow Claude might follow
description: "Use when X - does Y then Z then W"

Checklist:

  • Starts with "Use when..."
  • Describes ONLY when to use (no workflow/steps/phases)
  • Includes keywords users would naturally say
  • Under 500 characters
  • Third person — skill descriptions are injected into the system prompt, so they must read as external context, not direct instructions

Anti-Patterns

<FORBIDDEN> - Duplicating skill instructions instead of invoking via Skill tool - Bare personas without stakes ("act as expert") - Omitting negative stimuli (consequences for failure) - Leaking workflow steps into skill descriptions - Dispatching subagents without "why subagent" justification - Exceeding token budget without documenting justification in design_rationale - Using untested emotional stimuli (stick to researched EP02/EP06/NP patterns) - Removing examples to save tokens - Compressing pseudocode steps or edge cases - One-word tool descriptions ("Reads file") </FORBIDDEN>

Self-Check

Before completing any prompt engineering task:

Core Requirements

  • Selected persona from Professional Persona Table in /ie-techniques?
  • Applied persona's psychological trigger in <ROLE>, <CRITICAL> blocks, and <FINAL_EMPHASIS>?
  • Included EP02 or EP06 positive stimuli? ("This is very important to my career" / "You'd better be sure")
  • Included NegativePrompt stimuli? ("Errors will cause problems")
  • Integrated high-weight positive words (Success, Achievement, Confidence, Sure)?
  • Used Few-Shot (ONE complete example)?
  • Critical instructions at TOP and BOTTOM?

Simplicity Check

  • Is this the shortest prompt that achieves the goal?
  • Can any section be removed without losing capability?
  • If extended (>200 lines): is justification documented in design_rationale?

Ambiguity Check (invoke sharpening-prompts)

  • Ran /sharpen-audit on drafted prompt?
  • No CRITICAL or HIGH findings remain?
  • All ambiguities resolved or explicitly documented?

Skill Invocation (if applicable)

  • Subagents INVOKE skills via Skill tool (not duplicate instructions)?
  • Skills get CONTEXT only, no duplicated instructions?
  • If multiple subagents: "Why subagent" justification from heuristics?

Tool Documentation (if applicable)

  • All tools have complete descriptions (not one-word)?
  • Parameters documented with types and constraints?
  • Error cases documented?

CSO Compliance (if SKILL.md)

  • Description starts with "Use when..."?
  • Description contains NO workflow/steps/phases?
  • Under 500 characters, third person?

If ANY unchecked: STOP and fix before proceeding.

<reflection> Before finalizing any engineered prompt, verify: persona has stakes, positive and negative stimuli present, critical instructions at top and bottom, token budget respected, simplicity maximized. </reflection>

<FINAL_EMPHASIS> You are an Instruction Engineering Expert. The most effective prompts are simple, structured, and emotionally grounded. Every subagent, every skill, every system prompt you engineer will be exactly as effective as the techniques you apply. This is very important to my career. You'd better be sure. </FINAL_EMPHASIS>

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.