Instruction Modules

This directory contains a collection of instruction modules that provide guidance on various topics, including technology, foundational principles, and execution playbooks. These modules are designed to be used as a knowledge base for building intelligent agents.

The modules are organized into a hierarchical structure. Below is a list of all available modules.

---

Execution

Playbooks for executing common tasks.

• Meta
  • Classify an Instruction Module - A step-by-step procedure for classifying a new or existing instruction module into the correct tier (Foundation, Principle, Technology, or Execution) using the Top-Down Classification Test.
  • Module Integration Protocol - The core procedure for an AI agent to dynamically discover, select, and apply instruction modules to solve a user's request.
• Persona Builder
  • Foundation Layer Rules - The rule that Foundation modules must be ordered by their 'layer' metadata, from lowest to highest.
  • Instruction Module Validation Rules - A specification of the strict, declarative rules for ensuring an instruction module conforms to official authoring standards.
• Playbook
  • Create Commit Message - A playbook for analyzing a set of code changes and generating a commit message that conforms to the Conventional Commits standard.
  • Debug an Issue - A systematic playbook for debugging, leveraging foundational modules like root-cause-analysis and causal-reasoning.
  • Design Microservices Architecture - A playbook for designing a system based on the microservices architectural style.
  • Document a Function - A playbook for writing comprehensive documentation for a given function, including its parameters, return value, and potential errors.
  • Generate New Persona Module - A playbook for generating a new, complete persona file from a user's concept.
  • Generate Secure Error Response - A step-by-step process for generating a user-safe error response while logging detailed internal diagnostics.
  • Optimize Web Application Performance - A playbook that applies performance principles to a concrete goal of optimizing a web application.
  • Perform Security Audit - A playbook for conducting a comprehensive security audit of a codebase to identify and mitigate vulnerabilities.
  • Plan a Feature - A playbook for taking a user story and breaking it down into a technical implementation plan with concrete steps.
  • Plan Legacy Modernization - A playbook for creating a safe, incremental plan to modernize a legacy system.
  • Refactor a Component - A step-by-step process for safely improving the internal structure of a piece of code without changing its external behavior.
  • Review a Pull Request - A playbook that uses a checklist to provide structured, constructive feedback on a pull request.
  • Audit Documentation
    • Playbook: Verify and Comment Documentation - A step-by-step process for auditing documentation against a codebase.
  • Modules
    • Generate New Instruction Module - A systematic playbook for creating well-structured instruction modules that follow the official schema requirements and machine-centric writing principles.
    • Instruction Module Validation - A comprehensive checklist to validate that instruction modules conform to official schema requirements, frontmatter standards, and machine-centric language principles.
• Prompts
  • Prompt Improvement Procedure - A playbook for analyzing a user-provided prompt and rewriting it to be more effective using modern prompt engineering techniques.
• Testing
  • Playbook: Debug Failing Unit Test - A playbook that uses root-cause-analysis to diagnose a failing test report from Vitest and propose a minimal, correct fix.
  • Playbook: Refactor for Testability - A playbook for analyzing a hard-to-test function and refactoring it to use dependency injection, then writing a new unit test using vi.mock.
  • Playbook: Write New Unit Test - A step-by-step process for generating a new unit test file for a given source code function, strictly following the Arrange-Act-Assert pattern.

Foundation

Core principles and concepts for reasoning, problem-solving, and decision-making.

• Bias
  • Avoiding Survivorship Bias - A rule to consider the data from failures as well as successes, avoiding the error of drawing conclusions only from surviving examples.
  • Awareness of Availability Heuristic - Instructions to not overestimate the importance of information that comes to mind most easily.
  • Ignoring Sunk Costs - A directive to make decisions based on future potential value, explicitly ignoring past, irrecoverable costs.
  • Mitigating Confirmation Bias - A directive to actively seek out, consider, and present disconfirming evidence.
  • Recognizing Anchoring Bias - A rule to avoid over-relying on the first piece of information received.
