muzalee
UserClaude Code plugin marketplace — atelier (design → build → review pipeline + writing craft) and atelier-typescript (Fastify skills)
Categories
Indexed Skills (26)
backend-build
Implement the backend from the design file's `## Architecture` section — set up plugins, database, routes, tests, and wire everything into the server entry. Biased toward Fastify + Node. Use when user says "build the backend", "implement the server", "code the API from the brief", or after running /backend-design.
backend-design
Design the server side of a feature through interview and codebase scan — data model, API surface, auth, invariants, failure modes. Fastify-biased, any stack. Fills `## Architecture` in the feature's `.design/YYYY-MM-DD-<slug>.md`. Use when the user wants to plan a backend, design an API or data model, or mentions a "backend brief".
brief-to-tasks
Break a design into an ordered checklist of independently buildable tasks using vertical slices. Fills the `## Tasks` section of the feature's `.design/YYYY-MM-DD-<slug>.md`. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".
build
Explicit-invocation-only orchestrator that implements a completed `.design/YYYY-MM-DD-<slug>.md` — frontend, then backend — with a go/no-go between phases unless told "go all". Decisions were made in `/design`; this executes them. Use ONLY on /build or an explicit "build from the design", "implement the design", or "run the build pipeline". DO NOT auto-trigger from talk about writing frontend or backend code — those have their own skills. With no design file it asks whether to build directly, or `/design` first.
code-review
Technical code review for correctness, security, tests, error handling, and style. Findings are printed with `CR-n` ids; nothing is written to the repo. Distinct from design-review (which is visual/aesthetic). Use when user says "review this code", "check my PR", "code review", "check for issues", or after implementing a feature.
design-brief
Create a design brief through an interactive interview, codebase exploration, and experience design decisions. Fills the `## Problem`, `## Solution`, `## Scope` and `## Experience` sections of the feature's `.design/YYYY-MM-DD-<slug>.md`. Use when user wants to write a design brief, plan a new feature or page, define a UI direction, or mentions "brief".
design-review
Run a structured design critique against the design file and codebase. Checks visual hierarchy, consistency, responsiveness, accessibility, and aesthetic fidelity. Findings are printed with `DR-n` ids; nothing is written to the repo. Use when user wants a design review, critique, QA pass, polish pass, or mentions "review" after building.
design-tokens
Produce a design token spec — color (light + dark), spacing, type, layout, motion, breakpoints — derived from a named aesthetic philosophy. Fills `### Tokens` under `## Experience` in the feature's `.design/YYYY-MM-DD-<slug>.md` — names, values, roles, never a CSS or Tailwind file. Use when establishing a visual system, setting up tokens, or the user mentions "tokens" or "design system".
design
Explicit-invocation-only orchestrator for the pure-design pipeline — grill → brief → backend-design → IA → tokens → test-plan → tasks, gated between phases — filling one file, `.design/YYYY-MM-DD-<slug>.md`, in short or full form. Writes no code. Invoke as `/atelier:design`; a bare `/design` can hit the built-in design canvas or `ui-ux-pro-max:design`. Use ONLY on /atelier:design, /design, or "run the design pipeline". DO NOT auto-trigger from talk about briefs, IA, tokens, tests or tasks — those have their own skills.
fastify-route
Scaffold a new Fastify route (or set of routes) that matches the existing project's conventions — plugin structure, schema strategy (JSON Schema / TypeBox / Zod), auth, error shape, and tests. Use when user wants to add an endpoint, add a route, expose an API, or mentions "new route" / "add endpoint" in a Fastify project.
frontend-design
Build distinctive, production-grade frontend interfaces with high design quality, guided by named aesthetic philosophies. Use when building components, pages, or applications. Generates working code with exceptional attention to aesthetic details and creative choices that avoid generic AI output.
information-architecture
Define the structural layer of a product or site before visual design begins. Covers navigation, content hierarchy, page structure, URL patterns, and user flows. Fills the `## Structure` section of the feature's `.design/YYYY-MM-DD-<slug>.md`. Use when user wants to plan site structure, define navigation, map user flows, organize content, or mentions "IA" or "information architecture".
keep-it-simple
House rules for everything written — conventional commits and matching branch names (respecting `.commitlintrc`), PR titles and bodies, code comments (none by default, never historical, a low ratio), and docs. Short, why-focused, no Claude trailers. Use on any git commit, `gh pr create` or `git checkout -b`, and whenever writing or reviewing code comments, docstrings, or README/docs.
project-bootstrap
Scaffold a new project from scratch — folder, .gitignore, README, LICENSE, git init + first commit, and (if gh is authed) create the GitHub repo with description, topics, and visibility. Use when user says "start a new project", "bootstrap", "new repo", "scaffold X", or asks to set up a fresh codebase.
review
Explicit-invocation-only orchestrator that runs code review, security review and design review of the built code, measured against `.design/YYYY-MM-DD-<slug>.md` when one exists. Prints findings with ids; writes nothing. Use ONLY on /review or an explicit "run the review pipeline" / "review the build". For one technical review use `code-review`; for one visual review, `design-review`. DO NOT auto-trigger from adjacent talk about reviewing code.
test-plan
Write a short test plan before implementing — the cases that must pass, the level each lives at (unit / integration / e2e), what to break to prove them, and what NOT to test. Fills `## Tests` in the feature's `.design/YYYY-MM-DD-<slug>.md` when one exists, otherwise prints inline. Use before non-trivial work, when asked for a "test plan", or to sanity-check a PR's coverage.
bootstrap
Scaffold a new project from scratch — folder, stack starter, the right folder structure for that stack, CLAUDE.md, `.claude/rules/`, .gitignore, README, LICENSE, git init + first commit, and (if gh is authed) the GitHub repo with description, topics, and visibility. Use when the user says "start a new project", "bootstrap", "new repo", "scaffold X", or asks to set up a fresh codebase.
prd
Write or amend a PRD — the scope contract covering problem, users, requirements, metrics, non-goals, milestones, dependencies — as a numbered file in `docs/prd/`. Use when the user mentions a PRD, product spec, requirements or project scope, or wants in/out of scope pinned before design, even without saying "PRD". Also to amend one when requirements change — something cut or added, a change of plan, a late constraint.
preflight
Check a plan against the actual repo before it is built and drive it to buildable — verify every file, symbol, dependency and command it names; fix what has one right answer, ask about the rest. Use when a plan, task list, PRD or design doc might be stale or might not run ("check this plan", "sanity check before I build"), or when handed a plan from an earlier session.
ship
Explicit-invocation-only orchestrator that takes a completed `.design/YYYY-MM-DD-<slug>.md` to a review-ready PR, unattended — branch off main, draft PR, build per phase, browser-test, warm review, fix, cold review of the whole PR in a fresh session, fix, flip to ready. Use ONLY on /ship or an explicit "ship this", "run the ship pipeline", or "build and open a PR unattended". DO NOT auto-trigger from talk about branches, PRs, building or reviewing — those have their own skills.
ui-build
Build a feature's frontend from its `.design/YYYY-MM-DD-<slug>.md` — `## Tasks` against `## Experience`, `## Structure` and the tokens — guided by a named aesthetic philosophy, never generic AI styling. The frontend phase of `/atelier:build`. Use when implementing UI from an atelier design file, or building components, pages or screens in a project that has one.
flutter-conventions
House conventions for Flutter and Dart — project structure, layering, state boundaries, widget composition, testing. Use when writing, refactoring or reviewing Flutter or Dart code, scaffolding a Flutter app, deciding where a repository, ViewModel, model or widget belongs, and whenever `/build` or `/bootstrap` works in a Flutter repo.
typescript-conventions
House conventions for TypeScript — type discipline, module shape, async, validation boundaries — with React and Fastify specifics in reference files. Use when writing, refactoring or reviewing TypeScript, TSX, React components, or Fastify routes and plugins, including every `/build` task in a TS repo; also for type vs interface, memoization, or where validation belongs.
errors
Design errors that self-explain — stable code, internal and user messages, public ref code, cause chain, retryable flag, HTTP status. Use when adding an error type, fixing or reviewing error handling, deciding throw vs return vs wrap, or writing an API route — also in scripts, jobs, queue workers, CLIs, batch loops, and when maintaining a ref-code registry. YAGNI — no taxonomy for one endpoint.
logging
Emit structured logs that tell a story — who, where, what, how it ended — so you can debug without rerunning. Every entry carries trace-id, identity anchor, operation, specific message; errors carry their cause chain; no secrets or PII. Use when adding a log line, setting up a logger, carrying a trace across a queue, reviewing observability, or cutting duplicate and noisy logs.
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.