toolkit

Plugin toolkit from marketplace skills in m-de-graaff/skills. Commands read from the repo's manifest — 1 month ago.

Skills (44)

• accessibility

  Use when building or changing any user-facing UI — a component, form, modal, menu, icon button, custom control, colour or focus style — on web, iOS, or Android. Also use when auditing for WCAG compliance, when a design uses colour alone to carry meaning, when adding a click handler to something that

• animation-principles

  Use when adding, changing, or judging any UI motion — a transition, an entrance, a hover, a drag, a spring, a loading state. Also use when choosing an easing curve or a duration, when motion feels sluggish or jumpy, when deciding whether something should animate at all, and whenever another skill ne

• animation-vocabulary

  Use when someone describes a motion effect without knowing its name — "what's it called when…", "the bouncy thing when a popover opens", "that iOS scroll that resists and snaps back" — and wants the right term to search for or to ask a designer or an AI for. For naming an effect, not designing or bu

• api-connector-builder

  Use when adding an integration to a codebase that already has integrations — "build a Jira connector", "add a Slack provider", "create an integration for this API", "add another webhook source". Also use when reviewing a new connector for consistency with the existing ones, and when tempted to start

• api-design

  Use when adding or changing an HTTP endpoint, choosing a status code, shaping a request or response body, adding pagination, filtering, or sorting to a list endpoint, designing an error format, or deciding whether a change needs a new API version. Also use when reviewing an endpoint someone else wro

• apple-interface-patterns

  Use when building gesture-driven UI on the web — drag, swipe, sheets, drawers, momentum, velocity handoff, interruptible transitions — or when an interaction feels laggy, snappy in the wrong way, or breaks when the user changes their mind mid-motion. Also use for translucent materials and depth, siz

• auditing-animations

  Use when asked to audit the motion across a codebase, improve an app's animations generally, or produce a roadmap of motion fixes rather than a verdict on one diff. Also use when the request is "make this app feel better" and the scope is the whole product. For one diff use reviewing-animations; for

• backend-patterns

  Use when writing or reviewing server-side code behind an endpoint — data access, service layers, database queries, caching, transactions, background work, auth enforcement, or logging. Also use when a query is slow, when a list endpoint loads related records in a loop, when deciding whether logic be

• brainstorming

  Use when asked to build, add, create, implement, redesign, or change the behaviour of anything and the design is not already settled — feature requests, new components, "can you make it do X", rewrites, schema changes, a vague idea that needs shape. Also use when a request names several subsystems a

• ci-pipelines

  Use when setting up or changing continuous integration — a GitHub Actions workflow, a required check, a build or deploy job. Also use when CI is slow enough that people stop waiting for it, when a check fails intermittently, when deciding what should block a merge versus warn, when main goes red, wh

• competitive-benchmarking

  Use when scoring competitors against each other on comparable dimensions — a competitive landscape, a positioning study, a market or category review, "how do we stack up against them", "who else is doing what we do". Also use when a competitor comparison already exists but is gut-feel, unsourced, or

• database-migrations

  Use when changing a database schema — adding, dropping, or renaming a column or table, adding an index or constraint, changing a type, or backfilling data. Also use when writing an Alembic, Prisma, Django, Rails, or raw SQL migration, when a deploy needs to happen without downtime, when a migration

• deleting-code

  Use when removing a feature, an endpoint, a flag, a dependency, or code that looks dead — and when asking whether something is still used. Also use when deprecating a public interface, migrating callers off an old one, cleaning up after a launch, or finding commented-out code, a legacy branch nobody

