Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Waddling-Penguin/mogkit --skill launch-readinessgit clone --depth 1 https://github.com/Waddling-Penguin/mogkitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/waddling-penguin/mogkit/launch-readiness)<a href="https://agentmods.dev/skills/waddling-penguin/mogkit/launch-readiness"><img src="https://agentmods.dev/badge/skills/waddling-penguin/mogkit/launch-readiness.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00003 | $0.01411 |
| Opus 5 | $0.00002 | $0.00705 |
| Sonnet 5 | $0.00001 | $0.00282 |
| Haiku 4.5 | $0.00000 | $0.00141 |
Grade A, and why
launch-readiness scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 120 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
A launch fails for boring reasons. Nobody owned the docs. The rollback was theoretical. Support didn't get the briefing. The integration partner found out from a tweet. Half the failures are visible in advance to anyone who asks the right questions about this launch — not a generic launch.
This skill is the pre-flight interrogation: what is unowned, what is unprepared, what breaks under unexpected demand or unexpected silence, and what would tell us we should pull the launch. The output is specific to the launch described — not the canonical launch checklist a PM could Google.
It does NOT write the launch plan, the rollback runbook, the comms email, or the FAQ. It surfaces the gaps. The PM closes them.
Procedure
- Read the launch description. Extract:
- What is launching — the actual product/feature/change.
- To whom — segment, scope (all users, beta, an account, a region).
- When — date, time, sequencing.
- What's already planned — anything the PM has called out as in place (e.g. "we have a rollback flag", "support has been briefed"). If any of these is genuinely missing from the description, list it as a gap rather than guessing.
- Walk through ownership: who owns each load-bearing piece of the launch on launch day — product, engineering on-call, support response, marketing/PR, customer success, sales enablement, partner comms, data instrumentation. For each, name owned/unowned/unclear based on what the description says. "Unclear" is a real and common state; flag it.
- Stress the rollback plan against the actual change. A rollback for a pricing change is not a rollback for a data-model change. Ask: what specifically can be undone, what cannot, and what would the rollback leave half-done? If the launch contains a one-way-door element, name it.
- Identify comms & enablement gaps: who hears about this and when — internally (support, sales, success, exec), externally (users, partners, press if relevant). What does each audience need to be ready? Where is the briefing missing?
- Run the demand stress test:
- 10x adoption — if adoption is ten times expectation, what breaks? Capacity, support volume, fraud surface, partner contracts, on-call load.
- 0.1x adoption — if adoption is one-tenth, what does that tell us? What would we then have committed to (engineering load, partner promises, marketing spend) that no longer pays back?
- Define kill criteria: the explicit thresholds at which the team should pull or pause the launch. Specific, measurable, decided now, not in the heat of launch day. Common shapes: error rate above X for Y minutes, support volume above Z%, a single P0-class issue. If the PM already has kill criteria, audit them; if not, propose specific placeholders the PM should confirm.
- Emit the output contract. Do not produce launch plan content (runbooks, comms drafts, FAQs).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 120 lines · 3 tokens per session scan A b0420b0c3782
launch-readiness is a skill published in the GitHub repository Waddling-Penguin/mogkit (5 stars, last pushed 3mo ago), licensed MIT. It adds 3 tokens to every session and 1,411 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
quality
Evaluates whether a GitHub issue is spam, empty, needs more information, or is OK to proceed.
gh-file-issue
Use when filing a new Codewhale GitHub issue: turn a bug or idea into a well-formed, actionable issue with repro, acceptance criteria, labels, and milestone.
gh-treasure-hunt
Hunt the issue/PR queue for highest value-over-risk wins: clean focused community PRs, already-implemented issues to close, safe quick-fixes.
follow-up-after-call
Use after a completed customer, prospect, partner, or important internal sales call, discovery session, demo, or conversation, including when the user supplies or uploads a transcript, notes, recording summary, or other grounded evidence. Advise on, assess, qualify, recap, and produce seller-ready follow-up actions…
persona-project-manager
Coordinate projects — track tasks, schedule meetings, and share docs.
persona-event-coordinator
Plan and manage events — scheduling, invitations, and logistics.