azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity

bug-tracker: add input-side check — look up matching issue before starting work

Browse Source 
The close-with-comment rule only covers the output side. Without
checking the tracker when starting work, fixes get committed but
matching issues stay open (exactly what happened with #13).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Howard Enos
2026-07-19 09:21:17 -07:00
parent 7b1093cad7
commit b57f098487
2 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.claude/CLAUDE.md
View File

@@ -80,8 +80,10 @@ production, data-loss. Detail: EXTENDED + `.claude/OLLAMA.md`.
tracking. If the bug is reproducible, affects a skill/tool/harness component, and won't be tracking. If the bug is reproducible, affects a skill/tool/harness component, and won't be
fixed in this session → file it as a Gitea issue via the `bug-tracker` skill (confirm fixed in this session → file it as a Gitea issue via the `bug-tracker` skill (confirm
title/priority with the user). The errorlog captures patterns for linting; the tracker title/priority with the user). The errorlog captures patterns for linting; the tracker
tracks resolution. When fixing a tracked bug, update/close the issue with a commit ref tracks resolution. **When starting work on a bug/feature/skill task, check the tracker
comment — never close silently. See `SKILL_ROUTING.md` "Bug tracking" block. for a matching issue first** — this is the step that connects the fix to the close.
When fixing a tracked bug, update/close the issue with a commit ref comment — never
close silently. See `SKILL_ROUTING.md` "Bug tracking" block.
- **Log preventable friction too (`--friction`):** any time you waste tokens on a preventable, repeatable self-inflicted error — harness/env/tool misuse (Git-Bash `/tmp` path mismatch, shell env not persisting between Bash calls, passing huge args on the command line, PowerShell var case-collisions, etc.) — log it: `bash .claude/scripts/log-skill-error.sh "<context e.g. bash/env>" "what wasted tokens + the fix" --friction [--context "ref=<memory-or-rule>"]`. **If it repeats something already in memory or CLAUDE.md, that's the highest-value entry** — it means a rule/memory isn't working; cite the ref. This log is the corpus we lint to build better CLAUDE.md rules and to clean stale/misleading memory. Goal: stop paying twice for the same mistake. - **Log preventable friction too (`--friction`):** any time you waste tokens on a preventable, repeatable self-inflicted error — harness/env/tool misuse (Git-Bash `/tmp` path mismatch, shell env not persisting between Bash calls, passing huge args on the command line, PowerShell var case-collisions, etc.) — log it: `bash .claude/scripts/log-skill-error.sh "<context e.g. bash/env>" "what wasted tokens + the fix" --friction [--context "ref=<memory-or-rule>"]`. **If it repeats something already in memory or CLAUDE.md, that's the highest-value entry** — it means a rule/memory isn't working; cite the ref. This log is the corpus we lint to build better CLAUDE.md rules and to clean stale/misleading memory. Goal: stop paying twice for the same mistake.
- **Windows:** ensure `bash` resolves to Git-for-Windows MSYS bash, not the WSL stub; write - **Windows:** ensure `bash` resolves to Git-for-Windows MSYS bash, not the WSL stub; write
`.claude/current-mode` with a relative/forward-slash path only (never a backslash Windows `.claude/current-mode` with a relative/forward-slash path only (never a backslash Windows

5
.claude/SKILL_ROUTING.md
View File

@@ -57,6 +57,11 @@ title/priority). This is in addition to `log-skill-error.sh` (the errorlog captu
patterns; the tracker tracks resolution). Do NOT file: client machine problems, vendor patterns; the tracker tracks resolution). Do NOT file: client machine problems, vendor
API limitations, one-off env/friction issues already resolved, or transient errors. API limitations, one-off env/friction issues already resolved, or transient errors.
When **starting work** on a bug, feature, or skill task, check the tracker first:
`py tracker.py list --repo <repo> --type <type>` — if a matching issue exists, note the
number and work against it. This is the step that connects "fix the thing" to "close the
issue" — skip it and the issue stays open after the fix is committed.
When **fixing** a tracked bug during a session, update the issue: When **fixing** a tracked bug during a session, update the issue:
1. Add a progress comment if doing partial work 1. Add a progress comment if doing partial work
2. On fix: `py tracker.py close <repo> <num> --comment "Fixed in <sha>. <what changed>"` 2. On fix: `py tracker.py close <repo> <num> --comment "Fixed in <sha>. <what changed>"`