# How the /ship-check Command Audits AI-Generated Code in pm-skills > Discover how the /ship-check command audits AI-generated code in pm-skills. This six-step workflow ensures code quality by documenting intent, auditing security, and mapping test coverage for a review-ready shipping packet. - Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills) - Tags: how-to-guide - Published: 2026-07-01 --- **The `/ship-check` command orchestrates a six-step workflow that transforms AI-generated code into a review-ready shipping packet by documenting system intent, auditing security and performance against that baseline, and deriving test coverage maps to close quality gaps.** The `phuryn/pm-skills` repository provides structured command specifications for AI-assisted project management. When you need to validate AI-generated code before production, the `/ship-check` command audits AI-generated code by chaining specialized skills into a comprehensive quality gate that compares documented intent against actual implementation. ## The Six-Step Audit Workflow The audit process defined in [`pm-ai-shipping/commands/ship-check.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/ship-check.md) executes sequentially, with each step building upon the artifacts of the previous one. ### Step 1: Document the System Intent The workflow begins by establishing an **intended-state baseline**. The command runs `/document-app` (or ingests existing documentation) and applies the **shipping-artifacts** skill to generate [`architecture.md`](https://github.com/phuryn/pm-skills/blob/main/architecture.md), [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/flows.md), [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md), and variables documentation. This creates the authoritative reference that all subsequent audits compare against. ### Step 2: Wire Agent Context Next, `/ship-check` creates or updates [`CLAUDE.md`](https://github.com/phuryn/pm-skills/blob/main/CLAUDE.md) and a thin [`AGENTS.md`](https://github.com/phuryn/pm-skills/blob/main/AGENTS.md) derived from the documentation. This step gives downstream AI agents a clear operating manual, ensuring that all future changes respect the documented architectural intent and security boundaries. ### Step 3: Execute Security Audit The command runs `/security-audit-static` to perform a static analysis that: - Maps entry points to trust boundaries and sinks - Inspects high-value paths (authentication, data access) - Cross-references the **intended-vs-implemented** skill against the docs from Step 1 - Applies **self-refutation** to dismiss false positives - Reports only evidence-backed risks This security audit specifically flags where implementation diverges from documented permissions or flows, as implemented in [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md). ### Step 4: Run Performance Audit In parallel to the security pass, `/ship-check` executes `/performance-audit-static` to catch over-fetching, missing database indexes, and caching problems. This guarantees the code meets performance expectations before shipping. ### Step 5: Derive Test Coverage Map The workflow calls `/derive-tests` to turn documented rules and uncovered audit findings into a [`tests.md`](https://github.com/phuryn/pm-skills/blob/main/tests.md) coverage map. This artifact marks which rules already have tests, which are only proposed, and which lack verification entirely. By converting every detected gap into an explicit regression test requirement, the command prevents the same issue from resurfacing after subsequent AI edits. ### Step 6: Compile the Shipping Packet Finally, `/ship-check` synthesizes all artifacts into a single markdown packet (e.g., [`shipping_packet_2024-07-01.md`](https://github.com/phuryn/pm-skills/blob/main/shipping_packet_2024-07-01.md)). The packet includes: - Documentation inventory - Agent context status - Test-coverage summary - Security and performance summaries - Launch blockers - Recommended next actions This document serves as the hand-off artifact for human reviewers, clearly showing what was audited, what passed, and what requires sign-off. ## Reliability Mechanisms The `/ship-check` command achieves audit reliability through four core architectural decisions. ### Ordered Orchestration Each step depends on the outputs of the previous step, ensuring that security and performance audits always compare against the most current "intent" documentation. This prevents audits from running against stale or missing specifications. ### Intended-vs-Implemented Verification By cross-referencing files like [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md) and [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/flows.md) with the actual codebase using the **intended-vs-implemented** skill ([`pm-ai-shipping/skills/intended-vs-implemented.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/skills/intended-vs-implemented.md)), the audit catches missing security checks or architectural deviations that static analysis alone would miss. ### Self-Refutation Protocol The security command attempts to disprove every candidate finding before reporting it. Only risks that survive this adversarial validation—those backed by concrete evidence of divergence from documented intent—appear in the final report. ### Test Coverage Derivation Rather than simply listing vulnerabilities, the workflow immediately converts audit gaps into concrete test requirements. This closes the loop between audit and quality assurance, ensuring every finding has a verification path. ## Usage Examples Run `/ship-check` against your entire repository or target specific services: ```text # Full repository audit /ship-check # Target a specific microservice /ship-check payments-service # Audit a directory of Supabase functions /ship-check supabase/functions ``` The command prints a concise summary to the console and writes the detailed shipping packet to the workspace root, ready for attachment to a pull request. ## Key Source Files The audit logic resides in the `pm-ai-shipping` directory: - [`pm-ai-shipping/commands/ship-check.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/ship-check.md) — Orchestrates the full shipping sequence and defines packet layout - [`pm-ai-shipping/commands/security-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/security-audit-static.md) — Implements the static security audit - [`pm-ai-shipping/commands/performance-audit-static.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/performance-audit-static.md) — Performs the static performance audit - [`pm-ai-shipping/commands/document-app.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/document-app.md) — Generates system documentation - [`pm-ai-shipping/commands/derive-tests.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/derive-tests.md) — Produces the test-coverage map - [`pm-ai-shipping/skills/intended-vs-implemented.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/skills/intended-vs-implemented.md) — Compares documented intent with implementation - [`pm-ai-shipping/skills/shipping-artifacts.md`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/skills/shipping-artifacts.md) — Gathers core architecture and flow documentation ## Summary - The `/ship-check` command audits AI-generated code through a six-step ordered workflow: document, wire context, security audit, performance audit, derive tests, and compile packet. - It relies on the **shipping-artifacts** skill to generate baseline documentation and the **intended-vs-implemented** skill to catch deviations. - The **self-refutation** protocol eliminates false positives by requiring evidence-backed findings. - Every audit gap converts into a test requirement via `/derive-tests`, creating a closed-loop quality system. - Output artifacts include [`CLAUDE.md`](https://github.com/phuryn/pm-skills/blob/main/CLAUDE.md), [`tests.md`](https://github.com/phuryn/pm-skills/blob/main/tests.md), and a comprehensive shipping packet for human review. ## Frequently Asked Questions ### What is the primary purpose of the /ship-check command? The `/ship-check` command serves as an orchestrator that transforms raw AI-generated code into a validated shipping packet. It automates the audit process by chaining documentation generation, security analysis, performance checks, and test derivation into a single workflow that ensures code aligns with documented architectural intent before release. ### How does /ship-check prevent false positives in security findings? The command implements a **self-refutation** protocol within `/security-audit-static` that actively attempts to disprove each candidate vulnerability. Only findings that survive this adversarial scrutiny—those with concrete evidence of divergence from documented permissions or flows—are included in the final report, drastically reducing noise for human reviewers. ### What files does the /ship-check command generate? The command generates several key artifacts: [`CLAUDE.md`](https://github.com/phuryn/pm-skills/blob/main/CLAUDE.md) and [`AGENTS.md`](https://github.com/phuryn/pm-skills/blob/main/AGENTS.md) for agent context, [`tests.md`](https://github.com/phuryn/pm-skills/blob/main/tests.md) mapping coverage gaps, and a timestamped [`shipping_packet_YYYY-MM-DD.md`](https://github.com/phuryn/pm-skills/blob/main/shipping_packet_YYYY-MM-DD.md) containing the comprehensive audit summary. It also produces or updates documentation files like [`architecture.md`](https://github.com/phuryn/pm-skills/blob/main/architecture.md) and [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md) via the **shipping-artifacts** skill. ### Can /ship-check target specific parts of a codebase? Yes. While running `/ship-check` without arguments audits the entire repository, you can pass a specific service name or directory path as an argument (e.g., `/ship-check payments-service` or `/ship-check supabase/functions`) to limit the audit scope to that particular component.