sw-agent-skills

Systematic debugging workflow for isolating software root causes, implementing proportional fixes, and verifying recovery with reproducible evidence. Use when application/runtime failures, regressions, or flaky behavior are observed and the task requires both diagnosis and remediation. When specialized skills are available in the environment, defer GitHub Actions failure triage to `github-fix-ci`, commit-introduction isolation to `git-bisect-debugging`, profiler-led hotspot analysis to `performance-profiling`, active security incident command to `security-incident-response`, and postmortem-only reporting to `incident-postmortem`. Do not use for broad feature implementation or speculative hardening without evidence.

Resource-oriented REST/OpenAPI contract design for URI/method semantics, idempotency, pagination, and HTTP status behavior. Trigger when REST contract diffs are detected in paths, methods, schemas, or status semantics, or when request-response transport choice is still unresolved before implementation. Do not use for GraphQL schema authoring, error-taxonomy-only changes, version lifecycle governance, or consumer-provider contract test implementation.

Controlled online experiment workflow for product changes with causal inference, randomization integrity checks, and pre-registered decision criteria. Trigger when ship/no-ship decisions require causal evidence under uncertainty and KPI trade-offs must be quantified. Do not use for feature-flag rollout policy without experiment design, deterministic functional verification, or observability-only analysis.

Provider-consumer compatibility testing for service interface changes. Use when APIs or event schemas evolve and executable contract checks must guard compatibility before release; do not use for UI-only validation or architecture topology decisions.

End-to-end test planning for critical user journeys across integrated systems. Use when release confidence depends on browser/API/dependency behavior as one flow; do not use for isolated unit behavior or pure contract checks.

Risk-based regression suite curation for release gating under time and budget limits. Use when teams must decide what runs always versus conditionally by impact and risk; do not use for implementing a single test type in isolation.

Design executable acceptance criteria for approved requirements by converting goals/specs into binary pass/fail checks with observable outcomes. Use when implementation handoff, QA validation, or release decisions need testable criteria for stable `REQ-*`/`NFR-*` baselines; do not use for requirement discovery, prioritization, or sprint slicing.

Accessibility-first design workflow for specifying semantics, keyboard/focus behavior, readability, and assistive-technology expectations. Use when UI accessibility behavior must be defined before implementation or design sign-off; do not use for backend data modeling or deployment pipeline decisions.

Analyze candidate algorithms for time/space complexity, scalability limits, and resource-budget fit (CPU, memory, I/O, concurrency). Use when feasibility depends on input growth or latency/memory constraints and quantitative bounds are required before implementation; do not use for persistence schema or deployment topology decisions.

Design algorithms by modeling constraints, enumerating candidate strategies, proving correctness, and selecting data structures with explicit tradeoffs. Use when implementation success depends on algorithm choice or decomposition under unclear constraints, from vague outcome requests to concrete directives; do not use for persistence schema or deployment topology decisions.

Consumer-provider contract testing and release-gate design for compatibility matrices, contract assertions, and CI blocking rules across versions and transports. Trigger when API contract diffs are detected but compatibility evidence is missing or stale (contract test pass, consumer-impact mapping, or compatibility matrix update), or when multiple consumers, versions, or transports must be protected by automated gates. Do not use for first-pass API interface design.

GraphQL schema and resolver contract design for type boundaries, nullability, authz, and query-cost safety. Trigger when SDL, resolver behavior, field contracts, or query safety controls are added/changed, and their contract impact is not yet explicitly specified. Do not use for REST/OpenAPI endpoint design, API version lifecycle governance, or standalone error taxonomy design.

API failure-contract design for status mapping, stable error codes, retryability semantics, and traceable error payloads across sync and async transports. Trigger when error behavior, retry semantics, or debuggability fields change in specs or source, or when those rules remain implicit. Do not use for full resource/schema modeling or version-channel policy definition.

API version lifecycle governance for breaking-change classification, deprecation windows, migration planning, and support matrix management across internal and external consumers. Trigger when contract diffs may break consumers (for example required-field removal, semantic change, or channel change), when deprecation/sunset planning is required, or when multiple consumer cohorts must be supported in parallel. Do not use for first-pass endpoint/schema design.

C4 architecture modeling workflow for context, container, and component views that make boundaries and responsibilities explicit. Use when teams need a shared structural model before major implementation or refactoring; do not use as a substitute for decision records.

Clean Architecture workflow for enforcing dependency direction, stable domain boundaries, and use-case-centered application design. Use when teams must separate business rules from frameworks and delivery mechanisms; do not use for isolated module cleanup without boundary implications.

Domain-driven design workflow for bounded context partitioning, aggregate design, and context mapping in complex domains. Use when domain complexity or organizational scaling requires explicit model boundaries; do not use for small CRUD domains without competing language models.

Architecture Decision Record workflow for capturing technical decisions, alternatives, trade-offs, and revision triggers over time. Use when decisions materially affect system behavior, cost, or team workflow; do not use for trivial implementation choices.

