Prompt Lab

Replaces trial-and-error prompt engineering with structured methodology: objective definition, current prompt analysis, variant generation (instruction clarity, example strategies, output format specification), evaluation rubric design, test case creation, and failure mode identification.

Reference Files

File	Contents	Load When
references/prompt-patterns.md	Prompt structure catalog: zero-shot, few-shot, CoT, persona, structured output	Always
references/evaluation-metrics.md	Quality metrics (accuracy, format compliance, completeness), rubric design	Evaluation needed
references/failure-modes.md	Common prompt failure taxonomy, detection strategies, mitigations	Failure analysis requested
references/output-constraints.md	Techniques for constraining LLM output format, JSON mode, schema enforcement	Format control needed

Prerequisites

• Clear objective: what should the prompt accomplish?
• Target model (GPT-4, Claude, open-source) — prompting techniques vary by model
• Current prompt (if improving) or task description (if creating)

Workflow

Phase 1: Define Objective

1. Task specification — What should the LLM produce? Be specific: "Classify customer support tickets into 5 categories" not "Handle support tickets."
2. Success criteria — How do you know the output is correct? Define measurable criteria before writing any prompt.
3. Failure modes — What does a bad output look like? Missing information? Wrong format? Hallucinated content? Refusal to answer?

Phase 2: Analyze Current Prompt

If an existing prompt is provided:

1. Structure assessment — Is the instruction clear? Are examples provided? Is the output format specified?
2. Ambiguity detection — Where could the model misinterpret the instruction?
3. Missing components — What's not specified that should be? (output format, tone, length constraints, edge case handling)
4. Failure mode mapping — Which known failure patterns (see references/failure-modes.md) apply to this prompt?

Phase 3: Generate Variants

Create 2-4 prompt variants, each testing a different hypothesis:

Variant Type	Hypothesis	When to Use
Direct instruction	Clear instruction is sufficient	Simple tasks, capable models
Few-shot	Examples improve output consistency	Pattern-following tasks
Chain-of-thought	Reasoning improves accuracy	Multi-step logic, math, analysis
Persona/role	Role framing improves tone/expertise	Domain-specific tasks
Structured output	Format specification prevents errors	JSON, CSV, specific templates

For each variant:

• State the hypothesis (why this variant might work)
• Identify the risk (what could go wrong)
• Provide the complete prompt text

Phase 4: Design Evaluation

1. Rubric — Define weighted criteria:

   Criterion	What It Measures	Typical Weight
   Correctness	Output matches expected answer	30-50%
   Format compliance	Follows specified structure	15-25%
   Completeness	All required elements present	15-25%
   Conciseness	No unnecessary content	5-15%
   Tone/style	Matches requested voice	5-10%

2. Test cases — Minimum 5 cases covering:

   • Happy path (standard input)
   • Edge cases (unusual but valid input)
   • Adversarial cases (inputs designed to confuse)
   • Boundary cases (minimum/maximum input)

Phase 5: Output

Present variants, rubric, and test cases in a structured format ready for execution.

Output Format

## Prompt Lab: {Task Name}

### Objective
{What the prompt should achieve — specific and measurable}

### Success Criteria
- [ ] {Criterion 1 — measurable}
- [ ] {Criterion 2 — measurable}

### Current Prompt Analysis
{If existing prompt provided}
- **Strengths:** {what works}
- **Weaknesses:** {what fails or is ambiguous}
- **Missing:** {what's not specified}

### Variants

#### Variant A: {Strategy Name}

{Complete prompt text}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant B: {Strategy Name}

{Complete prompt text}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant C: {Strategy Name}

{Complete prompt text}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

### Evaluation Rubric

| Criterion | Weight | Scoring |
|-----------|--------|---------|
| {criterion} | {%} | {how to score: 0-3 scale or pass/fail} |

### Test Cases

| # | Input | Expected Output | Tests Criteria |
|---|-------|-----------------|---------------|
| 1 | {standard input} | {expected} | Correctness, Format |
| 2 | {edge case} | {expected} | Completeness |
| 3 | {adversarial} | {expected} | Robustness |

### Failure Modes to Monitor
- {Failure mode 1}: {detection method}
- {Failure mode 2}: {detection method}

### Recommended Next Steps
1. Run all variants against the test suite
2. Score using the rubric
3. Select the highest-scoring variant
4. Iterate on the winner with targeted improvements

Calibration Rules

1. One variable per variant. Each variant should change ONE thing from the baseline. Changing instruction style AND examples AND format simultaneously makes results uninterpretable.
2. Test before declaring success. A prompt that works on 3 examples may fail on the 4th. Minimum 5 diverse test cases before concluding a variant works.
3. Failure modes are more valuable than successes. Understanding WHY a prompt fails guides improvement more than confirming it works.
4. Model-specific optimization. A prompt optimized for GPT-4 may not work for Claude or Llama. Always note the target model.
5. Simplest effective prompt wins. If a zero-shot prompt scores as well as a few-shot prompt, use the zero-shot. Fewer tokens = lower cost + latency.

Error Handling

Problem	Resolution
No clear objective	Ask the user to define what "good output" looks like with 2-3 examples.
Prompt is for a task LLMs are bad at (math, counting)	Flag the limitation. Suggest tool-augmented approaches or pre/post-processing.
Too many variables to test	Focus on the highest-impact variable first. Iterative refinement beats combinatorial testing.
No existing prompt to analyze	Start with the simplest possible prompt. The first variant IS the baseline.
Output format requirements are strict	Use structured output mode (JSON mode, function calling) instead of prompt-only constraints.

When NOT to Use

Push back if:

• The task doesn't need an LLM (deterministic rules, regex, SQL) — use the right tool
• The user wants prompt execution, not design — this skill designs and evaluates, it doesn't run prompts
• The prompt is for safety-critical decisions without human review — LLM output should not be the sole input