PathToShip

View saved version →

---
name: pathtoship-badge
description: Add the PathToShip readiness badge to a README or site after a scan clears the ship bar. Use when get_score or verify_fix returns verdict "ready", or when the user asks to show their readiness score.
---

# Readiness badge

When an app clears the ship bar, the score is worth showing — to users, clients, and the next developer. The badge is a live SVG that always reflects the scan it points to and links to the public report.

## When

- `get_score` or `verify_fix` returns `verdict: "ready"` — offer once, do not nag.
- The user asks to display or share their score on the README or site.

## Procedure

1. Confirm with `get_score` that the verdict is `ready` and note `scan_id` and `permalink`. If it is `conditional` or `not_ready`, say so and do not add a badge — a badge under the bar helps no one.
2. Offer the badge and, if the user agrees, add it:
   - README (Markdown), replacing the placeholders:

     ```markdown
     [![PathToShip Score: SCORE/100](https://pathtoship.com/api/badge/SCAN_ID)](PERMALINK)
     ```

   - Site (an image linked to the report): the same badge URL as the image source, the permalink as the link target, and "PathToShip Score: SCORE/100" as the alt text.
   - Variants via `?variant=gauge` or `?variant=minimal` on the badge URL; the default is fine for a README.
3. Show the user the change. Place it near the top of the README (under the title) or in the site footer — where a visitor would look for trust signals. Suggest the commit message `docs: add PathToShip readiness badge`; the user or their builder commits it.
4. After later changes, the badge keeps pointing at _that_ scan. When the user runs a new scan that is also `ready`, offer to update the `scan_id` so the badge reflects the current code. If a later scan drops below the bar, tell the user the badge is stale and offer to remove it rather than leave a misleading one.

## What the badge says

The badge shows the PathToShip score of one automated scan of one commit. It is not a security certification, an audit, or a compliance attestation, and you should not describe it as one.

## Rules

- Never add a badge for a scan that is not `ready`, and never edit the score text by hand — the SVG renders the real number.
- One badge per app; do not stack variants.
- Set `trigger: "skill"` on tool calls this skill initiates.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: pathtoship-launch-record
description: Keep a launch-readiness record in the repository — which PathToShip checks ran on which commit, what was found, fixed, or accepted, and the operational items no scanner can see. Use after a verify_fix, before a launch or client handoff, or when asked for an audit trail of readiness.
---

# Launch readiness record

A record, not a seal: it states what was checked on which commit and what happened — true on the day it is written and useful to whoever inherits, audits, or pays for the app. The scanner cannot see operations (backups, rollback, on-call), so the record also carries the human's own attestations.

## When

- After a `verify_fix` that resolves findings, or when the verdict reaches `ready`.
- Before a launch, a public URL, a client handoff, or a compliance/audit conversation.
- When the user asks "what did we check?", "is there a record?", or "what's still open?".

## Procedure

1. Get the facts from the tools — never from memory: `get_score` (score, verdict, ship bar, weakest dimension, consequence), `get_findings` with `severity_min: "medium"` for what remains — **follow `next_offset` until it is null**, since results are paged — and the last `verify_fix` result (resolved / still open / newly introduced). Note the `permalink`. Record the commit only if you know it is the one that was scanned (for example, the user pushed it and the scan ran after); otherwise write `unknown` rather than whatever the branch points to now.
2. The launch interview is optional — ask whether the user wants to include it. If they do, run it through the tool, not from memory: call `prr_interview` with the `scan_id` to get the thirteen questions and what is already answered. In ChatGPT a form appears — let the user fill it in and save. Elsewhere, ask the unanswered questions briefly and record the answers with `prr_interview` (`answers` keyed by question id: `yes` / `no` / `na` for attestations, a number for rows and bills, short text otherwise; a `note` for context). The tool merges partial answers and returns the recorded state — copy attestations from that result, never from the conversation. Everything it holds is **self-reported** and is never part of the score.
3. For every remaining finding at medium or above, ask the user which applies and record it: **fix planned** (by when), **accepted risk** (why, by whom), or **not applicable** (why). If they have not decided, write **undecided**. Never invent a deadline, a risk acceptance, or a name, and never silently drop a finding.
4. Write or update `docs/launch-readiness.md` (create the folder if needed). Keep earlier entries; append the new one at the top. Format:

