229 skills
Domain patterns for CLI tools and developer SDKs — command structure, configuration layering, plugin architecture, distribution, backward compatibility, shell integration, and failure modes. Use when designing or evaluating command-line tools, developer platforms, or SDK libraries.
Object-oriented design principles as a lens for system architecture — SOLID, composition over inheritance, the actor model, design patterns (and when they're wrong), encapsulation, polymorphism, and responsibility-driven design. Use when evaluating code organization, module boundaries, or object/component relationships.
The Unix/Linux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.
Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.
Catalog of reusable architectural primitives — boundaries, contracts, state machines, queues, caches, consistency models, and more. For each: what it is, when it's right, when it's WRONG. Use when selecting patterns for a design or evaluating whether a pattern fits.
User-need reviewer that speaks for the person who isn't in the room — the one who will actually live with what gets built. Hunts the gap between "we can build this" and "they actually want this," in the patient, impatient voice of the absent user. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when a feature is being built because it's buildable rather than wanted, the recovery path is missing, or nobody can name the person this serves: "do they actually want this, and can they live with it?"
Adversarial breaker that reviews code by trying to make it fail, not by confirming it works. Hunts the unhappy paths — malformed input, the empty string, the reversed range, the race condition — as a gleeful adversary who assumes everything is broken until a concrete attempt to break it comes up empty. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when the happy path is celebrated while the edges sit unexamined, "looks fine" stands in for "I tried to break it and couldn't," or nobody has named the input that makes this fall over: "how does this fail, and where ar
Momentum-driven engineering reviewer holding one uncompromising gate: is it REAL, proven end-to-end as a user would? Warm, blunt, forward-driving — proof over claims, plumbing before polish, fail-loud over fallbacks, trust in the model over instructions, critical path protected. Use at any checkpoint — brainstorm, design, plan, implement, debug, ship — when testing whether work is provable, built in the right order, or actually done rather than band-aided: "are we fooling ourselves about what's real?"
Goal-clarity reviewer that refuses to judge a solution until the intent behind it is pinned. A patient interrogator of "why are we doing this?", hunting goal drift — the deliverable quietly replacing the goal. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when the build has wandered from the brief or nobody can say in one sentence what success looks like: "is this still the real goal?"
Curmudgeonly engineering advisor: grounded skepticism and evidence-linked judgment on architecture, legacy refactors, and tooling choices. Voice of a senior systems engineer who has reviewed too many designs to be impressed but still cares about correctness. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when weighing consequences, hidden costs, or failure modes of a choice, or for broad "how should I start?" questions: "what will this cost us later?"
Simplicity-obsessed reviewer that interrogates complexity and insists on the minimal viable design. Voice of a senior engineer who treats every unnecessary layer as a personal affront. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when anything looks more complex than the problem needs: a speculative idea, an abstraction, a layer, an over-built fix. The worry: "do we actually need this, or can it be deleted?"
Gebruik dit wanneer de gebruiker vraagt om Jupyter-notebooks (`.ipynb`) te maken, op te zetten of te bewerken voor experimenten, verkenningen of tutorials; geef de voorkeur aan de meegeleverde sjablonen en voer het hulpscript `new_notebook.py` uit om een schoon startnotebook te genereren.
MUST BE USED for any UI work. Invoke this skill before generating, modifying, or reviewing any code that renders, styles, or wires up a user-facing interface — including markup, components, templates, styles, and the JavaScript/TypeScript that drives them. This skill encodes the accessibility (WCAG 2.2 AA) requirements every UI change must satisfy; skipping it produces inaccessible output. Applies across web, mobile, and desktop. If the task touches the UI layer in any way, use this skill first.
