Asynchronous event-based communication to decouple producers/consumers for scalability and resilience. Triggers: event-driven, message queue, pub/sub, asynchronous, decoupling Use when: real-time workloads or multiple subsystems react to same events DO NOT use when: selecting paradigms (use architecture-paradigms first), simple request-response.
Coarse-grained service architecture for deployment independence without microservices complexity. service-based, SOA, coarse-grained services, domain services Use when: teams need deployment independence without microservices complexity DO NOT use when: fine-grained scaling needed - use microservices.
Consult this skill when designing data pipelines or transformation workflows. Use when data flows through fixed sequence of transformations, stages can be independently developed and tested, parallel processing of stages is beneficial. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: data flow is not sequential or predictable. DO NOT use when: complex branching/merging logic dominates.
Decouple domain logic from infrastructure using Hexagonal (Ports & Adapters) pattern. Triggers: hexagonal, ports-adapters, infrastructure-independence, domain-isolation, testability Use when: business logic separation, infrastructure changes needed, testability critical DO NOT use when: selecting paradigms (use architecture-paradigms first), simple CRUD.
Serverless FaaS for event-driven workloads with minimal infrastructure management. serverless, FaaS, Lambda, event-driven, pay-per-use Use when: workloads are event-driven with bursty traffic DO NOT use when: long-running processes or stateful operations required.
Consult this skill when implementing layered patterns or enforcing layer boundaries. Use when building traditional applications with clear boundaries, working with moderate-sized teams, needing familiar and well-understood patterns, compliance requirements demand clear separation. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: high scalability needs independent component scaling. DO NOT use when: teams need independent deployment cycles - use microservices.
Use this skill at the BEGINNING of any detailed review for consistent structure. Use when starting any detailed review workflow, needing consistent structure for capturing context and findings, ensuring comparable review outputs. Do not use when quick catchup without formal review - use catchup. DO NOT use when: diff-focused analysis - use diff-analysis.
CQRS and Event Sourcing for auditability, read/write separation, and temporal queries. Triggers: CQRS, event-sourcing, audit-trail, temporal queries, distributed-systems Use when: read/write scaling differs or audit trail required DO NOT use when: selecting paradigms (use architecture-paradigms first), simple CRUD without audit needs.
Consult this skill when designing client-server systems or API architectures. Use when traditional web/mobile applications with centralized services, clear separation between client and server responsibilities needed. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: peer-to-peer dominates - consider dedicated P2P patterns.
Minimal core system with plugin-based feature extensibility for platform development. Triggers: microkernel, plugin-architecture, extensibility, platform-design Use when: platforms/IDEs/marketplaces, core stability critical, plugin isolation needed DO NOT use when: selecting paradigms (use architecture-paradigms first), no extensibility needed.
Consult this skill for session-scoped temporary knowledge structures. Use when working on complex multi-step projects, preserving context across interruptions, tracking session-specific state. Do not use when permanent knowledge structures needed - use memory-palace-architect. DO NOT use when: searching existing knowledge - use knowledge-locator.
Consult this skill when designing permanent memory palace structures. Use when creating new memory palace structures, organizing complex domains, designing spatial layouts for knowledge retention. Do not use when quick knowledge search - use knowledge-locator instead. DO NOT use when: session-specific context - use session-palace-builder.
Consult this skill when cultivating and maintaining digital gardens. Use when managing note collections, creating link structures, maintaining knowledge bases, tending garden health and growth. Do not use when creating memory palace structures - use memory-palace-architect. DO NOT use when: evaluating new knowledge - use knowledge-intake.
Functional Core, Imperative Shell: isolate deterministic logic from side effects for testability. Triggers: functional-core, imperative-shell, pure functions, side-effects, testability Use when: business logic is entangled with I/O or tests are brittle DO NOT use when: simple scripting without complex logic, or performance-critical hot paths where immutability overhead matters.
Outputs markdown digests and CSV exports for GitHub issues and PRs. Use when creating status reports, weekly updates, stakeholder briefings, generating GitHub comment digests, tracking initiative health. Do not use when release gates/readiness - use release-health-gates. DO NOT use when: project planning - use spec-kit:speckit-orchestrator.
Interactive selector and router for architecture paradigms. Use when selecting architecture patterns for new systems, comparing paradigm trade-offs, creating architecture decision records, evaluating architecture fit for team size and domain complexity, planning implementation roadmaps. Do not use when implementing a specific known paradigm - use the specific architecture-paradigm-* skill (hexagonal, layered, microservices, etc.) instead. reviewing existing architecture - use architecture-review instead. Use this skill BEFORE making architecture decisions. Check even if unsure about needs.
Use this skill for scope-focused PR reviews. Use when reviewing PRs, validating against requirements, triaging findings to backlog, preventing overengineering. Do not use when preparing PRs - use pr-prep instead. DO NOT use when: deep code review - use pensive:unified-review.
Use this skill for systematic bug hunting with evidence trails. Use when deep bug hunting needed, documenting defects, verifying fixes, systematic debugging required. Do not use when test coverage audit - use test-review instead. DO NOT use when: architecture issues - use architecture-review.
Cross-plugin testing quality metrics and standards. Referenced by pensive:test-review and parseltongue:python-testing. testing standards, quality metrics, coverage thresholds, anti-patterns Use when: test quality evaluation, coverage thresholds, quality standards DO NOT use when: simple scripts without quality requirements.
Consult this skill for Python performance profiling and optimization. Use when debugging slow code, identifying bottlenecks, optimizing memory, benchmarking performance, production profiling. Do not use when async concurrency - use python-async instead. DO NOT use when: CPU/GPU system monitoring - use conservation:cpu-gpu-performance.