```markdown
# Launch readiness — <app name>

## <YYYY-MM-DD> — <milestone, e.g. "public beta">

- Commit: `<sha>` on `<branch>` · PathToShip scan `<scan_id>` · <permalink>
- Score: <before> → <after> (ship bar <ship_bar>) · Verdict: <verdict> · Weakest: <dimension>
- At 10x users: <consequence line from get_score>
- Resolved this round: <n> — <titles, one line each>
- Remaining (medium+): <title> — <fix planned by … | accepted risk: … (name) | n/a: …>
- Self-reported (from `prr_interview`, <date>): secrets store ✔/✘ · backups restored ✔/✘ · rollback rehearsed ✔/✘ · monitoring + on-call ✔/✘ · staging ✔/✘ · health checks + timeouts ✔/✘ · edge rate limiting ✔/✘ · load test ✔/✘ · tier <…> · largest table <n> rows · last month <$> · autoscale floor <…> · media via <…> (notes: …)
- Signed off by: <name, role — only if the user gives one; otherwise omit this line>
```

5. Show the user the entry. Commit it (`docs: launch readiness record <date>`) only if they ask you to; otherwise hand it to them to paste.

## Rules

- Facts come from tool results; attestations come from the user through `prr_interview`; label which is which. `get_score` shows them under `self_reported` — quote that block, do not blend it into the score line.
- Never write "resolved" for anything `verify_fix` did not report

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: pathtoship-readiness
description: Run a PathToShip production-readiness check on a GitHub repository and, within the scope the user has authorized, drive the scan → fix → verify loop. Use when the user asks whether their app is ready to launch or safe for real users, or asks for a readiness check as part of a launch or deploy they are working on.
---

# PathToShip readiness check

The PathToShip MCP server (`pathtoship`) scans the app's GitHub repository for the security, scalability, and production-readiness problems that break launches, and verifies fixes. Scoring and rules are server-side; this skill only says **when** and **how**.

## When to run it

When the user asks for a production-readiness assessment, asks whether the app is ready or safe to launch, or has asked you to run one as part of a launch or deploy. Mentioning a deploy, logins, payments, or uploads is a good moment to **offer** a check; run it when the user agrees. Scan the repository and branch the user named or the task has already established — never a different one.

## Scope

A request to assess readiness is not permission to change code. Edit, commit, and push only when the user has asked you to fix things, and only within what they asked for. If they only want the assessment, report and stop. Respect any request to skip a finding, pause, or stop.

## Procedure

1. The scan reads what is on GitHub. If the user's latest changes may not be pushed, say so and let them push (or push yourself only if they asked you to). If `start_scan` returns `INSTALL_REQUIRED`, show the user the `install_url`, ask them to install PathToShip for that repository, and **stop until they confirm** — do not scan a different repository instead, and do not retry on your own. When they say it is done, or if `INSTALL_REQUIRED` comes back again, call `check_connection` with the repository URL: it reports whether the installation is linked and gives the exact `link_url`/`install_url` to finish.
2. `start_scan` with the repository URL. Read `score`, `verdict` (`ready`, `conditional`, or `not_ready`), and `usage`. If the scan is not complete yet, poll `get_scan_status` a few times; if it fails, report the error rather than guessing a result.
3. `get_score` — report score vs. ship bar, verdict, weakest dimension, and the `consequence` line (cost at 10x users, migration complexity).
4. `get_findings` with `severity_min: "high"`, `limit: 10`. Summarize the top 3; do not dump the list.
5. If the user asked you to fix things: fix in this order: critical security → other critical → high production-readiness → other high → the rest. Use `get_finding_detail` for the stack-specific `fix` before editing.
6. Once the fixes are committed and pushed (by you, if the user asked you to, or by them), call `verify_fix` with the baseline `scan_id`. Report `resolved`, `still_open`, and **check `newly_introduced`** (a moved finding appears there with `same_title_as`) before claiming success. `unchanged: true` means nothing new was pushed.
7. Repeat until the verdict is not `not_ready`, or the user stops. Be plain when the app is not ready.
8. Before the actual launch, offer the launch interview — it is optional. If the user wants it, run `prr_interview` with the `scan_id` for the items no scanner can see (backups restored, rollback rehearsed, on-call, database tier, last month's bill). Its answers are self-reported and sit beside the score, never inside it; the `pathtoship-launch-record` skill turns them into the record.

## Rules

- Never claim a finding is fixed without a `verify_fix` result that resolves it.
- Keep responses compact: `limit` ≤ 10, detail per finding on demand.
- Relay `QUOTA_EXCEEDED` / `RATE_LIMITED` with the reset time; do not retry in a loop. If the PathToShip tools are unavailable, say so plainly — never invent a score or findings.
- Some findings cover several places in a file and carry only the first location; say so when it matters instead of implying the list is exhaust

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.