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

docs(triage): check for an open PR before taking an issue into work; credit @mattv8 for the CRLF composer fix

Browse Source
This commit is contained in:
Bohdan Triapitsyn
2026-08-28 22:45:29 +03:00
parent 33783999e5
commit cddc366afc
5 changed files with 15 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.opencode/commands/bug-work.md
+5 -4
View File
@@ -7,7 +7,8 @@ Focus, if any: $ARGUMENTS
The maintainer wants to fix real bugs without touching the GitHub UI. Run this as a conversation, not a report:
1. **Gather the menu.** `gh issue list --state open --label root-cause:found --json number,title,labels,comments` — bugs whose intake comment cites a traced mechanism with file:line.
2. **Propose 3–5 candidates**, one line each: the user-visible symptom, the traced mechanism (file:line), and rough size. Order by severity: data-loss and regression first, then whatever matches the maintainer's focus (an area, a platform, "щось маленьке"). Ask which to take — batches of related small fixes in one area are welcome.
3. **Verify before fixing.** Anchors age: confirm the cited mechanism still exists on current main (main moves fast). If it is gone, say so and mark the issue for a fixed-close instead of fixing air.
4. **Fix properly.** Follow AGENTS.md instruction order (matching skills — sync bugs demand `sync-state-invariants`, hot paths `performance-engineering`); minimal fix plus a regression test per local precedent; focused validation.
5. **Close the loop.** When the maintainer confirms and asks to commit, include `fixes #<N>` per bug in the commit message so GitHub closes the issues automatically. Never commit or push without being asked.
2. **Check for a PR in flight.** Before proposing anything, look for an open PR that already fixes it (`gh pr list --state open --search "<N> OR <error string>"`, and the issue's linked PRs). A candidate with an open PR is dropped from the menu and named as such — the fix belongs to its author; the work is reviewing their PR with the `pr-review` skill, never re-implementing it.
3. **Propose 3–5 candidates**, one line each: the user-visible symptom, the traced mechanism (file:line), and rough size. Order by severity: data-loss and regression first, then whatever matches the maintainer's focus (an area, a platform, "щось маленьке"). Ask which to take — batches of related small fixes in one area are welcome.
4. **Verify before fixing.** Anchors age: confirm the cited mechanism still exists on current main (main moves fast). If it is gone, say so and mark the issue for a fixed-close instead of fixing air.
5. **Fix properly.** Follow AGENTS.md instruction order (matching skills — sync bugs demand `sync-state-invariants`, hot paths `performance-engineering`); minimal fix plus a regression test per local precedent; focused validation.
6. **Close the loop.** When the maintainer confirms and asks to commit, include `fixes #<N>` per bug in the commit message so GitHub closes the issues automatically. Never commit or push without being asked.
.opencode/commands/feature-work.md
+4 -3
View File
@@ -7,8 +7,9 @@ Focus, if any: $ARGUMENTS
The maintainer wants to start feature work without touching the GitHub UI. Run this as a conversation, not a report:
1. **Gather the menu.** `gh issue list -R openchamber/openchamber --state open --label accepted --json number,title,labels,comments` — these are features the maintainer already approved; the acceptance comment on each records the approved scope ("welcome shape"), which is binding.
2. **Propose 3–5 candidates**, one line each: what the user gets, rough size (small / medium / large by mechanism, never hours), and which areas it touches. Favor small wins and anything the maintainer's focus hints at. Ask which one to take (or accept "surprise me" — then pick the best value-to-size).
3. **Build it properly.** Re-read the issue and its acceptance comment for the approved scope; follow AGENTS.md instruction order (matching skills, owning DOCUMENTATION.md); implement with tests per local precedent; run the focused validation the change class requires.
4. **Close the loop.** When the maintainer confirms it works and asks to commit, include `fixes #<N>` in the commit message so GitHub closes the issue automatically. Never commit or push without being asked.
2. **Check for a PR in flight.** Before proposing anything, look for an open PR that already implements each candidate (`gh pr list --state open --search "<N> OR <title terms>"`, and the issue's linked PRs). If one exists, the feature is taken — say so and offer to review that PR with the `pr-review` skill instead of building a duplicate.
3. **Propose 3–5 candidates**, one line each: what the user gets, rough size (small / medium / large by mechanism, never hours), and which areas it touches. Favor small wins and anything the maintainer's focus hints at. Ask which one to take (or accept "surprise me" — then pick the best value-to-size).
4. **Build it properly.** Re-read the issue and its acceptance comment for the approved scope; follow AGENTS.md instruction order (matching skills, owning DOCUMENTATION.md); implement with tests per local precedent; run the focused validation the change class requires.
5. **Close the loop.** When the maintainer confirms it works and asks to commit, include `fixes #<N>` in the commit message so GitHub closes the issue automatically. Never commit or push without being asked.
If nothing carries the `accepted` label yet, say so and suggest running `/triage-issues enhancements` first to build the menu.