compose:feedback

Evaluates code review feedback with technical verification before implementation.

Updated Jun 27, 2026
One-click install
npx skills add https://github.com/HKUST-QUANT-SOCIETY/quantcode --skill compose-feedback-hkust-quant-society
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: compose:feedback
Source: https://github.com/HKUST-QUANT-SOCIETY/quantcode/tree/main/.opencode/meta-skills/feedback
Command: npx skills add https://github.com/HKUST-QUANT-SOCIETY/quantcode --skill compose-feedback-hkust-quant-society

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Receiving code review feedback often triggers reflexive agreement or blind implementation, leading to broken code, wasted effort on unnecessary features, and unverified changes. This Skill enforces a disciplined response pattern: read, understand, verify against the codebase, then implement or push back with technical reasoning. ## Core Features & Use Cases - Structured Response Pattern: Guides you through reading, restating, verifying, evaluating, responding, and implementing feedback one item at a time with individual testing. - Source-Specific Handling: Distinguishes trusted feedback from your human partner versus external reviewer suggestions that require skepticism and codebase verification. - YAGNI Enforcement: Checks whether suggested features are actually used in the codebase before implementing them, preventing speculative over-engineering. - Use Case: A reviewer suggests removing legacy compatibility code. Instead of agreeing, you verify the build target and discover the API requires backward compatibility, then respond with the technical constraint and propose options. ## Quick Start Apply the feedback skill to evaluate the review comments on my pull request before implementing any changes.

Frequently Asked Questions about compose:feedback

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I respond to code review feedback on a pull request?

Read all feedback completely, restate each requirement in your own words, verify suggestions against the actual codebase, then implement one item at a time with individual testing. Avoid performative agreement like "great point" and instead state the fix or ask clarifying questions.

How do I handle unclear code review comments?

Stop and ask for clarification before implementing anything, presenting your interpretations as options. Partial understanding of multi-item feedback leads to wrong implementations, so clarify all ambiguous items first even if other items are clear.

When should I push back on reviewer suggestions?

Push back when a suggestion breaks existing functionality, violates YAGNI for unused features, is technically incorrect for your stack, or conflicts with prior architectural decisions. Use technical reasoning and reference working code rather than being defensive.

Should I implement every suggestion from external reviewers?

No. External feedback is a suggestion to evaluate, not an order. Check whether it is technically correct for your codebase, breaks existing functionality, works on all target platforms, and whether the reviewer understands the full context before implementing.

What is the YAGNI check for code review feedback?

When a reviewer suggests implementing a feature "properly", search the codebase for actual usage of that code path first. If nothing calls it, propose removing it instead of expanding it, avoiding speculative features that add maintenance burden.