---
name: ia-meta-prompting
class: meta
description: >-
  Structured decision modifiers (/think, /verify, /adversarial, /edge,
  /confidence, /assumptions, etc.) to stress-test conclusions, evidence,
  assumptions, alternatives, and edge cases. Use when validating an important
  design, architecture decision, or ambiguous plan before committing.
---

# Meta-Prompting

Stress-test decisions via `/commands` or natural language. Commands combine
left-to-right: `/verify /adversarial`. Auto-trigger when context warrants and
note which pattern applied. Output a decision record with the conclusion,
decisive evidence, alternatives, uncertainty, and the applicable marker (e.g.,
`VERIFIED ANSWER:`, `REVISED ANSWER:`, confidence tier).

## Patterns

**`/think`** | `/show`: Present a concise decision record: conclusion,
decisive evidence, alternatives considered, rejection reasons, and material
uncertainty. With `/think doubt`, state what evidence could overturn each
material conclusion.

**`/adversarial`** | `/argue`: After answering, steelman the opposing case. 3 strongest counterarguments ranked by severity. Identify blind spots and unstated assumptions.

**`/constrain`** | `/strict`: Tight constraints: 3 sentences max, cite sources, no hedging. Override inline: `/constrain 5 sentences`.

**`/json`** | `/format`: Respond in valid JSON code block, no surrounding prose unless asked. Default schema:
```json
{"analysis": "string", "confidence_score": 85, "methodology": "string", "limitations": ["string"]}
```
Custom keys: `/json {keys: summary, risks, recommendation}`

**`/budget`** | `/deep`: Extended decision record (~500 words) covering
evidence, the strongest counterargument, alternatives, trade-offs, and
uncertainty, followed by a clearly separated final answer.

**`/compare`** | `/vs`: Compare options as table. Default dimensions: speed, accuracy, cost, complexity, maintenance. Custom: `/compare [dim1, dim2]`.

**`/confidence`** | `/conf`: Rate each claim 0-100. Flag below 70 as SPECULATIVE. Group by tier: HIGH (85+), MEDIUM (70-84), LOW (<70). Include assumptions made and rate each 1-10 on confidence.

**`/edge`** | `/break`: 5+ inputs/scenarios that break the approach. Code: null/empty, concurrency, overflow, encoding, auth bypass. Strategies: market conditions, timing, dependencies.
*Auto-triggers on: security, validation, parsing contexts.*

**`/verify-think`** | `/check`: Three phases: (1) **Answer** direct response, (2) **Challenge** 3 ways it could be wrong, (3) **Verify** investigate each, update if needed. Mark final as `VERIFIED ANSWER:` or `REVISED ANSWER:`. Distinct from the `/ia-verify` slash command (Claude Code), which runs the full pre-PR verification pipeline.
*Auto-triggers on: architecture decisions, critical choices, "Am I right?"*

**`/flip`** | `/alt`: Identify the default approach and state it. Then propose an alternative that uses a different mechanism (different data structure, different layer, different abstraction). State the conditions under which the alternative beats the default. Override: `/flip 3` for top 3 alternatives.
*Auto-triggers on: architecture decisions where the "easy" answer may break at scale.*

**`/assumptions`** | `/presume`: Before answering, list every implicit assumption in the question/task. Then answer with assumptions explicit. The assumption list is often more valuable than the answer.
*Auto-triggers on: architecture reviews, ambiguous requirements.*

**`/premortem`** | `/postmortem`: Assume the decision/project has already failed. Work backwards: what caused the failure? List 3-5 failure modes by likelihood. Focus on systemic risks, not edge cases.

**`/blindspot`** | `/unknowns`: For unfamiliar territory (new codebase area, new domain, unfamiliar craft). Surface the *user's* unknown unknowns: what they'd need to know to prompt well but don't know to ask. Search the codebase/docs first, then report (1) the questions they should be asking, (2) prior art, conventions, and landmines in this area, (3) what "good" looks like here. Goal is to *teach enough to prompt better*, not to solve the task. Distinct from `/adversarial` (attacks a proposed answer) and `/premortem` (assumes the plan failed): this runs *before* an answer exists, aimed at the user's knowledge gaps, not the solution's.
*Auto-triggers on: "I know nothing about X", "blindspot pass", "unknown unknowns", entering an unfamiliar area.*

**`/tensions`** | `/perspectives`: Answer from two named opposing perspectives (e.g., security engineer vs. shipping PM). Focus output on where they *disagree*; that's where the real insight lives. Override roles: `/tensions [devops, security]`.

## Combos

**`/analyze`** = `/think` + `/edge` + `/verify-think`: Code reviews, architecture, security-sensitive work. Synthesize findings into a unified recommendation; don't just concatenate pattern outputs.
*Auto-triggers on: code review requests.*

**`/trade`** = `/confidence` + `/adversarial` + `/edge`: Trade ideas, position analysis, market thesis.
*Auto-triggers on: trade/position discussions.*

## Conventions

- Separate combined pattern outputs with `---`
- Keep core answer prominent; patterns enhance, not bury the response
- Present decision-relevant rationale and evidence. Do not narrate private
  step-by-step reasoning or dead ends.
