muzalee
UserA workshop of personal Claude Code skills — design, build, and writing craft
Categories
Indexed Skills (17)
backend-build
Implement the backend from a BACKEND_DESIGN.md brief — 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
Create a backend design brief through an interactive interview, codebase exploration, and decisions about data model, auth, scale, consistency, deployment, and observability. Biased toward Fastify (Node) but works for any backend stack. Saved as a markdown file in the project. Use when user wants to plan a backend, design an API, define a data model, mention "backend brief", or pair with a frontend design brief.
brief-to-tasks
Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. 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 reads a completed `.design/<slug>/` folder and implements the code — frontend + backend — with confirmation gates between phases. Invoked ONLY when the user types /build or explicitly asks to "build from the design", "implement the design", "code the feature from the brief", or "run the build pipeline". DO NOT auto-trigger from adjacent talk about writing frontend or backend code — those have their own skills. Requires a `.design/<slug>/` folder from a prior `/design` run.
code-review
Technical code review for correctness, security, tests, error handling, and style. 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. Saved as a markdown file in the project. 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 brief and codebase. Checks visual hierarchy, consistency, responsiveness, accessibility, and aesthetic fidelity. Use when user wants a design review, critique, QA pass, polish pass, or mentions "review" after building.
design-tokens
Produce a `DESIGN_TOKENS.md` spec — colors (light + dark), spacing, typography, layout, motion, breakpoints — derived from a chosen aesthetic philosophy. Output is a markdown document (name / value / semantic role) saved to `.design/<slug>/`, NOT an actual CSS or Tailwind config file. Materialization into the project's real token file happens later in `/build` (or when `frontend-design` runs standalone). Use when starting a new project, establishing a visual system, setting up tokens, or the user mentions "tokens" or "design system".
design
Explicit-invocation-only orchestrator that runs the pure-design phase end-to-end — grill → brief → backend-design → IA → tokens → tasks — with confirmation gates between every phase. Every output is a markdown doc saved to `.design/<slug>/`. NO CODE is written in this skill. Invoked ONLY when the user types /design or explicitly asks to "run the design pipeline" / "run the design orchestrator". After this, the user runs `/build` to implement and `/review` to check the result. DO NOT auto-trigger from adjacent talk about briefs, IA, tokens, tasks, or building — 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. Use when user wants to plan site structure, define navigation, map user flows, organize content, or mentions "IA" or "information architecture".
keep-it-simple
Apply to all written output — commit messages, PR descriptions, code comments, documentation, and explanations. Keep it short, no over-explaining, no filler. Never add "Co-Authored-By Claude" trailer on commits. Trigger on any writing task, especially git commit, PR create, adding comments/docstrings, or writing 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 + design review against the built code, using `.design/<slug>/` as the source of intent. Invoked ONLY when the user types /review or explicitly asks to "run the review pipeline", "review the build", or "check the feature". For a single technical review only, use `code-review` directly. For a single visual review only, use `design-review` directly. DO NOT auto-trigger from adjacent talk about reviewing code — those have their own skills.
test-plan
Write a short test plan for a change before implementing — list the cases that must pass, what to break to prove them, and what NOT to test. Use before starting non-trivial work, when asked for a "test plan", or when reviewing a PR to sanity-check coverage.
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.