Ship Pipeline · ratify · updated 2026-07-19
Own the decisions your AI makes.
Ask an agent to write code and you get a black box. You have to read all of it back to know what's going on in detail.
/ratify is a Claude Code skill that has the agent walk you through the code around core design elements. You give your expected behavior, it tells you what it chose, and you author the final call.
The final result is yours to own, not just approve.
What it solves
No more massive PR reviews
Everyone wants to build faster with AI-generated code, but it often costs more time than it saves. Research shows code reviews are a rising cost:
- "When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts" (METR, 2025).
- "Bugs per developer are up 54%. The incidents-to-PR ratio has more than tripled. Median review time has increased 5X. 31% more PRs are merging without any review" (Faros AI, 2026).
- "We found that using AI assistance led to a statistically significant decrease in mastery... participants in the AI group scored 17% lower than those who coded by hand" (Anthropic, 2026).
AI work can outpace the people answering for it. /ratify is built to help close that gap by improving ownership over increments of work.
What it does
Open the black box & examine its parts
Like a handoff meeting, the AI agent steps through each decision with you one at a time: it lays out the work or code at the core of that decision, shares the context around it, then asks what you'd expect before it reveals what it actually thought.
Where the two diverge, you decide what the actual behavior should be. You own judgement on the final design decisions before pushing.
- Predict before reveal — you have to predict code behavior before seeing what AI wanted it to do.
- You make the final call — AI won't move past a design decision without your approval, so you sign off before committing.
The data · five systems
Misalignment is not a miss
Across development work on 5 different projects — this includes non-code systems like skills — I made predictions on 31 core decisions:
most foreseen before the reveal · steered on every divergence · none slipped through
77% of decisions were built as I intended from seeing the code around it. On any misaligned prediction, I changed or cut the AI's proposal. I improved or corrected 6 times the AI didn't match the behavior I intended, and demoted one decision AI generated on its own as out of scope. There were 0 decisions where I had no idea and left the final choice to AI.
Each misaligned prediction had a visible cause:
authored a better call · needed specific knowledge to be certain · did not misjudge what the code should do
2 times the AI and I differed, I had a better understanding of how code should behave. The AI fell short, so I authored the outcomes. For 5 decisions, I needed more domain knowledge or deeper tool knowledge, but these weren't failed quizzes. After learning what I needed, I ruled on what was committed in the end.
0 times did I misjudge how the system should behave, and AI never committed before I could approve it myself. Even if something breaks, I'd know where to look.
Three examples
Where ownership made a difference
/ratify's first run was Runway (an app I'm building) where I cold-predicted code behavior in 21/23 cases and overrode 2 AI choices to make sure v0 worked as I intended. I've run it on non-code systems I'm buliding too for my AI workflow, and here's where my authorship made a difference:
Building the full desired scope
non-codepersona-library
The AI recommended deferring a feature when it judged the demand wasn't real yet. It didn't know I had already been using a rough version of that feature, repeatedly. I overrode it and built the feature in. Misaligned prediction, but I called out AI on something I knew and it didn't. Logged as authorship, not a miss.
Clearly defining my data schema
non-coderatify-schema-v2
When knowledge difference between me and AI causes disagreement, the AI wanted to categorize both as "missing-info" in /ratify's schema. I decided it was better to distinguish that from "authored" because there are 2 distinct cases here. Sometimes I need more info to make a confident choice, but sometimes I have info the AI is missing. Patterns will show where users need to document or research better.
Verify important features before committing
codeRunway
Upon revisiting a feature, I noticed a sharper way to design it using domain knowledge I didn't have before. Refactoring broke tests and gave me the chance to redesign, rebuild, test, and approve before calling this done. Review gave me a chance to verify something that looked right at a glance but didn't actually fully meet my design needs.
Honest status
An early record, not a study. 31 logged decisions across five delegated systems, plus the original code build that proved it first. One person, a handful of sittings. It's proof /ratify can help increase work ownership while still leveraging AI to move faster, but it hasn't been tested at scale.
What's hard evidence, and what isn't. I've been iterating on /ratify by using it and improving as I go. About two-thirds of these records were typed retrospectively after updating the schema based on patterns noticed in my own decision logs, so not all data was caught live. The log is append-only; every number here is recomputed from raw entries when you read it.
Future testing and use in daily work
"Ship Pipeline" is a pipeline of skills I'm working on to bake ownership into the development process, and /ratify is one of the core pieces. It's a process for being intentional about building documentation, testing, and trust into AI-assisted development workflows to mitigate excess review time.
Build around documented design, ratify the actual implementation, and hone your mastery as you go.
The whole point is a "done" you earned, not one you claimed.
Try it yourself
Run /ratify on your own work
You can try this skill with Claude Code right now. In the full Ship Pipeline skill set, it runs in /finish-build when there is a possible decision fork. Install it and run it on work you're finishing. Say "ratify this spec", "walk me through ratifying these,", just /ratify, or let a pipeline stage invoke it at its stop gate.
github.com/chzylee/skill-library — install /ratify on its own; github.com/chzylee/ship-pipeline — the full pipeline it anchors.
What /ratify operates on
A run ratifies the functional decisions for a unit of work: a spec, a design doc, a decision list, a build increment. If you're building on something, it checks that your build respects the design doc.
It starts by naming that artifact, explaining what you sign off on, and listing its decisions. Then it walks through them, asking what you predict before each reveal.
Name the decisions clearly going in, and the record comes out sharp. You predict before AI reveals so you can think in tandem with it without its influence appearing first.