• dispatching-parallel-agents

  Use when the user asks for subagents, parallel agents, fan-out, delegation, a workflow, or "ultracode" — and to decide whether to *offer* that when you notice several independent pieces of work (unrelated failures across subsystems, a search that spans many directories, an audit or migration over ma

• eliciting-requirements

  Use when a request is too vague to design against — "build me a dashboard", "we need notifications", "make it better" — or when nobody can state what success would look like. Also use when the request names a solution and the problem behind it is unstated, when different people want different things

• executing-plans

  Use when a written implementation plan, spec, or task list exists and the work is to carry it out — a plan file from writing-plans, a design doc with numbered steps, a checklist handed over from a previous session. Also use when partway through a plan and a step turns out to be blocked, wrong, or ba

• fastapi-patterns

  Use when writing or reviewing FastAPI code — routers, Pydantic schemas, dependencies, async handlers, auth, or the service layer behind them. Also use when structuring a new FastAPI project, when a route handler is accumulating business logic, when a sync database call appears in an async route, and

• finding-animation-opportunities

  Use when asked what could be animated in an interface, to make something feel more alive, or where motion is missing. Also use when a UI feels flat or static and nobody can say why. For fixing motion that already exists use reviewing-animations or auditing-animations.

• git-workflow

  Use when a unit of work finishes, tests just went green, a refactor is about to start, a work block ends, or the tree has drifted uncommitted — and whenever asked to commit, branch, push, open or merge a PR, stack PRs, tag, version, or cut a release. Also use on a dirty main, a detached HEAD, a diff

• jira-workflow

  Use when meeting notes, a transcript, or a call summary need turning into tickets, when work turns up mid-task that is out of scope for what you are doing, when a bug appears in a module you were not working on, or when a PR implies follow-up nobody has written down. Also use when grooming a backlog

• make-interfaces-feel-better

  Use when a UI reads as flat, generic, cramped, jumpy, or unfinished, and when building or reviewing controls, cards, lists, dashboards, navigation, forms, or toolbars. Also use when adding hover, active, focus, loading, or empty states, when numbers jitter as they update, when nested rounded corners

• measuring-performance

  Use when someone says something feels slow, before and after a change that could affect speed, when setting a performance budget or baseline, before a launch with performance targets, or when a page, endpoint, query, build, or test suite needs a number attached to it. Also use before claiming a chan

• observability

  Use when adding logging, metrics, tracing, dashboards, or alerts — and when deciding what to instrument before shipping something. Also use after an incident nobody could diagnose from the data available, when a log line is being added to debug production, when an alert fires too often to read, when

• optimization-loop

  Use when asked to make something faster, cheaper, or lighter — "speed this up", "cut the latency", "reduce the bill", "try a bunch of approaches and pick the best" — or when tuning parameters by repeated measured runs. Also use when an optimization attempt is already underway with no baseline, no co

• picking-ui-libraries

  Use when explicitly asked which library to use for a frontend task — toasts, command menus, drag and drop, virtualization, charts, OTP inputs, animated numbers, state, styling, theming. A curated opinionated list; invoke it deliberately rather than letting it fire on its own.

• react-patterns

  Use when writing or reviewing React components, custom hooks, or component trees — choosing where state lives, composing components, crossing the Server/Client boundary, wiring forms or data fetching, or placing Suspense and error boundaries. Also use when a `useEffect` is being added, when props ar

• react-performance

  Use when a React or Next.js app is slow to load, slow to interact with, or heavy on the client — and when reviewing code that could make it so. Also use when auditing bundle size or Core Web Vitals, when sequential `await`s appear in a Server Component or route handler, when a list renders hundreds

• react-testing

  Use when writing, fixing, or reviewing tests for React components, custom hooks, or pages — choosing queries, mocking network calls, testing async UI, or deciding what belongs in a component test versus a browser test. Also use when adding coverage to untested components, when a test is flaky, and w

• receiving-code-review

  Use the moment code review feedback arrives — from the user, a reviewer on a PR, a GitHub comment thread, or an automated pass like /code-review or /security-review — and before implementing any suggestion. Especially when a finding seems wrong, unclear, or would add something nobody asked for, or w

• redis-patterns

  Use when adding caching, rate limiting, session storage, distributed locks, queues, or pub/sub backed by Redis — and when reviewing code that uses it. Also use when picking a Redis data structure, designing keys or TTLs, configuring eviction or connection pooling, and when a cache is returning stale

• reporting-work

  Use when asked for a status update, a summary of what happened, or a report on work done — and when the user asks for less: "be concise", "just tell me", "skip the preamble", "shorter", "get to the point", or complains that the answer buried the answer. Also use when a reply is about to open by rest

• requesting-code-review

  Use after finishing a task or feature, before opening a PR or merging, before a risky refactor, after fixing a subtle bug, or when stuck and a fresh read would help. Also use when deciding which review instrument fits — working diff, GitHub PR, security-specific — or when asked for a code review, a

• reviewing-animations

  Use when reviewing a diff, PR, or component that adds or changes motion — transitions, keyframes, springs, gestures, entrances, hover effects. Also use when asked whether an animation is good, whether motion should ship, or to check a change against a craft bar. For a whole-codebase survey use audit

• security-patterns

  Use when writing or reviewing code that handles authentication, authorization, user input, file uploads, secrets, payments, or personal data — and when adding an endpoint, a webhook, or an integration that fetches a URL. Also use before a first production deploy, and whenever a value from a request

• subagent-driven-development

  Use when the user asks for a plan to be executed by subagents — "run this plan with subagents", "fan out the tasks", "use SDD", "ultracode this plan" — or asks to resume such a run after a compaction or interruption. Not for executing a plan yourself; that is executing-plans.

• systematic-debugging

  Use on any bug, test failure, crash, flake, performance problem, build break, or behaviour that isn't what you expected — before proposing a fix. Especially when the cause looks obvious, when you're in a hurry, when a previous fix didn't hold, or when you're about to change something to "see if it w

• typescript-patterns

  Use when writing or reviewing TypeScript — types, generics, `tsconfig`, or the shape of data crossing into the program. Also use when `any` or a type assertion is being added, when a type error is too long to read, when optional fields are multiplying on one interface, when parsing JSON from an API

• using-git-worktrees

  Use before starting feature work that shouldn't disturb the current checkout, before executing an implementation plan, or when a long-running task would leave the working tree unusable for anything else. Also use when asked for a worktree, an isolated workspace, or a scratch checkout, and when about

• using-toolkit

  Use at the start of any task — a feature request, a bug, a refactor, a review, a question about the code — to decide which skills apply and in what order. Also use when partway through and the work turns out bigger than it looked, when it reaches an area the original request never named, or when uns

• verification-before-completion

  Use immediately before saying anything is done, fixed, working, passing, ready, or complete — and before committing, opening a PR, marking a task finished, or moving to the next one. Also use when relaying an agent's or tool's success report, and the moment you notice yourself about to write "should

• writing-plans

  Use when an approved design, spec, or set of requirements exists and the work is multi-step — before touching code. Also use when a task is big enough that you would otherwise lose track of it partway, when handing work to another session or agent, and when someone asks for a plan, a breakdown, or a

• writing-prose

  Use when drafting any prose a human will read — a commit message, a PR description, a ticket, a README, a changelog entry, release notes, documentation, a design doc, a code comment, or an email. Also use when text reads as machine-written, when a reviewer says something sounds generic or padded, an

• writing-skills

  Use when creating a skill, editing an existing one, migrating one from another marketplace, or deciding whether something should be a skill at all. Also use when a skill isn't firing when it should, fires when it shouldn't, or gets argued around under pressure.

• writing-tests

  Use when writing a test, adding coverage to code that has none, or deciding what a test should assert. Also use when a bug needs a regression test, when a test is slow, brittle, or passes and fails intermittently, when one small change breaks twenty tests at once, when mocks outnumber assertions, an

Slash commands (3)

• /toolkit:jira-apply

  Create Jira issues from ready ticket drafts — the only thing here that writes to Jira

• /toolkit:jira-capture

  Sweep this session for work worth a ticket and draft the ones that survive the filter

• /toolkit:toolkit

  Run one of Mark's personal skills

Hooks (4)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" skills/using-toolkit/scripts/print-router.sh

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" skills/git-workflow/scripts/git-context.sh

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" skills/git-workflow/scripts/guard-git.sh

• Stop

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" skills/git-workflow/scripts/stop-check.sh

Similar plugins