Event-driven architecture workflow for asynchronous integration, decoupled workflows, and failure-tolerant event propagation. Use when temporal decoupling and independent evolution are required; do not use when strict synchronous consistency is mandatory across all steps.

Microservices architecture workflow for service boundary design, independent deployability, and distributed operational safety. Use when domain and team structure justify independent service evolution; do not use as a default scaling strategy for all systems.

Modular monolith architecture workflow for strong domain boundaries, transactional consistency, and operational simplicity in a single deployable. Use when teams need fast delivery and coherent data consistency with controlled complexity; do not use when independent runtime scaling boundaries are mandatory.

Define architecture principles and review guardrails before choosing monolith, microservices, serverless, or event-driven options. Use when teams need explicit decision criteria; do not use to record final decisions.

Serverless architecture workflow for event-driven and bursty workloads using managed compute and platform services. Use when elasticity and reduced platform operations justify managed-service constraints; do not use when workload shape requires long-lived stateful control loops.

Architecture trade-off analysis workflow for comparing options with explicit criteria, weighting, and sensitivity under uncertainty. Use when multiple viable architecture choices exist and rationale must be defensible; do not use after architecture direction is already fixed.

Style, review, and refactoring standards for Bash shell scripting. Trigger when `.sh` files, files with `#!/usr/bin/env bash` or `#!/bin/bash`, or CI workflow blocks with `shell: bash` are created, modified, or reviewed and Bash-specific quality controls (quoting safety, error handling, portability, readability) must be enforced. Do not use for generic POSIX `sh`, PowerShell, or language-specific application style rules. In multi-language pull requests, run together with other applicable `*-style-guide` skills.

Design and execute controlled chaos experiments to validate resilience assumptions with explicit steady-state metrics, blast-radius limits, and abort rules. Use when reliability claims need evidence before wider rollout; do not use for active incident command or postmortem-only reporting.

Design CI/CD pipelines with explicit stage order, quality gates, artifact traceability, and rollback safety. Use when build/test/release flow is being created or changed and teams need deterministic release controls before adoption; do not use for application-domain algorithm or schema design.

Run full-scope code review for correctness, maintainability, and regression risk when no single specialty dominates. Use for broad merge-readiness reviews with explicit findings and evidence; if security or performance risk is primary, prioritize `code-review-security` or `code-review-performance` first.

Run performance-focused code review when changes may affect latency, throughput, or CPU/memory/I/O efficiency on critical paths. Use for merge decisions requiring explicit performance-risk findings; do not use for broad non-performance review scope.

Run security-focused code review when changes cross trust boundaries or may affect authentication, authorization, input validation, secrets handling, or sensitive-data exposure. Use for merge decisions requiring explicit security findings; do not use for non-security-only review scope.

Design and review concurrency strategy for shared state, coordination, and contention control. Use when parallel execution or async coordination introduces race/deadlock/liveness risk and explicit pattern selection is required; do not use for persistence schema or deployment topology decisions.

Optimize cloud spend with explicit tradeoffs across cost, performance, and reliability. Use when spend or forecast misses budget targets and teams need concrete optimization actions without violating SLOs or compliance constraints; do not use for purely functional product behavior design.

Style, review, and refactoring standards for C#/.NET codebases. Trigger when `.cs`, `.csproj`, `.sln`, `.props`, `.targets`, or `.razor` artifacts are created, modified, or reviewed and C#-specific quality rules (naming, nullability, async patterns, API design consistency) must be enforced. Do not use for Java/Kotlin or JavaScript/TypeScript style concerns unless C# artifacts are also changed. In multi-language pull requests, run together with other applicable `*-style-guide` skills.

Select data structures using explicit access patterns, mutation behavior, memory limits, and concurrency constraints. Use when implementation correctness or performance depends on choosing between alternatives (array/map/heap/tree/queue/set) under real workload assumptions; do not use for persistence schema or deployment topology decisions.

Database backup and recovery workflow for defining RPO/RTO-aligned retention, restore strategy, and disaster readiness. Use when data durability and recovery guarantees are in scope; do not use for query-only tuning tasks.

Conceptual data modeling workflow for domain entities, relationships, and lifecycle boundaries. Use when teams must align on domain meaning before logical/physical schema decisions; do not use for index-only or migration-only tasks.

Index strategy workflow for balancing read latency, write amplification, and plan stability on critical query paths. Use when query performance depends on index design trade-offs; do not use for high-level conceptual modeling.

Logical database design workflow for table structure, key strategy, constraints, and relational consistency. Use when durable schema semantics must be defined before physical tuning; do not use for query-only optimization tasks.

Schema migration strategy workflow for sequencing changes, compatibility windows, and rollback-safe rollout in live systems. Use when schema evolution impacts running services; do not use for static greenfield schemas without deployment constraints.

Normalization workflow for reducing update anomalies while balancing query practicality and domain invariants. Use when schema redundancy and inconsistency risk need deliberate trade-off decisions; do not use for physical indexing-only tasks.