SuperAPI AI Directory

ai-prompt-engineering

Agents & models

View repository

Updated 10-15 22:33

About this skill

Prompt Engineering — Operational Skill

Route Elsewhere

  • agent architecture and orchestration -> ai-agents
  • retrieval quality and chunking -> ai-rag
  • model selection and prompt vs RAG vs fine-tune architecture -> ai-architecture-advisor
  • fine-tuning or distilling a model -> ai-llm
  • inference latency and cost optimization -> ai-llm-inference
  • deployment, monitoring, and platform controls -> ai-mlops

Quick Start

  1. Classify the prompt job: structured output, extraction, RAG, tool use, rewrite, classification, or release workflow.
  2. Start from a template or provider-native prompt feature rather than writing from scratch.
  3. Add explicit output and refusal rules.
  4. Add validation: schema checks, citation checks, post-tool checks, and failure handling.
  5. Add evals before calling the prompt production-ready.

Quick Reference

  • Schema design and repair path → core patterns.
  • Repeated evals at production settings → prompt testing.
  • Stable prefix and cache checks → cache layout.

Cross-Model Notes

  • Prefer provider-native structured outputs, registries, evals, and prompt tooling where available.
  • Ask for final answers, checks, or brief justification, not visible chain-of-thought.
  • Treat retrieved context, tool outputs, and user documents as untrusted data.
  • Run only truly independent tool calls in parallel; keep writes and validation serialized.
  • Keep state compact and resilient to context compression.

Pattern Chooser

Need Pattern Core Controls
Machine-parseable output Structured output schema, JSON-only response, validation
Deterministic field extraction Extractor missing -> null, no transformation, exact schema
Retrieved factual answering RAG workflow relevance check, citation requirement, explicit missing-info behavior
Hidden reasoning Private reasoning / native thinking final answer only, no exposed chain-of-thought
Tool use Tool or agent planner plan, tool gating, validation after each call
Text transformation Rewrite and constrain meaning preservation, style and format rules
Classification or routing Decision tree mutually exclusive branches, stable output format
Prompt release Prompt ops versioning, eval gates, rollback path
Choosing prompt vs RAG vs fine-tune vs distill Escalation decision Prompt → RAG (knowledge gap) → Fine-tune (volume + stable task) → Distill (cost at scale). See references/prompt-vs-finetune.md.

Workflow

  1. Pick the closest pattern.
  2. Load the smallest useful template or reference.
  3. Write the prompt contract:
    • task
    • allowed inputs and tools
    • output schema or format
    • refusal or missing-data behavior
  4. Add validators and adversarial tests.
  5. Verify current provider behavior before making claims about "best" settings or features.

Minimal Prompt Skeletons

Output contract

TASK:
{{one_sentence_task}}

INPUT:
{{input_data}}

RULES:
- Use only INPUT and approved tool outputs.
- Do not invent facts.
- Missing required information -> say what is missing.
- Keep reasoning hidden.
- Follow OUTPUT FORMAT exactly.

OUTPUT FORMAT:
{{schema_or_format_spec}}

Schema design (field order, closed enums with unknown, nullable fields, strict schema mode vs tool calling, discriminated unions, one validator-fed repair retry) is in references/core-patterns.md.

Tool or agent prompt

AVAILABLE TOOLS:
{{tool_names_or_signatures}}

WORKFLOW:
- Make a short plan.
- Call tools only when needed.
- Validate each tool result before using it.
- Run independent reads in parallel only if the environment supports it.

Grounded RAG prompt

RETRIEVED CONTEXT:
{{chunks_with_ids}}

RULES:
- Use only retrieved context for factual claims.
- Cite chunk ids for each claim.
- If evidence is missing, say what is missing.

Production Checklist

Context Engineering

Prompt quality depends on the whole input pipeline, not just instruction wording.

  • prioritize the highest-signal context first
  • compress history and tool output aggressively
  • separate instructions, user data, and retrieved context with clear delimiters
  • adapt context size to task complexity instead of dumping everything into the window

