tidb-change-instruction-critic

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.