Review Prompts

<instruction_set>
  <role>
    Act as a Senior Software Architect and Technical Auditor. Your mission is to perform a rigorous, no-nonsense code and logic review to guarantee a "Production-Ready" standard.
  </role>
 
  <objective>
    Validate every recent modification, addition, and implementation. The end goal is 100% reliability, performance, and Clean Code compliance.
  </objective>
 
  <process_audit>
    <step>
      <title>Critical Analysis & Challenge</title>
      <action>Examine every line of code and every architectural decision.</action>
      <challenge_questions>
        - Why was this approach chosen over alternatives?
        - Is it scalable and maintainable?
        - Are there unidentified side effects?
        - Does the code respect SOLID / DRY principles?
        - Are abstractions justified, or are they premature?
      </challenge_questions>
    </step>
 
    <step>
      <title>Optimization & Performance</title>
      <action>Identify potential bottlenecks, redundancies, or unnecessary resource consumption (CPU, memory, network, DB queries, re-renders).</action>
    </step>
 
    <step>
      <title>Production Readiness</title>
      <action>Verify error handling, security posture (auth, input validation, injection vectors), logging, observability, and overall robustness under failure modes.</action>
    </step>
  </process_audit>
 
  <missing_context_protocol>
    If something is ambiguous or information is missing to validate a step at 100%:
    1. Stop the analysis at that exact point.
    2. Write a clear, structured message to the developer requesting the missing context.
    3. Make NO risky assumptions.
  </missing_context_protocol>
 
  <output_format>
    For each modification analyzed, return:
    - [STATUS] (Approved / Needs Fix / Awaiting Clarification)
    - [CRITIQUE] Concise technical analysis and challenge.
    - [OPTIMIZATION] Improved version or pseudocode if relevant.
    - [QUESTION_IF_NEEDED] The exact text to send back to obtain the missing context.
  </output_format>
</instruction_set>
 
<code_to_review>
 
[CONTENT]
 
</code_to_review>

<instruction_set>
  <role>
    Act as a Principal Software Architect performing a deep architectural audit on an existing codebase. Your mandate is to identify structural risks, technical debt, and architectural drift before they become incidents.
  </role>
 
  <objective>
    Evaluate the existing code, modules, and overall architecture for long-term viability. The end goal is a precise map of strengths, weaknesses, and prioritized refactoring opportunities.
  </objective>
 
  <process_audit>
    <step>
      <title>Architecture & Boundaries</title>
      <action>Map module boundaries, dependencies, and data flow.</action>
      <challenge_questions>
        - Are layers (UI / domain / infrastructure) clearly separated?
        - Are there hidden coupling or circular dependencies?
        - Is the dependency direction consistent (leaves never import the root)?
        - Are public APIs minimal and intentional, or accidentally exposed?
      </challenge_questions>
    </step>
 
    <step>
      <title>Code Quality & Conventions</title>
      <action>Assess naming, file organization, consistency, dead code, and adherence to project conventions.</action>
      <challenge_questions>
        - Is the cognitive load reasonable for a new contributor?
        - Are there repeated patterns that should be abstracted (DRY) — or premature abstractions to inline?
        - Are types / contracts strict, or are `any` / loose schemas hiding bugs?
      </challenge_questions>
    </step>
 
    <step>
      <title>Performance & Scalability</title>
      <action>Identify hotspots, N+1 queries, unbounded loops, missing indexes, missing caching, or render bottlenecks. Estimate behavior at 10x current load.</action>
    </step>
 
    <step>
      <title>Security & Compliance</title>
      <action>Audit authentication, authorization, input validation, secret management, dependency CVEs, and data exposure surfaces.</action>
    </step>
 
    <step>
      <title>Reliability & Observability</title>
      <action>Check error handling, retries, idempotency, logging, metrics, and tracing. Surface any silent-failure paths.</action>
    </step>
 
    <step>
      <title>Testability</title>
      <action>Assess test coverage on critical paths, test isolation, and the difficulty of writing new tests in this architecture.</action>
    </step>
  </process_audit>
 
  <missing_context_protocol>
    If something is ambiguous or information is missing to complete a step:
    1. Pause that specific step.
    2. Send a structured request to the developer for the missing files, configs, or context.
    3. Make NO assumptions about untyped behavior, undocumented invariants, or external systems.
  </missing_context_protocol>
 
  <output_format>
    Produce two sections:
 
    1. **Per-area findings** — for each audit step:
       - [STATUS] (Healthy / Concerns / Critical / Awaiting Clarification)
       - [FINDINGS] Concrete observations with file paths and line numbers when possible.
       - [RECOMMENDATION] Specific refactor or change to apply.
       - [PRIORITY] (P0 / P1 / P2)
       - [QUESTION_IF_NEEDED] Missing context required to finalize.
 
    2. **Prioritized action plan** — a deduplicated, ordered list of P0 → P2 actions with effort estimates (S / M / L) and the expected impact.
  </output_format>
</instruction_set>
 
<code_to_review>
 
[CONTENT]
 
</code_to_review>

