A structured root-cause investigation protocol for complex, ambiguous, or multi-layer technical problems. Activate this skill whenever: a problem has resisted two or more fix attempts; the root cause is unknown or assumed; you are tempted to try a variation of something that already failed; a system has multiple interacting layers (hardware, OS, runtime, middleware, config, network); the user says "ultrathink", "think deeper", "figure out why", "stop guessing", "find the root cause", or "it's still broken after your fix". Also activate proactively when you catch yourself about to write a fix before you have verified the cause — that instinct is the signal the protocol is needed. The protocol enforces three disciplines that distinguish root-cause investigation from trial-and-error: (1) explicit THOUGHT/ACTION/OBSERVATION cycles, (2) a hard gate that blocks implementation until the cause is verified by direct evidence, and (3) structured escalation when in-process diagnostic tools are exhausted.
Orchestrates BMAD implementation workflows automatically — both the full Phase 4 epic/story pipeline and the Quick Flow for small, well-understood changes. Use this skill whenever the user wants to: (1) automate Phase 4 implementation ("auto implement", "start implementation", "begin phase 4", "automatic working on phase 4", "implement all stories", "process the epics"), (2) check implementation progress or status ("what's the status?", "how many stories are done?"), (3) resume a previously interrupted session ("continue from where we left off", "resume"), (4) implement a small self-contained change without going through full BMAD planning ("quick dev", "quick flow", "implement this change", a described bug fix, refactor, or small feature, patch). When the user describes a small change or asks to quickly implement something, route to Quick Flow — `bmad-quick-dev` handles intent-to-code directly without a separate spec step. If a multi-story project is already in flight (`sprint-status.yaml` exists) AND the us
E2E and integration testing for TypeScript/NestJS projects using Jest, supertest, and real infrastructure via Docker (Kafka, PostgreSQL, MongoDB, Redis) with the Given-When-Then pattern. Use whenever the user is working on `.e2e-spec.ts` files or anything under `test/e2e/`, or asks to set up, write, review, run, debug, or optimize E2E or integration tests — including flaky tests, docker-compose for tests, Kafka/Redpanda consumers, test isolation, or GWT compliance.
Unit testing for TypeScript/NestJS projects using Jest, @golevelup/ts-jest (DeepMocked/createMock), and in-memory databases, with AAA structure. Use whenever the user is working on `.spec.ts` files or asks to set up Jest, write/add tests for a service/usecase/controller/guard/interceptor/pipe/filter, mock dependencies, review test quality or coverage, run unit tests, debug failing or flaky tests, or optimize test performance and open handles.
Use when investigating and documenting a production incident, outage, data corruption event, or post-mortem — guides evidence collection during the investigation AND produces a rich, reproducible Root Cause Analysis report. Trigger on phrases like "write an RCA", "post-mortem for X", "document this incident", "what went wrong with...", "the pipeline broke yesterday, help me investigate", or any time the user is debugging a recently-resolved incident and wants a writeup. Also use proactively when the user finishes resolving an incident in-session and the resolution context is fresh — offer to capture it as an RCA before details fade.
Create structured technology trade-off analysis documents with scored comparison matrices. Use this skill whenever the user wants to compare technologies, evaluate architectural options, analyze build-vs-buy decisions, assess migration strategies, or produce any decision document that compares multiple approaches across weighted dimensions. Triggers on: 'trade-off analysis', 'tradeoff', 'comparison matrix', 'evaluate options', 'which technology should we use', 'compare approaches', 'pros and cons of', 'build vs buy', 'migration analysis', 'consolidation analysis', 'technology selection'. Also use when the user has completed technical research and wants to structure findings into a decision document.
Loads documents fully into the main agent's context so the agent can answer questions, summarize, or work with that content in subsequent turns. Use whenever the user wants to ingest, read, study, review, absorb, or pull in documents — especially when they say things like "load these docs", "read all of these", "ingest this folder", "pull in these PDFs", "load all docs in X", or paste a list of file paths/URLs and ask you to read them. Handles local files (text, code, markdown, PDFs, notebooks, images), entire folders (recursively), and remote URLs. The skill is single-turn — once the agent reports "DONE", it deactivates until the user invokes it again.
Manual test planning, writing, reviewing, executing, and maintaining test cases. Use when: user asks to write test cases, create a test plan, run manual tests, review test coverage, update tests after feature changes, or asks 'how should I test this'. Also trigger after implementing features that change system behavior — per CLAUDE.md, updating the manual test plan is mandatory. Covers API/backend, frontend, pipeline/workflow, AI/LLM, and infrastructure testing patterns.