How the /ship‑check Command Assesses Code Safety for Deployment

The /ship‑check command evaluates code safety by orchestrating a deterministic six‑step pipeline that documents system intent, executes parallel security and performance audits, and synthesizes findings into a human‑readable shipping packet containing explicit launch blockers.

In the phuryn/pm-skills repository, the /ship‑check command serves as a high‑level orchestrator that transforms "vibe‑coded" repositories into review‑ready deployment candidates. By chaining specialist sub‑commands and skills—coordinated through pm-ai-shipping/commands/ship-check.md—it produces a comprehensive safety assessment that human reviewers use to validate production readiness.

Six‑Step Safety Assessment Pipeline

The safety evaluation follows a rigid sequence where each step produces artifacts that feed into the final judgment.

Step 1 – Document the System Baseline

The pipeline initiates by running /document-app and applying the shipping‑artifacts skill to generate core documentation including architecture diagrams, data flows, permission models, and environment variables. This creates the intended‑state baseline stored in files like architecture.md and permissions.md, against which all subsequent audits compare actual implementation.

Step 2 – Establish Agent Operating Context

The command generates or refreshes CLAUDE.md and a thin AGENTS.md derived from the system documentation. These files supply subsequent AI‑coding agents with explicit guardrails and trust boundaries, ensuring that automated analysis respects documented constraints.

Step 3 – Execute Parallel Security and Performance Audits

Steps three and four run concurrently as independent sub‑agents to evaluate orthogonal risk dimensions:

• Security audit – /security-audit-static (defined in pm-ai-shipping/commands/security-audit-static.md) leverages the intended‑vs‑implemented skill to flag mismatches between documented permissions/flows and actual code, surfacing potential privilege escalations or compliance violations.
• Performance audit – /performance-audit-static (defined in pm-ai-shipping/commands/performance-audit-static.md) scans for N+1 queries, over‑fetching patterns, and missing database indexes that could degrade production performance.

Running these in parallel preserves pipeline speed without sacrificing thoroughness.

Step 4 – Derive Test Coverage Maps

The /derive-tests command (implemented in pm-ai-shipping/commands/derive-tests.md) examines existing test suites and augments them with new cases based on audit findings. It outputs a tests.md coverage map that categorizes rules as verified, proposed, or untested, ensuring every identified gap becomes a concrete regression test.

Step 5 – Compile the Shipping Packet

Finally, the orchestrator synthesizes all artifacts—documentation status, agent context, audit summaries, and coverage maps—into a single markdown shipping packet. This packet lists specific launch blockers and recommended next actions, creating a sign‑off‑ready artifact for human review.

Core Architectural Components

The assessment reliability stems from modular, skill‑based architecture defined across the pm-ai-shipping directory.

Intended‑vs‑Implemented Diff Logic

The intended‑vs‑implemented skill, defined in pm-ai-shipping/skills/intended-vs-implemented/SKILL.md, performs a semantic diff between design documents (e.g., permissions.md, flows.md) and the actual codebase. It surfaces discrepancies that represent security or compliance violations, such as unauthenticated endpoints that should require authorization.

Shipping‑Artifacts Generation

The shipping‑artifacts skill (pm-ai-shipping/skills/shipping-artifacts/SKILL.md) produces the curated documentation set that serves as the "source of truth" for audits. Without these baseline artifacts, the intended‑vs‑implemented comparisons cannot execute.

Parallel Execution Model

The orchestrator launches security and performance audits as concurrent sub‑agents. It waits for both results before proceeding to test derivation, ensuring that findings from both dimensions inform the final coverage mapping.

Safety Assessment Criteria and Launch Blockers

The final shipping packet explicitly flags launch blockers that should prevent deployment:

1. Unresolved Critical or High security findings, such as unauthenticated privilege escalation paths identified by the security audit.
2. Performance regressions exceeding predefined thresholds, including N+1 queries detected on hot code paths.
3. Boundary rules (permissions, flows) that are both unverified (lack tests) and unaudited (missing from documentation), creating invisible risk surface.

If none of these blockers appear, the packet is considered safe for human sign‑off, though the command defers final deployment approval to human reviewers.

Usage Examples

Execute the full safety pipeline against the entire repository:

/ship-check

Target a specific service or domain:

/ship-check the payments service

Assess a specific directory, such as serverless functions:

/ship-check supabase/functions

Summary

• The /ship‑check command orchestrates six deterministic steps: documentation, context establishment, parallel audits, test derivation, and packet compilation.
• It relies on the intended‑vs‑implemented and shipping‑artifacts skills to compare code against documented intent.
• Security and performance audits run in parallel via sub‑agents to maximize efficiency.
• Launch blockers explicitly flag critical security issues, performance regressions, and untested boundary rules.
• The command outputs a human‑readable shipping packet but does not replace individual specialist commands; it merely coordinates them for final human review.

Frequently Asked Questions

What triggers a launch blocker in /ship‑check?

Launch blockers occur when the pipeline detects unresolved Critical or High severity security findings, performance regressions exceeding predefined thresholds such as N+1 queries, or boundary rules that lack both test coverage and documentation. These conditions represent unacceptable risks for production deployment.

How does /ship‑check differ from running individual audit commands?

While individual commands like /security-audit-static or /performance-audit-static perform specific analyses, /ship‑check coordinates them into a deterministic sequence, ensures prerequisite documentation exists via the shipping‑artifacts skill, and synthesizes all outputs into a unified shipping packet with cross‑referenced launch blockers.

Can /ship‑check target specific parts of a codebase?

Yes. The command accepts path or service arguments (e.g., /ship‑check supabase/functions or /ship‑check the payments service) to limit analysis scope, though it still executes the full six‑step pipeline against the targeted subset.

What files does /ship‑check generate?

The command generates CLAUDE.md and AGENTS.md for agent context, a tests.md coverage map, and a final shipping packet markdown file. It also relies on artifacts produced by the shipping‑artifacts skill, including architecture.md, permissions.md, and flows.md.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}