How the /ship-check Command Creates a Shipping Packet for AI Code: A 6-Step Pipeline Explained

The /ship-check command orchestrates a six-stage pipeline that transforms vibe-coded repositories into a single, reviewer-ready shipping packet by coordinating documentation generation, security audits, performance checks, and test coverage mapping.

The /ship-check command in the phuryn/pm-skills repository provides a systematic approach to validate AI-generated code before deployment. By orchestrating multiple specialist commands and skills, it creates a comprehensive shipping packet that proves code is safe to ship. This command does not perform audits itself; instead, it coordinates the generation of documentation, security checks, and test coverage analysis into a single human-readable artifact.

The Six-Step Pipeline Architecture

The shipping packet creation follows a strict sequential order where each step builds upon artifacts from the previous stage. According to the source code in pm-ai-shipping/commands/ship-check.md, this ordering ensures that missing documentation is highlighted early and audit findings automatically convert into actionable test requirements.

Step 1: Document the System

The pipeline begins by generating or refreshing system documentation. This step invokes the /document-app command, which utilizes the shipping-artifacts skill defined in pm-ai-shipping/skills/shipping-artifacts/SKILL.md.

The documentation set includes:

• architecture.md – System structure and components
• flows.md – Data and control flows
• permissions.md – Access control definitions
• variables.md – Environment and configuration variables
• Optional docs: emails.md, cron.md, seo.md, automation.md

This documentation serves as the foundation for all subsequent audits.

Step 2: Generate Agent Operating Context

This step produces the operating-context files that encode trust boundaries and guardrails. The generation logic in pm-ai-shipping/commands/ship-check.md (lines 28-31) creates:

• CLAUDE.md – Comprehensive agent context
• AGENTS.md – Thin agent configuration

These files explicitly define "what may not be touched" and establish guardrails derived from the documentation created in Step 1.

Step 3: Execute Security Audit

The security stage runs the static security scanner via /security-audit-static and applies the intended-vs-implemented skill. Located in pm-ai-shipping/skills/intended-vs-implemented/SKILL.md, this skill compares the actual code against the documented intent in permissions.md, flows.md, and architecture.md.

This comparison identifies discrepancies between what the system is supposed to do and what the code actually implements, catching security violations that traditional scanners might miss.

Step 4: Run Performance Audit

The pipeline executes the static performance scanner using /performance-audit-static (defined in pm-ai-shipping/commands/performance-audit-static.md). This scan detects:

• Over-fetching patterns
• Missing database indexes
• Caching implementation issues

Step 5: Map Test Coverage

This step calls /derive-tests (defined in pm-ai-shipping/commands/derive-tests.md) to create a tests.md coverage map. The map categorizes rules into:

• Pinned by tests – Already verified by existing tests
• Proposed but not written – Identified gaps requiring new tests
• Guarded-live/manual – Rules protected by manual processes
• Unverified – Critical gaps with no coverage

Step 6: Synthesize the Shipping Packet

The final compilation logic in pm-ai-shipping/commands/ship-check.md (lines 44-69) synthesizes all previous outputs into a single markdown packet. This artifact includes:

• Documentation inventory with status (present/stale/missing)
• Agent context status
• Test coverage summary
• Security findings (critical/high/low)
• Performance issues
• Launch-blocker list (unresolved critical/high items)
• Recommended next actions

Command Invocation and Usage Examples

The /ship-check command accepts an optional path parameter to target specific services or sub-folders.

Run on the entire repository:

/ship-check

Target a specific service:

/ship-check payments-service
/ship-check supabase/functions

Execute the full pipeline manually for debugging:

/document-app
/ship-check

Inside the Generated Shipping Packet

The output is a hand-off document for human reviewers that consolidates scattered logs into a structured view. Here is an excerpt of the format generated by the compilation step:

## Shipping Packet: my-repo / payments-service

### Documentation Inventory

| Doc               | Status   | Notes |
|-------------------|----------|-------|
| architecture.md   | present  |       |
| permissions.md    | present  |       |
| flows.md          | missing  | Run `/document-app` |
| variables.md      | present  |       |

### Agent Context

CLAUDE.md / AGENTS.md: created

### Test Coverage

- Rules pinned by tests: 12
- Proposed but not yet written: 8
- Guarded-live/manual: 3
- Unverified rules: 5

### Security Summary

- Critical: 0
- High: 1 (SQL injection risk in `order/create`)

### Performance Summary

- Over-fetching in `GET /orders`: recommendation to add pagination
- Missing index on `orders.user_id`: priority high

### Launch Blockers

- Unresolved High: SQL injection risk in `order/create`

### Recommended Next Actions

- Fix the SQL injection issue (owner: backend-lead)
- Re-run `/derive-tests` after the fix

Summary

The /ship-check command in phuryn/pm-skills creates a shipping packet through strict orchestration rather than direct analysis:

• Six sequential steps ensure documentation exists before auditing and audit findings convert to test requirements
• Specialist coordination leverages /document-app, /security-audit-static, /performance-audit-static, and /derive-tests commands
• Intent verification uses the intended-vs-implemented skill to compare code against architecture.md, permissions.md, and flows.md
• Single artifact output provides human reviewers with documentation inventory, security summaries, performance gaps, and launch blockers in one markdown file
• Targeted scanning supports sub-path arguments for microservice-specific validation

Frequently Asked Questions

What is the difference between /ship-check and running individual audit commands?

The /ship-check command is an orchestrator, not an auditor. While commands like /security-audit-static perform deep analysis, /ship-check coordinates their execution in a specific order and compiles their outputs into a unified packet. According to the source code in pm-ai-shipping/commands/ship-check.md, it handles the dependencies between documentation generation and security validation, ensuring that audits run against fresh documentation.

Why must the pipeline run in a specific six-step order?

Each step depends on artifacts from the previous stage. Security and performance audits require the documented intent generated in Step 1 (documentation) and Step 2 (agent context). The test derivation in Step 5 requires complete audit findings to map gaps accurately. Running steps out of order would result in audits against stale or missing documentation, producing unreliable shipping packets.

Which files does /ship-check actually modify or create?

The command creates the shipping packet itself along with intermediate artifacts. It generates CLAUDE.md and AGENTS.md in Step 2, and produces the final markdown packet in Step 6. It also triggers the creation of system documentation (architecture.md, flows.md, etc.) through the /document-app command and the shipping-artifacts skill, though these are managed by the sub-commands it orchestrates.

How does the command handle partially documented repositories?

The shipping packet explicitly flags documentation gaps. In the Documentation Inventory section, files are marked as "present," "stale," "missing," or "n/a." If critical documentation like flows.md or permissions.md is missing, the packet lists this as a launch blocker and recommends running /document-app before proceeding with security reviews.

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