• Cognitive Frameworks
  • Chain of Verification - A self-correction framework where the AI generates a draft answer, formulates verification questions about it, answers those questions internally, and then produces a final, verified response.
  • Contrastive Reasoning - A directive to improve reasoning clarity by generating both a correct and an intentionally incorrect example or reasoning path, then explaining why one is correct and the other is flawed.
  • Graph of Thoughts - An advanced reasoning framework that models thoughts as nodes in a graph, allowing for complex, non-linear reasoning paths that can merge and diverge to solve highly interconnected problems.
  • ReAct Framework - A directive to solve problems by operating in a structured Thought -> Action -> Observation loop, allowing the AI to reason, use tools, and then reason again based on the outcome.
  • Self-Consistency Voting - A technique to improve accuracy by generating multiple diverse reasoning paths for the same problem and then selecting the most frequent or consistent answer from the conclusions.
  • Tree of Thoughts - A framework for complex problem-solving that explores multiple reasoning paths simultaneously, evaluates their viability, and pursues only the most promising ones.
• Communication
  • Ask Clarifying Questions - A directive to seek more information when a user's request is ambiguous or incomplete.
  • Clarity and Brevity - A set of rules for communicating in a way that is clear, concise, and unambiguous.
  • Define Technical Terms in Software Development - A specification for identifying and defining technical jargon, acronyms, and ambiguous terms in software development communications.
  • Structured Technical Arguments in Software Development - A specification for presenting technical recommendations, architectural decisions, and implementation proposals with logical structure and evidence-based support.
• Decision Making
  • Assess Risk and Uncertainty - A process to differentiate between risk (known probabilities) and uncertainty (unknown probabilities).
  • One-Way vs. Two-Way Doors - A framework for classifying decisions based on their reversibility.
  • Satisficing vs. Maximizing - A rule to understand when a 'good enough' solution is superior to striving for a perfect one.
  • Technical Cost-Benefit Analysis for Software Development - A specification for systematically evaluating software development decisions by comparing technical costs against expected benefits using quantifiable metrics.
• Ethics
  • Clarify and Correct - Instructions to admit when something is unknown or when a mistake has been made.
  • Do No Harm - A fundamental principle to evaluate proposed actions and code for potential negative consequences, prioritizing safety and stability.
  • Intellectual Honesty - A specification for representing facts, arguments, and evidence fairly, accurately, and without deception.
  • Principle of Charity - A rule to interpret a user's statements in their strongest, most reasonable form.
  • Respect User Autonomy - A directive to empower the user to make their own decisions, providing options and trade-offs rather than making choices on their behalf.
• Logic
  • Avoiding Logical Fallacies in Software Development - A specification for identifying and avoiding common logical errors in software development reasoning and argumentation.
  • Causality vs. Correlation - A critical rule to not assume that one event causes another just because they are correlated.
  • Conditional Logic (If-Then) - Rules for correctly processing and evaluating conditional statements.
  • Necessary and Sufficient Conditions - A core logical framework for precisely analyzing the relationship between conditions and outcomes.
  • Occam's Razor - The principle that, when presented with competing hypotheses, the one with the fewest assumptions should be selected.
  • Proof Verification - A process for systematically checking the validity of a logical argument or proof by examining its premises and deductive steps.
  • Quantifiers and Scope - A rule to be precise with logical quantifiers (e.g., 'all,' 'some,' 'none') and to clearly define their scope.
• Metacognition
  • Continuous Improvement - A meta-cognitive mindset focused on ongoing learning by reflecting on experiences, seeking feedback, and deliberately practicing new skills.
  • Distinguishing Fact from Opinion - A core rule to clearly separate objective, verifiable facts from subjective opinions or beliefs.
  • Evaluating Confidence Levels - A process for assessing and stating the level of confidence in a conclusion.
  • Evaluating Technical Evidence in Software Development - A specification for assessing the quality, reliability, and relevance of technical information and data in software development contexts.
  • Growth Mindset - The principle of viewing challenges as opportunities to learn and grow, rather than as threats to one's competence.
  • Self-Correction Process - A framework for identifying and correcting its own errors or flawed reasoning.
  • The Feynman Technique - A process for testing and validating understanding of software development concepts by explaining them in simple, clear terms without jargon or technical assumptions.
  • Understanding Levels of Certainty - A specification for classifying and communicating the certainty of technical claims, from speculation to established facts.
  • Weighing Trade-Offs - A process for systematically analyzing the technical trade-offs, constraints, and implications of different software development options and architectural decisions.
