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 agentmods add commands/chriswritescode-dev/opencode-forge/launch-groupgit clone --depth 1 https://github.com/chriswritescode-dev/opencode-forgeWhat 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 | $0.00000 | $0.00842 |
| Opus 5 | $0.00000 | $0.00421 |
| Sonnet 5 | $0.00000 | $0.00168 |
| Haiku 4.5 | $0.00000 | $0.00084 |
Grade A, and why
launch-group 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 2d 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 — 41 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Launch a group of features that Forge plans and executes in parallel. The input is a broad source of work — not a single issue or change — such as a set of GitHub issues, Linear tickets, a milestone or label, a backlog, a PRD, or other implementation documentation. Your job is to take that source, group it into implementation-coherent features, launch a planning session for each, and let Forge auto-launch the development loops (up to the configured concurrency cap, groupLaunch.maxConcurrentLoops).
Step 1: Understand the source
Read the user's request ($ARGUMENTS) and the surrounding conversation to identify the source they are pointing you at and any selection they implied (for example: all open issues, a range, a label, a milestone, a project or cycle). Use whatever tools are available to read it — the GitHub CLI (gh) for issues, the Linear MCP for tickets, or the provided text for a PRD.
Use the question tool only to resolve a genuine blocker (which source, or an ambiguous selection). Do not re-ask what is already clear from context, and do not demand details the source already implies.
Step 2: Gather and decompose into features
Pull the items from the source, then turn them into implementation-coherent features. Each feature needs a short title and a concrete description the architect-auto agent can plan from (name the target area, the behavior, source references, and any constraints you already know).
- Already-discrete items (issues / tickets): start from one source item per feature, then look for non-trivial implementation coupling before launch. Prefer the smallest independently reviewable plan/PR. Group multiple items only when they must be changed together or would otherwise duplicate design/refactor work, conflict on a shared data model/API contract/state machine, require one migration, or create merge-conflict-heavy edits. Incidental same-file edits are not enough to group. Preserve every exact issue/ticket reference in a combined description, preferably URLs and otherwise canonical tracker identifiers, so the planner can re-fetch full context and the work stays traceable.
- Unstructured input (a PRD or other documentation): do not pre-split it yourself; pass it through as
prdand let the feature-splitter agent decompose it with the same small-PR-first grouping rule. - Do not split tightly-coupled behavior just because the source lists it as separate bullets. Do not group unrelated or merely adjacent work just to reduce loop count; grouping is only for real coupling, unavoidable sequencing, or shared architectural changes.
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.
- 2d ago First seen · 41 lines · 0 tokens per session scan A c3cce89ca60c
launch-group is a command published in the GitHub repository chriswritescode-dev/opencode-forge (11 stars, last pushed 5d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 842 tokens. 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-30.
Other commands, from other repositories
advisor
Advisory gate for triage or plan decisions. Spawns a second-opinion agent that challenges assumptions, surfaces risks, and proposes alternatives before the decision commits. Based on Anthropic advisor tool pattern.
guide
You are a triage agent who continuously prioritizes loom:issue issues by applying loom:urgent to the top 3 priorities.
pm-review
Review local git diff with reasoning + snippets; cross-check; dispose findings into the rules library.
new
Creates a new item in a module that supports the new capability.
card
Open one self-contained OverClick card.
linear-bulk
Apply the same change to many Linear issues at once. Dry-run by default.