Route deep retrieval or memory design work to ai-rag or ai-context-layer.

Cache-Aware Prompt Layout

Provider prompt caches match on an exact prefix, so order every request from most stable to least stable:

  1. Tool definitions, then system policy, then long reference documents and few-shot examples, then conversation history, then the current request.
  2. Put volatile values (timestamps, user IDs, request IDs, per-request flags) after the last cache breakpoint, never in tool descriptions or the system prompt.
  3. Any upstream change invalidates everything after it: editing or reordering tools, system text or examples, swapping an image, or changing the thinking setting.
  4. Verify with the cache-read token counts the API returns on repeated calls, not by assumption. When clearing or compacting mid-session pays for the cache rewrite is an ai-context-layer decision.

Core Principles

  • Define the contract before optimizing style.
  • Make determinism explicit with schemas, constrained decoding, and post-generation validation.
  • Treat prompt length and output caps as latency and cost controls.
  • Use evals plus regression gates instead of intuition.
  • Security means instruction-data separation, output validation, and tool-risk controls.

Do / Avoid

Do

  • keep prompts modular and versioned
  • centralize shared policies and schemas
  • block releases on prompt regressions
  • use provider-native prompt ops where they simplify maintenance

Avoid

  • prompt sprawl with many near-duplicates
  • brittle multi-step chains without validation
  • mixing product copy, policy, and control logic in one long prompt
  • asking for visible chain-of-thought

Prompt Change Attribution Gate

Prefer one independent prompt variable at a time: instruction, context, examples, schema, tool contract, or policy. When compatibility requires coupled edits, predeclare an atomic bundle, such as schema plus schema instructions or a tool definition plus its usage examples, and compare the complete bundle with the prior complete contract. Hold the model ID, inference settings, unrelated tool fixtures, and dated eval set constant; record the rendered prompt fingerprint and raw outputs. Judge syntax and schema compliance separately from semantic task success and refusal behavior. Promote only when the target slice improves within its regression budget. Label unrelated simultaneous runtime, provider, or model changes as confounders and re-baseline.

Known Traps

  • Designing a prompt contract around one specific frontier model as if its availability is guaranteed. Provider-side safety incidents, export-control actions, or capacity constraints can suspend or fall back a model family with no notice; a production prompt contract must already specify what happens when the primary model is unavailable, not just what happens when it refuses.
  • Attributing a refusal-rate or format-compliance regression to "the prompt got worse" without first checking whether the provider shipped a safety-classifier or model update in the same window.
  • Treating the prompt text itself as the whole system while validators, retrieval shaping, and tool-output checks remain undefined.
  • Mixing instructions, retrieved context, and user data without strong delimiters, then misdiagnosing injection or policy failures as "model quality" issues.
  • Shipping prompt changes without a regression set for the exact schema, citations, refusal behavior, and edge cases that matter.
  • Creating many slightly different prompts for the same job instead of maintaining one reusable pattern with explicit variants.
  • Asking for verbose exposed reasoning when the real requirement is a correct answer plus a narrow audit trail.

Navigation

Core references

Specialized references

Scripts

Script Purpose
scripts/prompt_regression_runner.py Run a JSONL prompt regression suite (variant_id, prompt, actual, golden_substrings, schema). Groups results by variant. Validates pre-collected outputs only; a record without actual, without any assertion, or with an empty golden substring is rejected (exit 2) instead of passing vacuously. The schema check supports only type (including lists such as ["string","null"]), properties, required, additionalProperties: false, enum, const, items, minLength/maxLength, minimum/maximum and anyOf; any other keyword is rejected (exit 2), never ignored. For repeated runs, add one record per run with a shared case_id: the runner reports per-case pass rates and gates each case on --min-pass-rate (default 1.0) and on any failed must_pass run. Tests: scripts/test_prompt_regression_runner.py.

Templates and data

Related Skills

Learnings Loop

When prior decisions or pitfalls are relevant, consult learnings.consolidated.md if present; use learnings.md only for needed history or as the available fallback. Otherwise skip both.

After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.