• Problem Solving
  • Identify the Bottleneck - A process for analyzing a system to find the single constraint that limits its overall performance.
  • Means-End Analysis - A process for systematically reducing the difference between the current state and the goal state.
  • Problem Deconstruction - The process of breaking large, complex problems into smaller, more manageable, and mutually exclusive parts.
  • Root Cause Analysis - A systematic process to look beyond immediate symptoms and find the underlying, fundamental cause of a problem.
  • Rubber Duck Debugging - A meta-cognitive technique for solving problems by explaining the code, line-by-line, to an inanimate object.
  • Time-boxing - A technique for managing effort and focus by allocating a fixed time period to a specific task or approach.
  • Using Heuristics - A directive to use rules of thumb and educated guesses to find approximate solutions when a problem is computationally expensive.
  • Work Backwards from Goal - A strategy of starting from the desired outcome to determine the necessary preceding steps.
• Reasoning
  • Abductive Reasoning - A procedure for generating the most likely hypothesis for a set of observations by favoring the simplest explanation.
  • Analogical Reasoning - A cognitive process for transferring knowledge and solutions from one domain to solve problems in another domain by mapping structural relationships.
  • Causal Reasoning - A process for determining cause-and-effect relationships, moving beyond mere correlation by identifying mechanisms.
  • Constraint Satisfaction - A process for finding a solution to a problem by identifying its variables, domains, and constraints, and finding an assignment that satisfies all constraints.
  • Divergent Thinking - A cognitive process for generating a wide variety of possible solutions to a problem without initial judgment or criticism.
  • Edge Case Analysis - A systematic process for identifying and generating test cases for boundary conditions and non-standard inputs.
  • Inductive Reasoning - Forming broad generalizations based on specific observations.
  • Systems Thinking - A procedure for analyzing problems holistically by mapping system components, their interconnections, and identifying key leverage points like feedback loops and bottlenecks.
• Software
  • Logic
    • Deductive Reasoning for Code - A process for deriving logically certain conclusions about a system's state from general rules and specific conditions.
  • Reasoning
    • First Principles Thinking for Software - A specification for deconstructing software problems to their fundamental computational principles, rather than relying on frameworks or conventions.
• Universal
  • First Principles Thinking - A specification for deconstructing complex problems to their fundamental, irreducible components and rebuilding understanding from verified foundational truths rather than relying on assumptions or conventional wisdom.

Principle

Guiding principles for software development, architecture, and process.

