hsb3
UserA Claude Code plugin marketplace: installable extenders — delegation agents, session-discipline hooks, and skills for research, diagrams, decks, and repo standards.
Categories
Indexed Skills (46)
board-triage
This skill should be used when the user asks to "run board triage", "triage the backlog", "prioritize the issues", "rank the unranked issues", "fill in Impact/Effort/Priority", "do the weekly triage", or wants the untriaged items on a task board classified so the prioritization/now/roadmap views become useful. It runs the export -> analyze -> apply loop: pull a snapshot, find the un-ranked/blank/stale items, rank them by the Impact x Effort rubric, and apply only the diffs. The judgment is backend-agnostic; a thin adapter does the board's I/O (kata and GitHub Projects v2 adapters ship; any board with items and fields can have one).
readme-value-and-proof
Turn a README into a user-centric pitch backed by real visual proof. Use when asked to write/refresh a README with a value proposition, capture app screenshots for docs, add "visual proof" of a UI/feature, or explain "what someone gets" from a project. Captures live screenshots from the running app (not mockups), writes an honest motivation + value prop + roadmap, and embeds the shots.
claude-code-expertise
Expert map of Claude Code's extension surfaces for authoring and debugging extenders — skills, subagents, hooks, commands, plugins, marketplaces, MCP servers, and settings/permissions contracts. Use to decide which surface fits a need, to look up a surface's frontmatter or config contract, to author or debug a skill, subagent, hook, command, or plugin, or to answer how any Claude Code extension surface works. Not for changing settings, permissions, or hook wiring in a project - that is claude-code-config.
opencode-expertise
Expert knowledge of opencode — every extension surface (config, agents, skills, commands, custom tools, plugins, MCP, rules), the TypeScript constraint, and the claude-code → opencode translation mapping. Use when configuring opencode, authoring or migrating extenders for it, designing an opencode distribution target for a Claude Code skill collection, or answering how any opencode surface works.
carbon-builder
IBM Carbon Design System expert for React and Web Components — Carbon components, IBM Products UI, Carbon Charts, icons and pictograms, design tokens, IBM Plex, accessibility guidance, AI Chat / watsonx integration, and Carbon code generation or compliance audits. Use for any task that builds, reviews, or asks about Carbon UI code or Carbon design guidance.
pocketbase-best-practices
PocketBase design and review guidance — collection schema, API rules and access control, auth flows, SDK usage, query performance, realtime subscriptions, file handling, deployment, and server-side extending. Use when designing a PocketBase schema, writing or auditing API rules, setting up auth, diagnosing slow or N+1 queries, or reviewing a PocketBase backend before it ships.
activation
Create and verify the harness-appropriate per-project activation file that arms atelier's hooks. Use when someone asks to turn on, configure, or check atelier enforcement (custody, worker context, worktree isolation, handoff routing) in a project, or when a hook that should be firing appears silent.
comment-hygiene
Strip history and commentary out of source comments before work lands — harvest the reasoning onto its tracker item, keep only what a reader would break something without. Use before a PR or a milestone commit, when a file's comments read as narrative, or when invoked by layer-cycle's refine phase.
compact-handoff
Update and verify the session handoff, then prepare a KEEP/DROP compaction prompt that preserves active agents and dependent commands. Use when asked to compact with a handoff or prepare session compaction.
delegation
How to split a substantial task across agents: the three-layer model, the architecture matrix, effort and model-tier calibration, brief rules, and the never-delegated floor. Use when sizing a feature build, refactor, migration, audit, or multi-file fix; when the work arrived as a goal ("clean this up", "get it published") rather than as a list of slices; when crews, teams, managers, subagents, or waves come up; when token cost on a big job is a worry; or when a session has been editing files itself for a long stretch without delegating.
deletion-pass
Simplify a module to irreducible against its contract — remove or collapse every line that cannot name the commitment it keeps, without changing observable behavior. Use when asked to simplify or tighten a module against its spec, to produce a dry-run deletion report, or when invoked by layer-cycle after a build or fix pass.
handoff
Maintain the project's session-handoff so a brand-new session can pick up work cold - a file this skill writes directly (_meta/HANDOFF.md, HANDOFF.md, .claude/HANDOFF.md, or a per-project override), or an external tracker/board it signals via a freshness stamp when the project's handoff key is set to external mode. Use at session boundaries when the user says "wrap up", "update the handoff", "prepare to clear/compact", "write the handoff", or runs /handoff; use "/handoff init" to create the file in a project that lacks one (file mode only). Updates current state, in-flight work, decisions made and pending, and gotchas - or, in external mode, updates the external handoff and touches its stamp - the externalization pass that makes a session clearable.
layer-cycle
Drive a module through create → evaluate → refine cycles until convergence or budget exhaustion, translating findings into scoped fix briefs. Use when asked to "run the cycle", take a module through review and refinement, or iterate a module against a contract. Companions — rubric-panel (evaluate), deletion-pass (refine).
rubric-panel
Score one or more code artifacts against an anchored rubric using a persona-diverse judge panel; produces dimension scores plus findings classified as defect, noise, spec-hole, or undeclared-commitment. Use when asked to "score this implementation", "judge these two solutions", "rate this module against a rubric", or compare competing implementations of the same spec, and when invoked by layer-cycle. For choosing between technologies, frameworks, or vendors, use tech-eval-research instead.
waves
Drive a project's open backlog to closed through triage, wave planning, and isolated agent crews — the full loop: refresh the triage view, group buildable items into branch-sized waves, launch worktree-isolated teams via the delegation skill, verify and land each wave in order, reconcile, and externalize. Tracker-agnostic: the backlog can live on GitHub issues, a kata board or any tracker that can list open items and hold a written plan — see the tracker bindings under references/. Use when the user says "work through the waves", "launch isolated teams to resolve/close the issues", "run the backlog", "triage and execute", points at the triage view, or asks to plan development branches around open items. Use "/waves init" to create the triage view in a project that lacks one. Composes the delegation skill (execution) and the handoff skill (boundaries).
task-authoring
Write tracked work items a cold agent can actually execute — titles, acceptance criteria, thresholds, approval gates, scope ownership. Use whenever creating or rewriting a Kata issue, a GitHub issue, an OpenSpec change, or any tracker item, and when reviewing an existing task for executability.
bun
Work with the Bun JS/TS toolchain — running scripts, installing packages, testing, bundling, bunfig.toml, bun.lock, or migrating a repo from npm/pnpm/yarn to bun. Use when a task touches bun commands, when choosing between bun built-ins and an npm dependency, when a bun install resolves a stale version or drops a platform package, when debugging PATH/mise/node-version interactions with bun, or when converting package.json scripts and lockfiles to bun.
comms
Produce your recurring communication deliverables - a morning status briefing, end-of-day wrap-up, weekly planning briefing, advisor board status readout, or client product overview - as a deck (plus optional spoken companion) to a consistent standard. Use when you ask for any of those by name, or for a "briefing", "status deck", "status readout", "board deck", "comms package", or deck narration/audio. Self-comms build through a bundled stdlib-Python engine (spec in, validated, voice-linted, themed HTML/PDF out; no MCP server). Composes with the presentations skill (external decks) and the handoff skill (EOD wrap-up); it does not replace them.
presentations
Create, inspect, edit and review PowerPoint decks and templates (.pptx/.potx). Use semantic palettes, deliberate typography, portable PptxGenJS source packages and rendered visual verification. Recurring briefing content goes through comms, which calls this skill for external decks.
project-memory
The agent-memory taxonomy (layers, loading modes, memory vs rule vs skill, the birth rule) and the scripts that wire a repo for it or migrate it after a move. Use for "where does this memory go", "promote a memory", "run a curation pass", "memory vs rule vs skill", "set up project memory", "opt this repo into tracked memory", or "my project memory disappeared after I moved the folder".
pull-request
Work a pull request's review findings after the checks go green — collect the inline review comments, the review and summary-level comments, and the gate statuses; classify each finding as actionable (it sits on a line this PR changed, or it is a failing hard gate) or as pre-existing rot; then report the deferred set by name instead of dropping it. Use when asked to "check the PR comments", "address the review feedback", "what did the review bots say", "is this PR ready to merge", or right after opening a PR and watching its checks go green.
starting-conditions
Set a project's starting conditions before the code exists — the conversation that decides what is being built, in what language, and which quality checks are machine-enforced, ending in a `RULES.md` contract plus one gate command that proves it. Use when starting a new repo or project, adding rigor to an existing one, or when the ask is "set this up properly", "define done", "what gates should this repo have", "write a RULES.md", "how do I keep agents from making a mess in this repo", or when a repo's quality conventions live only in someone's head. Interview first, write second: every question left unanswered becomes divergence to adjudicate later. Not for repo layout standards (repo-meta-structure), scaffolding missing meta-structure (mise-en-place-scaffold), or running controlled experiments.
diagrams
Create technical architecture diagrams using Python's diagrams library (mingrammer/diagrams) or raw Graphviz dot. Use when users need to create cloud architecture diagrams with provider icons (Azure, GCP, AWS, Kubernetes, on-prem), system design diagrams, infrastructure visualizations, data flow diagrams, dependency graphs, org or process trees, or any structural diagram showing relationships between components. Also the hub for choosing the right diagram tool (Python diagrams vs Mermaid vs draw.io vs Excalidraw) and for the SVG plus PNG output pipeline that feeds GitHub markdown, PowerPoint decks and exec briefings, and standalone architecture docs. Includes iterative review loop and custom Graphviz attributes for professional formatting. Self-improving - accumulates learnings in memory file to avoid repeating mistakes. Structural diagrams only - data charts and plots belong to the dataviz skill, deck theming to presentations.
drawio
Read, convert, and export draw.io / diagrams.net files. Use when the user has legacy .drawio or .drawio.png/.drawio.svg files to inspect, extract content from, convert to Mermaid or another format, or export headlessly to PNG/SVG from the command line - or asks about drawio, diagrams.net, or mxGraph XML. Covers the compressed and uncompressed XML formats, a Python decompression recipe, and the desktop app's CLI export flags.
excalidraw
Create sketch-style, hand-drawn-look architecture diagrams as Excalidraw files. Use when the user asks for an excalidraw diagram, a whiteboard-style or sketchy diagram, or wants a .excalidraw file created or edited. Works with or without the Excalidraw MCP tools - when the MCP tools are unavailable, author the .excalidraw JSON scene directly. Covers the scene JSON schema, element and arrow-binding essentials, an offline headless render-and-lint loop that screenshots a scene and names its defects, and export to SVG/PNG.
mermaid
Author Mermaid diagrams for GitHub-rendered markdown and technical docs - architecture flowcharts, sequence diagrams for auth and API flows, entity-relationship diagrams for database design, state diagrams, and class diagrams. Use whenever adding a diagram to a README, repo doc, PR description, or any markdown that GitHub renders, or when the user says mermaid, flowchart, sequence diagram, ERD, or state diagram. Enforces the house rule that node labels must contain no parentheses or special characters, and covers light/dark theming and local rendering to SVG/PNG via mermaid-cli.
mise-en-place-scaffold
Fill-only repo scaffold against the packaged standards — use whenever the ask is "scaffold this repo", "run mise-en-place", "fill the audit gaps", "set up a new repo to the standard", or any request to create the missing meta-structure the compliance audit flags. Runs the bundled script from the repo root: `--plan` (default) prints planned creations, conflicts, and non-mechanical items per checklist ID and writes nothing; `--apply` creates only the planned items; `--init-manifest` writes the commented `_meta/mise-en-place.yml` variance template. Additive-only: it NEVER overwrites, merges, edits, deletes, or moves an existing file, never provisions GitHub-side objects, and never authors README/CLAUDE.md/AGENTS.md content. Not for measuring compliance (repo-compliance-audit) or for questions about what the standard says (repo-meta-structure / project-memory skills).
planning-desk
Stand up and run a source-grounded planning desk under _meta/plans/ - deep build plans driven through a multi-round draft -> review -> fix -> reconcile loop over a tracker read through a pluggable adapter, plus analysis scripts for conformance, coverage, and reconciliation. Use whenever the user wants to plan a feature or epic before building, run a planning or backlog-grooming session, organize work under _meta/plans/, audit plan/tracker drift, triage a candidate list into MUST/DEFER/CUT, or set the desk up in a repo - even phrased as "plan this out", "groom the backlog", "scope this", "what should we cut", "run the scope hammer", or "get this repo's planning organized". It enforces deliverables/criteria/parallelism (never timelines) and grounds every claim in cited source. Not for writing the body of a tracked work item (task-authoring), not for creating a repo's meta-structure or filling audit gaps (mise-en-place-scaffold), and not the layout standard itself (repo-meta-structure).
repo-compliance-audit
Run the read-only repo compliance audit — use whenever the ask is "run the compliance audit", "audit this repo against the standard", "is this repo conformant", "check this repo's structure/layout compliance", or any request for a pass/gap verdict against the repo meta-structure or project-memory standards. Runs the bundled script from the repo root and presents its `ID | Area | Verdict | Detail` table plus `N pass / M gap` summary verbatim. Strictly informational: it never writes to the audited repo, never fixes gaps (that is the mise-en-place scaffold skill), and defines no checklist content of its own (rows come from the sibling standards' checklist files). Not for questions about what the standard says (repo-meta-structure / project-memory skills) or for scaffolding missing structure.
repo-meta-structure
The canonical repo meta-structure standard — consult it whenever a question is about "what is the standard for X" in a repo's layout: the `_meta/` directory taxonomy (_archive/briefings/plans/operations/research + HANDOFF.md + README.md), the `.claude/` layout (what's tracked vs machine-local, commands/ as migration debt), the `.github/` template set, required root files, the gitignore conventions (track-by-default `_meta/` with the `operations/` ignore, `.env*` handling, the `.claude` stanza), the `_meta/plans/` planning-doc frontmatter schema, or where communication packages from the strategy desk land (`_meta/plans/inbox/`). Use when setting up or reviewing a repo's structure, answering layout questions, or checking what belongs where. This skill is reference content only — the compliance audit and mise-en-place scaffold are separate sibling skills that read this same content.
obsidian-api-basics
This skill should be used when the user asks to "create an Obsidian plugin", "plugin lifecycle", "plugin settings", "vault API", "register command", "add ribbon icon", or mentions Obsidian plugin fundamentals like onload, onunload, saveData, or loadData.
obsidian-chat-ui
This skill should be used when the user asks to "create chat interface", "build sidebar", "ItemView", "streaming messages", "chat sidebar", "copilot UI", or mentions building chat or conversational interfaces in Obsidian plugins.
obsidian-cli
This skill should be used when the user asks about "obsidian cli", "command line interface for obsidian", "automate obsidian", "script obsidian vault", "obsidian terminal commands", or wants to interact with their Obsidian vault from the command line for automation, scripting, or integration purposes.
obsidian-mcp-server
This skill should be used when the user asks to "add MCP server", "Model Context Protocol", "expose vault tools", "Streamable HTTP", "MCP tools", or mentions integrating MCP servers in Obsidian plugins to expose vault operations.
pocketbase
Operate a running PocketBase backend via REST API or Go package mode - collection CRUD, record CRUD, superuser and user authentication, backup and restore, migration file generation (JS and Go), Go hooks and custom routes, health checks, and e2e helpers, with bundled stdlib-Python scripts. Use for requests about PocketBase operations, pb_migrations, collection management, record operations, Go framework embedding, and driving an instance. For schema design, API-rule review, query-performance diagnosis, or a pre-ship backend audit, use the pocketbase-best-practices skill instead.
api-craft
Design, build, and structure an HTTP/REST API server — the layered architecture (route, schema, service, repository, model), what each layer is allowed to know and return, the rejection cascade that maps every failure to a status code, outside-in build order, and what belongs in OpenAPI/schema descriptions that ship to consumers. Use when starting an API, adding an endpoint, deciding which layer a piece of logic belongs in, designing error handling and status codes, or cleaning up a generated API reference. Triggers on FastAPI, Pydantic, route vs service vs repository, schema vs model, "where does this go", 4xx/422/409 status-code design, ErrorResponse envelopes, OpenAPI summary/description hygiene, and idempotency keys. Consult before writing the first endpoint, not after. Not for client-side HTTP calls, GraphQL schema design, or non-HTTP RPC.
claude-code-config
Configure Claude Code itself — settings-file precedence, permissions, hooks, env vars, and MCP registration, closed by a take-effect check. Use for "change a setting", "allow/deny a command", "add or move a permission rule", "set up a hook", "run something automatically whenever X happens", "always do Y every time", "add an environment variable", "register an MCP server", or "why isn't my setting taking effect".
dataviz
Design data visualizations - charts, graphs, plots, and dashboards - that are correct, legible, and honest, in any medium. Consult this BEFORE writing any chart, graph, plot, or dashboard code, whatever the library (matplotlib, plotly, d3, Recharts, inline SVG) or output (static image, notebook, web app, deck). Use whenever a task involves picking a chart type, a color palette for data, dashboard or KPI-tile layout, axis and label formatting, or making a visualization colorblind-safe and light/dark-ready. Covers the data-shape to mark-type heuristic, chart anti-patterns to refuse (pie overuse, dual axes, truncated bar axes, rainbow scales, 3D), a brand-neutral colorblind-safe palette you can rebrand, composition, interaction and static degradation, and a final validation checklist. Data charts only - structural diagrams and deck theming are out of scope.
deep-research
Run a deep, multi-source, fact-checked research investigation that ends in a cited report, not a single web lookup. Use when the user asks to "research X", "do a deep dive on", "find out everything about", "investigate", "compare the options for", "what's the state of the art on", or "give me a report with sources" — or poses a broad, open-ended question that one search cannot settle and that needs several sources cross-checked against each other. Runs the pipeline scope -> decompose into angles -> fan out searches -> dedupe and fetch sources -> extract falsifiable claims -> adversarially verify each load-bearing claim -> synthesize a confidence-ranked, per-claim-cited report that keeps negative findings. Prefer it over an ad-hoc search whenever being wrong is costly or the answer must be defensible.
editor-project-config
Design the tracked per-repo editor configuration for VS Code (`.vscode/`) and Zed (`.zed/`) — settings overrides, extension recommendations, tasks, and debug configs that travel with the repo. Use when asked to "set up editor config for this project", "add a .vscode or .zed folder", "recommend extensions for this repo", "wire lint or tests into editor tasks", or when a repo's files open without syntax highlighting (extensionless scripts, odd filenames, JSONC named .json). Covers the surface map for both editors, the two association mechanisms (files.associations vs file_types), mirroring the repo's existing lint toolchain instead of inventing one, and keeping the two folders in parity.
iterm2
Configure iTerm2 and exploit the features that distinguish it from other terminal emulators. Use for any iTerm2 request: "set iTerm2 as my default terminal", "change a profile or theme", "my iTerm setting keeps reverting", "add a dynamic profile", "version-control my iTerm config", "install shell integration", "set up triggers / status bar / hotkey window / badges / captured output", "why didn't my `defaults write` stick", or "what iTerm2 features am I not using". Covers the preferences model (why iTerm2 silently reverts scripted changes and how to write them safely), dynamic profiles, tracking the config in a dotfiles repo, shell integration and its utilities, the macOS default-terminal binding, and the power-feature catalog.
opencode-sandbox
Spin up a disposable, isolated opencode instance and hand it to this session as an MCP server — a sandboxed coding agent with its own workspace volume that cannot see the host filesystem. Use when the user asks for a sandbox, a scratch agent, an isolated or throwaway opencode instance, a place to let an agent work on a copy of a project, or says "opencode-sandbox", "sandbox this project", or "give me an isolated agent". Covers installing the CLI, seeding project context, custom config and plugins, worktrees inside the instance, registering with the current client, and destroying it afterward.
owner-signoff
Present a batch of decisions, approvals, or questions to the project owner as a local HTML form in their browser instead of asking in chat. Use when multiple items need the owner's input (sign-offs, dispositions, priorities, open questions), when the owner asks "what do you need from me", or asks for a summary/quiz they can react to. Answers flow back to a JSON file the session picks up automatically.
private-fork
Stand up and operate a private fork (private mirror) of an upstream open-source repo — creating the mirror and remotes, choosing the branch model and governance tier, deciding delete-vs-disable for unwanted upstream content, recording divergences in a ledger or registry, and running the recurring upstream review/merge cycle. Use when the user wants to "set up a private fork", "mirror an upstream repo", "sync/merge upstream", "run an upstream review", "strip out upstream cruft", asks about delete-vs-disable or merge tax, or is working in a repo with an `upstream` remote and a FORK_CHANGES.md / fork-customizations.md file. Not for ordinary contribute-back GitHub forks where changes are destined for upstream PRs.
tech-eval-research
Rigorous, cited, comparative evaluation of technology options — frameworks, infrastructure, serving layers, databases, libraries, SaaS-vs-self-hosted tools — producing a ranked shortlist, a capability comparison matrix, and a recommendation backed by primary sources. Use this whenever the user wants to compare, evaluate, choose, or shortlist technologies — "which X should we use", "evaluate these options", "is the free tier actually free" — and for license or paywall audits, self-hostability checks, open-source maturity assessments, build-vs-buy research, or vendor-neutral recommendations, even if the user never says "research" or "report". Especially valuable when license terms, free-tier boundaries, feature gating, or project health could decide the outcome.
test-quality
Use when writing a test, reviewing a test file or a test diff, encoding a defect as a failing test before the fix, or when a suite is green and nobody can say what production change would break it. Answers "would this test ever fail?" with a pre-write gate, a five-mutation check (wrong constant, wrong branch, missing side effect, empty return, missing validation), and the four shapes that stay green forever — mocking the subject under test, one double shared across every branch, assertions that mirror the implementation, and re-testing framework mechanics.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.