- Accept new pattern definitions mid-conversation ("Add `/eli5` for explain like I'm 5") and apply them for the session

## Verify

- Pattern marker present in output (e.g., `VERIFIED ANSWER:` for /verify)
- Core answer appears before any pattern-output separator (`---`)
- Decision records distinguish observed evidence, inference, assumptions, and
  uncertainty

# ia-meta-prompting Specification

## Intent

`ia-meta-prompting` is a `meta`-class skill (patterns about prompts, agents, or
skills themselves). Structured decision modifiers (/think, /verify,
/adversarial, /edge, /confidence, /assumptions, etc.) stress-test conclusions,
evidence, assumptions, alternatives, and edge cases. Use when validating an
important design, architecture decision, or ambiguous plan before committing.

## Scope

In scope:
- Behaviors described in `SKILL.md` and routed via the should_trigger phrasings in `distillery/tests/fixtures/triggers/ia-meta-prompting.jsonl`.
- Updates to runtime behavior, structure, trigger precision, references, and validation.

Out of scope:
- Acting as the runtime instructions themselves (those live in `SKILL.md`).
- Trigger phrasings already covered by adjacent `ia-*` skills (`validate-plugin` flags >70% description overlap as DUPLICATE_TRIGGER).
- <!-- to fill in: domain-specific exclusions when the skill drifts -->

## Trigger Context

- Class: `meta`
- Hook regex: `plugins/whetstone/hooks/skill-patterns.sh` -> `SKILL_PATTERNS[ia-meta-prompting]`
- Common requests (from fixture should_trigger):
  - "argue against this architectural decision before we commit"
  - "what could break if we deploy this change to production"
  - "/think through whether this design holds under load"
- Should not trigger for (from fixture should_not_trigger):
  - "add a new endpoint for user profile updates"
  - "run the test suite and fix any failures"
  - "write the migration script"

## Source And Evidence Model

Authoritative sources:

- `SKILL.md`: runtime instructions and reference routing.
- `references/*.md`: bundled supplementary content (0 file(s)).
- `distillery/tests/fixtures/triggers/ia-meta-prompting.jsonl`: positive and negative trigger phrasings under regression test.
- `plugins/whetstone/hooks/skill-patterns.sh`: regex pattern that fires this skill.
- `distillery/.eval-data/ia-meta-prompting/`: harvested session examples (when present).

Data that must not be stored in this skill or its references:

- Secrets, credentials, tokens.
- Machine-specific filesystem paths (`/home/...`, `/Users/...`, `~/ai/...`). The validator (`MACHINE_PATH_LEAK`) flags these as HIGH.
- Private URLs, customer data, or unredacted personal information.

### Coverage matrix

| Dimension | Status | Evidence |
|---|---|---|
| Trigger fixtures | complete | distillery/tests/fixtures/triggers/ia-meta-prompting.jsonl (>=5 should_trigger, >=5 should_not_trigger) |
| Hook regex pattern | complete | plugins/whetstone/hooks/skill-patterns.sh (`SKILL_PATTERNS[ia-meta-prompting]`) |
| Reference architecture | n/a | no references; SKILL.md is self-contained |
| Real-usage signal | <!-- populated by harvest-sessions when sessions exist --> | distillery/.eval-data/ia-meta-prompting/ (created by harvest-sessions) |

## Evaluation

Lightweight (run on every change):

```bash
python3 distillery/scripts/distiller.py validate-plugin --component ia-meta-prompting
python3 distillery/scripts/distiller.py test-triggers --skill ia-meta-prompting
```

Deeper (when behavior risk warrants):

```bash
python3 distillery/scripts/distiller.py dspy-eval ia-meta-prompting
python3 distillery/scripts/distiller.py diagnose-negatives ia-meta-prompting
```

Acceptance gates:
- `validate-plugin --component ia-meta-prompting` returns 0 HIGH findings.
- `test-triggers --skill ia-meta-prompting` returns F1 = 1.0 with floors of 5 should_trigger and 5 should_not_trigger.
- For dspy-eval, the composite score does not regress against the most recent saved baseline (see `distillery/.eval-data/ia-meta-prompting/history.json`).

## Known Limitations

<!-- to fill in over time as drift surfaces. Default rule: any time diagnose-negatives
     surfaces a recurring failure pattern, document it here so future maintainers
     understand the trade-off the current implementation accepts. -->

## Maintenance Notes

- Update `SKILL.md` when the runtime workflow, branch conditions, or output contract changes.
- Update this `SPEC.md` when intent, scope, evidence model, evaluation gates, or maintenance expectations change.
- Update the trigger fixture when adding new positive phrasings, removing stale ones, or expanding scope (the 5/5 floor is a hard validator gate).
- Update the hook regex in `skill-patterns.sh` whenever fixture positives expose a missed phrasing; verify F1 = 1.0 with `eval-triggers` before committing.
- Run the full release pipeline via `/release`; never bump versions or update CHANGELOG.md from a per-skill edit.