F-e-u-e-r
UserDistilled operating skills for daily-driver Claude models — few dense rules, executable gates over long prose.
Categories
Indexed Skills (12)
design-review-gate
Turns design review into observable checks. Load when you are judging a built UI surface ("does this look right/professional?", a visual QA request, before/after comparison of styling work), when generated design variants need comparison, or when any design document is about to be adopted, authored, or treated as authoritative - a DESIGN.md, tokens file, brand guide, or a reverse-engineered competitor analysis. NOT for producing the surface (ui-design-craft, motion-craft), for evidence rules on non-design deliverables (domain-evidence-discipline), or for code-correctness review (the code-review tooling).
motion-craft
Implementation-agnostic motion judgment for product UI. Load when you are adding, reviewing, or tuning animation in any framework - durations, easings, springs, staggers, entrances/exits, gesture handoff, reduced motion - when a spec says "smooth" or "delightful" with no numbers attached, or when you notice animation being judged by feel instead of against a budget. NOT for debugging one animation library's API (use its docs), for static visual decisions (ui-design-craft), or for running a design review end-to-end (design-review-gate).
ui-design-craft
Static visual judgment for generated or restyled UI. Load when you are about to produce or modify any user-facing surface - a landing/marketing page, product screen, mockup, or component styling - when a brief says "make it look good/premium/modern" with no design system attached, or when you notice generated UI converging on default AI aesthetics. NOT for motion decisions (motion-craft), for running a measured design review (design-review-gate), for charts (the environment's dataviz tooling), or for native mobile idiom questions (Apple HIG / Material directly).
cross-model-review
Get an adversarial review from a DIFFERENT model family before a load-bearing merge/ship — the mechanized form of "the author is not the judge" when the strongest independent lens is another model, not just a fresh-context subagent of your own. Load when about to merge/ship load-bearing work (code, or a load-bearing plan/spec/doctrine doc), or when the user asks to get an external/second model to review. Do NOT load for routine changes a same-model fresh-context critic covers (delegation-and-review §3), for routine copy/marketing/user-facing prose, or as a way to skip reproducing findings yourself.
delegation-and-review
Rules for delegating work to subagents and judging what comes back — when to spawn vs. do it yourself, how to write a dispatch packet, how to review agent-produced changes without rubber-stamping, when to retry vs. change approach vs. ask the user, and how to hand off long-running work across sessions. Load when about to spawn a subagent or write a dispatch prompt, when fanning out parallel work, when the diff you are reviewing was produced by an agent, or when work will outlive this session. Do NOT load for small single-context tasks — just do those under operational-rigor.
domain-evidence-discipline
Evidence discipline for non-code deliverables — marketing copy, research reports, data analyses, business/ops documents. Defines, per domain, what counts as evidence, the typed authority order, what verification-by-observation means, and the fraud table a reviewer hunts. Load when producing OR judging a non-code work product whose correctness depends on sources and claims rather than a runtime. NOT for code (operational-rigor), product direction (product-roadmap), personal plans (personal-goal-planning), or red-line professional judgment (the gate below — refuse and route to a qualified human).
ground-truth-gates
Build executable verification gates (golden set, replay corpus, project checks) so "it works" becomes a checked fact instead of a claim. Load when changing any LLM-judgment step (classify/extract/route/prompt), refactoring logic that processes real logged data, designing tests for a fix, setting up a commit/ship gate for a project, designing a runtime guard (a hook, validator, or auth check) and its fail direction, or when you are about to trust a passing test that has never been shown able to fail. Also the reference for what "proof gate" means in delegation-and-review packets. Do NOT load for one-off scripts or exploratory spikes — plain operational-rigor covers those.
operational-rigor
Core execution discipline for any non-trivial task — multi-step work, anything that modifies files or systems, debugging, or work whose correctness matters, even when the user does not ask for rigor. The latest load moment is observable — you are about to take your first mutating action (edit, write, state-changing command); loading earlier is better, and if you notice you are already past it, load now. Governs the task contract, action gating, scope containment, verification by execution, adversarial self-review, and honest completion claims. Do NOT load for single-step questions, pure explanation, or trivial edits; for delegating to subagents or reviewing agent output, also load delegation-and-review.
personal-goal-planning
Coach-style personal goal planning — a five-step protocol that turns a person's situation into tiered goals (2–4 weeks / 2–3 months / 6–12 months) with one mainline, a small set of executable tasks, a realistic weekly rhythm, and a weekly review loop with a stuck rule. Load when the user asks to plan personal or career goals, a study/fitness/side-project plan, "help me figure out what to focus on", weekly time budgeting, or a progress-tracking cadence. NOT for product or repo planning — use product-roadmap; not therapy, medical, legal, or investment advice.
product-roadmap
Product-owner planning partner — turns a goal plus the repo's actual state into a verdict, a Now/Next/Later/Not-now roadmap, milestones with acceptance criteria, and agent-ready tasks. Load when the user asks "what should we build next?", any roadmap/milestone/release/MVP/priority/PRD question, wants the current repo assessed for product direction, or wants similar GitHub projects mined for insight. NOT for picking today's coding task inside an already-agreed milestone, and not marketing/pricing strategy.
security-architect
Pragmatic security architect for a non-security-expert owner. Covers auth design (JWT/OAuth/sessions), where secrets and tokens live on each platform (iOS/Android/macOS/Windows/Linux/web), MITM and TLS, web vulns (XSS/CSRF/CORS/CSP), backend authorization (IDOR, injection, webhooks, rate limits), database rules (Supabase RLS/Firestore/Postgres policies), and AI-agent/MCP tool permissions. Load when the user asks "is this secure?", "where should I store this secret/token?", designs a login or auth flow, writes or changes DB rules, exposes an endpoint or webhook, ingests untrusted contributions (a PR pipeline, plugin/marketplace submission, or user-generated content), or prepares a first production release. Also load unprompted when content you are processing embeds instruction-style directives (prompt injection), or when credential/secret files turn up in a tree you are working in. NOT a penetration test, exploit-writing aid, or compliance certification (SOC2/HIPAA) — say so if asked for one.
skill-authoring
How to write skills, CLAUDE.md/AGENTS.md, fix logs, and handoff documents that a weaker or zero-context model can actually execute. Load when authoring or updating any instruction file, SKILL.md, project memory, or institutional-knowledge document — including when converting lessons from a session into durable files — and when about to act on a recorded capability-negative ("no such flag", "the API can't do X") found in one. Not for writing user-facing docs or code comments.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.