skill-collection

name

skill-collection

description

Personal manager for Claude Code skills, plugins, and bookmarks. Use when the user wants to install/list/remove/move/dedupe skills or plugins, manage them across user and project scope, install bookmarked skills into a project ("install [stack] skills from my collection", "what skills do I have for [stack]"), bookmark a new skill ("bookmark this skill"), add notes to existing bookmarks, or understand the difference between skills, plugins, and scopes. Auto-trigger when the user mentions installing/uninstalling/listing/managing skills or plugins, when they ask "what's installed", or when they reference scope (project, user, global).

Skill Collection

A personal manager for Claude Code's skills and plugins, plus a bookmark library of favorites with personal notes. The goal: keep global Claude lightweight by defaulting to project-scope installs, while still being able to discover, install, and clean up across scopes.

This skill itself lives at user-scope so it's always available; the things it tracks are mostly per-project.

Concepts

Skill vs Plugin

• Skill — a single SKILL.md (often with helpers) that Claude reads on trigger. Lightweight. Installed via npx skills add <owner>/<repo>@<skill> --agent claude-code from the skills.sh registry.
• Plugin — a bundled extension that can include skills, slash commands, agents, hooks, and MCP servers. Heavier. Installed via the /plugin command from a marketplace. A plugin can contain skills (e.g., frontend-design@claude-plugins-official is a plugin providing the frontend-design skill).

When the user says "install X", check the form to decide:

• owner/repo@thing with no --marketplace-like context → skill (use npx skills)
• name@marketplace or "install plugin X" → plugin (use /plugin)
• Ambiguous → ask.

Install methods

Most skills are installed from the skills.sh registry via npx skills add. But some skills ship as standalone npm packages with their own interactive installers — they may install multiple sibling skills as a bundle, support multiple agent runtimes (Claude Code, OpenCode, Gemini, Codex), and offer their own scope picker.

A bookmark declares its install method via frontmatter:

install_method:	When to use	Required fields
skills-sh (default)	Single skill from the skills.sh registry	install: anthropics/knowledge-work-plugins@code-review
npm	Standalone npm package with its own installer	install_cmd: "npx get-shit-pretty"
plugin	Claude Code plugin from a marketplace	plugin: frontend-design + marketplace: claude-plugins-official
custom	Anything else (git clone + symlink, brew, etc.)	install_cmd: "<full command>"

Optional for any method: note_install: (one-line guidance, e.g. "pick local install when prompted"), source: (link back to docs/repo).

The install workflow dispatches per method:

• skills-sh → npx skills add <install> --agent claude-code -y (add --global for user scope)
• npm / custom → run <install_cmd> directly from the project root (these are often interactive — surface note_install: first)
• plugin → ensure marketplace is registered via /plugin marketplace add <marketplace>, then /plugin install <plugin>@<marketplace>. Note: plugins run via Claude Code's slash commands, not shell.

Scope: project vs user (global)

• Project-scope — <repo>/.claude/skills/<name>/ or, for plugins, installed_plugins.json entry with "scope": "project" and a projectPath. Only loaded when working inside that project. Ships with the repo via git so collaborators get it on git pull.
• User-scope (also called "global") — ~/.claude/skills/<name>/ or installed_plugins.json entry with "scope": "user". Loaded in EVERY conversation, regardless of project. Use sparingly — bloat slows Claude down and clutters the available-skills list.
• Default for installs: project scope, unless the user explicitly says "global", "user-scope", or "everywhere". Confirm if unclear.

Bookmark vs Install

• A bookmark in this collection is a markdown file in bookmarks/ recording a skill's install path, when-to-use, and notes from past use. Bookmarking ≠ installing.
• An install copies the actual skill files into .claude/skills/, making them usable in conversations.
• Common flow: discover → bookmark → (later, in a relevant project) install.

Trigger phrases

