write-quality-contract

name	write-quality-contract
description	Define the non-negotiable rule, verification checks, anti-patterns, banned vocabulary, and tone for the target OS.

/write-quality-contract - Quality Contract Design

When to Use

• After domain discovery and identity model are in place
• When defining the guardrails that prevent the OS from producing harmful output
• When domain-input/quality-contract.md needs to be filled

Inputs

• Auto-loaded: domain-input/domain-workflow.md (what gets produced)
• Auto-loaded: domain-input/audiences.md (who evaluates it)
• Auto-loaded: domain-input/identity-model.md (what data is available to verify against)
• Auto-loaded: domain-input/scoring-rubrics.md (what "good" looks like quantitatively)

Process

Step 1: The Non-Negotiable Rule

Every OS has one rule above all others. In a production reference OS, it's "never fabricate experience." This rule shapes every skill.

Ask the designer: "What is the ONE thing the system must NEVER do? The thing that, if it happened once, would destroy trust or cause real harm?"

Probe until you get something specific and testable:

• "Don't make stuff up" → Too vague. Make stuff up about what? What's the test?
• "Never include a claim the user can't defend in a live conversation" → Better. Testable.
• "Never cite a source that doesn't exist" → Specific. Testable.
• "Never recommend a drug interaction that hasn't been verified" → Specific. High stakes.

Structure:

## The Non-Negotiable Rule

**Rule:** [one sentence, specific and testable]

**Why this matters:** [what happens if violated — concrete consequence]

**How to verify:** [the test every skill runs before presenting output]

**What to do when uncertain:** [flag with [UNVERIFIED], ask user, or STOP]

Step 2: Verification Checks

For each type of output the OS produces, design a verification step:

1. Source verification: Can every claim be traced to a specific entry in the context library? (equivalent to "every resume bullet traces to experience-library.md")
2. Freshness verification: Is the reference data current? What's the staleness threshold?
3. Specificity test: "Could this output have been produced for a different [target]?" If yes, it's too generic.
4. Audience alignment test: Does this output satisfy the primary audience's top priority?

For each check:

### Verification Check: [Name]

**Applies to:** [which skill outputs]
**Test:** [specific question to ask]
**Pass:** [what passing looks like]
**Fail action:** [what to do when it fails — flag, stop, or rewrite]

Step 3: Anti-Patterns

Ask the designer: "What does lazy AI output look like in this domain? What's the thing that technically answers the question but is actually useless?"

Get 5-7 specific anti-patterns. For each:

1. Name it. (e.g., "Framework Recitation," "Metric-Free Claims," "Generic Praise")
2. Describe what it looks like. Give an example of the bad output.
3. Explain why it's bad. What does the audience think when they see it?
4. Describe the fix. What should the output look like instead?

Structure:

## Anti-Patterns

### 1. [Name]
**Looks like:** "[example of bad output]"
**Why it's bad:** [what the audience thinks]
**Fix:** [what good output looks like instead]

Step 4: Tone and Vocabulary

Ask the designer:

1. What does the voice sound like? One sentence. (e.g., "Smart colleague who's done this 100 times, not a consultant writing a report.")
2. What words are banned? List specific words that signal AI-generated or domain-inappropriate language.
3. What's the formality level? Scale: casual friend → professional colleague → formal authority.
4. What's the length standard? For each output type: what's the target length? What's the maximum?

Structure:

## Tone

**Voice:** [one sentence]
**Formality:** [level]
**Banned words:** [list]
**Length standards:**
- [Output type 1]: [target / max]
- [Output type 2]: [target / max]

Step 5: Empty Context Guardrails

Design the system's behavior when context files are missing or empty:

1. Which skills require which files? Map dependencies.
2. What's the zero-setup entry point? At least one skill must work without any context. This is the "hook" that earns trust. (equivalent to /quick-start)
3. What's the message when context is missing? Specific, not generic. Tell the user exactly what to fill and why.

Structure:

## Empty Context Behavior

### Zero-Setup Entry Point
**Skill:** /[X]
**Works without:** any context files
**Purpose:** [immediate value that earns trust for setup investment]

### Dependency Map
| Skill | Requires | If Missing |
|-------|----------|-----------|
| /[X] | [files] | HARD STOP: "[message]" |
| /[Y] | [files] | WARN: "[message]" |
| /[Z] | none | Proceed (zero-setup entry point) |

Output

Write the complete quality contract to domain-input/quality-contract.md.

Tell the designer:

Quality contract defined:
- Non-negotiable rule: [the rule]
- [N] verification checks
- [N] anti-patterns named
- Voice: [one sentence]
- Banned words: [list]
- Zero-setup entry point: /[X]

Most important guardrail: [the verification check that catches the most common failure mode]

Next: Run /design-skills to design the full skill set.

Quality Checks

Good quality contract:

• The non-negotiable rule is specific enough to test programmatically
• Anti-patterns include real examples of bad output, not abstract descriptions
• Verification checks are tied to specific context files
• At least one zero-setup skill is identified
• Banned words are domain-specific, not just generic AI slop words

Bad quality contract:

• Non-negotiable rule is vague ("be accurate")
• Anti-patterns are generic ("don't be too wordy")
• No verification mechanism — just "check your work"
• No zero-setup entry point
• Tone description could apply to any domain