The first cut measured the agent's activity and reported it as the developer's. Rewrites the attribution so every number is one you could defend to someone who pushed back on it. What a number now means: - Projects resolve to a git root, or to the directory the work happened in when there isn't one. Not basename(cwd), which turned a home directory into a 49% "project" and split one repo across several rows. - A session's spend follows the files it touched, reads included, split across projects. Subagents share their parent's session, so their work lands on the same project with no special case. - Claude Code's own machinery — scratchpad, tool-results, ~/.claude, and this report's own past output — is excluded. It was 82% of the reported line count. - Commits are joined against git: authored under the identity git uses in that repo, AND touching a file Claude Code touched. The old identity grep counted a snapshot cron's 2,209 commits and claimed the developer committed on every active day they worked. - Work with no project — web search, chat tools, dashboards — is named as research rather than filed under whatever directory the shell sat in. What's gone, and why: - The activity/spend breakdown. A turn's cost is ~90% context handling, half of it re-reading what earlier turns added, so charging it to whichever tool fired is a modeling choice rather than a measurement — and the choice decides the answer. On one real month three defensible weightings put web search at 11%, 28% or 51%. Per-project spend survives the same test and stays. - The `git commit` counter. A Bash call carries no working directory, so a commit in a throwaway fixture repo can't be told from a real one. Measured 33 against 4. Also: local calendar arithmetic (active days could exceed the window), paths normalized so Windows doesn't silently count the scratchpad as the user's work, HTML written 0600 and refusing symlinks, a CSV export with formula injection neutralized, print output that stays vector text, and perforated edges. The report says which columns sum and which don't, and distinguishes "no commits" from "git couldn't be read" — unknown is not zero.
Claude Code Plugins Directory
A curated directory of high-quality plugins for Claude Code.
⚠️ Important: Make sure you trust a plugin before installing, updating, or using it. Anthropic does not control what MCP servers, files, or other software are included in plugins and cannot verify that they will work as intended or that they won't change. See each plugin's homepage for more information.
Structure
/plugins- Internal plugins developed and maintained by Anthropic/external_plugins- Third-party plugins from partners and the community
Installation
Plugins can be installed directly from this marketplace via Claude Code's plugin system.
To install, run /plugin install {plugin-name}@claude-plugins-official
or browse for the plugin in /plugin > Discover
Contributing
Internal Plugins
Internal plugins are developed by Anthropic team members. See /plugins/example-plugin for a reference implementation.
External Plugins
Third-party partners can submit plugins for inclusion in the marketplace. External plugins must meet quality and security standards for approval. To submit a new plugin, use the plugin directory submission form.
Plugin Structure
Each plugin follows a standard structure:
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Plugin metadata (required)
├── .mcp.json # MCP server configuration (optional)
├── commands/ # Slash commands (optional)
├── agents/ # Agent definitions (optional)
├── skills/ # Skill definitions (optional)
└── README.md # Documentation
Plugin names are immutable
The name field in a marketplace entry is an immutable slug. Once a plugin has been published, its name must not change — users have it installed under that slug, and renaming it breaks their install with a plugin-not-found error.
- To change how a plugin is labeled in the UI, set or update
displayNameinstead. - If a rename is genuinely unavoidable, add an entry to the top-level
renamesmap in.claude-plugin/marketplace.jsonso existing installs auto-migrate:
"renames": {
"old-name": "new-name"
}
The Claude Code plugin loader reads this map and transparently rewrites the old slug to the new one on the user's next sync.
Skill-bundle plugins
When a plugin's source repository ships skills (SKILL.md files) without a .claude-plugin/plugin.json manifest, the marketplace entry can declare the skills directly using strict: false and an explicit skills array.
{
"name": "example-bundle",
"description": "Brief description of the bundled skills.",
"author": { "name": "Author Name" },
"category": "development",
"source": {
"source": "git-subdir",
"url": "https://github.com/example-org/sdk.git",
"path": "packages/agent-skills",
"ref": "main",
"sha": "<commit sha>"
},
"strict": false,
"skills": [
"./skill-a",
"./skill-b",
"./skill-c"
],
"homepage": "https://github.com/example-org/sdk"
}
Each path in skills is relative to source.path and points at a directory containing a SKILL.md. Paths can reach deeper than a single level — for example, ["./libA/skill-1", "./libB/skill-2"] exposes a curated subset across multiple library subdirectories. Each skill is registered as <plugin-name>:<skill-name> in Claude Code.
For the underlying schema, see Strict mode in the marketplace documentation.
License
Please see each linked plugin for the relevant LICENSE file.
Documentation
For more information on developing Claude Code plugins, see the official documentation.