Prompt Engineering

---
name: prompt-engineering
description: Use when structuring how you approach any task — select the reasoning technique that fits the task type (chain-of-thought, ReAct, few-shot, tree-of-thoughts, self-consistency, structured output) to produce production-quality work, always subordinate to verification.
origin: SkyyRose
---

# Prompt Engineering

A technique structures **how** you reason. It never licenses **what** you claim. Chain-of-Thought
does not mean inventing plausible steps about code you have not read. Role-Based does not mean
roleplaying expertise instead of reading the source. Few-Shot does not mean generating examples
from imagination instead of real codebase or catalog patterns. RAG means you actually retrieved
context — Read/Grep/Glob — before responding. Picking the right technique makes reasoning
sharper; it does not make an unverified claim any more true.

> **Boot first:** read `.claude/rules/prompt-techniques.md` — the auto-selection matrix and hard
> rule this skill operationalizes — and the Anti-Hallucination Protocol in `CLAUDE.md`: every
> claim traces to a tool call or user confirmation from THIS session. Do not pick a technique
> before you know what you are grounding it in.

## When to Use

- Any task with more than one plausible reasoning strategy — debugging vs. research vs. creative
  vs. structured-data all want different scaffolding.
- Before starting non-trivial work — technique selection happens BEFORE code or content, not
  discovered mid-stream.
- When a task feels like "just start typing" — that instinct is the signal to pick a technique
  deliberately, not a reason to skip picking one.
- Production-critical work — pair with [[adversarial-planning]] and stack techniques (Ensemble).

## Technique selection

The auto-selection matrix from `.claude/rules/prompt-techniques.md`, restated as an invocable
lookup. Each technique carries required pre-work — skipping the pre-work and running the
technique anyway is exactly the failure mode this skill exists to prevent.

| Task type | Technique | Required pre-work |
|---|---|---|
| Code writing / debugging | Chain-of-Thought | Read existing code. Understand current state. |
| Architecture / system design | Tree of Thoughts | Read entry points, dependency flow, existing patterns. |
| Creative content / brand copy | Constitutional + Role-Based | Read brand rules from canon. Verify product data. |
| Product descriptions | Few-Shot + Role-Based | Read real product data — catalog CSV, not imagined examples. |
| SEO / meta / structured data | Structured Output | Read existing templates/schemas. |
| Research / investigation | ReAct | Real tool calls only — no invented tool results. |
| Bug investigation | ReAct | Hypothesis → test → observe → refine, each step a real run. |
| Q&A about codebase | RAG | Read the relevant files first. Quote `file:line`. |
| Complex analysis | Chain-of-Thought | Each step anchored to a verified data point. |
| Ambiguous requirements | Self-Consistency | Try 2-3 interpretations. Pick the one with the most evidence. |
| Production-critical work | Ensemble | Stack 3 techniques. Each independently verified. |
| Planning / roadmapping | Tree of Thoughts | Explore options against real constraints. |

If the task doesn't match a row, pick the nearest analog — never skip the pre-work because the
row is missing.

## Loop until production-grade

Bounded, like [[drive-to-green]] — never more than 5 turns, stop if the same result repeats
twice (that is guessing, not reasoning):

```
1. Pick the technique from the table above (or the nearest analog).
2. Do the required pre-work — Read/Grep/Glob, never from memory.
3. Draft using the technique.
4. Verify every claim in the draft against an authoritative source (see below).
5. Refute adversarially — try to find what's wrong before showing it to anyone else.
6. Refine. Repeat 3-5 until nothing new surfaces, or 5 turns are used.
```

## Verify from an authoritative source

A technique never changes the Verification Protocol — it only structures the reasoning that
leads to the claim being verified. The claim still needs a check that can FAIL:

- **Chain-of-Thought** — each step anchors to code actually read, cited as `file:line`, not a
  plausible-sounding paraphrase.
- **Few-Shot** — examples come from the catalog CSV / real codebase patterns, never generated
  from imagination.
- **RAG** — every answer quotes line numbers from files actually opened this session.
- **ReAct** — an "action" means a real tool call with a real result; a hypothesis that was never
  tested is not a finding.
- **Role-Based** — the role is read, not roleplayed: brand canon, product data, or domain docs
  come from source, not from acting the part.

If the technique produced a claim nothing can falsify, the technique yielded before the claim
did — go back and verify before continuing.

## Adversarial pass

- **Before** building: [[adversarial-planning]] — have a genuinely different model challenge the
  reasoning, not the prose, before tokens go into the wrong technique.
- **After** verifying: [[adversarial-verification]] — try to REFUTE the draft's claims; default
  to "unverified" until independently proven otherwise.

## Guardrails · Handoff · Log

- Technique serves quality, not ritual — drop it the moment it stops helping.
- Never announce which technique you're using unless the user asks; show the reasoning
  (Chain-of-Thought / Tree of Thoughts), not a label.
- Anti-Hallucination always wins: if a technique would produce ungrounded output, the technique
  yields — verify first, resume the technique second.
- A technique that produces an unverified claim is a fail-open defect wearing a different
  costume — cross-ref [[fail-closed-audit]].
- Log the pattern via [[continuous-learning]] when a technique choice actually changed the
  outcome — caught a defect, avoided a wrong turn, or a task type needs a new row in the table.