feedback-writer
Skill0 starsChanged 38 days agoMITView on GitHub
Drafts specific, observable, kind workplace feedback using the SBI model - Situation, Behavior, Impact - for both praise and correction. Use when someone asks "help me give feedback to a teammate", "how do I tell my report they keep missing deadlines", "make this feedback less vague", or wants to reinforce a good behavior specifically. Do NOT use for formal performance review documents - use performance-review-writer instead; for feedback on student work, use student-feedback-writer; for mediating an active interpersonal dispute, use conflict-resolution.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- ThomasAiluminated/feedback-writertheir own version, first seen Oct 20, 2026
- SkillMedev/people-ops-recruitingword for word, first seen Oct 5, 2026
- SkillMedev/remote-team-toolkitword for word, first seen Oct 5, 2026
Other versions3 projects use a version of this.
Word for word · 2
- SkillMedev/people-ops-recruiting★ 0100% same
- SkillMedev/remote-team-toolkit★ 0100% same
Edited · 0
None found.
Wrote their own version · 1
- ThomasAiluminated/feedback-writer★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- 1on1-agendaSkill
- eng-status-rollupSkill
- hiring-scorecardSkill
- performance-review-writerSkill
- sprint-retro-facilitatorSkill
- team-health-checkSkill
- tech-debt-prioritizerSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Before drafting, pin down:
- Distinctive: line 48
If any answer is no, redraft before delivering.
- Distinctive: line 83
Do not use the feedback sandwich (praise-criticism-praise) - it dilutes the message and trains people to dread compliments.
- Distinctive: line 84
Do not mind-read: "you don't care about quality" attributes motive.
- Distinctive: line 85
Do not describe character ("you're rude") when you mean behavior ("you interrupted twice").
- Distinctive: line 86
Do not cite an anonymous chorus ("people are saying") - it is unverifiable and reads as an ambush.
- Distinctive: line 87
Do not save everything for the quarterly review - feedback decays.
- Distinctive: line 88
Do not give only corrective feedback - positive SBI builds the trust that makes corrective SBI land.
- Distinctive: line 89
Do not inflate impact to add weight - the first exaggeration the receiver catches discredits the whole message.
- Distinctive: line 97
If part of an ongoing pattern, the message still cites one concrete instance - one specific beats ten generalizations.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Feedback Writer
Vague feedback ("be more proactive") is useless and stressful: the receiver cannot act on it and cannot defend against it. The SBI model - Situation, Behavior, Impact - makes feedback concrete, actionable, and defensible, and it works identically for praise and correction. The costly failure this prevents is the slow one: months of unspoken friction detonating in a review the person never saw coming.
The SBI model
- Situation - when and where it happened. Anchors the feedback in one real moment.
- Behavior - what the person observably did or said. No interpretation, no labels, no motives.
- Impact - the effect on you, the team, or the work. This is the "why it matters."
- Optional fourth step for growth, Intent/Next: ask about intent and agree on a path forward. Ask before prescribing - you may be missing context.
Operating procedure
Step 1: Gather the inputs
Before drafting, pin down:
- The single specific moment (meeting, PR, call, message thread). If the giver says "always" or "never", make them produce one dated instance; if they cannot, the feedback is not ready to give.
- The observable behavior, and whether it passes the camera test: could a camera have recorded it? "Interrupted twice" passes; "was disrespectful" does not.
- The real impact, stated proportionally - what actually happened, not an inflation of it.
- Whether this is praise or correction, and the relationship context (peer, report, manager).
Step 2: Apply the timing and channel rules
- Deliver within a day or two, while the memory is shared. Feedback decays; past a week, the receiver's memory of the moment differs from the giver's and the conversation becomes a dispute about facts.
- Hard or corrective feedback: in person or live. Written channels strip tone and invite rumination.
- Praise or low-stakes notes: written is fine.
- Corrective in private; praise in public - with the person's comfort in mind, since some people hate public praise.
Step 3: Draft in strict SBI order
Situation first, then behavior, then impact, then (optionally) the question about intent and the request. Separate observation from request: first describe, then propose. Keep it to one behavior per conversation - stacking three complaints turns feedback into an ambush.
Step 4: Run the pre-send checklist
- Is the behavior observable (camera test)?
- Is the situation one specific moment, not "always"?
- Is the impact real and stated plainly, without inflation?
- Is there room for their perspective - a genuine question, not a verdict?
If any answer is no, redraft before delivering.
Worked contrast: the same feedback, bad and good
Bad: "You need to be more respectful in meetings. People have noticed you have a communication problem, and it's affecting the team."
Why it fails: no situation (which meeting?), a character label instead of a behavior ("respectful", "communication problem"), an unverifiable anonymous chorus ("people have noticed"), and no path forward. The receiver can only feel accused.
Good: "In yesterday's planning meeting (Situation), you interrupted Maria twice before she finished her point (Behavior). We lost her estimate, and I noticed she went quiet for the rest of the meeting (Impact). What was going on for you there? Going forward, can we make sure everyone finishes before we jump in? (Next)"
Why it works: one dated moment, camera-recordable behavior, honest proportional impact, and a question that leaves room for context before the request.
Positive SBI example
Praise the same way - specific reinforcement of good behavior is often higher leverage than correction:
"In the customer demo this morning (Situation), you paused to confirm the client's goal before showing the feature (Behavior), which made them feel heard and surfaced a need we hadn't planned for (Impact). Keep doing that - it changed the whole tone of the call."
Template
Copy and fill:
Situation: In [FILL: specific meeting/moment, with when], ...
Behavior: ...you [FILL: observable action - passes the camera test]...
Impact: ...which [FILL: real, proportional effect on people or work].
Next: [FILL: question about intent] + [FILL: the specific request going forward]Deliverable
Produce a ready-to-deliver feedback message (or talking script for live delivery) containing: one specific situation, one camera-observable behavior, an honest proportional impact, and an intent question plus request - with a recommendation on channel (live vs. written) and setting (private vs. public) based on whether it is corrective or praise.
Do NOT
- Do not use the feedback sandwich (praise-criticism-praise) - it dilutes the message and trains people to dread compliments. Be direct and kind instead.
- Do not mind-read: "you don't care about quality" attributes motive. Caring is not observable; behavior is.
- Do not describe character ("you're rude") when you mean behavior ("you interrupted twice").
- Do not cite an anonymous chorus ("people are saying") - it is unverifiable and reads as an ambush. Own the observation.
- Do not save everything for the quarterly review - feedback decays; deliver continuously, within a day or two.
- Do not give only corrective feedback - positive SBI builds the trust that makes corrective SBI land.
- Do not inflate impact to add weight - the first exaggeration the receiver catches discredits the whole message.
Quality bar
- Passes all four pre-send checks (camera test, one moment, honest impact, room for their view).
- One behavior per message; observation separated from request.
- Channel and setting match the type: corrective live and private, praise written or public as the person prefers.
- Delivered (or deliverable) within a day or two of the moment.
- If part of an ongoing pattern, the message still cites one concrete instance - one specific beats ten generalizations.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

