Defame1297
e869912374
The bin skills were the only plugin without per-skill READMEs, so a reader had to open SKILL.md — an agent-facing contract, not an explainer — to learn what a skill does and when it fires. Each README states purpose, triggers and boundaries for a human audience, leaving SKILL.md free to stay terse.
bin
A place for things to be binned
Install
Claude Code:
claude plugin marketplace add <owner>/<repo>
claude plugin install bin@<marketplace-name>
GitHub Copilot CLI:
copilot plugin marketplace add <owner>/<repo>
copilot plugin install bin
Local (development):
# Claude Code
claude --plugin-dir ./plugins/bin
# GitHub Copilot CLI
copilot plugin install ./plugins/bin
Contents
| Component | Path | Description |
|---|---|---|
| Skills | .apm/skills/ → skills/ |
Slash commands available after install |
| MCP servers | .mcp.json |
The obsidian server (npx @bitbonsai/mcpvault@0.15.0 docs/), hand-authored at the plugin root |
.apm/ is the authoring source; skills/ is the generated mirror plugin hosts scan (ADR-0017). This plugin ships no agents. It is the only plugin here with a non-empty .mcp.json, which is why its compiled manifests are the only ones carrying an mcpServers block.
The two compiled manifests get that block by different routes. .claude-plugin/plugin.json gets it from apm itself: build_plugin_manifest's Claude branch calls collect_mcp_servers, which reads .mcp.json, sanitizes it, and inlines the resulting server objects. .github/plugin/plugin.json gets nothing from apm — the Copilot branch drops the field — so scripts/sync-plugin-content.sh's reinject_mcp_servers() puts it back, as the string ".mcp.json" rather than the resolved objects. Copilot's manifest schema types the field as "string or object — MCP server config path or inline definitions", and a path reference cannot carry a credential into a committed manifest. See ADR-0017's mcpServers amendment.
Author
Defame1297