respond-review
Act on a reviewer agent's feedback systematically — categorize findings, apply fixes, verify tests still pass. Use after request-review returns a report, or when user wants to work through code review findings.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 292
- Forks
- 23
01 前言 Front Matter
- name
- respond-review
- model
- sonnet
- description
- Act on a reviewer agent's feedback systematically — categorize findings, apply fixes, verify tests still pass. Use after request-review returns a report, or when user wants to work through code review findings.
03 SKILL.md 正文
Respond Review
HARD GATE — HARD GATE — Every reviewer comment must be addressed (fix, disagree + document reason, or ask clarification). Do NOT ignore feedback and merge.
Work through reviewer findings systematically. Don't apply changes blindly — categorize first, then decide, then fix, then verify.
Process
1. Read the full review report
Read every finding before acting on any of them. Get the full picture first.
2. Categorize findings
For each finding, assign a category:
| Category | Meaning | Action |
|---|---|---|
| must-fix | Correctness bug, security issue, test failure, CONVENTIONS.md violation | Fix before proceeding |
| should-fix | Code quality issue, naming, clarity — worth fixing but not blocking | Fix if time allows |
| consider | Architectural suggestion, alternative approach — may or may not apply | Discuss with user |
Create a numbered list of all findings with their categories.
3. Confirm with user (for consider-category items)
For each "consider" item, briefly describe the trade-off and ask: "Apply, skip, or discuss?"
4. Apply must-fix items first
Fix every must-fix item. For each one:
- Describe what you're changing and why
- Make the change
- Run the verify command if one exists for this area
5. Apply should-fix items
Apply should-fix items. If any are large enough to warrant their own commit, note them separately.
6. Run the full suite
After all changes are applied:
<full test command>
<typecheck command>
<lint command>
- [ ] All tests pass
- [ ] No type errors
- [ ] No lint violations
7. Report
Summarize what was applied and what was skipped:
Applied (must-fix): #1, #2, #3
Applied (should-fix): #4
Skipped (consider): #5 — agreed with user to defer
All tests pass.
Suggest next skill: commit-message.
04 同仓库更多 Skills
skill-verify-fail-open-fixture
Negative-path fixture for run-skill-verify.sh — must never PASS.
negative-path
暂无简介
write-document
Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs/ directory.
wire-observability
Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.
wire-ci
CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.
visual-dashboard
Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers/dashboard/. Reads specs/state.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.