How do I install the Output Contracts skill?

Run npx skillmds@latest add rick-orphen/output-contracts in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Output Contracts safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Output Contracts?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Output Contracts free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under Apache-2.

Who published Output Contracts?

RICK-ORPHEN (@rick-orphen) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Output Contracts by rick-orphen — Agent Skill

Name: Output Contracts
Rating: 4.2 (5 reviews)
Author: RICK-ORPHEN

Output Contracts

The reference standard for deciding whether something may be shipped, and whether a command may be run. Returns PASS / DEGRADED / FAIL at three gates: entry, mid-work (destructive and irreversible operations), and exit. Use when: you want a fixed yardstick for 'is this safe to run' or 'is this ready to hand over'. Do NOT use when: you need the procedure for a specific change — this ships criteria, not steps.

RICK-ORPHEN Updated Sep 22, 2026

File contents

Output Contracts — the standard for what may ship

This skill ships criteria, not procedures. Other skills read it to decide pass or fail.

What is in here

File	Applies to	Contents
`work-contract.yaml`	Documents, decks, reports, sites, landing pages, dashboards	Forbidden destructive commands, per-archetype acceptance criteria, ban on silent degradation

This is a starting point, not a finished policy. Adapt the archetypes and the acceptance criteria to your own deliverables. What must not change is the three-valued verdict, the ban on silent degradation, and never counting an unchecked item as a pass.

Three gates

Entry — run preflight once before touching any source material or external tool. If a prerequisite is missing, stop; do not try to fix the environment on the spot. Reinstalling a missing tool mid-run has broken things that were already working.
Mid-work — do not run operations you cannot undo: brew uninstall, pip uninstall, rm -rf <system path>, git push --force, git add -A, DROP TABLE. The rule is install the new thing, verify it, then remove the old one. When a command is borderline, check it against irreversible_ops.block_patterns in the contract.
Exit — check the output acceptance criteria before handing anything over and return one of three verdicts: PASS / DEGRADED / FAIL.

⚠️ DEGRADED is not success

Any workaround that changes the nature of the output — a video that became a still, audio that disappeared, captions that were never burned in, chapters dropped to make the numbers work, real data replaced with sample data because the real data could not be fetched, an image-less deck because image generation failed — must never be carried through silently.

Always tell the requester what was lost and ask how they want to handle it. Do not report "100% complete."

This is not about reducing autonomy. It separates workarounds you may carry on through from degradations you must always disclose. The boundary is written in the contract's fallback_policy.

Never count an unchecked item as a pass

A check must list "N unverified" separately. Do not fill in what you could not read, or what was never specified, with a guess and then call it a pass. The moment unverified items are folded into the pass count, the check starts lying.

How to use it

The contracts are YAML — read them directly and judge. To run the check, the calling pipeline passes its archetype and the checker matches against it.

The contract files live in different places depending on the environment, so do not hardcode one path. Look in this order:

an explicit environment variable
the same directory as the checker (when shipped alongside it)
this skill's own directory

If none of them has it, print the places you looked and stop. Do not proceed on a guess.

---name: output-contractsdescription: The reference standard for deciding whether something may be shipped, and whether a command may be run. Returns PASS / DEGRADED / FAIL at three gates: entry, mid-work (destructive and irreversible operations), and exit. Use when: you want a fixed yardstick for 'is this safe to run' or 'is this ready to hand over'. Do NOT use when: you need the procedure for a specific change — this ships criteria, not steps.license: Apache-2.0---# Output Contracts — the standard for what may shipThis skill ships **criteria, not procedures.** Other skills read it to decide pass or fail.## What is in here| File | Applies to | Contents ||---|---|---|| `work-contract.yaml` | Documents, decks, reports, sites, landing pages, dashboards | Forbidden destructive commands, per-archetype acceptance criteria, ban on silent degradation |This is a starting point, not a finished policy. **Adapt the archetypes and the acceptancecriteria to your own deliverables.** What must not change is the three-valued verdict, the banon silent degradation, and never counting an unchecked item as a pass.## Three gates1. **Entry** — run preflight once before touching any source material or external tool. If a prerequisite is missing, **stop; do not try to fix the environment on the spot.** Reinstalling a missing tool mid-run has broken things that were already working.2. **Mid-work** — do not run operations you cannot undo: `brew uninstall`, `pip uninstall`, `rm -rf <system path>`, `git push --force`, `git add -A`, `DROP TABLE`. The rule is *install the new thing, verify it, then remove the old one.* When a command is borderline, check it against `irreversible_ops.block_patterns` in the contract.3. **Exit** — check the output acceptance criteria before handing anything over and return one of three verdicts: **PASS / DEGRADED / FAIL**.## ⚠️ DEGRADED is not successAny workaround that **changes the nature of the output** — a video that became a still, audiothat disappeared, captions that were never burned in, chapters dropped to make the numberswork, real data replaced with sample data because the real data could not be fetched, animage-less deck because image generation failed — must never be carried through silently.Always tell the requester **what was lost** and ask how they want to handle it.**Do not report "100% complete."**This is not about reducing autonomy. It separates workarounds you may carry on through fromdegradations you must always disclose. The boundary is written in the contract's`fallback_policy`.## Never count an unchecked item as a passA check must list **"N unverified"** separately. Do not fill in what you could not read, orwhat was never specified, with a guess and then call it a pass. The moment unverified itemsare folded into the pass count, the check starts lying.## How to use itThe contracts are YAML — read them directly and judge. To run the check, the calling pipelinepasses its `archetype` and the checker matches against it.The contract files live in different places depending on the environment, so **do not hardcodeone path.** Look in this order:1. an explicit environment variable2. the same directory as the checker (when shipped alongside it)3. this skill's own directoryIf none of them has it, **print the places you looked and stop.** Do not proceed on a guess.

Frequently asked questions