BuzzbeeSCD/openchamber
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(triage): waiting-on-author bucket, read reviews not only comments, deliberate-behavior premise check

Browse Source
This commit is contained in:
Bohdan Triapitsyn
2026-08-29 11:15:02 +03:00
parent 523a62e4db
commit 50159d3747
2 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/pr-review/SKILL.md
+1 -1
View File
@@ -11,7 +11,7 @@ The maintainer directs the project at the product level; they plan and understan
Choose exactly one. When torn between two, the deciding question is always: **what does accepting this cost the maintainer over the next year?** Between PUSH-BACK and MERGE-THEN-FIX specifically, size of the residue never decides — its owner does: *does the fix close the symptom?* then *whose knowledge finishes it?* then *what does a round-trip cost?*
**Product fit is the maintainer's call, not yours.** For a PR that adds or changes user-facing functionality, judge the code but never silently decide the feature is wanted: state the product question explicitly (who asks for this, what it costs the product) and make the verdict conditional on the maintainer's answer when desirability is genuinely open — "PUSH-BACK if you want this feature; DECLINE if you don't". A bug fix has no product question; a new surface always does.
**Product fit is the maintainer's call, not yours.** For a PR that adds or changes user-facing functionality, judge the code but never silently decide the feature is wanted: state the product question explicitly (who asks for this, what it costs the product) and make the verdict conditional on the maintainer's answer when desirability is genuinely open — "PUSH-BACK if you want this feature; DECLINE if you don't". A bug fix has no product question; a new surface always does. So does a PR that **removes or bypasses behavior the code marks as deliberate** — a `skip`/`intentionally`/`on purpose` comment, a guard with a reason next to it, a suppression with its own setting: the PR's premise ("this is a bug") is then the first thing to question, before any of its implementation. Put the product question to the maintainer up front — "the code suppresses X on purpose; the PR treats that as a defect — is it?" — and hold the implementation findings until it is answered; a push-back list on a change whose premise the maintainer rejects is wasted work for both sides.
1. **DECLINE** — the project must not take this change. Grounds:
- *Whim*: functionality that suits the author's personal workflow, not the product's direction.