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

> Discover the 6-step pipeline behind the /ship-check command. Learn how it generates a shipping packet for AI code, covering docs, security, performance, and tests.

- Repository: [Pawel Huryn/pm-skills](https://github.com/phuryn/pm-skills)
- Tags: how-to-guide
- Published: 2026-06-23

---

**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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/skills/shipping-artifacts/SKILL.md).

The documentation set includes:
- [`architecture.md`](https://github.com/phuryn/pm-skills/blob/main/architecture.md) – System structure and components
- [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/flows.md) – Data and control flows
- [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md) – Access control definitions
- [`variables.md`](https://github.com/phuryn/pm-skills/blob/main/variables.md) – Environment and configuration variables
- Optional docs: [`emails.md`](https://github.com/phuryn/pm-skills/blob/main/emails.md), [`cron.md`](https://github.com/phuryn/pm-skills/blob/main/cron.md), [`seo.md`](https://github.com/phuryn/pm-skills/blob/main/seo.md), [`automation.md`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/ship-check.md) (lines 28-31) creates:
- [`CLAUDE.md`](https://github.com/phuryn/pm-skills/blob/main/CLAUDE.md) – Comprehensive agent context
- [`AGENTS.md`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/skills/intended-vs-implemented/SKILL.md), this skill compares the actual code against the documented intent in [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md), [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/flows.md), and [`architecture.md`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/pm-ai-shipping/commands/derive-tests.md)) to create a [`tests.md`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/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:

```bash
/ship-check

```

Target a specific service:

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

```

Execute the full pipeline manually for debugging:

```bash
/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:

```markdown

## 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`](https://github.com/phuryn/pm-skills/blob/main/architecture.md), [`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)
- **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`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/CLAUDE.md) and [`AGENTS.md`](https://github.com/phuryn/pm-skills/blob/main/AGENTS.md) in Step 2, and produces the final markdown packet in Step 6. It also triggers the creation of system documentation ([`architecture.md`](https://github.com/phuryn/pm-skills/blob/main/architecture.md), [`flows.md`](https://github.com/phuryn/pm-skills/blob/main/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`](https://github.com/phuryn/pm-skills/blob/main/flows.md) or [`permissions.md`](https://github.com/phuryn/pm-skills/blob/main/permissions.md) is missing, the packet lists this as a launch blocker and recommends running `/document-app` before proceeding with security reviews.