Transplant a skill, command, or capability from one agentic-system repo into another via a 5-phase gated protocol (inventory → import → localize → wire → verify). Use when grafting a feature from an upstream repo that has its own dependencies, platform assumptions, or upstream-specific file references that need adapting before the feature will work in the destination repo. Not for copying a self-contained file — use only when the feature has a dependency footprint and the destination repo has its own conventions the import must respect.

2026-04-212

build-scoring

SujinHwang27/agent-os-lab

Design multi-dimensional evaluation rubrics with calibrated scales, thresholds, and function-adaptive weights.

2026-04-132

define-audiences

SujinHwang27/agent-os-lab

Identify who evaluates the user's output, what each audience prioritizes, and where their priorities conflict.

2026-04-132

design-identity

SujinHwang27/agent-os-lab

Define the user context model — identity axes, context files, persona variants, and privacy rules for the target OS.

2026-04-132

design-loops

SujinHwang27/agent-os-lab

Design compounding feedback loops — what data accumulates, what reads it, and how the system gets smarter with use.

2026-04-132

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:

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")
Freshness verification: Is the reference data current? What's the staleness threshold?
Specificity test: "Could this output have been produced for a different [target]?" If yes, it's too generic.
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:

Name it. (e.g., "Framework Recitation," "Metric-Free Claims," "Generic Praise")
Describe what it looks like. Give an example of the bad output.
Explain why it's bad. What does the audience think when they see it?
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:

What does the voice sound like? One sentence. (e.g., "Smart colleague who's done this 100 times, not a consultant writing a report.")
What words are banned? List specific words that signal AI-generated or domain-inappropriate language.
What's the formality level? Scale: casual friend → professional colleague → formal authority.
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:

Which skills require which files? Map dependencies.
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)
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) |

Step 6: Data Trust Rules

If the OS ingests external data, define trust levels:

What sources are high-trust? (live observation, direct API — Level 1)
What sources are medium-trust? (structured API with cache, RSS — Level 2)
What sources are low-trust? (cached search, web scraping — Level 3)
What's the verification rule? (must verify low-trust before acting)
What labels are used? ([VERIFIED], [UNVERIFIED], [STALE: date])

Structure into:

## Data Trust Rules

### External Data Sources
| Source | Trust Level | Verification Rule | Staleness Threshold |
|---|---|---|---|
| [source] | Level [1/2/3] | [how to verify] | [when it's stale] |

### Verification Labels
- **[VERIFIED]:** Confirmed via Level 1/2 source
- **[UNVERIFIED]:** Not yet verified (e.g., batch mode, Level 3 only)
- **[STALE: date]:** Data older than staleness threshold

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