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 besimple-oss/broccoli --skill plan-sketchgit clone --depth 1 https://github.com/besimple-oss/broccoliWrote 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/besimple-oss/broccoli/plan-sketch)<a href="https://agentmods.dev/skills/besimple-oss/broccoli/plan-sketch"><img src="https://agentmods.dev/badge/skills/besimple-oss/broccoli/plan-sketch/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/besimple-oss/broccoli/plan-sketch"><img src="https://agentmods.dev/badge/skills/besimple-oss/broccoli/plan-sketch.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.00041 | $0.01378 |
| Opus 5 | $0.00020 | $0.00689 |
| Sonnet 5 | $0.00008 | $0.00276 |
| Haiku 4.5 | $0.00004 | $0.00138 |
Grade A, and why
plan-sketch 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 9d 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 — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Sketch
Preconditions
- Confirm you are in the intended repo:
git rev-parse --show-toplevel - Confirm whether web browsing is allowed.
- If browsing is blocked by sandbox/approvals, ask the user to enable/approve it.
- If the user says "no web browsing", proceed but clearly label assumptions where "latest" matters.
Output contract (required)
plan-sketch must produce:
- A sketch markdown file (usually under
sketch/, or an explicit--outputpath if provided). - A small, parseable Questions for user block in the subagent's stdout output so wrapper skills can ask the user without reading the sketch content into context.
- A machine-readable JSON Questions block in stdout so wrapper skills can parse choices programmatically.
The Questions block must cover:
- Any open questions / unknowns that change the plan materially.
- Any assumptions that should be confirmed.
- Any high-level approach forks (architecture, APIs, rollout/testing strategy, migrations).
- If there are multiple viable implementation approaches, include an explicit choose an approach question so the user picks one before planning.
Format requirements (strict):
- Do not print the sketch content in the response.
- Print the sketch path (single line) and then print a Questions block bracketed by markers:
BEGIN_USER_QUESTIONSEND_USER_QUESTIONS
- In the Questions block:
- Start with a short instruction telling the user to answer in one batch by label/number.
- Present all decision-steering questions at once.
- Number questions as
1),2), ... (not bullets). - For each question, include 2–4 mutually exclusive options.
- Label options as
1a),1b),1c)... (letters per question), and make the labels easy to copy/paste. - Put the recommended option first and include a 1-sentence rationale on the same line.
- End the block with a single-line summary of recommended picks in the format:
Recommended picks (copy/paste): 1a, 2b, 3a
- If there are no meaningful open questions, include at least 1 explicit confirmation question with options.
- After the text Questions block, print a JSON Questions block bracketed by markers:
BEGIN_USER_QUESTIONS_JSONEND_USER_QUESTIONS_JSON
- The JSON block must be valid JSON and include:
questions: array of objects withid(number or string) andoptions.- Each
optionsentry includeslabel(e.g.,1a) andtext. - Optional:
recommendedboolean on options andrecommended_picksarray at the top level.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 9d ago First seen · 118 lines · 41 tokens per session scan A 1f557f420fc7
plan-sketch is a skill published in the GitHub repository besimple-oss/broccoli (285 stars, last pushed 4mo ago), licensed MIT. It adds 41 tokens to every session and 1,378 once invoked, about $0.0002 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-30.
Other skills, from other repositories
memory-onboard
Use this skill when the user types /memory-onboard (or asks "set up memory for this repo" / "onboard this repo to memory" / "what should be in lore for this repo?"). It runs a repo-aware onboarding interview that produces DRAFT lore records grounded in concrete repo signals (README, ADRs, recent commits, deprecation…
plan-build
Use to turn a one-line brief into a phased, dependency-ordered epic of small, well-specified, deliverable tickets — covering BOTH "build me an app that does X from scratch" (greenfield) and "change/extend/redesign an existing app X" (brownfield, when a target repo is supplied). Clarify genuine ambiguity first, draft…
design-system
Use when a ticket needs a systematic token + component foundation for a frontend — the three-layer token architecture (primitive → semantic → component), component specs with full state coverage, or a recommendation for which design system a product should have. Invoke for "set up design tokens", "define the component…
spec-author
Use to turn a brief into a structured product SPEC — a set of testable CLAUSES, each exactly one statement, tagged requirement / non-goal / decision — that a human edits and freezes before it feeds the decompose engine. Clarify genuine load-bearing ambiguity first, then draft. Invoke whenever someone describes an app…
brand
Use to establish or audit a product's brand so the factory's output looks intentional, not template — when a ticket asks to "create a brand", "define the design system / visual identity / palette / typography", or when delivered UI looks generic and needs a deliberate direction. Detects existing brand and extends it…
code-tour
Use when asked to create a code walkthrough, onboarding tour, architecture tour, PR review tour, or any structured explanation of how a codebase works. Triggers on "create a code tour", "onboarding tour", "how does X work", "explain the codebase", "architecture walkthrough", "PR tour", or "contributor guide". Outputs…