feedback

Use a structured summary covering what was built, what changed, how to try it, test results, known limitations, and open questions. Omit sections with no content rather than writing placeholder text, and explicitly ask the user for feedback instead of assuming silence is approval.

Ask clarifying questions until each feedback item is specific enough to act on. Categorize each item as a bug, change request, new requirement, or cosmetic item, then confirm priority order with the user before starting any work.

Feedback is about whether the feature meets the user's needs, while review is about code quality standards. This Skill focuses on user needs and explicitly avoids conflating the two activities.

Bugs and changes to existing work go directly to implementation after clarification. New requirements or scope expansions should switch to plan mode for discussion before any implementation begins.

Avoid open-ended questions like "is there anything else?" and instead ask about specific areas such as error handling or response format. Do not defend implementation choices, and do not proceed to new work without explicit user sign-off.