craft

Plugin craft from marketplace conjurer in conjurer-rich/skills. Commands read from the repo's manifest — today.

Skills (66)

• bff-design

  Decide whether a system needs a backend-for-frontend, how many, and what each one may own: adoption signals and honest costs, one-experience-one-BFF granularity with frontend-team ownership, the shape-don't-decide rule, upstream aggregation with partial-failure and resilience budgets, identity-keyed

• cli-design

  Unix-composable CLI design patterns. Use when building CLI tools, designing command trees, implementing output layers, or testing CLI behavior. Covers stream separation (stdout/stderr), format flags (--json/--plain), exit codes, TTY detection, composability, and error design. Language-agnostic princ

• graph-engineering

  Compose installed agent skills into one orchestrated multi-agent run: an agent graph where each node is a sub-agent that loads exactly one skill, edges carry structured data, and stages fan work out, adversarially verify it, and synthesize one deliverable. Claude Code calls the executable form a dyn

• panel-review

  Composable multi-agent code review of any change boundary — the working tree mid-development, a branch diff, a stacked layer, or a pull request: one orchestrator fans out sub-agents, each loading exactly one installed skill as a review lens (hexagonal-architecture, domain-driven-design, structure-co

• production-parity-skill-builder

  Create an application-specific production parity skill by inspecting an app's docs, source, tests, CI, deployment, infrastructure, config, auth, and environment setup, then asking targeted harness questions only for source-unanswerable decisions. Use when local, CI, PR, preview, staging, or other no

• render-code-shape

  Render the shape of code — module boundaries, the types that cross them, signatures, and a cited call graph — for code that already exists or a change about to be built. Every name, type, and path is read from source and cited, or marked NEW; bodies collapse to one line of intent. Use when asking ho

• api-design

  Stable consumer-facing API and interface design patterns. Use when designing REST endpoints, cross-team boundaries, or any externally consumed or versioned service contract. Covers contract-first development, error semantics (RFC 9457), REST conventions, pagination, idempotency, rate limiting, and b

• bff-entry-points

  Design and protect browser-facing BFF and backend HTTP entry points: an explicit public/protected access classification for every production route, a composition-prepared endpoint registrar that installs session, Origin, Fetch Metadata, CSRF, and content-type policy by construction, provider-free au

• codebase-design

  Design and evaluate deep modules: cohesive responsibility behind a small, stable caller-facing contract, with information hiding, justified seams, explicit effects, dependency strategy, and behavior-focused tests. Use when designing or changing an in-process module or package contract, consolidating

• domain-driven-design

  Domain-Driven Design patterns for TypeScript. Use when implementing ubiquitous language, value objects, entities, aggregates, domain events, domain services, or bounded contexts. Only applies to projects that explicitly use DDD. Do NOT use for simple CRUD or projects without domain modeling.

• evaluate-existing-solutions

  Research and compare established libraries, open-source tools and applications, managed services, and standard, framework, or platform primitives against an explicit bespoke baseline before committing to a material generic mechanism. Use for library/tool recommendations, build-versus-adopt questions

• event-sourcing

  Event sourcing patterns for functional TypeScript — persist state as an append-only log of past events and rebuild it by folding them. Use when implementing a Decider write model, an event store, projections and read models, event versioning, or snapshots. Builds on the Decider from domain-driven-de

• hexagonal-architecture

  Use when the user or project explicitly adopts hexagonal (ports and adapters) architecture — a README, CLAUDE.md, or ADR that says so is the opt-in. Once a project has opted in, load this for every code change in it, not only architecture work — a new feature, a transport or SDK swap, a bug fix, or

• improve-codebase-architecture

  Audit an existing repository or multi-module subsystem for evidence-backed architecture improvements, rank bounded candidates, and present them in a visual HTML report with before-and-after diagrams and a top recommendation. Use when the user asks where architecture investment would pay off across a

• observability

  Observability as an engineering discipline — wide events / canonical log lines, OpenTelemetry instrumentation (traces, metrics, context propagation, sampling, Collector), SLIs/SLOs/error budgets, symptom-based alerting with burn rates, telemetry hygiene, and testing instrumentation as behavior. Use

• secure-oauth-oidc

  Design, implement, audit, test, troubleshoot, or migrate secure OAuth 2.0 and OpenID Connect (OIDC) systems using RFC 9700 / BCP 240. Use for authorization servers and OpenID Providers, OAuth clients and OIDC relying parties, resource servers, native apps, browser-based apps, multi-issuer login, red

• structure-codebase

  Design, audit, and evolve physical source and package structures that expose real architectural boundaries while keeping related behavior together. Use when creating or reviewing repository trees, deciding where files or packages belong, reducing flat folders, organizing by feature, route, screen, u

• twelve-factor

  Twelve-Factor App patterns for software-as-a-service and long-running process applications. Use when configuring deploy-time environment, backing services, process startup/shutdown, or operational parity. Apply individual principles to frontends, serverless functions, and CLIs only where their runti

• acceptance-review

  WHEN deciding whether a PR, branch, diff, or current implementation satisfies an authoritative issue, specification, or decision contract; NOT for improving the written artifact, reconstructing meetings, general code review, or implementing fixes. Returns a read-only criterion-by-criterion proof and

• ask

  Ask which craft skill, agent, command or flow fits your situation, including shelved skills worth promoting. A router over everything in craft. User-invoked.

• browser-ux-walkthrough

  Walk a changed UI surface in a real browser against a project's own doctrine checklist, grade the checklist sections the change can affect, in both themes when styles or tokens changed, fix findings, and produce a findings table with screenshots for a PR body. Use when a PR or diff touches user-faci

• continue

  Continue after a merged independent PR, or advance and sync a dependent PR stack. Sets up the next branch and updates the plan; writes no code. User-invoked.

• delegate

  Keep delegating under /loop (watch delegated PRs, then pick and work the next issue), or work a labelled GitHub issue to a reviewable PR, pick the next one, address review comments, watch delegated PRs, or land a PR marked ready

• delegating-github-issues

  Take a triaged GitHub issue end-to-end to a reviewable pull request in an isolated worktree, then address review comments on request. With the land parameter on, also review, simplify and merge one the human marked Ready for review. Use when a project command such as /delegate asks to pick up an iss

• double-check

  Get a rigorous read-only second opinion on finished work through the host's available reviewer capabilities, preferably from a different model provider. Falls back to a fresh same-provider agent only when necessary and labels the reduced independence. Every review includes a mandatory scope-fidelity

• find-gaps

  Adversarially review an existing written artifact — stories, plans, acceptance criteria, specs, or design mocks — to surface missing states, unhandled edge cases, unstated assumptions, unverifiable criteria, and slices still too broad or horizontal. Works interactively, one question at a time, writi

• grill-me

  A relentless interview to sharpen a plan or design, with nothing written down. User-invoked.

• grill-with-docs

  A relentless interview to sharpen a plan or design that records the language and decisions it settles in the repository as it goes. User-invoked.

• grilling

  Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

• plan

  Create a vertical-slice or selected reduction plan in the repository's planning workflow, with no code changes. User-invoked; run it with the feature or work to plan.

• planning

  Planning work as vertical slices or an explicitly selected mechanism-reduction program in small, known-good increments, with independent pull requests or an optional stacked-PR topology across one or more ordered slices. Use when starting significant work, turning already-split stories into implemen

• retro

  Run a retrospective on a coding session and propose changes to the agent's environment, not the code — navigation pointers, automated checks, coding standards, steering files, tooling, information access, and craft skills the session should have used but did not. User-invoked; run it in the session

• review

  Review a branch, pull request or work in progress against a fixed point on two separate axes — Standards (does the diff follow the repository's written standards and the craft skills that apply to it?) and Spec (does it do what the originating issue or spec asked, no more and no less?). Use when rev

• specification

  Turn fuzzy intent into shared understanding and acceptance criteria — specification as a conversation, run one question at a time, before any story is split or planned. Use when an idea, feature request, or problem statement has no agreed rules or examples yet ("let's spec this out", "what should th

• stack-pull-requests

  Decide whether planned vertical implementation work should ship as independent pull requests or as a stack of small ordered pull requests, then plan, build, review, update, and merge the stack safely. Use when one slice is too large for effective review, when later slices should proceed on the same

• story-splitting

  Turn broad requirements, large stories, epics, features, initiatives, or backlog items into small end-to-end child stories without turning them into technical component tasks. Use when refining a backlog, decomposing epics, planning an MVP or walking skeleton, looking for vertical slices, reducing s

• storyboard

  Produce a mock-audit storyboard — a single HTML page embedding related UX surfaces side-by-side, with per-mock audit checklists, a flow diagram, and gap cards for missing mocks. Use when reviewing several mocks together would materially reduce context-switching or expose cross-surface gaps, or when

• folder-structure

  Deprecated compatibility alias for structure-codebase. Activate only for the exact legacy name folder-structure or an explicit $folder-structure invocation. Contains no independent architecture guidance and must delegate to the canonical sibling skill.

• characterisation-tests

  Use when modifying existing code that lacks tests and you need to document its actual current behavior before making changes -- the legacy code dilemma where you need tests to refactor safely but the code was not written for testability. Specifically for understanding and pinning down what code curr

• ci-debugging

  Systematic CI/CD failure diagnosis using hypothesis-first investigation, local reproduction, and environment delta analysis. Use when a CI pipeline, GitHub Actions workflow, or build job fails; when tests pass locally but fail in CI; when diagnosing flaky tests, timeouts, or red pipelines; or when t

• debugging

  WHEN diagnosing a reproducible or observable software failure outside a CI-pipeline-specific workflow; NOT for speculative cleanup, general code review, or speculative behavior changes presented as fixes. Preserves evidence, tests one causal hypothesis at a time, and fixes the owning boundary only w

• engineering-practice

  Core engineering practice for any coding task — TDD is non-negotiable for behaviour change, behaviour-driven testing, TypeScript strict, immutable data and pure logic, small increments with the mutation gate at PR readiness — plus the routing table that says which craft skill to load for which kind

• finding-seams

  Use when existing code has untestable dependencies that prevent writing tests -- direct construction of collaborators, static or global function calls, tight coupling to external systems, or singleton access patterns. Specifically for identifying substitution points (seams) that make legacy or tight

• front-end-testing

  Behavior-driven UI testing patterns across Vitest Browser Mode, Playwright E2E evidence boundaries, and DOM Testing Library. Use when testing any front-end application, writing UI or end-to-end tests, querying DOM elements, simulating user interactions, or choosing the lightest harness that proves a

• functional

  Functional programming patterns with immutable data. Use when writing logic, data transformations, or encountering mutation bugs — including any feature request that builds, merges, filters, sorts, prices or otherwise reshapes records, lists, carts, orders or invoices, even when it never mentions im

• mutation-testing

  Set up and run mutation testing with Stryker, including full-project and focused diff runs against the current review base, then use surviving mutants to strengthen weak or missing tests. Use as the end-of-phase PR-readiness gate after implementation and refactoring are complete, not inside each RED

• python

  Use for any code change in a Python codebase (a pyproject.toml, .py files) — adding an endpoint, route, handler, setting, export or feature, fixing a bug, reviewing or refactoring, adding a module, script, CLI or service, changing pyproject.toml, or writing pytest tests — even when the request never

• react-performance

  Make React and Next.js performance changes that are measured, evidence-backed, and behaviorally safe. Routes to the right rule catalogue — vercel-react-best-practices for the 72 prioritized React/Next rules, vercel-composition-patterns for component API shape, next-best-practices for App Router sema

• react-testing

  React component testing patterns including components, hooks, context, and forms. Covers Vitest Browser Mode with vitest-browser-react and @testing-library/react. Use when testing React applications. For general UI testing patterns, see the front-end-testing skill.

• reduce-system-complexity

  Reduce total mechanism in a selected existing system or behavior path while conserving its agreed observable behavior and non-functional guarantees. Use when the user explicitly wants fewer branches, states, dependencies, layers, flags, retries, jobs, adapters, or operational moving parts and needs

• refactor-scan

  Use to assess bounded refactoring opportunities after GREEN or another passing proportionate preservation baseline. Invoke when that baseline is established or when weighing whether an abstraction adds value. Mutation testing verifies the accumulated result later at the end-of-phase PR-readiness gat

• refactoring

  Refactoring assessment and behavior-preserving patterns for code with a passing baseline and proportionate preservation evidence. Use when the user asks to clean up, tidy, simplify, restructure, deduplicate, collapse, or merge look-alike code in a selected area, or after GREEN establishes the passin

• tdd-guardian

  Use to verify TDD process compliance for new or changed observable behavior during fast RED-GREEN-REFACTOR increments and the separate end-of-phase mutation gate. Invoke when users plan to implement behavior, when checking that behavior tests preceded implementation, before committing behavior-chang

• tdd

  RED-GREEN-REFACTOR for production behavior changes, followed by mutation testing or alternate evidence once at the end-of-phase PR-readiness gate. Use before implementing new features, bug fixes, or any changed observable behavior, and as the governing workflow for mixed implementation work. Load it

• test-design-reviewer

  Review test quality using Dave Farley's eight properties of good tests. Use when assessing a test file or suite for understandability, maintainability, repeatability, atomicity, necessity, granularity, speed, and evidence of test-first development.

• testing

  Testing patterns for behavior-driven tests. Use when writing tests, creating test factories, structuring test files, or deciding what to test. Do NOT use for UI-specific testing (see front-end-testing or react-testing skills).

• typescript-strict

  TypeScript strict mode patterns including schema-first development, branded types, type vs interface guidance, and tsconfig strict flags. Use when writing TypeScript code, defining types or schemas, or reviewing type safety. For immutability and pure function patterns, see the functional skill.

• xstate

  Model front-end and workflow logic as XState v5 statecharts and actors — when finite states earn their place (and when @xstate/store or a discriminated union is honest), event-first machine design, guards/actions/delays, invoke vs spawn, app-level actor systems, persistence, @xstate/react integratio

• diagrams

  Create or audit maintainable diagrams when relationships, sequence, state, hierarchy, or quantitative comparisons are materially clearer visually than in prose. Selects a format the destination actually renders, preserves source authority, validates output, and includes an accessible text explanatio

• expectations

  Decide where a learning, gotcha, or decision should live so it is not lost, and capture it there while context is fresh. Use when the user says they just discovered, learned, or found out something non-obvious, asks where a fact should be recorded, written down, or go, wants a setup gotcha, workarou

• find-skills

  Discover and, with authorization, install agent skills from the open skills ecosystem. Use when the user explicitly asks to find or install a skill from the external skills ecosystem, asks whether an installable agent skill exists for a task, or wants to extend agent capabilities through skills.sh o

• teach

  Teach the user a new skill or concept, within this workspace.

• technical-writing

  Writing developer-facing prose that can be skimmed first and trusted enough to finish — READMEs, guides, tutorials, reference docs, proposals, PR descriptions, release notes. Load before drafting, rewriting, restructuring, or editing technical documents, when a doc reads as a wall of text, claims ne

• ubiquitous-language

  One ubiquitous language per bounded context, with a repository-declared glossary as the naming authority and explicit decisions for language changes. Covers the five-step language protocol (detect, propose, decide, record, rename), optional glossary-driven lint ratchets, and safe context-wide rename

• writing-for-agents

  Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.

• wtf

  Re-explain the immediately previous LLM response when it did not land, using plain, precise UK English.

Subagents (7)

• adr

  Use this agent proactively when making significant architectural decisions and reactively to document architectural choices after they're made. Invoke when evaluating technology options, making foundational decisions, or discovering undocumented architectural choices.

• delegate-implementer

  The delegating-github-issues implementer. Dispatched by the delegator to write code, tests and fixes in one delegated worktree, to merge the default branch into it, or to simplify a diff before Land. Not for review or for steps whose brief names every command.

• delegate-mechanical

  The delegating-github-issues mechanical step. Dispatched by the delegator to run the exact commands a brief names: bootstrap a worktree, push evidence, ship a commit, clean up, or post a comment or label. No judgement, no code changes.

• delegate-reviewer

  The delegating-github-issues independent check. Dispatched by the delegator to review a staged diff or a conflict resolution in a delegated worktree (the process, acceptance and whole-diff checks, and Sync's resolution check) and write a findings report. It has no edit tool and keeps write only for

• delegate-walkthrough

  The delegating-github-issues walkthrough. Dispatched by the delegator to boot the project's stack, drive a browser through shell commands, grade the changed UI surfaces and save screenshots. It reports findings and never fixes them.

• learn

  Use this agent when completed work reveals a durable, non-obvious constraint or practice that may need to be captured. It routes each learning to its actual owner rather than putting every insight in CLAUDE.md.

• twelve-factor-audit

  Read-only audit of an existing deployable service against the applicable Twelve-Factor principles. Use for deployment-readiness or infrastructure reviews; do not apply the method wholesale to libraries, CLIs, desktop apps, or embedded software.

Hooks (1)

• Stop

  "${CLAUDE_PLUGIN_ROOT}/hooks/stop-hook-git-check.sh"

Similar plugins