sdlc

Systematic debugging of a reported problem: reproduce, gather evidence from logs, hypothesize, fix, verify. Trigger on "it is broken", "figure out why", "debug", a pasted stack trace, or a prod incident report.

The one standard both the coding work and the reviewers work from: architecture, failure handling, security, scalability, performance, naming, data and migrations, behaviour analytics, and tests. Also defines review scope (the diff plus the code around it) and the one-pass discipline. Load it before writing code and before reviewing any, so what is written and what is judged come from the same list.

Accumulated engineering lessons from real production incidents across the owner's projects. Load PROACTIVELY during development, code review, and planning of any feature that sends notifications, handles errors, or runs on a schedule - and whenever a new incident is analyzed, append its lesson here. Trigger on "check for repeat incidents", "lessons", or when implementing notification/alert/email logic.

Author a tracker-ready task the way a business analyst would, and never let a contradictory one through. Turns an intake into structured requirements, runs a mandatory consistency audit, writes full Gherkin scenarios, and creates the ticket in the project's tracker. Also runs in audit mode against a ticket that already exists. Use for "create a task for X", "write this task up properly", "check this ticket for contradictions", or before any feature leaves the idea stage.

Plan the implementation of a defined task before writing code. Trigger on "plan this out", "plan this", or before starting any multi-file change. Produces the file-level plan, risks, and verification strategy, grounded in the actual code (not assumptions).

Exercise a change end-to-end like a user before declaring it done. Trigger on "test this", "qa this", or after implementing any user-visible change. Drives the real flow (API calls, running app, UI), not just unit tests.

Turn a raw (often dictated) idea into concrete requirements before coding. Trigger on "let us build...", "I want a feature...", "add a feature", or any substantial new-feature request where scope is fuzzy. Produces user-visible behavior, edge cases, acceptance criteria, and a consistency check against the existing app.

Task-scoped review after implementing: regressions, bugs, and smells on the touched files only. Trigger on "review the task", or after finishing a multi-file change before commit. Complements pre-push-review (which gates the push); this one runs right after implementation.