• Architecture
  • API Design Principles - A specification for designing clean, consistent, and easy-to-use RESTful APIs.
  • Architecture Decision Records (ADRs) - A documentation pattern for capturing significant architectural decisions, their context, and consequences in a structured, lightweight format.
  • Command-Query Responsibility Segregation (CQRS) - The principle that separates methods that change state (Commands) from methods that read state (Queries). This can improve performance, scalability, and security.
  • Design for Scalability - The principle of designing systems that can handle increased load by adding resources, typically horizontally.
  • Domain-Driven Design (DDD) - An approach to software development for complex needs by connecting the implementation to an evolving model.
  • Event-Driven Architecture - A software architecture paradigm promoting the production, detection, consumption of, and reaction to events.
  • Hexagonal Architecture (Ports and Adapters) - An architectural pattern that isolates the application core from external services.
  • Layered Architecture - An architectural pattern that organizes software into layers, each with a specific responsibility.
  • Microservices Architecture - An architectural pattern that decomposes applications into a collection of loosely coupled, independently deployable services organized around business capabilities.
  • Principle of Least Astonishment - A rule that a system's components should behave in a way that users expect, without surprising them. The goal is to reduce the cognitive load required to use the system correctly.
  • Robustness Principle (Postel's Law) - A design principle for software implementation that states to 'be conservative in what you do, be liberal in what you accept from others.' This helps build resilient systems that can handle imperfect input.
  • Separation of Concerns - The principle of dividing a system into distinct sections, where each section addresses a specific aspect of the functionality.
  • Serverless Architecture - A cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources.
• Collaboration
  • Effective Communication - A set of principles for clear, concise, and effective technical communication with team members and stakeholders.
  • Error Reporting - A directive to report errors in a way that is clear, informative, and actionable for the user.
  • Escalation Protocol (Asking for Help) - A protocol for recognizing when to stop working alone and when to escalate a problem to a human user or another expert.
  • Knowledge Sharing - Principles for actively mentoring, documenting, and sharing technical knowledge to improve a team's collective capability.
  • Request for Comments (RFC) Process - A formal process for proposing and building consensus on significant technical changes by inviting feedback from a wide audience.
• Design Patterns
  • Composition Over Inheritance Principle - A design principle stating that systems should achieve polymorphic behavior and code reuse by containing instances of other classes rather than inheriting from a base class.
  • Dependency Inversion Principle - High-level modules should not depend on low-level modules. Both should depend on abstractions.
  • KISS (Keep It Simple, Stupid) - The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
  • Law of Demeter (Principle of Least Knowledge) - A design principle that reduces coupling by restricting a method from accessing objects deep within another object's structure.
  • Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
  • Single Responsibility Principle - A class should have only one reason to change, meaning it should have only one job or responsibility.
  • Behavioral
    • Command Pattern - A behavioral design pattern that encapsulates requests as objects, enabling parameterization of clients with different requests, queuing operations, logging requests, and supporting undo functionality.
    • Template Method Pattern - A behavioral design pattern that defines the skeleton of an algorithm in a base class, allowing subclasses to override specific steps without changing the overall algorithm structure.
  • Creational
    • Builder Pattern - A creational design pattern that constructs complex objects step by step, separating the construction process from the representation to enable flexible object creation with optional parameters.
    • Factory Pattern - A creational design pattern that provides an interface for creating objects without specifying their exact classes, enabling loose coupling between client code and object creation logic.
    • Observer Pattern - A behavioral design pattern where a subject object maintains a list of its dependent observers and notifies them automatically of any state changes.
    • Singleton Pattern - A creational design pattern that ensures a class has only one instance and provides a single, global point of access to it.
    • Strategy Pattern - A behavioral design pattern that defines a family of interchangeable algorithms, encapsulates each one, and allows them to be selected at runtime.
  • Structural
    • Adapter Pattern - A structural design pattern that allows incompatible interfaces to work together by creating a wrapper that translates one interface to another, enabling integration of existing classes without modifying their source code.
    • Decorator Pattern - A structural design pattern that allows adding new functionality to objects dynamically by wrapping them in decorator objects that implement the same interface, providing a flexible alternative to subclassing.
    • Facade Pattern - A structural design pattern that provides a simplified interface to a complex subsystem by hiding its complexity behind a unified, easy-to-use interface that coordinates interactions between multiple components.
• Documentation
  • Documentation Must Match Code - A core principle that documentation must accurately reflect the current implementation, not future aspirations.
  • Documentation Standards - A set of standards for writing and maintaining clear, accurate, and useful documentation for a software project.
• Methodology
  • Continuous Integration & Delivery (CI/CD) - A set of practices that automate the integration, building, testing, and deployment of software to enable rapid and reliable releases.
  • Feature Toggles (Feature Flags) - A technique that decouples code deployment from feature release, allowing new functionality to be deployed to production in a disabled state.
  • Infrastructure as Code (IaC) - The practice of defining and managing infrastructure using declarative configuration files, enabling version control and reproducibility.
  • Iterative Development - The practice of building software in small, incremental cycles that deliver working functionality, enabling rapid feedback and adaptation.
  • User Story Mapping - A technique for expressing requirements from the user's perspective, focusing on value rather than technical implementation.
• Performance
  • Design for Performance - The principle of intentionally designing for efficiency in response time, throughput, and resource utilization.
  • Optimization Principles - A set of guiding principles for improving system performance, emphasizing measurement and focusing on bottlenecks.
• Process
  • Agile (Scrum) - An iterative and incremental framework for project management and software development, focused on delivering value in small increments (Sprints) and adapting to change.
  • Boy Scout Rule - The principle that one should always leave the codebase cleaner than they found it. This encourages continuous, incremental improvement of code quality.
  • Re-read for Comprehension in Software Development - A meta-cognitive procedure for thoroughly reviewing all requirements, constraints, and context before implementing any software solution.
  • Test-Driven Development (TDD) - A software development process where tests are written before the code that they are intended to validate. The process is a short, repeating cycle of Red-Green-Refactor.
  • YAGNI (You Ain't Gonna Need It) - The principle of not adding functionality until it is demonstrably necessary to avoid over-engineering.
  • Modules
    • Module Authoring Principles - A procedure for authoring high-quality, machine-centric instruction modules that conform to the system's standards.
    • Module Concept Checklist - A checklist to validate that a proposed module concept is atomic, clear, and adds value to the system.
    • Schema Selection Procedure - A deterministic procedure for selecting the correct module schema based on its primary purpose.
• Quality
  • Clean Code Principles - A software development philosophy emphasizing code readability, maintainability, and simplicity through consistent naming, minimal complexity, and self-documenting practices.
  • Code Organization Pattern - The principle of structuring a codebase for clarity, logical cohesion, and maintainability.
  • Code Review Checklist - A systematic checklist for reviewing code, focusing on readability, maintainability, and correctness.
  • Code Review Process - The principle of implementing a thorough peer review process to catch issues before they enter the codebase.
  • Don''t Repeat Yourself (DRY) - The principle of reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
  • Single Source of Truth (SSoT) - Software architecture principle requiring that every data element, business rule, and system configuration must be stored in exactly one authoritative location to ensure data integrity, consistency, and eliminate synchronization conflicts.
  • SOLID Design Philosophy - A design philosophy comprising five fundamental principles for creating maintainable, scalable, and robust object-oriented software architecture.
  • Static Analysis Integration - The principle of using automated tools to identify potential issues in code before it is executed.
  • Technical Debt Management - A proactive process for identifying, tracking, and paying down technical debt to maintain long-term codebase health.
  • Modules
    • Machine-Centric Language Specification - A comprehensive specification for authoring machine-centric instructions, defining the style, structure, and formal meaning of requirement keywords to ensure deterministic AI behavior.
    • Module Content Specification - A comprehensive specification defining both the required Markdown structure (H2 headings) and content formats for each of the six official module schemas.
    • Module Metadata Specification - A formal specification defining the required and optional fields for valid module frontmatter, including their data types and constraints.
• Quality Attributes
  • Maintainability - The quality attribute that enables a system to be easily modified and extended.
  • Performance - The quality attribute that focuses on the efficiency of a system in terms of response time, throughput, and resource utilization.
  • Reliability - The quality attribute that ensures a system functions correctly even under adverse conditions.
  • Scalability - The quality attribute that enables a system to handle increased load by adding resources.
  • Security - The quality attribute that protects a system against unauthorized access and potential vulnerabilities.
  • Testability - The quality attribute that enables a system to be easily tested in isolation.
• Reliability
  • Chaos Engineering - The practice of proactively testing system resilience by introducing controlled, deliberate failures into a production environment.
  • Design for Reliability - The principle of designing systems that function correctly and consistently, even under adverse conditions.
  • Fault Tolerance Design - Principles for designing systems that can continue to function correctly despite the failure of one or more of their components.
• Security
  • Defense in Depth - The strategy of protecting a system with multiple, redundant layers of security controls, such that if one layer fails, another is in place to thwart an attack.
  • Fail-Safe Defaults - The principle that, unless a subject is given explicit access to an object, it should be denied access. This is the foundation of a secure system.
  • Principle of Least Privilege - A security principle stating that any user, program, or process should have only the bare minimum privileges necessary to perform its function.
  • Threat Modeling Process - A systematic process for identifying, assessing, and mitigating potential security threats during the design phase of a system.
• Testing
  • Arrange-Act-Assert (AAA) Pattern - A mandatory structural pattern for all unit tests to ensure clarity, consistency, and readability.
  • Binary Debugging - A systematic procedure for isolating the source of a bug by repeatedly dividing the problem space.
  • Design for Testability - A design philosophy that emphasizes writing code in a way that makes it easy to write high-quality, isolated unit tests.
  • Test Isolation - The critical principle that automated tests must be independent and not rely on a shared state or a specific execution order.
  • The Testing Pyramid - A strategic model for creating a balanced and effective testing portfolio with a focus on speed and reliability.

Technology

Guidance on specific technologies, languages, and platforms.

• Build Tool
  • Vite
    • Vite: Configuring a Development Server Proxy - A procedure for setting up a proxy in vite.config.ts to solve CORS issues during local development.
    • Vite: Vendor Chunking for Caching - A pattern for optimizing production builds by splitting node_modules dependencies into a separate 'vendor' chunk to improve browser caching.
• Css
  • Tailwind
    • TailwindCSS: Config as Design Tokens - A specification for using the tailwind.config.js file as a single source of truth for a project's design tokens.
• Database
  • Postgresql
    • PostgreSQL Query Optimization - Directives for writing efficient and performant queries in PostgreSQL, focusing on indexing, joins, and query analysis.
• Framework
  • Preact
    • Preact: React Ecosystem Compatibility - A procedure for using preact/compat to leverage the vast React ecosystem within a Preact application.
    • Preact: State Management with Signals - A pattern for managing state in Preact using Signals for fine-grained reactivity, avoiding unnecessary component re-renders.
  • React
    • React Component Best Practices - Rules for component composition, state management, and props to create maintainable and performant React applications.
    • React State Management Decisions - A decision-tree module for choosing between useState, useReducer, useContext, and external libraries.
    • React: Handling Side Effects with useEffect - A specification for using the useEffect hook to manage side effects, dependencies, and cleanup.
    • React: Rules of Hooks - The two fundamental rules for using React Hooks correctly.
• Language
  • Python
    • Effective Python Error Handling - Directives on using try/except/finally blocks correctly and creating custom exceptions.
    • PEP 8 Style Guide - A strict rulebook for ensuring all Python code is compliant with the PEP 8 style guide.
  • Typescript
    • TypeScript: Async/Await with Types - A guide to correctly typing asynchronous functions and handling Promises to ensure type safety.
    • TypeScript: Effective Generics - Best practices for using generics () to create reusable, type-safe functions, classes, and components.
    • TypeScript: Enums and Discriminated Unions - A guide for using enums and discriminated unions to create type-safe state machines and variant types.
    • TypeScript: Module Resolution and Path Aliasing - A specification for configuring tsconfig.json to use non-relative path aliases, eliminating fragile, relative import paths.
    • TypeScript: Strict Compiler Options - A specification for enforcing a strict, safe coding style by enabling advanced TypeScript compiler flags.
    • TypeScript: Strict Type-Checking - A rule enforcing the use of strict type-checking options in tsconfig.json to catch common errors at compile time.
    • TypeScript: Template Literal Types - A specification for using template literal types to create precise, type-safe string unions for events, routes, or other string-based APIs.
    • TypeScript: Type Guards and Narrowing - A guide to using type guards to narrow down the type of a variable within a conditional block.
    • TypeScript: Types vs. Interfaces - A specification outlining the pragmatic conventions for choosing between type aliases and interface declarations.
    • TypeScript: Utility Types Best Practices - A guide to effectively using TypeScript's built-in utility types (Partial, Pick, Omit, Record, etc.) to manipulate and create new types.
• Platform
  • Aws
    • API Gateway Integration Patterns - A guide to different integration patterns for API Gateway, such as Lambda Proxy integration, HTTP integration, and AWS service integration.
    • AWS IAM Best Practices - A set of security best practices for managing users, groups, roles, and permissions in AWS Identity and Access Management (IAM).
    • AWS Lambda Best Practices - A set of best practices for writing, configuring, and deploying efficient, secure, and cost-effective AWS Lambda functions.
    • AWS S3 Storage Classes - A decision-making guide for selecting the appropriate Amazon S3 storage class based on access frequency and cost considerations.
    • DynamoDB Data Modeling - A module on how to model data effectively for DynamoDB, focusing on single-table design, access patterns, and choosing the right keys and indexes.
    • VPC Network Security - A guide to securing an AWS Virtual Private Cloud (VPC) using security groups, network ACLs, and public/private subnets.
  • Firebase
    • Cloud Functions for Firebase Best Practices - Rules for writing efficient, secure, and idempotent Cloud Functions for Firebase.
    • Firebase Authentication Best Practices - Best practices for implementing and managing user authentication with Firebase Auth.
    • Firestore Data Modeling - Principles for structuring data in Firestore for scalability and efficient querying, focusing on collections, documents, and subcollections.
    • Firestore Security Rules - A critical guide for writing and testing Firestore security rules to protect data from unauthorized access.
  • Vercel
    • Vercel Deployment Best Practices - A set of rules and processes for deploying applications to Vercel, focusing on performance, environment variables, and caching.
• Security
  • Owasp Top 10
    • Broken Access Control - A set of strict rules to prevent broken access control vulnerabilities by enforcing a default-deny policy and verifying authorization for every request.
    • Cryptographic Failures - A set of strict rules to prevent cryptographic failures by protecting data in transit and at rest using up-to-date, strong cryptographic algorithms and protocols.
    • Identification and Authentication Failures - A set of rules to prevent authentication failures by implementing strong identity and session management controls.
    • Injection - A set of strict rules to prevent injection vulnerabilities by treating all user-supplied data as untrusted and using structured, safe APIs for all interpreter interactions.
    • Insecure Design - A set of principles for secure software design, emphasizing threat modeling and the integration of security into every phase of the development lifecycle.
    • Security Logging and Monitoring Failures - A set of rules to ensure sufficient logging and monitoring is in place to detect and respond to security incidents in a timely manner.
    • Security Misconfiguration - A set of rules to prevent security misconfigurations by establishing a hardened, repeatable configuration process and regularly auditing the system for deviations.
    • Server-Side Request Forgery (SSRF) - A set of rules to prevent Server-Side Request Forgery (SSRF) vulnerabilities by validating all user-supplied URLs and restricting the server's ability to make arbitrary network requests.
    • Software and Data Integrity Failures - A set of rules to protect against software and data integrity failures by verifying the integrity of all code, data, and critical updates.
    • SQL Injection Prevention - A set of strict rules to prevent SQL injection vulnerabilities by never using dynamic query concatenation and always using parameterized queries.
    • Vulnerable and Outdated Components - A set of rules for managing third-party components to prevent the use of software with known vulnerabilities.
• Testing
  • Test Data Management with Fixtures - A conceptual pattern for using test fixtures to create consistent, reusable, and maintainable test data.
  • Cypress
    • Cypress Best Practices - A guide to best practices for writing reliable, maintainable, and effective end-to-end tests with Cypress.
    • Cypress Custom Commands - A guide to creating and using custom commands in Cypress to promote reusable and readable test code.
    • Cypress Selector Strategies - A guide to the best strategies for selecting elements in Cypress tests to create stable and resilient tests.
  • Jest
    • Jest Best Practices - A guide to best practices for writing clean, effective, and maintainable tests with Jest.
    • Jest Mocking - A guide to effectively using mocking in Jest to isolate components and functions for focused testing.
    • Jest Snapshot Testing - Guidelines for using snapshot tests in Jest to verify the output of UI components and large data structures.
  • Vitest
    • Vitest Async Testing - A guide to testing asynchronous operations including promises, async/await, and time-dependent code in Vitest.
    • Vitest Configuration - A guide to setting up vitest.config.ts with proper TypeScript, coverage, and environment configuration for optimal testing.
    • Vitest Error Testing - A guide to testing error conditions, exception handling, and failure scenarios to ensure robust error handling in applications.
    • Vitest Performance - Tips for writing performant tests in Vitest to ensure a fast and efficient testing cycle.
    • Vitest Test Organization - A guide to structuring test files, naming conventions, and test suite organization for maintainable and scalable test suites.
    • Vitest Test Utilities - A guide to creating reusable test helpers, factories, and custom matchers to reduce duplication and improve test maintainability.
    • Vitest: Best Practices - A guide to best practices for writing clean, effective, and maintainable tests with Vitest.
    • Vitest: Controlling Time with Fake Timers - A guide on using vi.useFakeTimers() to reliably test time-based logic like setTimeout and setInterval.
    • Vitest: Mocking with vi - A procedure for using the vi utility to create mocks for external dependencies, ensuring unit tests are isolated and deterministic.
• Tool
  • Git
    • Conventional Commits Specification - A formal specification defining the rules of the Conventional Commits v1.0.0 standard for creating an explicit and machine-readable commit history.
    • Interactive Rebase Workflow - A process for cleaning up commit history using interactive rebase before merging a feature branch.