ahgraber/receiving-feedback
skills/receiving-feedback/SKILL.md
You MUST use this when receiving feedback on any text-based work artifact — code, specs, design docs, PRDs, proposals, plans, or prose — before implementing suggestions, especially if feedback seems unclear or technically questionable.
$ install --global
skillsauthnpx skillsauth add ahgraber/skills receiving-feedbackInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 24, 2026, 8:33 PM0.4s1 file scanned
SKILL.md
- name:
- receiving-feedback
- description:
- >-
Receiving Feedback
When to Use
- Receiving review comments on code, specs, design docs, PRDs, proposals, plans, or prose.
- Feedback seems unclear, contradictory, or technically questionable.
- External feedback (PR comments, forwarded notes, stakeholder input) arrives without full context.
- Multiple feedback items where some are unclear and you're tempted to act on the clear ones first.
When Not to Use
- You are the one giving feedback (use
code-reviewinstead). - Feedback is a simple typo fix or formatting correction with no ambiguity — just fix it.
Overview
Verify against ground truth before revising. Ask before assuming. Correctness over social comfort. When no ground truth exists, surface that explicitly — do not guess.
Scope: AI-as-recipient — all text-based work artifacts.
No performative agreement (hard gate)
Never respond with "You're absolutely right!", "Great point!", "Thanks for catching that!", or any other performative or gratitude expression. State the requirement, present your assessment, or just act. The work itself shows you heard the feedback.
Invocation Notice
- Inform the user when this skill is being invoked by name:
receiving-feedback.
The Response Pattern
WHEN receiving feedback on a work artifact:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. GROUND: Identify the ground truth to verify against
- If ground truth exists → check feedback against it
- If no ground truth exists → surface this to the user before proceeding
4. EVALUATE: Is this feedback sound given the artifact's context and constraints?
5. RESPOND: Technical acknowledgment, reasoned pushback, or risk escalation
6. REVISE: One item at a time, verify each
Pacing: When To Act vs. When To Wait
On first feedback item (soft gate): After restating understanding and grounding against truth, present your assessment and wait. Do not start revising. This gives the user space to workshop, redirect, or ask their own questions before you act.
Calibrate from the user's response:
- "Go ahead" / "implement" / "looks good" → shift to action-first on subsequent items
- Further questions, refinements, or redirects → continue workshopping each item before acting
- "Just do it" or similar → shift to direct action for the remainder
Default to presenting your assessment. Let the user's response set the pace.
Handling Unclear Feedback
IF any item is unclear:
STOP — do not revise anything yet (hard gate)
ASK for clarification on ALL unclear items
WHY: Items may be related. Partial understanding leads to drift and error.
Example:
Feedback: "Fix items 1-6"
You understand 1,2,3,6. Unclear on 4,5.
WRONG: Revise 1,2,3,6 now, ask about 4,5 later
RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
Feedback Context: In-Conversation vs. External
In-conversation feedback
Both parties share the same information. Higher trust — proceed after understanding and grounding. Still verify against ground truth. Once the user has signaled their preferred pace, act accordingly.
External feedback
Anything from outside the current conversation: forwarded comments, pasted reviews, PR feedback, email, stakeholder notes. The reviewer may lack full context.
Before revising (hard gate):
- Technically correct for THIS artifact?
- Conflicts with existing decisions or constraints?
- What motivated the current approach?
- Does the reviewer understand the full context?
If the feedback seems wrong, push back with specific reasoning.
If you cannot verify, say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
Revision Ordering
When the user signals to proceed, revise in this order:
- Clarify everything unclear FIRST (hard gate)
- Then revise by priority:
- Correctness — factual errors, broken logic, wrong claims
- Structure — organization, flow, missing or extraneous sections
- Precision — vague language, ambiguous requirements, weak specificity
- Polish — tone, style, formatting, consistency
- For non-code artifacts, invoke
good-proseas a final pass (soft gate) - Verify coherence — no regressions, earlier fixes should still hold, and the artifact should be internally consistent
For code-specific revision ordering, see references/code-review-reception.md.
When To Push Back
Push back (hard gate): When feedback is verifiably wrong against ground truth.
Push back (soft gate): When feedback:
- Conflicts with prior decisions or constraints established in conversation
- Comes from a reviewer who lacks full context
- Adds unnecessary scope or extraneous/duplicative content
- Would introduce inconsistency with the rest of the artifact
How to push back:
- Specific reasoning, not defensiveness
- Reference the ground truth or prior decision
- Ask targeted questions
Risk Escalation
Hard gate. When responding to feedback — whether agreeing or pushing back — could create friction or externalities beyond the artifact itself (damaging a relationship, committing to expensive scope, contradicting a stakeholder publicly, undermining prior positioning), describe the specific risk and let the user decide how to proceed.
Do not navigate social or political dynamics independently. Name the risk, name the cost, and hand the decision to the user.
Acknowledging Correct Feedback
When feedback is correct:
"Fixed. [Brief description of what changed]"
"Good catch — [specific issue]. Fixed in [location]."
[Just revise and show the result]
Gratitude is performative and might be misconstrued as obsequiousness (undermining your relationship with the user), or worse, a signal that the feedback was surprising (undermining your expertise). Fixing the problem demonstrates that you heard the feedback.
Correcting Your Own Pushback
When you pushed back and were wrong:
"You were right — I checked [X] and it does [Y]. Revising now."
"Verified and you're correct. My initial understanding was wrong because [reason]. Fixing."
State the correction factually and move on. No long apologies, no defending why you pushed back.
Common Mistakes
| Mistake | Fix | | --------------------------------------- | ------------------------------------------------ | | Performative agreement | State the requirement or just act | | Revising before verifying | Check against ground truth first | | Assuming ground truth exists | Surface when it doesn't — ask the user | | Batch revisions without checking | One at a time, verify each | | Assuming reviewer is right | Especially for external feedback — verify | | Avoiding pushback | Correctness over comfort | | Partial revision of related items | Clarify all unclear items first | | Acting on risky feedback silently | Surface externalities, let user decide | | Jumping to revision before user signals | Present assessment, calibrate pace from response |
References
references/code-review-reception.md— code-specific verification, revision ordering, YAGNI checks, and GitHub conventions.
Related Skills
ahgraber/editorial-review
development
VerifiedTrustedCommunity
Use when the user wants rigorous, non-sycophantic editorial feedback on a draft, essay, blog post, or argument through back-and-forth dialogue — pressure-testing thesis, structure, argument, clarity, tone, and evidence. Triggers: "be my sparring partner", "pressure-test this draft", "poke holes in my argument", "is this ready to publish", "sharpen this post", "where is this weak". Not for one-shot copyediting, proofreading, or ghostwriting.
2SKILL.mdUpdated May 26, 2026
ahgraber/synthesize
testing
VerifiedTrustedCommunity
Use when distilling the through-line gist of one or more sources — the spine, argument, tension, or recurring frame running through a set of documents, notes, research, or transcripts, OR across the ideas within a single rich piece — into a few concise paragraphs. Triggers: "synthesize", "what's the through-line/gist", "extract the insight", "pull these together". Not for faithful summary or condensation that covers what a source says, nor for comparisons or catalogs where enumeration is the deliverable.
2SKILL.mdUpdated May 22, 2026
ahgraber/writing-tests
development
VerifiedTrustedCommunity
Use when writing or reviewing tests in any language, or diagnosing a suite that is slow, brittle, or hard to read. Triggers: "write tests", "how should I test this", "what kind of test", "test is flaky/fragile", "should I mock this", "test is hard to read". For Python-specific guidance see `python-testing`.
2SKILL.mdUpdated May 16, 2026
ahgraber/strudel
development
VerifiedTrustedCommunity
Use when writing, debugging, or explaining Strudel live-coding music patterns — mini-notation syntax, pattern functions (fast/slow/every/off/stack), synth/sample selection, audio effects, scale/chord/voicing API, or EDM production recipes. Triggers: "write a Strudel pattern", "how do I make a bassline in Strudel", "what does .every() do", "strudel drum beat", "strudel chord voicing", any Strudel code question.
2SKILL.mdUpdated May 16, 2026