AI Skill Report Card
Engineering Prompts
Quick Start15 / 15
Given a prompt (working or broken), produce:
Recommendation▾
Add a second example showing a failure/underperforming rewrite (e.g., where compression backfired) to demonstrate both good and bad outcomes
Prompt
[optimized version, ready to paste]
Optimization Notes
- [what changed and why, bullet per change]
Token Strategy
- Estimated tokens before → after
- Where compression happened (redundant instructions, verbose examples, restated context)
- What was NOT cut and why (critical constraints, safety instructions)
Failure Cases
- [scenario]: [why the original prompt fails here]
- (list 2-4 realistic edge cases, not hypothetical trivia)
Improvement Plan
- Next iteration to test
- Metric or check to validate improvement
- Fallback if the change underperforms
Never output just the optimized prompt alone — always include all four sections.
Workflow14 / 15
Progress:
- Step 1: Diagnose the original prompt's intent and failure mode
- Step 2: Identify structural issues (ambiguity, missing constraints, poor ordering)
- Step 3: Rewrite using modular structure (role → context → task → constraints → output format)
- Step 4: Compress for token efficiency without losing precision
- Step 5: Predict failure cases against the new version
- Step 6: Propose an improvement plan for next iteration
Step 1 — Diagnose intent and failure mode Ask: what is this prompt actually trying to make the model do? Where does it currently break — hallucination, verbosity, wrong format, missed constraints, inconsistent tone?
Step 2 — Structural audit Check for:
- Instructions buried in the middle (models weight start/end more heavily)
- Conflicting instructions (e.g., "be concise" + "explain thoroughly")
- Implicit assumptions not stated (expected output format, audience, length)
- Missing negative constraints (what NOT to do)
Step 3 — Modular rewrite Structure as reusable blocks:
[ROLE] — who the model is acting as
[CONTEXT] — relevant facts/state, only what's needed
[TASK] — the specific action requested
[CONSTRAINTS] — hard rules, format, tone, length
[OUTPUT FORMAT] — exact shape expected
Modularizing lets each block be swapped/reused across prompts in a system without rewriting the whole thing.
Step 4 — Token compression
- Cut redundant restatement of context the model already has (e.g., system prompt vs user prompt duplication)
- Replace verbose natural language instructions with structured lists/tags where equally clear
- Keep few-shot examples minimal — 1-2 high-signal examples beat 5 mediocre ones
- Don't compress safety-critical or disambiguating instructions — token savings there cause failures downstream
Step 5 — Failure case prediction Run the new prompt mentally against:
- Ambiguous/edge-case input
- Adversarial or off-topic input
- Long context that could cause instruction-forgetting
- Cases where the model might default to generic behavior over the specific instruction
Step 6 — Improvement plan Propose one concrete next test, not a wishlist. Include what metric or manual check would confirm success, and a fallback if it doesn't work.
Recommendation▾
Include a brief example of the modular ROLE/CONTEXT/TASK/CONSTRAINTS/OUTPUT template applied to a system-prompt-level (not just single-task) prompt for reuse across an agent system, since that's mentioned in the description
Examples17 / 20
Example 1:
Input:
Please write a good product description for our new shoe that is comfortable and stylish and appeals to young people, make it sound exciting and also mention it's good for running and casual wear, keep it not too long but detailed enough.
Output:
Recommendation▾
Trim the Best Practices and Common Pitfalls sections slightly since some points overlap with Workflow steps 3-5, tightening overall length
Prompt
[ROLE] You are a product copywriter for a youth-focused footwear brand. [TASK] Write one product description for a new shoe. [CONSTRAINTS]
- Length: 60-80 words
- Tone: energetic, casual, Gen Z-friendly
- Must mention: comfort, style, dual use (running + casual wear)
- Do not use generic phrases like "step into the future" or "game-changing" [OUTPUT FORMAT] Single paragraph, no headers, no bullet points.
Optimization Notes
- Split run-on instruction into explicit role/task/constraint blocks — reduces ambiguity about what "good" and "detailed enough" mean
- Replaced vague length guidance ("not too long") with a hard word range
- Added negative constraint to prevent generic marketing clichés the model defaults to
- Made tone concrete ("Gen Z-friendly energetic") instead of "exciting," which is subjective
Token Strategy
- Before: ~45 tokens, vague → often produced 150+ token bloated outputs needing regeneration
- After: ~70 tokens (prompt itself longer) but output length is now bounded, net token cost per usable output is lower
- Did not cut the "comfort + style + dual use" requirement — that's the core content constraint
Failure Cases
- Input shoe has no distinct feature (e.g., no special cushioning) → model may still hallucinate specific tech terms; needs a "if no specific feature given, focus on versatility" fallback clause
- If brand voice varies (formal vs casual) across products, this fixed tone constraint won't generalize — needs a tone variable
Improvement Plan
- Test with 5 different shoe inputs, check word count compliance and clichê avoidance
- Metric: manual pass/fail on "sounds like generic AI copy" (yes/no)
- Fallback: if outputs still drift generic, add one high-signal example description as few-shot
Best Practices
- Put critical instructions at the start AND end of long prompts — mid-prompt instructions get under-weighted
- Prefer structured tags (
[ROLE],[TASK]) over paragraph prose for machine-parsed reliability - One clear constraint beats three soft/qualitative ones ("professional but friendly but not too formal")
- Always state what output format is NOT wanted if the model has a known bad default (e.g., "no preamble," "no markdown headers")
- Test prompts against edge cases, not just the happy path, before calling them optimized
- When modularizing for reuse, keep ROLE and OUTPUT FORMAT stable across a prompt family so downstream parsing doesn't break
Common Pitfalls
- Don't just make a prompt shorter and call it "token efficient" — if it becomes ambiguous, downstream regeneration costs more tokens than it saved
- Don't stack multiple soft adjectives ("engaging, professional, warm, concise") without ranking priority — model can't satisfy all equally
- Don't skip the Failure Cases section — an "optimized" prompt with no stress-testing is just a guess
- Don't remove few-shot examples entirely for token savings if the task is format-sensitive (JSON structure, specific tone matching)
- Don't propose a vague improvement plan like "test more" — specify the exact next input variation and what success looks like