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

docs(agents): record the fate of feature decisions

Browse Source 
A maintainer's answer on a FEATURE-DECISION now resolves mechanically:
wanted features get an acceptance comment plus the new accepted label
(never re-asked by later sweeps; label:accepted is the implementation
roadmap), declined ones get the drafted close; conditional answers are
recorded as the accepted scope.
This commit is contained in:
Bohdan Triapitsyn
2026-08-28 13:48:54 +03:00
parent f826f41f55
commit 5978b6cb14
1 changed files with 4 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/triage-issues/SKILL.md
+4 -1
View File
@@ -12,7 +12,10 @@ Turn an unbounded issue queue into a short list of maintainer decisions. Three p
- **CLOSE-FIXED** — behavior fixed by a merged change. Ready action: close comment naming the commit/PR and the release that carries it.
- **CLOSE-DUPLICATE** — same failure as an existing issue. Keep the issue with the better evidence, close the other naming it.
- **CLOSE-DECLINE** — a feature or behavior the product should not take (the `pr-review` skill's whim/scope grounds apply). Ready action: honest close comment; where a real ache underlies it, salvage per the pr-review skill's rule.
- **FEATURE-DECISION** — a plausible feature only the maintainer can judge. Ready action: the product question in one line plus drafted comments for both answers. These go to the maintainer as a numbered list, like the PR triage's Product fit block.
- **FEATURE-DECISION** — a plausible feature only the maintainer can judge. Ready action: the product question in one line plus drafted comments for both answers. These go to the maintainer as a numbered list, like the PR triage's Product fit block. The maintainer's answer resolves the issue's fate mechanically:
- **"так" (wanted)** → post the acceptance comment (what was approved and, when known, the welcome implementation shape), add the `accepted` label, and leave it open. `accepted` marks the decision as made — later sweeps never re-ask an `accepted` issue, and `label:accepted` is the implementation roadmap for agents and contributors.
- **"ні" (declined)** → post the drafted decline comment (with ache salvage where one underlies it) and close as not planned.
- A conditional answer ("так, але тільки як настройка", "ні в такому вигляді, але X — так") is folded into the posted comment verbatim in spirit — the maintainer's condition becomes the recorded scope.
## Phase 1 — Mechanical sweep