jeffreytse/grimoire-core - Page 23

audit-training-data-integrity

Use when curating, collecting, or managing datasets for training or fine-tuning machine learning models — to detect and mitigate poisoned, biased, mislabeled, or adversarially crafted training data.

design-llm-action-boundaries

Use when building LLM agents that can take actions in the world — sending emails, modifying files, making API calls, or executing code — to prevent the model from taking actions beyond its intended scope.

design-llm-plugin-security

Use when building tools, plugins, or function-calling integrations for LLM systems — defining what actions the model can invoke, how those invocations are validated, and how to prevent misuse of plugin capabilities.

design-prompt-injection-defense

Use when building LLM-powered applications that process user input alongside system instructions — chatbots, AI agents, document processors, code assistants, or any system where untrusted text reaches an LLM.

design-prompt

Use when crafting or improving prompts for large language models — including system prompts, user-facing instructions, evaluation prompts, RAG query templates, agent tool descriptions, or any text that instructs an LLM to perform a task. Trigger when prompt…

design-prompt-template

Use when building LLM-powered features that require consistent, reliable outputs across varied inputs, or when prompt quality is causing inconsistent application behavior

validate-llm-output

Use when LLM outputs are used to make decisions, generate content, answer questions, or drive application logic — to detect hallucinations, verify factual grounding, and prevent over-reliance on unverified AI-generated content.

write-eval-suite

Use when building a test suite to evaluate LLM model performance, prompt quality, or AI system behavior

apply-abstraction

Use when designing modules, services, or class hierarchies — especially when callers depend on concrete implementations, when swapping one provider requires changing multiple call sites, or when tests require the real implementation to run.

apply-composable-design

Use when designing modules, services, or functions — especially when units are hard to reuse independently, replacements require touching many files, or combining two features requires coupling their internals.

apply-composition-over-inheritance

Use when designing relationships between classes or modules — especially when tempted to extend a class to reuse its behavior, or when an inheritance hierarchy is becoming deep or brittle.

apply-controller-pattern

Use when deciding which non-UI class should handle a system operation or external event — especially when business logic leaks into UI handlers, or when the same system operation is triggered from multiple interfaces (web, CLI, API).

apply-creator-pattern

Use when deciding which class should be responsible for creating instances of another class — especially when object creation is scattered across the codebase, or when constructors are called in classes that have no other relationship to the created object.

apply-domain-based-naming

Use when naming variables, functions, classes, modules, or directories — especially when new team members struggle to connect code to domain concepts, or when domain experts and engineers use different terms for the same thing.

apply-domain-driven-design

Use when designing complex business software where the domain logic is the primary source of complexity and where miscommunication between technical and business teams causes bugs

apply-encapsulation

Use when a class's internal state is accessed or mutated from outside — especially when callers reach into fields directly, when invariants are violated by external setters, or when internal data structures leak into the public API.

apply-high-cohesion

Use when assigning responsibilities to classes — especially when a class is hard to name, does work unrelated to its core concept, or a single change requires understanding an entire class to avoid breaking something.

apply-indirection

Use when two components are directly coupled and that coupling causes problems — especially when changing one component forces changes in the other, or when a component cannot be tested without its direct dependency.

apply-information-expert

Use when deciding which class should be responsible for a computation, validation, or operation — especially when the same data is accessed from multiple places to perform the same calculation, or when a class delegates all its work to another class that…

apply-inheritance-correctly

Use when deciding whether a class should extend another — especially when tempted to inherit for code reuse, when instanceof checks appear in callers, or when an override weakens the parent's contract.

apply-law-of-demeter

Use when a class reaches through intermediate objects to access deep properties, when a change to an internal object forces changes in unrelated callers, or when code chains method calls three or more levels deep.

apply-low-coupling

Use when assigning responsibilities to classes — especially when a change to one class ripples into many others, classes are hard to test in isolation, or reusing a class requires dragging in unrelated dependencies.

apply-object-design-heuristics

Use when reviewing or refactoring an OOP codebase — especially when classes are hard to name, methods reach into other objects' internals, or responsibilities feel wrong but it's unclear exactly why.

apply-omakase-philosophy

Use when designing a framework, library, API, or developer tool and deciding how much of the stack to curate for users vs. how much to leave open for user assembly — especially when targeting a specific use case or audience.

apply-polymorphism

Use when behavior varies based on type — especially when if/switch statements check the type of an object to decide what to do, or when adding a new variant requires editing an existing class.

apply-protected-variations

Use when a point of variation or instability is identified in a design — especially when a third-party dependency, algorithm, or external interface is likely to change and other components should not be affected.

apply-pure-fabrication

Use when no domain class is a suitable home for a responsibility — especially when assigning a responsibility to a domain object would violate high cohesion or low coupling by introducing infrastructure concerns (database, email, logging) into domain objects.

apply-solid-principles

Use when designing or reviewing classes and modules in OOP code — especially when tests are hard to write, changes ripple unexpectedly, or classes accumulate unrelated responsibilities.

apply-strangler-fig-pattern

Use when replacing a legacy system or component incrementally without a full rewrite, by routing traffic progressively from the old system to a new implementation.

apply-unix-philosophy

Use when designing tools, services, CLIs, or modules — especially when a component accumulates responsibilities over time, changes to one feature break unrelated features, or the component is hard to test in isolation.

audit-technical-debt

Use when assessing, cataloging, or prioritizing technical debt in an existing codebase or system

design-api

Use when designing a new REST API, adding endpoints to an existing API, or reviewing an API design for correctness, consistency, and long-term maintainability.

design-api-versioning-strategy

Use when designing public or partner APIs that must evolve without breaking existing integrations, or when API changes are causing client disruption

design-cqrs-architecture

Use when designing a system where read and write workloads have significantly different scaling, consistency, or model requirements that a single unified model cannot serve efficiently.

design-event-driven-architecture

Use when designing systems that need loose coupling between services, asynchronous processing of high-volume events, or real-time data propagation across multiple consumers

design-event-driven-system

Use when designing systems that communicate through events, including event sourcing and CQRS architectures

design-microservices

Use when decomposing a monolith or designing a new system using microservices architecture

design-system-architecture

Use when asked to design, evaluate, or document the high-level architecture of a system — including new systems, major feature additions, or scaling a system beyond its current design limits.

write-adr

Use when a significant technical decision is being made or has just been made — including technology choices, architectural patterns, API contracts, data models, or security boundaries. Use before implementing a decision that would be costly to reverse.

apply-smart-contract-access-control

Use when writing Solidity contracts with admin functions, upgradeable proxies, or multi-role permissions — implementing Ownable, role-based access control, and two-step ownership transfer to prevent unauthorized function execution.