Quality Guard

A meta-skill that enhances output quality through four structured gates:
first-principles decomposition, explicit contracts, controlled execution,
and adversarial verification.

When to Use

• As a dependency in complex skills (data analysis, report generation, code output)
• When output correctness is critical
• When the task has ambiguity or multiple valid interpretations
• When the output will be used for decision-making
• When consistency across multiple runs matters

The Four Gates

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   本质解构   │ → │   契约定义   │ → │   受控执行   │ → │  对抗验证   │
│ (Deconstruct)│    │  (Contract) │    │  (Execute)  │    │ (Adversarial)│
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
       ↑                                                      │
       └────────────── 验证失败则回溯修正 ←─────────────────────┘

Gate 1: Deconstruct (本质解构)

Before executing, strip the request to its essential problem.

Why: Most quality failures start with solving the wrong problem.
A perfectly executed analysis of the wrong metric is worthless.

Method:
1. Surface request — What was literally asked? (quote it)
2. 5-Why analysis — Why is this needed? Keep asking until you hit
a decision, action, or state change.
3. Essential problem — Restate in one sentence: "The real problem is..."
4. Assumptions — List everything you're taking for granted

Output format:

Surface: [original request]
Why chain: [why1] → [why2] → [why3]...
Essential: [one-sentence problem statement]
Assumptions: [list with confidence levels]

Red flags that require deeper deconstruction:
- The request contains jargon or domain terms you don't fully understand
- Multiple stakeholders with potentially conflicting goals
- The "obvious" interpretation seems too simple for the context
- The requester seems uncertain about what they want

Gate 2: Contract (契约定义)

Define what "good" looks like before producing it.

Why: Explicit contracts prevent scope creep, format drift, and
the "I thought you meant X" problem. They also give you a checklist
for self-verification.

Contract elements:

Output: Written contract — can be 3 bullet points for simple tasks,
full table for complex ones.

When to get user sign-off:
- Output format matters (client deliverable, presentation, etc.)
- Ambiguity in scope or depth
- Trade-offs exist (speed vs completeness, detail vs clarity)

Gate 3: Execute (受控执行)

Produce output while maintaining process discipline.

Why: Discipline during execution prevents silent errors,
unverified assumptions, and "confidence inflation."

Rules:

1. Contract visible — Keep the contract in context; check against it
   as you work, not just at the end.

2. Mark uncertainty — Distinguish between:
   - [VERIFIED] — directly from data/source
   - [INFERRED] — logically derived, assumptions stated
   - [ESTIMATED] — guessed/extrapolated, confidence level noted
   - [UNKNOWN] — couldn't determine, flagged for user

3. Document deviations — If you must deviate from the contract,
   note: what changed, why, and impact on output.

4. Trace decisions — For complex reasoning, show key decision points.
   Not full chain-of-thought, but enough for audit.

Output: Draft deliverable + Process notes (brief)

Gate 4: Adversarial (对抗验证)

Attack your own output before delivering.

Why: Self-criticism is hard. Structured adversarial review forces
you to find problems before the user does.

Three lenses — run each explicitly:

Lens 1: The Skeptic (怀疑论者)

Goal: Find logical and evidential weaknesses

• Is every claim supported? By what specifically?
• Are there alternative explanations for the patterns observed?
• What would make this conclusion wrong?
• Is the sample/method representative, or biased?

Lens 2: The Adversary (恶意用户)

Goal: Find misuse and misinterpretation risks

• How could this be quoted out of context?
• What decision could someone wrongly make based on this?
• Is any phrasing ambiguous enough to be misleading?
• What's the worst-case interpretation of this output?

Lens 3: The Edge-Tester (边界测试员)

Goal: Find boundary and exception failures

• Does this work with empty/null/minimal data?
• What about extreme values (0, negative, very large)?
• Timezone/currency/locale edge cases?
• Concurrent modification/version conflicts?

Output format:

Adversarial review:
- Skeptic: [findings or "no issues"]
- Adversary: [findings or "no issues"]  
- Edge-tester: [findings or "no issues"]
Confidence: [HIGH/MEDIUM/LOW with rationale]
Revisions needed: [list, or "none"]

Confidence levels:
- HIGH — All lenses passed, verified data, no assumptions
- MEDIUM — Minor caveats, some inferred data, assumptions stated
- LOW — Significant unknowns, unverified assumptions, or edge case risks

Integration Pattern

When used as a dependency in another skill:

# In the consuming skill's workflow

1. LOAD quality-guard at task start

2. RUN Deconstruct:
   - If essential problem differs from surface request → confirm with user
   - If assumptions >3 or any low-confidence → flag explicitly

3. DEFINE Contract:
   - Simple task: 3-bullet contract inline
   - Complex task: full contract table, user sign-off if stakes high

4. EXECUTE with contract in context:
   - Tag all uncertainty markers
   - Note any forced deviations

5. RUN Adversarial review:
   - All three lenses, explicit output
   - If confidence LOW → consider revision or user check-in

6. DELIVER:
   - Final output (clean, no meta-commentary unless requested)
   - Confidence label if MEDIUM or LOW
   - Brief process notes if user asked for transparency

Quick Reference by Task Type

Failure Modes to Watch

See references/failure-modes.md for full catalog. Most common:

1. Solving the wrong problem well — Gate 1 failure
2. Format drift — Contract not enforced during execution
3. Silent assumption failure — Unverified guess presented as fact
4. Edge case crash — Adversarial review skipped or superficial
5. Confidence inflation — MEDIUM work delivered as HIGH confidence

References

• references/first-principles.md — Detailed decomposition methods
• references/adversarial-review.md — Attack vectors and review checklists
• references/failure-modes.md — Catalog of common AI output failures

Scripts

• scripts/validate_structure.py — Programmatic structure/format validation
• scripts/adversarial_probe.py — Generate adversarial test cases

Agents

• agents/reviewer.md — Sub-agent instructions for independent adversarial review