ship_skill

Overview

This skill finalizes an implementation by running an adversarial code review, committing approved changes, and recording a mandatory reflection. It combines adversarial REVIEWER agents and a DOCUMENTER flow to ensure acceptance criteria, documentation, and learnings are captured before marking the task complete.

How this skill works

Load the task file and verify it is in the implement phase, then extract the task contract, implementation details, diffs, and validation results. Launch five parallel Phase 1 review agents (security, performance, architecture, test coverage, code quality), run two Phase 2 adversarial challengers to validate findings, synthesize results into action decisions, commit approved changes, and append a structured reflection to the task file. The process enforces mandatory steps: adversarial review, git commit, and final reflection; failure to pass review transitions the task back to rework.

When to use it

• When implementation is complete and you need an adversarial, multi-perspective review before shipping.
• To verify acceptance criteria mapping, detect out-of-scope changes, and enforce documentation updates.
• When you require an auditable commit plus a recorded reflection for process improvement.
• For tasks that must pass security, performance, architecture, testing, and quality gates simultaneously.

Best practices

• Provide the task identifier and ensure frontmatter.phase is implement before starting.
• Include comprehensive implementation metadata: files modified/created, tests, patterns used, and reviewer handoff notes.
• Run full git diffs and recent logs so review agents have accurate change context.
• Address FIX_NOW items before commit; if REJECT occurs, set phase to rework and iterate.
• Update any docs that reference changed APIs, workflows, or data structures and stage them for the same commit.

Example use cases

• Finalizing a feature branch where ACs must be explicitly mapped to changes and verified.
• Shipping a security-sensitive patch that needs independent adversarial validation before release.
• Completing a refactor that touches architecture and documentation, requiring coordinated doc updates.
• Capturing learnings and pattern outcomes for a complex change so future tasks benefit from recorded reflection.