Phrase	Action
Bookmarks
"install [stack] skills from my collection"	install_collection(stack)
"install my bookmarked skills"	List collections, ask which
"install [name] from my collection"	install_one(name)
"what skills do I have for [stack]"	list_collection(stack)
"list my bookmarked skills"	list_all_bookmarks()
"bookmark this skill" / "add [path] to my collection"	add_bookmark(path)
"add a note to [skill]"	update_notes(name)
Skills (lifecycle)
"list my skills" / "what skills are installed"	list_skills(both)
"list project skills"	list_skills(project)
"list global skills" / "list user skills"	list_skills(user)
"install [path]" / "add [path]"	install_skill(path, scope?) — ask scope if unclear
"remove [name]" / "uninstall skill [name]"	remove_skill(name, scope?) — ask scope if at both
"move [name] from [a] to [b]"	move_skill(name, a, b)
"dedupe my skills" / "find duplicate skills"	dedupe_skills()
Plugins (lifecycle)
"list my plugins" / "what plugins are installed"	list_plugins()
"install plugin [name]" / "add plugin [name]"	install_plugin(name, marketplace?)
"reload plugin [name]"	reload_plugin(name)
"update plugin [name]"	update_plugin(name)
"uninstall plugin [name]" / "remove plugin [name]"	uninstall_plugin(name, marketplace?)
"publish my plugin" / "upload [name]"	publish_plugin(name)

Workflows

Bookmarks

install_collection(stack)

1. Read every file in bookmarks/ whose frontmatter collections: contains the stack name (case-insensitive).
2. Show the user the matched bookmarks: name + one-line "when to use".
3. Ask: "Install all N? Or pick a subset?"
4. After confirmation, for each chosen bookmark, derive the command from install_method: (default skills-sh):
   • skills-sh → cd <project-root> && npx skills add <install> --agent claude-code -y
   • npm / custom → cd <project-root> && <install_cmd> (these are often interactive — surface note_install: to the user before running)
5. Update each bookmark's last_installed: to today's date.
6. Report: which were installed, which already existed at project scope (skipped), which failed.
7. After install, check ~/.claude/skills/<name>/ — if a duplicate exists at user scope, warn and offer dedupe_skills().

install_one(name)

1. Read bookmarks/<name>.md.
2. Run the appropriate install command (per install_method:) from current project root.
3. Update last_installed:.

list_collection(stack) / list_all_bookmarks()

Print as a markdown table: name | install path | when-to-use. No installs.

add_bookmark(path)

1. Derive filename from the skill name (part after @, or last path segment).
2. Ask one at a time: which collection(s)? when to use (one-liner)? notes?
3. Create bookmarks/<name>.md using the template (see below).
4. If a new collection was introduced, add it to the Collections section of this file.

update_notes(name)

Open bookmarks/<name>.md and append to the Notes section under a new ### YYYY-MM-DD sub-heading.

Skills (lifecycle)

list_skills(scope)

• project — ls <cwd>/.claude/skills/
• user — ls ~/.claude/skills/ (filter out *.md files like boundaries.md, themes.md which are config not skills)
• both (default) — show both as a 3-col table: name | project? | user? — flag duplicates with ⚠

install_skill(path, scope)

• project (default): cd <project-root> && npx skills add <path> --agent claude-code -y
• user/global: npx skills add <path> --agent claude-code --global -y
• After install, check the OTHER scope; if duplicate exists, warn and offer to remove it.

remove_skill(name, scope)

• project: rm -rf <cwd>/.claude/skills/<name>
• user: rm -rf ~/.claude/skills/<name> — confirm first; affects all projects.
• If skill is at both scopes and user said <name> without scope, ask which.

move_skill(name, from, to)

1. Read frontmatter of source SKILL.md to get the install path.
2. Install at target scope.
3. Remove from source.
4. Verify both: ls <target>/.claude/skills/<name> exists, ls <source>/.claude/skills/<name> doesn't.

Common case: promote project skill to user-scope when it's broadly useful → move_skill(X, project, user). Or demote noisy user-scope skill to a single project → move_skill(X, user, project).

dedupe_skills()

1. Find skills present at BOTH ~/.claude/skills/ AND <cwd>/.claude/skills/.
2. For each, ask: keep project (recommended — see feedback_skill_install_scope) or keep user.
3. Apply choices.

Plugins (lifecycle)

Plugins are managed via the /plugin slash command and stored in ~/.claude/plugins/. Their state lives in ~/.claude/plugins/installed_plugins.json (read-only from this skill — modify via /plugin).

list_plugins()

1. Read ~/.claude/plugins/installed_plugins.json.
2. Print as a table: name | marketplace | version | scope (user/project) | installPath.
3. Note: project-scope plugins show projectPath — group those by project.

install_plugin(name, marketplace)

