# Interface Ship > Run the final evidence-based release gate and issue a SHIP, SHIP WITH KNOWN LIMITATIONS, or DO NOT SHIP verdict. Use before releasing interface work, when deciding whether quality and coverage are sufficient, or when remaining risk must be made explicit. - Skill: `dragoon0x/interface-ship` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add dragoon0x/interface-ship` - Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/interface-ship/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dragoon0x (https://skillmd.com/u/dragoon0x) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dragoon0x/interface-ship --- # Interface Ship ## Mission Decide whether the interface is ready to be trusted by real users. This is a gate, not a summary. ## Release philosophy A feature is not ready merely because it compiles, looks attractive, passes the happy path, or has been declared done. It is ready when remaining risk is understood and acceptable. ## Intent gate Verify intended task, requested outcome, common path, acceptance criteria, and scope. ## Architecture gate Verify hierarchy, navigation, surface selection, state ownership, responsive architecture, and progressive disclosure. ## Craft gate Verify typography, spacing, alignment, density, color, material, iconography, imagery, states, and consistency. ## Interaction gate Verify feedback, transitions, motion, interruption, cancellation, loading, errors, recovery, focus, and input modalities. ## Adaptation gate Verify meaningful combinations of space, input, content, text scaling, orientation, and reduced motion. ## State gate Verify reachable important states: empty, loading, success, error, disabled, partial, overflow, stale, interrupted, restored. ## Accessibility gate Verify native semantics, names, keyboard, focus, contrast, non-color cues, target behavior, reduced motion, and dynamic updates. ## Performance gate Use evidence for startup, interaction latency, rendering, memory, network, or storage where relevant. Never invent measurements. ## Regression gate Identify changed components, shared primitives, changed behavior, adjacent flows, and known untouched areas. Test according to coupling and impact. ## Evidence language VERIFIED: direct evidence supports the claim. PARTIALLY VERIFIED: relevant evidence exists but coverage is incomplete. UNVERIFIED: not adequately tested. FAILED: evidence contradicts the requirement. Never turn "looks fine" into VERIFIED. ## Release matrix | Area | Evidence | Status | |---|---|---| | Intent | ... | PASS/FAIL | | Architecture | ... | PASS/FAIL | | Craft | ... | PASS/FAIL | | Interaction | ... | PASS/FAIL | | Adaptation | ... | PASS/FAIL/UNKNOWN | | States | ... | PASS/FAIL/UNKNOWN | | Accessibility | ... | PASS/FAIL/UNKNOWN | | Performance | ... | PASS/FAIL/UNKNOWN | | Regression | ... | PASS/FAIL/UNKNOWN | ## Confidence Do not invent a scientific-looking single score. Report evidence coverage: critical paths tested, important states tested, important contexts tested, known gaps, and unresolved risk. ## Never ship Do not recommend shipping when the primary workflow is broken, critical state is corrupt, important action is inaccessible, a major regression exists, a core requirement is missing, destructive behavior is unsafe, or a release-critical area is entirely unverified. ## Verdict ### SHIP Release-critical requirements pass and evidence is sufficient. ### SHIP WITH KNOWN LIMITATIONS No blocker remains, but explicit non-critical limitations or uncertainty remain. ### DO NOT SHIP A release-critical problem exists or essential evidence is missing. ## Final report ### Verdict One of the three. ### What changed Brief factual summary. ### What was verified Concrete evidence. ### Known limitations Only real limitations. ### Release risk What remains uncertain and why it is acceptable or blocking. ## Reference artifact Use `references/release-report.md` to produce the final release report with scope, critical paths, evidence, gaps, risk, and verdict. ## Completion criteria The release decision is backed by evidence and remaining risk is explicit. ## Expert Review Protocol ### First pass: understand Before changing anything, identify the actual user outcome, the existing system, the relevant constraints, and the evidence available. Do not begin by choosing a visual treatment. ### Second pass: compare Ask: - What is the simplest credible solution? - What is the strongest alternative? - What does the current solution cost? - What behavior does each option teach the user? - Which decision is easiest to reverse? - Which failure would be most expensive? Choose deliberately. ### Third pass: stress Do not review only the happy path. Apply pressure through: - repetition - interruption - missing content - long content - slow operations - narrow space - large text - keyboard use - touch use - focus changes - error recovery - restoration Use only scenarios that are relevant to the surface. ### Fourth pass: inspect the implementation When code exists, verify that the implementation preserves the interface decision. Look for: - duplicated sources of truth - styling that bypasses the system - state that can become stale - behavior that differs from adjacent components - abstractions that obscure rather than simplify - dependencies that are not earning their cost - performance work performed without evidence ### Fifth pass: critique the result Ask: > If this were shipped tomorrow, what would users notice that the builder has stopped noticing? Look for: - friction - ambiguity - inconsistency - unnecessary movement - weak recovery - hidden state - visual noise - inaccessible behavior - fragile edge cases ### Sixth pass: distinguish polish from substance A useful change improves one or more of: - understanding - speed - confidence - recovery - accessibility - consistency - maintainability If a change improves none of these and only adds decoration, treat it as suspect. ### Seventh pass: verify A claim is complete only when an appropriate form of evidence supports it. Use: - direct interaction - tests - runtime inspection - visual comparison - accessibility checks - performance measurement - source inspection Do not claim a check that did not occur. ### Completion standard Stop when: 1. the intended outcome is achieved 2. important states are handled 3. meaningful failure modes were considered 4. the interface fits its surrounding system 5. important claims are verified 6. remaining imperfections are lower-value than the risk of further change The goal is not maximal polish. The goal is a result that is difficult to improve without changing the underlying decision.