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 RobinNorberg/oh-my-copilot --skill launchgit clone --depth 1 https://github.com/RobinNorberg/oh-my-copilotWrote 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/robinnorberg/oh-my-copilot/launch)<a href="https://agentmods.dev/skills/robinnorberg/oh-my-copilot/launch"><img src="https://agentmods.dev/badge/skills/robinnorberg/oh-my-copilot/launch/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/robinnorberg/oh-my-copilot/launch"><img src="https://agentmods.dev/badge/skills/robinnorberg/oh-my-copilot/launch.svg" alt="Reviewed on agentmods" width="80" 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.00113 | $0.06611 |
| Opus 5.5 | $0.00045 | $0.02644 |
| Sonnet 5.5 | $0.00023 | $0.01322 |
| Haiku 4.5 | $0.00011 | $0.00661 |
Grade A, and why
launch 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 10d 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.
This is a copy
88% identical to launch — 89 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Launch
Launch is the shipyard's delivery run: from mission brief to shipped, verified change. It stands on the verifiability boundary — agents continuously run everything repeatable and acceptable-by-evidence; humans decide what cannot be judged by the system or what fails expensively. The goal is not maximum automation — it is maximum delegation of verifiable work, so the human's time is spent only on the decisions only a human can make.
The verifiability test, applied to every step: if this is done wrong, can the system detect it? Can it redo or roll back automatically? Both yes → agent. No unique answer, system cannot judge, or expensive to get wrong → human.
Launch assumes the shipyard exists — and refuses to run if it does not. The yard gate is the first action of every invocation, before document-language resolution and before reading any supplied spec:
The audit report includes contractVersion: 2; missing required day-one faces use shipyard.yard.unlaid, and consumers must not interpret retired shipyard.surface.missing.* IDs as optional-surface failures.
- Run the full drydock
--checkaudit — require the day-one base facesCLAUDE.mdandGLOSSARY.md(a recognizable legacy glossaryCONTEXT.mdis accepted until drydock migrates it); beyond those, audit only adopted optional surfaces, so an absent optional surface is not a finding. The audit also checks a missing or invalid glossarydocumentLanguage, dead paths, glossary terms unused in code, and standards never referenced. This is the single criterion: Launch performs no separate facility inventory of its own. - Actionable / high-confidence findings hard-block the run: list every such finding verbatim, point at
/oh-my-copilot:drydock, state that the run never started and no artifacts were produced, and stop. Without an explicit override, treat any finding as blocking. - Narrow override (explicit intent only): low-confidence findings, findings explicitly classified as false positives in the drydock report, or a scratch/throwaway repository explicitly declared by the user may be overridden only with deliberate, per-invocation user intent — the override must name the finding(s) or the throwaway scope and must never silently swallow a high-confidence actionable finding. No general bypass flag.
- Current audit contract (version 2): the mechanical subset of
--checkis executable —node scripts/shipyard-audit.mjs [repoRoot]emits a versioned JSON report and checks the required yard base faces, duplicate glossary authority, a missing/invaliddocumentLanguagetag, dead paths inCLAUDE.md, project-skill triggers, and intent statuses. Absence of an optional surface is not a finding;shipyard.surface.missing.*IDs are retired in contract version 2. Exit 0 = clean, 1 = high-confidence actionable findings present. The gate consumes that exit: 0 admits the run, 1 lists the findings verbatim and blocks. The heuristic classes (glossary terms unused in code, standards never referenced) stay in the drydock prose audit — low-confidence by construction, override rules unchanged. - A clean audit (or an explicitly overridden low-confidence/false-positive/scratch scope) admits the run. The day-one faces are present;
docs/adr/anddocs/business/appear on first use — the slot is there when a decision settles, and if it is not, Launch triggers its first use (per drydock's deferred-surface table) and sediments into it immediately. Launch fills the paper trail as decisions settle and never creates a slot speculatively. - The rules entry is
CLAUDE.md— the shipyard map recognizes no substitute.
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.
- 10d ago Changed 9379443d1622
- 19d ago Changed · +33 lines 07112951286c
- 1mo ago First seen · 153 lines · 113 tokens per session scan A b05c73d13247
launch is a skill published in the GitHub repository RobinNorberg/oh-my-copilot (5 stars, last pushed 7d ago), licensed MIT. It adds 113 tokens to every session and 6,611 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 88% identical to launch, differing in 89 lines, and is treated as a copy.
Other skills, from other repositories
speckit-workflow
Manage and run Spec Kit automation workflows via specify workflow. USE FOR: running a workflow by ID or local YAML, resuming a paused/failed run, checking run status, listing/installing/removing workflows, searching the workflow catalog, showing a workflow step graph. DO NOT USE FOR: extensions (use…
prepare-ticket
Use when asked whether a ticket or issue is ready for development, or to prepare, validate, refine, challenge, or sanity-check a Jira work item, GitHub Issue, or GitLab Issue before building it. Checks material claims against evidence, follows questions until outcome decisions are settled, rewrites the title and…
implement-ticket
Use when asked to implement, build, or pick up a ticket end to end — a Jira work item, GitHub Issue, or GitLab Issue — including "implement ABC-123", "implement gh issue #137", "work on issue 137", or "pick up this ticket". Critiques the request against the code, builds it in a throwaway git worktree, verifies it with…
estimate-size
Estimate software tickets and work items with a configurable relative-sizing workflow. Respect dedicated estimators and local project rules, and use the built-in defaults when no local rules are provided.
fetch-ticket
Reusable ticket reader that resolves a Jira work item, GitHub Issue, or GitLab Issue through the project's saved route and returns it as one provider-neutral ticket with every comment verbatim. Invoked by prepare-ticket and implement-ticket; not for validating or implementing a ticket directly, use those skills…
write-prd
Create a PRD and user stories through user interview, codebase exploration, and component design. Use when user wants to write a PRD, create a product requirements document, user stories or plan a new feature.