davidbirchall/squad-skills-shared

Cross-platform accessibility baseline for any user interface other than a Vue/Nuxt web page - CLIs, documents, native and desktop apps, mobile apps, PDFs, emails, and game menus. Covers the perceivable/operable/understandable/robust checklist, contrast and text sizing, keyboard and alternate input, focus order, labels and alt text, motion and flashing, error messaging, colour independence, plain language, CLI specifics (NO_COLOR, --plain, screen-reader-friendly output), document and email specifics, when to apply WCAG 2.2 criteria, automated plus manual checks, and recording an accessibility statement. Load when building or reviewing a non-web UI, CLI output, document, email template, or any deliverable a person must read or operate.

Technology-neutral application security discipline - lightweight threat modelling (assets, actors, trust boundaries, STRIDE), OWASP Top 10 categories, input validation and output encoding, authentication and authorisation principles, least privilege, secure defaults, injection, XSS, CSRF, SSRF, logging without sensitive data, defence in depth, fail-closed behaviour, security review checklist, and vulnerability handling and disclosure. Load when designing, building, or reviewing any feature that handles user input, identity, data access, external calls, or secrets.

Technology-neutral code review practice - reviewing for correctness, design, tests, security, and readability; keeping changes small; self-review with a checklist after a cooling-off period, using an AI assistant as a second reviewer, change descriptions, comment severity labels (blocking, suggestion, nit), automation versus human focus, extra scrutiny for AI-generated code, and what not to review. Load when finishing a change, reviewing your own or AI-generated code, or deciding how a solo developer reviews work.

Technology-neutral systematic debugging - reproducing first, minimal repros, hypothesis-driven investigation, bisecting history and inputs, reading errors and stack traces, checking recent changes, observing with logs, debuggers, and tracing rather than guessing, isolating variables, fixing root causes, regression tests, documenting findings, time-boxing and escalation, heisenbugs and race conditions, and debugging production safely. Load when investigating a bug, failing test, crash, flaky behaviour, or production incident.

Dependency management for any stack - choosing dependencies (need, maintenance health, licence, size, security record, transitive cost), committed lockfiles, pinning vs ranges, reading semver, update cadence and automated update PRs (Renovate and Dependabot principles), batching and grouping, major upgrade process with changelog reading and tests, audit and vulnerability triage by reachability and severity, licence compliance, removing unused dependencies, supply chain risks (typosquatting, install scripts, provenance), vendoring and forks, peer dependencies, deprecations, monorepo single-version policy, and Unity packages. Load when adding, upgrading, auditing or removing a dependency, configuring update bots, or responding to a vulnerability report.

Provider-neutral incident response for a solo operator - severity levels, the lifecycle from detection to resolution, a one-person runbook, a first-15-minutes checklist, mitigating before root-causing with rollback, feature flags or scaling, evidence preservation, a written timeline, blameless solo postmortems with impact, root cause, contributing factors and tracked action items, runbooks, personal on-call plan with alerts to yourself, error budgets, and tracking actions to completion. Load when handling a production incident, setting up alerting, writing a runbook or postmortem, or defining severity and escalation.

Technology-neutral performance discipline - measuring before optimising, budgets and SLOs, profiling to find the real bottleneck (CPU, memory, IO, network, rendering), algorithmic complexity versus constant factors, caching and batching principles, latency percentiles, load testing basics, regression guards in CI, trade-offs against maintainability, avoiding premature optimisation, and writing up findings. Load when something is slow, when setting performance targets, when planning load tests, or when reviewing a change that claims a performance benefit.

Writing small scripts and command-line tools to automate repeatable tasks in Node and TypeScript (default) or shell - when to script versus do by hand, idempotent and safe-by-default behaviour (dry-run, confirmation for destructive actions), argument parsing, exit codes, stdout versus stderr, machine-readable JSON output, logging verbosity, config and environment variables, keeping secrets out of arguments, cross-platform paths, shell safety (quoting, strict mode, avoiding eval), testing scripts, usage via --help, script locations and pnpm package scripts, scheduled runs with failure alerts, and keeping scripts small and boring. Load when automating a repeated task, adding a script or CLI to a project, or reviewing a script for safety.

Technology-neutral software architecture discipline - architectural drivers and quality attributes, boundaries with high cohesion and low coupling, dependency direction, choosing between layered, modular monolith and services (default to simplest), separation of concerns, interfaces and seams, evolutionary architecture and fitness functions, trade-off analysis, avoiding premature abstraction, C4 diagrams at the right level, and lightweight in-repo decision records. Load when shaping or reviewing system structure, drawing module boundaries, choosing a deployment style, introducing an abstraction, or recording an architectural decision.

Technology-neutral testing strategy - test pyramid and trophy, deciding what to test at which level, risk-based testing, unit vs integration vs end-to-end vs contract tests, judgement on test doubles, determinism and flakiness, test data, coverage as a signal not a goal, testing non-deterministic systems, CI feedback speed, definition of done, regression tests for bugs, and mutation and property-based testing. Load when planning how a feature will be tested, choosing test levels, fixing flaky tests, setting coverage or CI policy, or testing non-deterministic or AI-driven behavior.

Technology-neutral technical design process - writing a design doc with problem, goals and non-goals, constraints, options considered with trade-offs, chosen approach, risks, rollout and rollback, testing and observability plan, open questions, and review; sizing the design to the change from one-pager to full doc; using spikes to retire uncertainty; and an inline template. Load when planning a non-trivial feature or change, writing or reviewing a design doc, comparing implementation options, or planning a rollout.

Technology-neutral technical documentation practice - producing accurate, durable knowledge artifacts for the user and future AI sessions - purpose and reader, README structure, the four doc types (tutorial, how-to, reference, explanation), docs-as-code in the repository, keeping docs close to code, API docs, runbooks, diagrams as text with Mermaid, freshness, examples that run, changelog vs docs, and comments that explain why. Load when writing or reviewing a README, guide, API reference, runbook, design record, diagram or code comment, or when deciding where documentation should live.

Framework-neutral TypeScript conventions covering strictness and tsconfig inheritance from a shared base config, unknown over any, non-null assertions, @ts-expect-error with a reason, type vs interface, no enums with an as const alternative, import type, naming, discriminated unions, type guards, satisfies, utility types, schema-derived types (Zod), API response typing, catch clause errors, module augmentation, generics, branded types, and where types live. Load when writing or reviewing any TypeScript, defining shared types, or configuring tsconfig.