prodcraft

Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.

Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).

Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.

The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.

Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.

Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly

Use when discovery needs evidence about target users, behaviors, and pain points, especially after intake or problem-framing surfaces open questions that must be validated before requirements are written

Use when defining testable criteria that determine whether a requirement is met

Use when reviewed requirements still carry ambiguous business nouns, overlapping concepts, or possible bounded contexts, and the team needs a shared domain model before spec writing, API design, or data modeling.

Use when the work is still at the “what should we build” stage and approved discovery inputs or entry-stack outputs must become prioritized requirements and scope boundaries before specification, architecture, planning, or coding. Not for acceptance criteria, spec review, or implementation.

Use when reviewed requirements need a shared product or technical specification that fixes scope, non-goals, interfaces, rollout concerns, and open questions before architecture or implementation. Skip for routine agile story refinement.

Use when architecture boundaries are already defined and the team must specify stable API contracts between components or for external consumers, especially when backward compatibility, brownfield coexistence, authorization rules, and error semantics must be made explicit before implementation.

Use when the system structure is known and the team must turn domain concepts and architectural boundaries into durable storage schemas, ownership rules, and migration-safe data flow decisions before implementation.

Use when the architecture is defined and the team must turn trust boundaries, sensitive data paths, and attacker assumptions into concrete control design before implementation and audit.

Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.

Use when the architecture is known and the team must choose concrete languages, frameworks, data stores, or infrastructure tools with explicit trade-offs instead of letting implementation drift into ad hoc stack decisions.

Use when reviewed tasks exist and the team must size them with explicit assumptions, confidence, and risk awareness before committing to a timeline or sprint scope.

Use when planned work must be challenged for delivery, dependency, migration, security, or operational risk before the team commits to scope or sequence.

Use when the team has sized work and must choose a realistic iteration scope, sequence, and ownership model that fits capacity and current risk.

Use when reviewed architecture or API contracts must be decomposed into implementation-ready work items, especially when sequencing, reversible brownfield increments, dependency mapping, and vertical slices must be explicit before coding begins.

Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.

Use when existing code is correct but structurally costly to change, and the team needs to improve clarity, coupling, duplication, or seam quality without changing externally observable behavior.

Use when an approved task slice already exists and the team needs a 2-5 minute execution plan with checkpoints, stop conditions, and batch discipline before or during implementation, especially when brownfield seams or review-sensitive changes make ad hoc execution unsafe.

Use when a reviewed task is ready for implementation and the team must drive the work by writing failing tests first, especially when contract behavior, brownfield regressions, unsupported flows, or coexistence safety must be proven before code changes.

Use when a concrete code change is ready for review and the reviewer must evaluate correctness, security, maintainability, test adequacy, contract alignment, and brownfield safety before merge, especially when unsupported flows, backward compatibility, or release-boundary constraints must be enforced.

Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).

Use after implementation or repair work when the reviewer must judge intent realization, requirement coverage, scope consistency, and claim truth before code-review or delivery-completion can accept the work.

Use after code changes when the reviewer must aggressively audit low-level defects, deceptive implementations, improper mocks, fake evidence, and test shortcuts before a delivery claim is trusted.

Use when review feedback has arrived and the author must verify, sequence, and respond to comments without blind agreement, especially when suggestions may conflict with brownfield constraints, contracts, or existing architecture decisions.

Use when a reviewed change, release candidate, or high-risk slice must be challenged for abuse paths, trust-boundary failures, secret handling, dependency risk, or data exposure before release.

Use when a reviewed implementation slice or feature needs a deliberate test plan across unit, integration, contract, and end-to-end layers, especially when brownfield regressions, unsupported flows, coexistence boundaries, or API contracts require explicit coverage beyond the default happy path.

Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.

Use when verified implementation work must be merged, handed off through a PR, preserved for later, or explicitly discarded with a recorded outcome instead of an ambiguous "done".

Use when a release candidate is ready and the team must choose the safest rollout pattern, verification checkpoints, and rollback path for the current risk, blast radius, and operational constraints.

Use when a tested release candidate needs a coordinated go/no-go decision, release window, communication path, and ownership model before deployment proceeds.

Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.

Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.

Use when an operational task or incident needs a concrete step-by-step procedure that another responder can execute safely, especially when rollback, fail-closed containment, coexistence fallback, communication cadence, or evidence capture must be explicit under pressure.

Use when a sprint, release, or incident has ended and the team needs to turn evidence about what worked, what failed, and what should change into a small set of owned follow-up actions.

Use when repeated findings from reviews, incidents, retrospectives, or delivery friction need to be turned into a prioritized technical-debt registry and remediation plan, especially when brownfield seams, release-boundary gaps, or operational workarounds are accruing real engineering cost.