Build, secure, and package Electron desktop apps — main/preload/renderer split, contextIsolation-safe typed IPC over a preload bridge, BrowserWindow + application menu + app naming, a strict CSP, and distribution (electron-builder/Forge, productName, code signing). Use when building an Electron app, wiring IPC, hardening security, fixing the app/menu name, or packaging. Do NOT use for web-only React UI (use cleanui) or Expo/React Native.
Write an engineering tech spec (design doc / RFC) that turns an approved PRD into an implementable design. Use when turning a PRD or epic into a design doc, writing an RFC, or answering 'how should we build this'. Do NOT use for product requirements (prd-development) or recording a single architectural decision (adr).
Run a right-sized threat-modeling pass (trust boundaries, STRIDE, abuse cases) on a forming design so security decisions land before Sign-Off 2. Use when a design adds attack surface — a new endpoint, data class, integration, or authz change. Do NOT use for code-diff security review (/security-review), pentests, or compliance audits.
Build and maintain a durable automated E2E suite — Playwright for web, Maestro for Expo/React Native: stable selectors, owned test data, CI gating, and a flake policy with teeth. Use when automating the E2E journeys a test plan defines or fixing a slow/flaky suite. Do NOT use for deciding what to test (test-strategy) or unit tests (tdd).
Run a go/no-go release review producing a scored readiness report — rollout plan, observability, rollback, comms verified before shipping. Use when preparing a release/launch, a go-live checklist, a rollout plan, or 'are we ready to ship'. Do NOT use for store-submission mechanics (expo-deployment) or writing the test plan itself (test-strategy).
Define production health before launch: user-centric SLIs, SLO targets with error budgets, burn-rate alerts that page on user pain (not CPU), and a runbook per pageable alert. Use when designing SLOs, alerts, error budgets, or runbooks. Do NOT use for the go/no-go review (release-readiness) or post-incident analysis (incident-postmortem).
Turn acceptance criteria into a right-sized test plan: unit vs integration vs E2E split, test-double policy, and the merge/release done-bar. Use when planning tests for a feature or epic, deciding the test pyramid, or making coverage decisions ('how should we test this'). Do NOT use for writing test cases in code or reviewing an existing diff.
Run a blameless postmortem: reconstruct the timeline, find contributing factors (never one root cause, never a person) and owned, dated action items. Use after an incident/outage/sev for a postmortem, incident review, 'what went wrong' or RCA. Do NOT use during an active incident (stabilize first; sentry-cli + runbooks) or for retro of normal work.