• Can I restate this requirement in my own words?
• Is this technically sound for THIS codebase?
• Does this break existing functionality?
• Is there a reason for the current implementation?

CRITICAL: If ANY item is unclear, STOP. Ask for clarification on ALL unclear items before implementing ANYTHING.

Example:

User: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.

✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
❌ Implement 1,2,3,6 now, ask about 4,5 later

Step 3: Implement Changes

Follow implementation order:

1. Blocking issues (breaks, security)
2. Simple fixes (typos, imports)
3. Complex fixes (refactoring, logic)

For each fix:

• Implement one at a time
• Test individually
• Commit individually (frequent commits)

YAGNI check: If reviewer suggests "implementing properly", grep for actual usage:

grep -r "endpointName" .

If unused: "This endpoint isn't called. Remove it (YAGNI)?"

Step 4: Run Tests, Lint, and Format

Reference finishing-a-development-branch skill (Steps 1-2):

See .claude/skills/finishing-a-development-branch/SKILL.md

• Run tests: npm test (or project equivalent)
  • If tests fail, fix before proceeding
• Run type checks: npm run lint:*-types (if available)
  • If type errors, fix before proceeding
• Run formatter: npm run format
• Run linter: npm run lint
• Verify changes: git diff --stat

Step 5: Push Updates

Push changes to PR:

git push

Step 6: Summary and Next Action

Report what changed:

"Code review feedback addressed:

• Fixed [item 1]: [brief description]
• Fixed [item 2]: [brief description] ...

Changes pushed to PR. Options:

1. Done - PR is ready for re-review
2. More feedback - Additional changes needed
3. Show changes - Review diffs before marking done

Which would you like?"

Quick Reference Checklist

• Create TodoWrite for all feedback items
• Fetch PR comments (gh pr view --comments)
• Clarify ALL unclear items before implementing ANY
• Implement in order: blocking → simple → complex
• Test each fix individually
• Run tests, type checks, formatting, linting (finishing-a-development-branch)
• Push updates
• Summarize changes and ask for next action

Response Tone Guidelines

Forbidden:

• "You're absolutely right!" / "Great point!" / "Thanks for..." (performative agreement)
• Implementing before verifying against codebase
• Proceeding with unclear feedback

Required:

• Verify suggestions against codebase reality before implementing
• Push back with technical reasoning if suggestion breaks things or violates YAGNI
• Ask for clarification on ALL unclear items before implementing ANY items
• State fixes factually: "Fixed. [what changed]" or just show the code

…

systematic-debugging

用四阶段系统化排查框架定位缺陷根因，再制定可靠修复方案。

council-review

调用多模型交叉审查代码变更、PR与高风险修改，辅助发现缺陷与争议点