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 PrabhdeepSingh/claude-plugins --skill plugin-devgit clone --depth 1 https://github.com/PrabhdeepSingh/claude-pluginsWrote 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/prabhdeepsingh/claude-plugins/plugin-dev)<a href="https://agentmods.dev/skills/prabhdeepsingh/claude-plugins/plugin-dev"><img src="https://agentmods.dev/badge/skills/prabhdeepsingh/claude-plugins/plugin-dev/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/prabhdeepsingh/claude-plugins/plugin-dev"><img src="https://agentmods.dev/badge/skills/prabhdeepsingh/claude-plugins/plugin-dev.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.00143 | $0.05326 |
| Opus 5.5 | $0.00057 | $0.02130 |
| Sonnet 5.5 | $0.00029 | $0.01065 |
| Haiku 4.5 | $0.00014 | $0.00533 |
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 1mo 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 — 140 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.
- 1mo ago Changed · +3 lines 4c086af06d53
- 1mo ago First seen · 137 lines · 143 tokens per session scan A fb8b2d7c952b
plugin-dev is a skill published in the GitHub repository PrabhdeepSingh/claude-plugins (4 stars, last pushed 1mo ago), licensed MIT. It adds 143 tokens to every session and 5,326 once invoked, about $0.0006 per session on Opus 5.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
unity-coder
Use when implementing Unity C# code to follow proper coding guidelines, naming conventions, member ordering, and Unity-specific patterns.
tg-account
A skill for using Telegram as the account owner through a local Telegram Desktop session. It can read chats and export messages, while writing actions require showing the target and exact text for confirmation.
agent-teams
Set up and orchestrate Claude Code agent teams - multiple Claude Code instances working together with shared tasks, inter-agent messaging, and centralized management. Use when the user wants to (1) create or start an agent team for parallel work, (2) configure agent team settings like display mode or teammate mode or…
python-coder
Implements Python code following PEP 8, type hints, and project conventions. Use when implementing features designed by python-architect.
python-testing
Python testing patterns with pytest including unit tests, integration tests, fixtures, mocking, and coverage. Use when writing Python tests.
typescript-coder
Implements TypeScript/JavaScript code following established architecture and coding guidelines. Use when implementing features designed by typescript-architect.