Pressure-Test Your Spec

Why this exercise?

You already know how to build an OCAREO prompt (TC14). But here's the thing: most OCAREO specs stop at Objective, Context, and Actions. The Rules layer — edge cases, failure modes, constraints — is where the real design lives. And most people skip it because they don't know what to ask.

That's the problem this exercise solves. You're going to install a skill that interrogates your spec until every gap is exposed. Then you'll see the proof: three versions of the same task, side by side, with wildly different results.

The proof: three outputs, one task

Before you build anything, look at what happens when the same task gets three different levels of specification. Same AI, same model, one shot each, no retries.

Version 1 — Bare prompt (what most people do)

Build me a tool that tracks my team's expenses.

What you get: A generic expense tracker with assumptions baked in everywhere.

What breaks:

• Wrong currency (defaults to USD, your team is in EUR)
• No approval flow (auto-approves a EUR 5,000 dinner)
• No rules about receipt requirements (accepts anything)
• No multilingual support (rejects Portuguese receipts)
• Categorises everything under "Other"

The AI fills every gap with guesses. Most of them wrong.

Version 2 — Half-OCAREO (Objective + Context + Actions only)

OBJECTIVE: You are an operations automation expert who designs
lightweight internal tools for mid-size tech companies.

CONTEXT: 25-person engineering team across Berlin and Lisbon.
Using Google Sheets and Slack. Current process: receipts in
a shared Drive folder, no categorisation, finance team manually
matches at month-end. Average 140 expenses per month.

ACTIONS:
1) Categorise expenses by type (travel, software, meals, equipment)
2) Flag duplicates and missing receipts
3) Generate a monthly summary by category and person

What you get: Better structure, correct team size, right tools.

What still breaks:

• No approval threshold (who approves EUR 500 vs EUR 50?)
• Receipt language not specified (rejects Portuguese receipts from Lisbon team)
• No late submission policy (accepts receipts from 6 months ago)
• Ambiguous categorisation (is a home office chair "equipment" or "other"?)

This is where most specs stop. This is also where most tools break.

Version 3 — Full OCAREO spec (after pressure-testing)

OBJECTIVE: You are an operations automation expert who designs
lightweight internal tools for mid-size tech companies.

CONTEXT: 25-person engineering team across Berlin and Lisbon.
Using Google Sheets and Slack. Current process: receipts in
a shared Drive folder, no categorisation, finance team manually
matches at month-end. Average 140 expenses per month.
Budget owner: Engineering VP. Fiscal year: Jan-Dec.

ACTIONS:
1) Categorise expenses by type (travel, software, meals, equipment)
2) Flag duplicates and missing receipts within 48h
3) Route expenses above EUR 500 to VP for approval in Slack (no meeting needed)
4) Generate a monthly summary by category and person
5) Produce a quarterly trend analysis for the VP

RULES:
NEVER auto-approve expenses above EUR 500.
ALWAYS flag receipts older than 30 days as "late submission".
NEVER accept receipts without a date and vendor name.
ALWAYS accept receipts in any language (team is multilingual).
ALWAYS categorise "home office" under "equipment", not "other".
If a receipt is ambiguous, ask the submitter — do not guess.
If the same amount appears twice from the same person within 7
days, flag as potential duplicate but do not auto-reject.

EXAMPLES:
Input: Receipt for EUR 45, "Restaurante Lisboa", 2025-03-12
Output: Category: Meals | Status: Approved (under threshold)
        | Person: Maria S. | Month: March

Input: Receipt for EUR 1,200, "AWS", 2025-03-01
Output: Category: Software | Status: Pending VP approval
        (above EUR 500) | Person: Tom K. | Month: March

OUTPUT:
Monthly Google Sheet with columns: Date, Person, Amount (EUR),
Category, Status (Approved/Pending/Flagged), Notes.
Slack summary posted to #finance-updates on the 1st of each month.
Flag alerts sent as DMs to the submitter within 24h.

What you get: Handles multilingual receipts. Knows the approval threshold. Catches late submissions. Doesn't auto-reject duplicates. Categorises home office correctly. Every edge case the pressure-testing surfaced is now a rule.

None of the rules in Version 3 were in the original spec. All of them matter.

Step 1 — Install the skill

Step 2 — Get pressure-tested

Open a new conversation in ToqanClaw and say:

Pressure-test my spec. I want to build [your real problem here].

The skill will:

1. Ask whether you want a quick prompt (5-10 min) or a deep design (full production spec)
2. Walk you through all six OCAREO phases — one question at a time
3. Push back on vague answers (it won't let you off easy)
4. After each answer, share its own interpretation so you can correct assumptions
5. Surface the Rules layer — edge cases and constraints you hadn't thought of
6. Deliver a structured OCAREO brief AND a ready-to-paste prompt

Try it with something real from your work. The more specific your starting point, the deeper the pressure-test goes.

Step 3 — Compare: before vs. after

Once the pressure-test is done, run a quick experiment:

1. Open a new conversation (fresh context)
2. Paste the original vague version of your request and run it
3. Open another new conversation
4. Paste the pressure-tested OCAREO prompt the skill produced and run it
5. Compare the outputs side by side

The difference isn't subtle. The pressure-tested version handles edge cases the bare prompt doesn't even know exist.

Step 4 — Pressure-test a colleague

The most powerful use of this skill is on someone else's problem. Why? Because when you describe your own work, you carry implicit knowledge — assumptions you don't even realise you're making. The skill exposes those assumptions.

Pair up with someone and pressure-test each other's specs. Even without the skill open, you can run a quick human pressure-test with three questions:

1. "What happens when it goes wrong?" — surfaces failure modes and edge cases
2. "Who else will use this output, and what do they need?" — surfaces audience gaps
3. "What should it NEVER do?" — surfaces the Rules layer directly

You'll be surprised how many gaps surface when a structured interview replaces a casual description.

Step 5 — Save your tested spec

OptionalGo deeper▸

Once you've been pressure-tested, try these advanced moves:

• Pressure-test an existing prompt — paste a prompt you've been using and say "pressure-test this". The skill will find what's missing.
• Use pressure-testing before building apps — run a session before TC2 (Build your first app) and see how much better the output is.
• Stack with OCAREO templates — combine the tested spec with the problem-framing skill from TC14 for recurring tasks.
• Production specs — for anything going to production, always choose "deep design" in the scope calibration. The extra 10 minutes save hours of rework.

What just happened

You learned to stress-test your own specifications before AI ever touches them. This is the difference between a prototype and something that lasts. The spec describes the outcome, not the solution — and the Rules layer is where outcomes get precise.

OCAREO is the Portuguese methodology OCANES adapted for English: Objective, Context, Actions, Rules, Examples, Output. Same framework, same power.

FAQ

Q: Is this different from TC14 (Problem Framing with OCAREO)? A: Yes. TC14 teaches you the OCAREO structure — what each letter means. This exercise teaches you how to interrogate a spec until it's complete. TC14 gives you the framework; this gives you the quality assurance process.

Q: Can I pressure-test someone else's prompt? A: Absolutely. Say "pressure-test this" and paste any existing prompt. The skill will identify gaps across all six OCAREO phases.

Q: How long does a deep pressure-test take? A: 15-25 minutes for a production spec. The quick mode takes 5-10 minutes. Both are dramatically faster than writing a spec from scratch — and more thorough.