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 besimple-tiny-broccoligit 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/besimple-tiny-broccoli)<a href="https://agentmods.dev/skills/besimple-oss/broccoli/besimple-tiny-broccoli"><img src="https://agentmods.dev/badge/skills/besimple-oss/broccoli/besimple-tiny-broccoli/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/besimple-tiny-broccoli"><img src="https://agentmods.dev/badge/skills/besimple-oss/broccoli/besimple-tiny-broccoli.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.00030 | $0.01271 |
| Opus 5 | $0.00015 | $0.00635 |
| Sonnet 5 | $0.00006 | $0.00254 |
| Haiku 4.5 | $0.00003 | $0.00127 |
Grade A, and why
besimple-tiny-broccoli 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Tiny Broccoli: Implement → Check → Commit → Dedup
Use this when the user request is already clear and you can safely implement directly (no plan docs), but you still want:
- repo checks to be green, and
- a dedupe pass over the resulting diff.
Not for
- Big/ambiguous work that needs research, design decisions, or a multi-phase plan.
- “Refactor the whole repo” style requests.
Preconditions (hard stop if missing)
- Confirm you are in the intended repo:
git rev-parse --show-toplevel - Start from a clean working tree:
git status --porcelainis empty - Ensure git can create commits (
user.name/user.emailconfigured) - Ensure required CLIs exist (dedup requires distinct vendors):
codex,claude
Required subskills
dedup
Workflow
0) Record BASE_SHA (required)
Capture the base ref before any changes (used later for dedup):
BASE_SHA="$(git rev-parse HEAD)"
1) Choose the repo check command(s) once (required)
Do a one-time tooling detection + configuration so the per-step “build/lint” commands match the target repo.
Detect languages and entrypoints
- Node/TS: look for
package.jsonin repo root and common subprojects (for examplefunctions/package.json). - Python: look for
pyproject.toml,uv.lock,poetry.lock,requirements.txt. Pick build/lint/typecheck commands (prefer repo-native scripts) - Prefer existing package scripts when present (e.g.
npm run build,npm run lint,npm test). - Prefer the repo’s configured Python toolchain:
- If
uvis clearly in use: useuv-based commands. - If Poetry is clearly in use: use
poetry run .... - If neither: use the repo’s documented commands (README/CONTRIBUTING) if available.
- If
- If multiple options exist or it’s unclear, ask the user once for the canonical build/lint/typecheck commands, then reuse them for every step. Write down a “Tooling config” block and reuse it for every step
- Example format (adapt to the repo):
- Root (Node): build=
..., lint=... - functions/ (Node): build=
..., lint=... - Root (Python): build=
..., typecheck=..., lint/format=...
- Root (Node): build=
- From now on, only run the commands from this block after each step (instead of hard-coded defaults). If the repo has no build/lint tooling
- Explicitly record “No build/lint configured” and skip build/lint steps (do not invent tooling). Call this out in the final summary.
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 · 130 lines · 30 tokens per session scan A 217da48dee92
besimple-tiny-broccoli is a skill published in the GitHub repository besimple-oss/broccoli (285 stars, last pushed 4mo ago), licensed MIT. It adds 30 tokens to every session and 1,271 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
submit-review
Reference for how a finished ticket reaches human review in the Gaffer factory. Submission is RUNNER-OWNED — the agent commits its work and evidences the ACs, then stops; the runner records the delivery, pushes, opens the PR, and submits for review. Invoke when you think your work is ready to hand off, to confirm what…
commit-and-push
Create a well-formatted git commit and push to remote repository.
customize-contribute-back
Contribute a user's AIWG customization back upstream as a PR — reviews for general applicability, creates branch, opens PR.
create-branch
Use at the start of work on any claimed Dispatch ticket, before editing files, to create the working branch with the required prefix. Invoke whenever a ticket needs code changes and you are not yet on a non-protected feature branch.
changelog-generator
Use when producing release notes from Conventional Commits, computing the next semantic version from a commit stream, generating CHANGELOG.md, or automating release notes in CI. Triggers on "generate the changelog", "what version bump do these commits require", "release notes", "CHANGELOG", or "semantic version".
cc-autopilot
Run cc-autopilot, a perpetual autonomous AUDIT/GENERATE→TRIAGE→BATCH→FIX→VERIFY→REVIEW→COMMIT loop that holds every change to a configured quality bar through a judge panel. Its fixers each own a file-disjoint slice of the tree so no two can ever touch the same file, and nothing unverified reaches git. Works on a web…