grimoire-engineering

Plugin grimoire-engineering from marketplace grimoire in jeffreytse/grimoire-core. Commands read from the repo's manifest — 28 days ago.

Skills (200)

• apply-bm25-ranking

  Use when building or tuning full-text search relevance, scoring documents against a keyword query, or building the sparse/keyword leg of a hybrid RAG retriever — including deciding between BM25, raw TF-IDF, and dense/vector search, or diagnosing why keyword search results feel poorly ranked.

• apply-deterministic-verifier-chain

  Use when deciding whether AI-generated code can be trusted without reading it line by line — instead of reading the target code, build or generate small, deterministic, narrowly-scoped verification tools (coverage checkers, complexity linters, mutation testers) to check it, and trust those tools not

• 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.

• apply-llm-output-sanitization

  Use when rendering LLM-generated text in a browser, executing LLM-generated code, or inserting LLM output into a database or downstream system — any place LLM output leaves the AI layer and enters another execution context.

• apply-llm-resource-limits

  Use when building applications that make LLM API calls, run inference locally, or build agentic systems — to prevent runaway costs, infinite loops, and denial of service via unrestricted model consumption.

• audit-llm-data-disclosure

  Use when deploying an LLM application that may have been trained on or given access to sensitive data — to assess the risk of the model leaking PII, proprietary information, or confidential context through its outputs.

• audit-llm-output

  Use when evaluating, auditing, or improving the quality, factual accuracy, or safety of LLM-generated outputs

• audit-model-fairness

  Use when deploying ML models that make decisions affecting people (hiring, lending, healthcare, content moderation) or when required by regulation to assess algorithmic bias

• 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-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-ai-governance-framework

  Use when an organization is establishing oversight for how it develops, deploys, or uses AI systems — classifying AI use cases by risk level, assigning accountable owners, and applying oversight proportionate to each use case's actual risk, rather than applying either no governance or the same unifo

• 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-ml-pipeline

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

• design-model-based-reinforcement-learning

  Use when training a reinforcement-learning agent where real-environment interaction is expensive, slow, or limited — robotics, game-playing agents, or any control task — by training a model of the environment's dynamics from real interaction data, then planning or training the policy against simulat

• 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-template

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

• 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 outputs are inconsistent, too long, off-fo

• 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

• 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-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-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-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-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-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-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-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-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-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-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 holds the actual data.

• 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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.

• 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.

• audit-technical-debt

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

• 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-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-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-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

• 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-greenfield-brownfield-strategy

  Use when starting a new software project or major initiative — classifying it as greenfield (no existing system or constraints), brownfield (must integrate with or replace an existing system), or retrofit (upgrading an existing system in place) before choosing an architecture and rollout strategy.

• 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.

• apply-smart-contract-randomness

  Use when writing Solidity contracts that need randomness — NFT mints, lotteries, games — replacing insecure block variable entropy with Chainlink VRF or commit-reveal to prevent miner manipulation.

• design-oracle-security
• prevent-front-running
• prevent-reentrancy
• review-smart-contract-security
• apply-cloud-runtime-security
• apply-serverless-function-security
• apply-serverless-least-privilege
• apply-serverless-secrets
• apply-twelve-factor-app
• calculate-cloud-costs
• design-cloud-network-segmentation
• design-cloud-workload-identity
• design-disaster-recovery-plan
• design-multi-region-architecture
• design-serverless-cost-protection
• design-serverless-observability
• optimize-cloud-spend
• review-cloud-native-security
• design-access-governance-review
• design-data-governance-policy
• design-data-model
• design-data-pipeline
• design-data-quality-framework
• design-data-stewardship-program
• write-sql-query
• apply-api-first-design
• apply-branch-by-abstraction
• apply-changesets
• apply-convention-over-configuration
• apply-defensive-copy
• apply-dry-principle
• apply-fail-fast
• apply-forking-workflow
• apply-gitflow
• apply-github-flow
• apply-gitlab-flow
• apply-hyrums-law
• apply-idiomatic-code
• apply-kiss-principle
• apply-pair-programming
• apply-parallel-change
• apply-predictable-code
• apply-ship-show-ask
• apply-small-cls
• apply-trunk-based-development
• apply-yagni-principle
• bisect-regression
• design-branching-strategy
• design-code-review-process
• design-grpc-service
• design-naming-convention
• design-restful-api
• diagnose-bug
• propose-conventional-commit
• review-code-style
• review-pull-request
• run-changelog-automation
• triage-bug-report
• write-changelog
• write-database-migration
• write-openapi-spec
• write-regression-test
• write-review-comments
• apply-docker-security
• apply-feature-toggles
• apply-iac-security
• apply-kubernetes-security
• audit-infra-drift
• design-ci-pipeline
• design-cicd-pipeline-security
• design-deployment-strategy
• design-gitops-workflow
• design-it-governance-steering-committee
• design-platform-engineering-model
• plan-incident-response
• review-kubernetes-top10
• write-post-mortem
• design-contribution-standard
• write-tech-spec
• design-component-api
• design-component
• apply-iot-device-hardening
• apply-iot-network-hardening
• design-iot-device-management
• design-iot-secure-boot
• review-iot-security
• apply-mobile-code-hardening
• apply-mobile-cryptography
• apply-secure-mobile-storage
• audit-mobile-performance
• design-mobile-privacy-controls
• design-offline-first
• write-push-notification
• audit-network-security
• design-network-segmentation
• diagnose-network-latency
• audit-bundle-size
• audit-performance
• calculate-capacity-plan
• design-caching-strategy
• diagnose-memory-leak
• profile-web-vitals
• run-load-test
• design-experiment
• write-prd
• write-prfaq
• write-release-note
• write-user-story
• apply-monte-carlo-risk-simulation
• design-risk-register
• plan-retrospective
• plan-sprint
• apply-five-whys
• apply-fmea-analysis
• audit-error-budget
• design-slo-sla-framework
• design-slo
• run-chaos-engineering
• run-game-day
• write-sre-runbook