jeffreytse/grimoire-hub - Page 4

apply-text-alternatives

Use when adding images, icons, SVGs, canvas elements, or any non-text content to a page — to ensure users who cannot see the content receive an equivalent text description.

apply-timed-content-controls

Use when building carousels, auto-advancing slideshows, session management, or any content that moves, blinks, or updates automatically — to ensure users can pause, stop, or extend time-sensitive content.

design-accessibility-standards

Use when auditing or designing UI components to meet WCAG 2.2, Section 508, or ARIA accessibility requirements

design-form-layout

Use when designing data-entry forms — to arrange fields, labels, and actions so users complete them faster and with fewer errors, independent of accessibility requirements.

design-onboarding-flow

Use when designing or redesigning a user onboarding flow for a SaaS or digital product where activation rate, time-to-value, or early churn are problems.

prevent-dark-patterns

Use when reviewing or designing e-commerce flows, subscription sign-ups, cookie consent banners, settings pages, and cancellation flows — to identify and remove deceptive UX patterns that manipulate users against their own interests.

apply-interleaving

Use when designing practice schedules that mix different problem types or topics to improve discrimination and long-term retention

apply-deliberate-practice

Use when designing a practice regimen to build expert performance in any skill domain — to structure sessions around specific weaknesses, immediate feedback, and focused repetition at the edge of current ability rather than comfortable repetitive performance.

design-differentiated-instruction-plan

Use when planning lessons or units that must accommodate learners with diverse readiness levels, learning profiles, or interests within the same classroom or group

apply-evaluation-driven-development

Use when building or iterating on an LLM feature, prompt, or agentic system — to measure improvement objectively rather than speculating about what the model needs.

design-agentic-workflow

Use when building or prompting a multi-step agentic system — to structure execution so the agent plans before acting, creates verifiable checkpoints, and avoids irreversible mistakes.

design-ml-pipeline

Use when building or refactoring machine learning systems that need to move from experimentation to reliable production deployment

design-rag-pipeline

Use when designing a retrieval-augmented generation (RAG) pipeline for grounding LLM outputs in external knowledge

design-rag-system

Use when building LLM applications that need to answer questions about proprietary, recent, or domain-specific knowledge that is not in the model's training data

apply-abstract-factory-pattern

Use when a system must create families of related objects and must remain independent of how those objects are created — so that swapping one product family for another requires no changes to client code.

apply-adapter-pattern

Use when you need to use an existing class but its interface is incompatible with what your code expects — converting one interface into another without modifying either.

apply-bridge-pattern

Use when you need to vary both an abstraction and its implementation independently — avoiding an exponential class hierarchy that results from combining them through inheritance.

apply-builder-pattern

Use when constructing a complex object requires many steps or parameters — especially when the same construction process should produce different representations, or when telescoping constructors become unreadable.

apply-chain-of-responsibility-pattern

Use when more than one object may handle a request and the handler isn't known a priori — letting you pass the request along a chain of handlers until one handles it, without coupling the sender to any specific handler.

apply-command-pattern

Use when you need to parameterize objects with operations, queue or log requests, support undoable operations, or implement transactional behavior — by encapsulating each request as an object with a uniform execute interface.

apply-composite-pattern

Use when you need to represent part-whole hierarchies of objects and want clients to treat individual objects and compositions of objects uniformly — without special-casing leaf vs. container nodes.

apply-decorator-pattern

Use when you need to add responsibilities to individual objects dynamically — without modifying the class and without the combinatorial explosion that results from subclassing every combination of features.

apply-facade-pattern

Use when you want to provide a simple, unified interface to a complex subsystem — reducing the number of objects clients must interact with and lowering the coupling between client code and subsystem internals.

apply-factory-method-pattern

Use when a class must create objects but should not be responsible for deciding which concrete class to instantiate — letting subclasses or configuration determine the type at runtime.

apply-flyweight-pattern

Use when an application creates a very large number of fine-grained objects whose combined memory cost is prohibitive — by sharing the intrinsic (immutable) state across instances and storing only extrinsic (context-specific) state outside.

apply-interpreter-pattern

Use when you need to interpret sentences in a simple language — defining a grammar as a class hierarchy where each rule is a class and interpreting an expression is traversing that hierarchy.

apply-iterator-pattern

Use when you need to access elements of a collection sequentially without exposing its underlying representation — decoupling traversal logic from the collection's data structure.

apply-mediator-pattern

Use when many objects communicate with each other in complex, tangled ways — centralizing all interaction in a mediator object so that components only talk to the mediator, not to each other.

apply-memento-pattern

Use when you need to capture and restore an object's internal state — for undo/redo, rollback, or snapshot functionality — without exposing or violating the object's encapsulation.

apply-observer-pattern

Use when a change in one object must automatically notify and update an open-ended set of dependent objects — without the subject knowing which specific objects depend on it.

apply-prototype-pattern

Use when creating a new object by copying an existing instance is cheaper or simpler than constructing from scratch — especially when object initialization is expensive or when the exact type of object to create is determined at runtime.

apply-proxy-pattern

Use when you need to control access to an object — adding lazy initialization, access control, logging, caching, or remote access — without changing the object's interface or the client's code.

apply-singleton-pattern

Use when exactly one instance of a class must exist across the entire application — such as a configuration store, connection pool, or logger — and global access to that instance is required.

apply-state-pattern

Use when an object's behavior changes based on its internal state and the logic for each state is complex — replacing large conditional chains with state objects where each state encapsulates its own behavior.

apply-strategy-pattern

Use when you have multiple algorithms or behaviors that can be swapped for a given task — encapsulating each algorithm in its own class and making them interchangeable at runtime.

apply-template-method-pattern

Use when multiple classes share the same algorithm skeleton but differ in specific steps — defining the invariant structure once in a base class and letting subclasses override only the varying parts.

apply-visitor-pattern

Use when you need to perform many distinct operations on a stable object structure — adding new operations without modifying the element classes by separating the operation from the data structure.

design-data-mesh-architecture

Use when a centralized data platform has become a bottleneck, when data teams cannot keep up with business demand, or when designing data architecture for a large organization with multiple autonomous business domains

apply-api-first-design

Use when starting a new API, adding a major feature to an existing API, or aligning multiple teams on an interface — to define the contract in an OpenAPI spec before writing any implementation code.

apply-hyrums-law

Use when designing APIs, evolving existing interfaces, or planning a change to system behavior — to account for the fact that all observable behavior will be depended upon by someone, regardless of what the documented contract says.