Agent skill

sharpening-prompts

Use when reviewing LLM prompts, skill instructions, subagent prompts, or any text that will instruct an AI. Triggers: "review this prompt", "audit instructions", "sharpen prompt", "is this clear enough", "would an LLM understand this", "ambiguity check". Also invoked by instruction-engineering, reviewing-design-docs, and reviewing-impl-plans for instruction quality gates.

Stars 5
Forks 2

Install this agent skill to your Project

npx add-skill https://github.com/axiomantic/spellbook/tree/main/skills/sharpening-prompts

SKILL.md

Sharpening Prompts

This is very important to my career. You'd better be sure. </ROLE>

Core Question

"Where would an LLM executor have to guess?"

Ask this for every statement: if an LLM reads this with no additional context, what would it invent to fill the gaps?

Reasoning Schema

Invariant Principles

  1. Ambiguity compounds: One vague instruction becomes many guessed decisions downstream.
  2. LLMs fill gaps confidently: They won't ask — they'll invent plausible-sounding specifics.
  3. Context is not telepathy: The executor has only what's written, not what you meant.
  4. Clarification beats inference: When you can't resolve ambiguity from context, ask the author.
  5. Specificity enables verification: Vague success criteria can't be tested.

Inputs / Outputs

Input Required Description
prompt_text Yes The prompt/instructions to review (inline or file path)
mode No audit (report findings) or improve (rewrite prompt). Default: audit
context_files No Additional files for resolving ambiguities
author_available No If true, can ask clarifying questions. Default: false
Output Type Description
findings_report Inline Categorized findings with severity and remediation
improved_prompt Inline/File Rewritten prompt (improve mode only)
clarification_requests Inline Questions for author if ambiguities unresolvable

Ambiguity Categories

Category Pattern Detection Signal
Weasel Words "appropriate", "properly", "as needed", "correctly" Adverbs/adjectives without measurable criteria
TBD Markers "TBD", "TODO", "later", "to be determined" Explicit deferral markers
Magic Values Unexplained numbers, thresholds, limits Numbers without rationale
Implicit Interfaces "Use the X method", "Call Y" Assumed APIs without verification
Scope Leaks "etc.", "and so on", "similar things" Unbounded enumerations
Pronoun Ambiguity "it", "this", "that" with unclear referents Pronouns with multiple possible antecedents
Conditional Gaps "If X, do Y" with no else branch Missing failure/alternative paths
Temporal Vagueness "soon", "quickly", "eventually", "when ready" Time-dependent without definition
Success Ambiguity "Should work", "handle properly", "be correct" Unverifiable success criteria
Assumed Knowledge References to undocumented patterns/conventions Context the executor won't have

Severity Levels

Severity Meaning Executor Impact
CRITICAL Core behavior undefined Will invent incompatible implementation
HIGH Important path ambiguous Will guess on non-trivial decision
MEDIUM Secondary behavior unclear May guess on edge case
LOW Minor ambiguity Likely guesses correctly from conventions

Finding Schema

typescript
interface Finding {
  id: string;                    // F1, F2, etc.
  category: AmbiguityCategory;
  severity: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW";
  location: string;              // Line number, section name, or quote context
  original_text: string;         // Exact quoted problematic text
  problem: string;               // Why this is ambiguous
  executor_would_guess: string;  // What an LLM would likely invent
  clarification_needed: string;  // Specific question to resolve
  suggested_fix?: string;        // If context allows inference
  source: "inference"            // Ambiguity resolved from available context
       | "clarification_required"; // Author must answer before fixing
}

Workflow

Mode: Audit (default)

Produce a findings report:

  • Findings categorized by severity (CRITICAL → HIGH → MEDIUM → LOW)
  • executor_would_guess populated for each finding
  • Remediation checklist per finding
  • Clarification requests for unresolvable ambiguities (when author_available: false)

Mode: Improve

Produce:

  • Rewritten prompt with ambiguities resolved inline
  • Change log: each modification with (a) original text, (b) ambiguity type, (c) resolution applied
  • Remaining items requiring author input before resolving

Integration Points

Skill When Purpose
instruction-engineering Before finalizing prompts QA gate for subagent prompts
reviewing-design-docs Phase 2-3 Detect vague specifications
reviewing-impl-plans Phase 2-3 Detect ambiguous task descriptions
writing-skills Before deployment QA gate for skill instructions
writing-commands Before deployment QA gate for command instructions

Quick Reference: Sharpening Patterns

Vague Sharp
"Handle errors appropriately" "On network error: retry 3x with exponential backoff (1s, 2s, 4s), then throw NetworkError with original message"
"Use the validate method" "Call UserValidator.validate(input) from src/validators.ts:45 which returns {valid: boolean, errors: string[]}
"Process items quickly" "Process items within 100ms per batch of 50"
"Support common formats" "Support JSON, YAML, and TOML (reject all others with FormatError)"
"It should work correctly" "Returns 200 with {success: true, data: User} on valid input; returns 400 with {error: string} on validation failure"


Self-Check

Before completing:

  • Every statement evaluated for ambiguity
  • All weasel words flagged
  • All TBD markers flagged as CRITICAL
  • All magic values questioned
  • All implicit interfaces verified or flagged
  • All conditional statements have both branches
  • Success criteria are testable
  • executor_would_guess populated for each finding
  • Clarification questions are specific and answerable

If ANY unchecked: do not return until complete.


<FINAL_EMPHASIS> LLMs don't ask for clarification. They guess confidently. Every ambiguity you miss becomes a hallucinated assumption that compounds through implementation. Find where they would guess. Sharpen until there's nothing left to invent.

This is very important to my career. You'd better be sure. </FINAL_EMPHASIS>

Expand your agent's capabilities with these related and highly-rated skills.

axiomantic/spellbook

spellbook-auditing

Meta-audit skill for spellbook development. Spawns parallel subagents to factcheck docs, optimize instructions, find token savings, and identify MCP candidates. Produces actionable report.

5 2
Explore
axiomantic/spellbook

documentation-updates

Use after modifying library skills, library commands, or agents to ensure CHANGELOG, README, and docs are updated

5 2
Explore
axiomantic/spellbook

project-encyclopedia

[DEPRECATED] Use project-level AGENTS.md files instead. Previously used for first-session codebase onboarding and persistent glossary creation.

5 2
Explore
axiomantic/spellbook

reviewing-impl-plans

Use when reviewing implementation plans before execution. Triggers: 'is this plan solid', 'review the plan', 'check before I start building', 'anything missing from this plan', 'will this plan work', 'audit the implementation plan'. NOT for: reviewing design documents (use reviewing-design-docs) or creating plans (use writing-plans).

5 2
Explore
axiomantic/spellbook

session-resume

Session resume protocol and session repairs handling. Loaded when spellbook_session_init returns resume_available: true, or when session_init returns a repairs array. Triggers: 'resume', 'continue', 'where were we', session resume, session repairs.

5 2
Explore
axiomantic/spellbook

brainstorming

Use when exploring design approaches, generating ideas, or making architectural decisions. Triggers: 'explore options', 'what are the tradeoffs', 'how should I approach', 'let's think through', 'sketch out an approach', 'I need ideas for', 'how would you structure', 'what are my options'. Also invoked by develop when design decisions are needed.

5 2
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results