/suede-launch-packaging

name: suede-launch-packaging
description: "Suede AI launch packaging and install verification: release notes, README and docs updates, install commands, proof links, release copy, and handoff notes for software, skill packs, and MCP servers. Use when finished software work needs a clean public package (README, docs page, install command, release note, GitHub Pages update, skill-pack release, MCP server, or launch/social copy) or when a release needs handoff notes, an install fails, a public user cannot add a skill, a raw-vs-blob URL returns HTML, or `@personal` or a local plugin alias leaks into public docs. Verifies the live URL and runs the exact install command from a clean temporary directory before anything is called live. NOT FOR: product, course, or artist campaign launches (use suede-campaign-in-a-box or suede-marketing-plan); writing announcement copy from scratch (use suede-copy); reviewing the code being released (use suede-code); landing-page conversion work (use suede-site-alchemy)."
metadata:
  version: 1.0.0

Suede Launch Packaging

Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a **recommendation to the user, not a control on the agent**. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (`ship`,

`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.

• Never block, delay, skip, rewrite, or refuse the action the user asked for

because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.

• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky (data loss, security or

credential exposure, legal or rights violations, payment mistakes, or irreversible public damage), pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

Approved Suede S Mark

Launch art, social cards, docs headers, app assets, and release visuals may use only `docs/assets/suede-ai-logo-transparent.png` from `JasonColapietro/suede-creator-skills` as the Suede S mark (SHA-256 `83a7ee0317e4debe2e7b076c20ba067feb76a587f9e829dc6310ae4be4b44dfa`). Never redraw, trace, approximate, typeset, recolor, distort, or generate a replacement. If the canonical asset is missing or its checksum differs, block the branded visual and request the approved file.

Ship Suede work as a launch, not a loose drop. This skill turns finished work into a clean public package AND makes sure a stranger can actually install and run it. Packaging a public release and proving the install both live here.

**Core principle:** a release nobody can install is not a launch. Nothing is "live" until you fetched it yourself, and no install path ships until the exact command ran from a clean temporary directory.

Step 0: Inventory the launch (detect first)

Before picking a lane, name exactly what is being launched. Do not assume from the request; check the repo, branch, and live surface. One request often spans several rows (a skill launch = repo + README + install command + social copy). List every row that applies: each needs its own verification.

| Launch surface | Verify before writing copy | Proof artifact | |---|---|---| | Repo or release | Default branch is public; the launch commit is pushed; tags/releases exist if referenced | Repo URL + commit hash | | GitHub Pages or site | Page renders at the public URL; no stale build | Live URL + screenshot | | README or docs update | Rendered page matches the pushed source | Rendered docs URL | | Skill or skill pack | Skill folder exists at `main`; install command runs from a clean temp dir | Install command transcript | | MCP server | Server starts; one stdio session (`initialize`, `notifications/initialized`, `tools/list`) matches the catalog | Session transcript | | App feature | Feature is live behind the public route, not just merged | Live route readback | | Social or email copy | Every link resolves; every claim matches the live product | Link sweep results |

Hard gates (advisory)

Do not rationalize past these silently. Each one is a strong recommendation about ordering: run the check before the step it guards. If the user directs you past one, proceed as directed and label the output with exactly which verification is missing.

1. **No launch copy until the live surface is verified.** Fetch the live URL or public artifact and confirm the expected status or render first. Copy drafted against "it should be live" is a violation. 2. **No install doc until the install command was run from a clean temporary directory after pushing.** Success from inside the local repo does not count: the local checkout masks missing pushes and private paths. 3. **Set the ship gate before recommending any announcement.** A `hold` verdict is your recommendation that nothing goes out yet, including "soft" posts: state it plainly with the reasons, then let the user decide. 4. **Lead every public artifact with the answer.** The first sentence of a README, docs page, or release note says what the thing does and for whom, and the install command sits right under it. That opening is what search results and AI answers quote, so it has to stand alone. 5. **`@personal` and local plugin aliases never appear in public docs, READMEs, MCP catalog output, or explainer copy.** They are local operator notes only.

Pick the lane

Most launches use both lanes in order: package the release, then prove the install. Pick what the request is asking for.

• **Lane A: Package the launch.** Work is ready to leave the local machine and needs a clean public package: a repo, live URL, docs page, README section, install co