docs(commands): add feature-work and bug-work session starters

Conversation-style entry points so the maintainer can start real work
without opening the GitHub UI: feature-work serves a menu of accepted
features (approved scope from the acceptance comment is binding);
bug-work serves verified bugs from the local fix backlog and the
root-cause:found label, severity-first, re-verifying anchors before
fixing. Both close the loop with fixes #N in the eventual commit.

.opencode/commands/bug-work.md

@@ -0,0 +1,15 @@
+---
+description: Pick verified bugs and fix them — "шо в нас по ерорам?" starter
+---
+
+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.** Two sources, both verified:
+   - the local backlog at `.opencode/plans/issue-triage/fix-backlog.md` — LIVE bugs with current file:line anchors, grouped by area, data-loss first;
+   - `gh issue list -R openchamber/openchamber --state open --label root-cause:found --json number,title,labels` for anything newer than the backlog file.
+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 — see the backlog header). 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. Update the backlog file: remove the fixed entries. Never commit or push without being asked.

.opencode/commands/feature-work.md

@@ -0,0 +1,14 @@
+---
+description: Pick an accepted feature and build it — "чим нині займемось?" starter
+---
+
+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.
+
+If nothing carries the `accepted` label yet, say so and suggest running `/triage-issues enhancements` first to build the menu.