Tidb Change Instruction Critic

---
name: tidb-change-instruction-critic
description: Use when implementing a user- or reviewer-prescribed code change (including review comments with suggested fixes or options), especially when the requested edit may be risky, incomplete, ambiguous, or misaligned with TiDB correctness and compatibility constraints.
---

# TiDB Change Instruction Critic

## Trigger

Use this skill when:

- The request specifies a concrete implementation direction (for example: "change it this way", "use option B", "just follow this patch idea").
- The task is to address review comments that include direct fix instructions or multiple solution options.
- The requested approach might be correct, but the risk or tradeoff is unclear.

## Principle

Treat every implementation instruction as a hypothesis, not a command to apply blindly.
First validate problem understanding and constraints, then select the solution that best preserves correctness and contract intent; use risk as a secondary filter.

## Workflow

1. Decompose the instruction.
   - Separate `intent` (what problem is being solved), `constraints` (must-have boundaries), and `proposed method` (how to solve it).
   - Mark each item as either `mandatory` or `negotiable`.
2. Reconstruct the actual problem before coding.
   - Locate concrete evidence in code/tests/review context for the defect or concern.
   - Restate the issue in one or two precise sentences before implementation.
3. Evaluate solution candidates.
   - Always evaluate the requested approach.
   - When feasible, compare with at least one alternative.
   - Judge by correctness, compatibility, performance, maintenance cost, and validation coverage.
4. Choose and justify.
   - Prioritize correctness and behavior-contract fit over mechanical risk minimization.
   - Use lower-risk preference only when multiple candidates satisfy the same contract and intent.
   - If the requested method is weaker than an alternative, explain why and propose the better option.
5. Share analysis summary before coding.
   - Provide a short self-analysis summary: reconstructed problem, compared options, chosen solution, and why alternatives were rejected.
6. Challenge gate before implementation.
   Ask the user for clarification before coding when any condition holds:
   - Requirement or review intent is ambiguous or internally conflicting.
   - Requested change may alter SQL semantics, compatibility, or distributed behavior in non-obvious ways.
   - Requested change increases blast radius (broad refactor, cross-module behavior shift, fragile workaround).
   - Validation plan cannot prove safety with scoped tests.
   Keep questions concise and decision-enabling; do not proceed on assumptions.
7. Implement after alignment.
   - Keep diff minimal and focused on agreed intent.
   - Add or update regression coverage when behavior changes or bugs are fixed.
   - Report residual risks explicitly if any tradeoff remains.

## Question Patterns

- "The requested fix and current behavior contract conflict on `<constraint>`. Which priority is correct?"
- "I can implement `<requested approach>`, but `<alternative>` better matches `<contract>` with acceptable risk. Which should we proceed with?"
- "This change may impact `<scope>`. Should I keep scope limited to `<safe scope>` in this patch?"

## Output Checklist

- Clear problem statement confirmed from evidence.
- Chosen solution and reason for rejecting alternatives.
- Short self-analysis summary shared before implementation.
- Any user-confirmed risk decisions captured before coding.
- Validation scope aligned with change risk.