jeffreytse/grimoire-core - Page 24

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

Use when writing DeFi smart contracts that rely on price feeds, randomness, or external data — preventing oracle manipulation via TWAP, multiple oracle sources, and circuit breakers.

prevent-front-running

Use when writing DeFi smart contracts with user-submitted transactions — implementing commit-reveal, slippage tolerance, and MEV-resistant patterns to prevent front-running and sandwich attacks.

prevent-reentrancy

Use when writing Solidity smart contracts that transfer ETH or call external contracts — applying the Checks-Effects-Interactions pattern and ReentrancyGuard to prevent reentrancy attacks.

review-smart-contract-security

Use when auditing a Solidity smart contract or reviewing a protocol before deployment — systematically checking all 10 OWASP Smart Contract Top 10 vulnerability classes with Slither/Foundry test procedures.

apply-cloud-runtime-security

Use when running workloads in cloud environments — enabling GuardDuty, Security Command Center, or Microsoft Defender, and deploying Falco for Kubernetes runtime threat detection.

apply-serverless-function-security

Use when writing serverless functions (AWS Lambda, Google Cloud Functions, Azure Functions) — validating event data from all trigger sources, preventing execution flow manipulation, and securing error handling.

apply-serverless-least-privilege

Use when writing serverless functions — assigning per-function IAM execution roles with minimal permissions, disabling unused triggers, and securing function URLs and API authentication.

apply-serverless-secrets

Use when managing secrets in serverless functions — replacing environment variable credentials with Secrets Manager or Parameter Store, auditing third-party Lambda layers, and preventing secret leakage in logs.

apply-twelve-factor-app

Use when building or refactoring cloud-native applications to ensure portability, scalability, and operability across environments

calculate-cloud-costs

Use when estimating, forecasting, or auditing cloud infrastructure costs before provisioning, during architecture review, or at budget planning time

design-cloud-network-segmentation

Use when designing cloud network architecture — structuring VPCs with public/private subnets, using VPC endpoints for AWS service access, and implementing security groups as stateful firewalls to contain blast radius.

design-cloud-workload-identity

Use when Kubernetes pods or cloud services need to access cloud APIs — replacing long-lived IAM keys with IRSA (AWS), Workload Identity (GCP), or Managed Identity (Azure) to eliminate credential leakage risks.

design-disaster-recovery-plan

Use when establishing or auditing business continuity for cloud systems that must recover from catastrophic failures, data loss, or prolonged outages

design-multi-region-architecture

Use when designing systems that must survive regional outages, minimize global latency, or meet geographic data residency requirements

design-serverless-cost-protection

Use when deploying serverless functions at scale — setting reserved concurrency, SQS visibility timeouts, recursion detection, and budget alerts to prevent denial-of-service via financial resource exhaustion.

design-serverless-observability

Use when operating serverless functions in production — implementing structured logging, distributed tracing, anomaly-based alerting, and cold start monitoring to detect security incidents and performance degradation.

optimize-cloud-spend

Use when cloud costs are growing faster than usage, when preparing for budget reviews, or when seeking to reduce infrastructure spend without degrading performance

review-cloud-native-security

Use when auditing a cloud-native application or infrastructure — systematically checking all 10 OWASP Cloud-Native Application Security Top 10 vulnerability classes with AWS CLI, kubectl, and Terraform commands.

design-data-governance-policy

Use when designing a data governance policy covering data ownership, classification, access control, lifecycle management, and regulatory compliance

design-data-model

Use when designing a new relational database schema, adding entities to an existing system, reviewing a schema for normalization issues, or planning migrations — before writing DDL or ORM models.

design-data-pipeline

Use when designing, building, or reviewing a data pipeline for ingestion, transformation, or analytics

design-data-quality-framework

Use when designing a systematic data quality framework covering completeness, accuracy, consistency, timeliness, validity, and uniqueness across data pipelines and data warehouses

write-sql-query

Use when writing, reviewing, or optimizing SQL queries for correctness, performance, and maintainability

apply-branch-by-abstraction

Use when replacing a large or deeply integrated component of a system incrementally without creating a long-lived feature branch, by introducing an abstraction layer that allows old and new implementations to coexist.

apply-changesets

Use when a monorepo contains multiple independently versioned packages and each package needs its own changelog updated only when that package has actual changes.

apply-convention-over-configuration

Use when designing a project structure, framework, or tooling setup and deciding how much explicit configuration to require from developers.

apply-defensive-copy

Use when writing constructors, setters, or methods that accept or return mutable objects — to prevent callers from silently mutating internal state through shared object references.

apply-dry-principle

Use when you notice duplicated code, logic, data, or knowledge across a codebase and need to decide whether and how to consolidate it.

apply-fail-fast

Use when writing functions, modules, or services to assert internal assumptions — preconditions, postconditions, invariants — so that violated assumptions produce an immediate, loud error at the point of violation rather than propagating corrupt state…

apply-forking-workflow

Use when contributing to a repository you cannot push to directly — to fork the repo, develop on your fork, keep it in sync with upstream, and submit changes via pull request without requiring write access to the canonical repository.

apply-gitflow

Use when a team has scheduled releases, maintains multiple supported versions simultaneously, or operates in a regulated environment requiring formal release approval gates.

apply-github-flow

Use when a team deploys continuously from a single mainline — to keep `main` always deployable, use short-lived feature branches, and ship via PR without release branches or long-lived parallel branches.

apply-gitlab-flow

Use when deploying to multiple environments (staging, pre-production, production) and needing a branch-per-environment promotion model that is simpler than GitFlow but more structured than GitHub Flow.

apply-idiomatic-code

Use when writing or reviewing code in a specific language or ecosystem — especially when contributors from different language backgrounds write in conflicting styles, or when code compiles but feels foreign to native speakers of the language.

apply-kiss-principle

Use when reviewing or writing code that feels unnecessarily complex, clever, or hard to follow — to simplify implementation without losing correctness.

apply-pair-programming

Use when onboarding new engineers, tackling high-complexity problems, debugging subtle issues, or when code quality and knowledge sharing are priorities over individual throughput

apply-parallel-change

Use when evolving a public API, shared interface, or data schema in a way that must remain backward-compatible with existing consumers during the migration period.

apply-predictable-code

Use when writing or reviewing functions and modules — especially when callers encounter surprising side effects, error handling is inconsistent, or debugging requires tracing hidden state changes.

apply-ship-show-ask

Use when deciding how to handle a change in a code review workflow — to categorize each change as Ship (merge without review), Show (merge then notify), or Ask (open for discussion before merging), reducing review bottlenecks without eliminating oversight.