pm-feedback
Skill2 starsChanged 40 days agoMITView on GitHub
Phase 7, Learn. Pull post-release signal from GitHub issues and other channels into the feedback table, then triage every item into a change request, a new story, a fix task, or wontfix with a reason. Use when the user says "/pm-feedback", "check the issues", "what are users saying", "triage feedback", or after a release.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- konglong87/superPMtheir own version, first seen Mar 27, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- konglong87/superPM★ 84same 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.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
Import each one. external_id is what keeps re-runs from duplicating:
- Distinctive: line 28
Before importing, check what is already there:
- Distinctive: line 57
Before closing triage, ask:
- Very specific: line 77
Never close feedback silently and never let status=new accumulate.
≈ “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
/pm-feedback: close the loop back into the backlog
Shipping opens the next turn. Signal that stays in a GitHub tab is not signal.
1. Pull
gh issue list --state open --limit 100 \
--json number,title,body,labels,createdAt,authorImport each one. external_id is what keeps re-runs from duplicating:
./pm add feedback source=github external_id=<number> kind=<bug|request|praise|confusion> \
title="<title>" body="<first 500 chars>" status=newOther channels are equally valid signal, and get the same treatment:
source=telegram, source=support, source=user for something said directly,
source=analytics for a metric that moved.
Before importing, check what is already there:
./pm q "SELECT external_id FROM feedback WHERE source='github'"2. Triage, every item, no backlog of untriaged
Each item lands in exactly one of four places.
| Read | Action |
| The product does not do what it promised | a fix task under the owning story |
| A new thing the product should do | a new story under the right epic, via /pm-spec |
| The product should work differently than specified | /pm-change, because the spec is what is wrong |
| Not for us, or not now | wontfix with a written reason |
./pm set FB003 status=linked item=STORY002
./pm task title="fix: <thing>" parent=STORY002 type=fix
./pm set FB007 status=wontfixThe reason for a wontfix goes in the GitHub issue reply too, not just the database.
Someone wrote that issue.
3. Look for the pattern, not just the items
Five issues about the same screen are not five bugs, they are one design problem. Before closing triage, ask:
- Which epic or screen collects the most feedback
- Which story is being contradicted by real usage
- What did the risk register in
/pm-discoverpredict, and did it land
A pattern becomes a change request, not five tasks.
4. Feed the next turn
Confirmed patterns become the next milestone's intent. Say this explicitly to the user with a form: here is what the signal says, here are two or three things we could do next, which one. Their call, informed by evidence rather than by whoever complained loudest.
./pm add milestone name="<next outcome>" goal="<what is true when this lands>" status=plannedRule
Never close feedback silently and never let status=new accumulate. Run:
./pm q "SELECT count(*) AS untriaged FROM feedback WHERE status='new'"./pm status surfaces that count, and a growing number there means the loop is broken.
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.