1. If marketplace not specified, ask. Common defaults:
   • claude-plugins-official — Anthropic's official plugins (frontend-design, context7, github, superpowers, pr-review-toolkit, code-simplifier)
   • User-specific marketplaces (e.g., shippit)
2. If the marketplace isn't already added: /plugin marketplace add <marketplace>
3. Then: /plugin install <name>@<marketplace>
4. Report: install path, version. Note that plugin commands and skills become available after Claude reloads.

reload_plugin(name)

• Plugins changes typically require a Claude Code restart. Tell the user this.
• For active development of your own plugin, point them at the plugin source dir and the claude --reload-plugins command (if available in their version).

update_plugin(name)

• /plugin update <name>@<marketplace> — bumps to latest from the marketplace.
• After update, recommend a restart for changes to take effect.

uninstall_plugin(name, marketplace)

• /plugin uninstall <name>@<marketplace>
• Confirm if the plugin is at user scope and might be used elsewhere.

publish_plugin(name) (interpreted as "upload")

• If the user wants to publish their own plugin to a marketplace:
  1. Confirm the plugin source directory.
  2. Create/update the marketplace repo on GitHub (e.g., gh repo create owner/marketplace --public).
  3. Push the plugin spec.
  4. Tell the user how others can install it.
• For uploading the user's own skill to a personal repo (like this collection), use a normal git push workflow.

Decision matrix

When the user's request is ambiguous, resolve in this order:

1. Skill or plugin? Look at the path. owner/repo@skill from skills.sh → skill. name@marketplace or anything via /plugin → plugin. If unclear, ask.
2. Project or user scope? Default project. Override only if the user said "global", "user", "everywhere", or "for all my projects".
3. Already bookmarked? Before installing a new skill, check bookmarks/ — if it's there, surface the existing notes and use the bookmark workflow so notes stay attached.
4. Existing duplicate? After install, check the other scope; warn if duplicate.

Bookmark file template

---
name: <bookmark-name>
install_method: skills-sh           # skills-sh (default) | npm | plugin | custom
install: <install-path>             # required for skills-sh — e.g. anthropics/knowledge-work-plugins@code-review
install_cmd: <full command>         # required for npm/custom — e.g. "npx get-shit-pretty"
plugin: <plugin-name>               # required for plugin — e.g. frontend-design
marketplace: <marketplace>          # required for plugin — e.g. claude-plugins-official
note_install: <one-liner>           # optional — guidance for interactive installers (e.g. "pick local install when prompted")
collections: [core, nextjs]         # at least one
source: <https://skills.sh/... or repo URL>   # optional
added: YYYY-MM-DD
last_installed: YYYY-MM-DD          # optional
---

# <bookmark-name>

**Install:** `<the install command, written out>`

## When to use
<One-liner. The condition that should trigger reaching for this skill/plugin.>

## Notes
<Personal observations from using it: what worked, gotchas, links.>

Only fill the fields relevant to your install_method. The other fields can be omitted.

Collections

A collection is a tag in a bookmark's frontmatter — a bookmark may belong to multiple. Current collections (extend as needed by adding to a bookmark's collections: array):

• core — useful in every project (debug, code review, planning)
• nextjs — Next.js apps (App Router, Tailwind v4, shadcn)
• react-ui — React component / UI work (any framework)
• dashboard — dashboard / data-viz projects
• solana — Solana programs and dApps
• stellar — Stellar / Soroban work
• frontend — generic frontend quality (a11y, design)
• design — design engineering, brand work, UI design pipelines (GSP territory)
• planning — feature spec, brainstorming, roadmaps
• claude-meta — building Claude Code skills, plugins, agents

To add a new collection: just use it in a bookmark's collections: array, then add a one-liner here for discoverability.

Anti-patterns

• ❌ Don't install a bookmarked skill at user scope by default. Project-scope is the rule (see feedback_skill_install_scope).
• ❌ Don't bookmark a skill you haven't actually tried. The Notes field is the value-add — empty notes = empty bookmark.
• ❌ Don't auto-install on project open. The user must invoke explicitly.
• ❌ Don't conflate skills and plugins. They have different install paths, scopes, and lifecycle commands.
• ❌ Don't remove a user-scope skill or plugin without confirming — it affects every project.
• ❌ Don't merge stack profiles into a single mega-install. Each install_collection call is a focused intent.