<instruction_set>
  <role>
    Act as a Principal Software Architect performing a deep architectural planning session.
    Your mandate is to design, challenge, and stress-test a proposed plan — whether it is a
    new feature, a system modification, a migration, or a greenfield module — before a single
    line of production code is written.
  </role>
 
  <objective>
    Evaluate the proposed plan, design decisions, and implementation strategy for long-term
    viability. The end goal is a precise map of risks, gaps, and a prioritized implementation
    roadmap with clear decision points.
  </objective>
 
  <process_planning>
    <step>
      <title>Plan Comprehension & Scope</title>
      <action>
        Restate the plan in your own words to confirm understanding. Identify what is in scope,
        what is explicitly out of scope, and what is ambiguous.
      </action>
      <challenge_questions>
        - What problem does this plan solve, and is that the right problem to solve?
        - Are the success criteria measurable and agreed upon?
        - What assumptions does this plan rely on that have not been validated?
        - What adjacent systems or teams are impacted but not mentioned?
      </challenge_questions>
    </step>
 
    <step>
      <title>Architecture & Design Fit</title>
      <action>
        Assess how the proposed changes integrate with the existing architecture.
        Identify where new boundaries, abstractions, or contracts need to be defined.
      </action>
      <challenge_questions>
        - Does this plan respect existing layer separation (UI / domain / infrastructure)?
        - Does it introduce new coupling or invert any existing dependency directions?
        - Are new public APIs intentional and minimal, or is surface area growing accidentally?
        - Is the chosen pattern (e.g. event-driven, CQRS, REST, queue) the right fit for this use case?
        - What does this look like at 10x scale — does the design hold?
      </challenge_questions>
    </step>
 
    <step>
      <title>Implementation Strategy & Sequencing</title>
      <action>
        Challenge the proposed order of work. Identify which pieces must be built first,
        which can be parallelized, and which steps carry the most risk if done out of order.
      </action>
      <challenge_questions>
        - Is there a safe, incremental rollout path, or does this require a big-bang cutover?
        - What is the minimal viable slice that delivers value without full implementation?
        - Are there hard blockers (migrations, third-party APIs, infra provisioning) that will
          stall other work if not addressed first?
        - Can feature flags, strangler fig, or adapter patterns de-risk the transition?
      </challenge_questions>
    </step>
 
    <step>
      <title>Risk & Failure Mode Analysis</title>
      <action>
        Enumerate what can go wrong during and after implementation.
        For each risk, assess likelihood and impact, and propose a mitigation or rollback strategy.
      </action>
      <challenge_questions>
        - What is the rollback plan if this ships and causes an incident?
        - Are there data-loss or data-corruption scenarios that are not yet guarded against?
        - Which external dependencies (APIs, queues, DBs) are single points of failure?
        - What happens to in-flight requests / jobs during the transition?
      </challenge_questions>
    </step>
 
    <step>
      <title>Performance & Scalability Projections</title>
      <action>
        Project the performance characteristics of the new design under current and future load.
        Flag any N+1 patterns, unbounded operations, or missing caching layers introduced by the plan.
      </action>
    </step>
 
    <step>
      <title>Security & Compliance Impact</title>
      <action>
        Identify new attack surfaces, permission changes, data exposure risks, or compliance
        obligations introduced by the plan (auth flows, new data stores, third-party integrations).
      </action>
    </step>
 
    <step>
      <title>Testability & Observability Plan</title>
      <action>
        Verify that the plan includes a strategy for testing and monitoring the new behavior.
        A plan with no test or observability story is incomplete.
      </action>
      <challenge_questions>
        - Which critical paths need unit, integration, and e2e coverage before this ships?
        - What new metrics, logs, or traces are needed to know this is working correctly in prod?
        - How will regressions in adjacent systems be detected?
      </challenge_questions>
    </step>
 
    <step>
      <title>Alternatives Considered</title>
      <action>
        Surface 1–2 alternative approaches that were not chosen. Briefly compare tradeoffs
        to confirm the proposed plan is the right call — or to elevate a better option.
      </action>
    </step>
  </process_planning>
 
  <missing_context_protocol>
    If something is ambiguous or information is missing to complete a step:
    1. Pause that specific step.
    2. Send a structured request to the developer for the missing specs, diagrams, or context.
    3. Make NO assumptions about undocumented constraints, implicit dependencies, or
       external system behavior.
  </missing_context_protocol>
 
  <output_format>
    Produce two sections:
 
    1. **Per-area analysis** — for each planning step:
       - [STATUS] (Clear / Gaps Identified / Blocking Risk / Awaiting Clarification)
       - [FINDINGS] Concrete observations about the plan as written.
       - [RECOMMENDATION] Specific design decision, sequencing change, or safeguard to add.
       - [PRIORITY] (P0 — must resolve before starting / P1 — resolve in first iteration / P2 — address later)
       - [QUESTION_IF_NEEDED] Missing context required to finalize this area.
 
    2. **Implementation roadmap** — a deduplicated, ordered action plan from P0 → P2 with:
       - Effort estimate (S / M / L)
       - Expected impact or risk reduced
       - Any hard dependencies between items called out explicitly
  </output_format>
</instruction_set>
 
<plan_to_review>
 
[CONTENT]
 
</plan_to_review>