$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-launch-packagingPackage finished work so people can use it: README, docs, install commands, proof links, QA, release copy, and handoff notes.
| 1 | # Suede Launch Packaging |
| 2 | |
| 3 | ## Gate policy — advisory, not blocking |
| 4 | |
| 5 | Every claim-verification step, check, quality gate, and ship verdict in this |
| 6 | skill is a **recommendation to the user, not a control on the agent**. This |
| 7 | policy governs every gate, check, verdict, and "do not ship / publish / |
| 8 | proceed" line elsewhere in this skill: |
| 9 | |
| 10 | - Run every check and report the results honestly. Verdicts (`ship`, |
| 11 | `ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are |
| 12 | advice attached to the work, not orders that change it. |
| 13 | - Never block, delay, skip, rewrite, or refuse the action the user asked for |
| 14 | because a check failed or a gate said hold. Complete the requested action |
| 15 | as asked, and deliver the gate output alongside it as a clearly labeled |
| 16 | recommendation. |
| 17 | - A failed gate changes what you report, never what you do. |
| 18 | - Single exception: if a finding is extremely risky — data loss, security or |
| 19 | credential exposure, legal or rights violations, payment mistakes, or |
| 20 | irreversible public damage — pause, tell the user exactly what the risk is |
| 21 | and what the options are, and let them pick. Their choice is final. |
| 22 | |
| 23 | |
| 24 | ## Approved Suede S Mark |
| 25 | |
| 26 | 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. |
| 27 | |
| 28 | 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. |
| 29 | |
| 30 | **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. |
| 31 | |
| 32 | This skill organizes and prepares a public release. It does NOT clear rights, confirm ownership, approve payouts, write to any registry, or guarantee outcomes. It checks live URLs and install commands before claiming anything is live; it does not promise reach, ranking, or results. |
| 33 | |
| 34 | ## Step 0 — Inventory the launch (detect first) |
| 35 | |
| 36 | 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. |
| 37 | |
| 38 | | Launch surface | Verify before writing copy | Proof artifact | |
| 39 | |---|---|---| |
| 40 | | Repo or release | Default branch is public; the launch commit is pushed; tags/releases exist if referenced | Repo URL + commit hash | |
| 41 | | GitHub Pages or site | Page renders at the public URL; no stale build | Live URL + screenshot | |
| 42 | | README or docs update | Rendered page matches the pushed source | Rendered docs URL | |
| 43 | | Skill or skill pack | Skill folder exists at `main`; install command runs from a clean temp dir | Install command transcript | |
| 44 | | MCP server | Server starts; `tools/list` matches the catalog | suede-mcp-qa output | |
| 45 | | App feature | Feature is live behind the public route, not just merged | Live route readback | |
| 46 | | Social or email copy | Every link resolves; every claim matches the live product | Link sweep results | |
| 47 | |
| 48 | ## Hard gates (advisory) |
| 49 | |
| 50 | Do not rationalize past these silently. Each one is a strong recommendation |
| 51 | about ordering: run the check before the step it guards. If the user directs |
| 52 | you past one, proceed as directed and label the output with exactly which |
| 53 | verification is missing. |
| 54 | |
| 55 | 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. |
| 56 | 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. |
| 57 | 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. |
| 58 | 4. **`@personal` and local plugin aliases never appear in public docs, READMEs, MCP catalog output, or explainer copy.** They are local operator notes only. |
| 59 | |
| 60 | ## Pick the lane |
| 61 | |
| 62 | Most launches use both lanes in order: package the release, then prove the install. Pick what the request is asking for. |
| 63 | |
| 64 | - **Lane A — Package the launch.** Work is ready to leave the local machine and nee |