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 skills/prabhdeepsingh/claude-plugins/plugin-devnpx skills add PrabhdeepSingh/claude-plugins --skill plugin-devgit clone --depth 1 https://github.com/PrabhdeepSingh/claude-pluginsWhat 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.00143 | $0.04999 |
| Opus 5 | $0.00072 | $0.02499 |
| Sonnet 5 | $0.00029 | $0.01000 |
| Haiku 4.5 | $0.00014 | $0.00500 |
Grade A, and why
plugin-dev 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 yesterday.
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 — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plugin development — how to carry this repo forward
This repo has no test suite, no CI, and no compiler: every quality gate is discipline plus the checks in /validate. This skill is the discipline written down, so a zero-context contributor (human or model) can change the plugin without re-fighting battles that are already settled. Everything here was extracted from this repo's actual git history — each rule has an incident behind it.
When to apply this
Any change inside this repo: editing a skill or command, adding a component, bumping a version, touching a manifest or the README, or reviewing someone else's change to any of those. If your working directory is the claude-plugins repo, this skill applies.
When NOT to use it: using the plugin's skills/commands in some other repo. This file governs the toolbox, not the work done with the tools.
1. Architecture contract — the load-bearing decisions
These decisions are deliberate. Don't reverse them casually; if one must change, record why in the PR and update this section.
| Decision | Why it holds |
|---|---|
One plugin (sonu), one marketplace (prabhdeep-tools) |
The repo IS the marketplace. marketplace.json at the root points at ./sonu; everything installable lives under sonu/. |
| Commands are thin; skills carry the methodology | A command exists only where sequencing and gates add something beyond one skill (/sonu:build, /sonu:ship). A discipline that needs a direct entry point is invoked as /sonu:<skill-name> on the skill itself — skills are directly user-invocable and take argument-hint/$ARGUMENTS. Never ship a command and a skill under the same name: they collide on the one shared invocation surface (the docs say the skill shadows the command; observed live behavior has been inconsistent, including launch errors) — that collision shipped once as the tdd/design-tree/self-review wrapper commands and was removed in v2.0.0. |
/sonu:build is a conductor, not an implementation |
It sequences design-tree → tdd → self-review and adds only triage and gates. It never re-implements what the skills already say (its opening contract enforces this). |
/sonu:ship is the one deliberately fat command |
Its bulk is incident-hardened, copy-exact shell with the failure lore attached. It delegates what it can (PR bodies and replies → pr-conventions, risk lists → self-review). Do not split it; do not "clean up" a snippet whose comment says copy it exactly. |
| No hooks, no agents, no MCP servers, no scripts/ | Zero-dependency Markdown + JSON keeps the plugin installable anywhere with nothing to break. Adding executable machinery needs a strong reason and a PR discussion, not a drive-by. |
A skill's references/*.md files are content, not the forbidden machinery |
The rule above bans executable scripts/servers, not plain Markdown. A references/ subdirectory beside a heavy skill's SKILL.md is allowed and encouraged (§4) — it's still zero-dependency Markdown, just loaded on demand instead of always. |
| Prose that directs the harness's built-in Agent tool is content, not the forbidden machinery | The "no agents" ban above means no shipped agent definitions — components the plugin would have to carry and keep working. A skill or command instructing the model to use the harness's own subagent tool (model-tiering; build.md Phase 2, which pre-approves Agent in allowed-tools) is still zero-dependency Markdown: on a harness without subagents it degrades to inline execution by its own wording, with nothing to break. |
| Dual manifests (Claude Code + Cursor) | .claude-plugin/ and .cursor-plugin/ carry mirrored manifests at both the repo root (marketplace) and inside sonu/ (plugin). Cursor reads its own copy; the two plugin.json files must stay byte-identical in content. |
| Installed copies are pinned | A user's installed plugin does NOT track main. Changes reach users only after a version bump + their /plugin marketplace update. An unbumped fix on main is invisible to every installed copy — that has already happened once (a ship.md behavior fix landed without a bump). |
.sonu/ in a managed repo is the queue's own state directory |
/sonu:factory reads .sonu/factory-config.md (tracker choice, committed so a team shares it) and the local tracker keeps tickets in .sonu/tickets/. That directory belongs to the repo being managed, never to this one — the plugin ships no .sonu/. Credentials never live there; adapters read them from the environment, because config files and ticket text both get committed. Global fallbacks (~/.sonu/factory-config.md, ~/.sonu/tracker-adapter.md) live under ~/.sonu/, the plugin's established per-user home. |
The local tracker's tickets: commits are a deliberate carve-out |
Workflows don't commit — except that ticket-file edits (claim, spec, classification, status flip) are committed immediately, alone, with a tickets: message prefix. Two reasons, both load-bearing: an uncommitted claim is invisible to a second agent, which is the race the claim exists to prevent; and metadata mixed into a code commit makes a human's review diff noisier for nothing. It covers tracker metadata only, never source code — remote trackers get the same durability server-side. Don't "simplify" this into the normal build/ship commit flow. |
| Maintainer tooling is repo-local, never shipped | This skill, /validate, and /release live in .claude/ (project-level), not under sonu/ — they only work with this repo checked out, so the audience boundary and the distribution boundary are the same line. Anything useful only to people working ON the plugin goes in .claude/; anything useful to people working WITH the plugin ships under sonu/. Don't put the next maintainer tool in the plugin. |
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.
- yesterday First seen · 137 lines · 143 tokens per session scan A fb8b2d7c952b
plugin-dev is a skill published in the GitHub repository PrabhdeepSingh/claude-plugins (3 stars, last pushed 2d ago), licensed MIT. It adds 143 tokens to every session and 4,999 once invoked, about $0.0007 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
dummy-dataset
Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats (CSV, JSON, SQL, Python script). Use when creating test data, building mock datasets, or generating sample data for development and demos.
outcome-roadmap
Transform an output-focused roadmap into an outcome-focused one that communicates strategic intent. Rewrites initiatives as outcome statements reflecting user and business impacts. Use when shifting to outcome roadmaps, making a roadmap more strategic, or rewriting feature lists as outcomes.
release-notes
Generate user-facing release notes from tickets, PRDs, or changelogs. Creates clear, engaging summaries organized by category (new features, improvements, fixes). Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.
retro
Facilitate a structured sprint retrospective — what went well, what didn't, and prioritized action items with owners and deadlines. Use when running a retrospective, reflecting on a sprint, creating action items from team feedback, or learning how to run effective retros.
shipping-artifacts
The durable documentation set that makes an AI-built (vibe-coded) app reviewable before shipping. A small core every app needs — architecture, user/permission flows, permissions, variables/secrets, and a test-coverage map — plus conditional docs added only when they apply: emails, scheduled work, SEO, and embedded…
competitive-battlecard
Create sales-ready competitive battlecards comparing your product against a specific competitor — positioning, feature comparison, objection handling, and win/loss patterns. Use when preparing sales teams, creating competitive materials, or responding to 'why not competitor X?'.