Make the Stop hook impossible to regret installing
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 32/100
Research direction
Start at the backcheck install entry point and trace the Stop hook's current failure handling. This issue lists several independent proposals rather than naming a single change, file, or test; choose one item, define its behavior and completion criteria, and preserve the rule that malformed input, missing files, timeouts, and internal errors let the session finish normally.
Written by the indexing model from the issue text.
Description
backcheck install puts a Stop hook in the critical path of every Claude Code session. That is
where the tool earns its keep, and also where a bad decision costs the most: a hook that blocks
on honest work, or blocks twice in a row, is worse than no hook at all.
Current behaviour: on finding unsupported claims it returns decision: "block" with the reasons,
unless stop_hook_active is set (which would risk a loop). Panics are caught, a missing
transcript is tolerated, and any failure degrades to "say nothing and let the turn finish".
Ways it could be better:
- Configurable thresholds — a
.backcheck.tomlchoosing what blocks vs. what only
warns. Some teams will wantcontradictedto block andqualifiedto stay quiet. - Per-claim suppression — a way to say "this project has no test suite, stop telling me"
without uninstalling entirely - A hard time budget — the hook should abandon analysis rather than ever delay a turn.
A very large transcript on a slow disk is the case to worry about. -
backcheck doctor— confirm the hook is installed correctly, the binary is onPATH,
and show what it would have said about the last session - Statusline integration — a compact verdict in the Claude Code statusline instead of a
block, for people who want the signal without the interruption -
SessionEndas an alternative toStop, for reporting without ever blocking
Data that would help
If you install the hook and it blocks on something that was actually fine, that is a bug worth
reporting — see #6. Real examples of unnecessary blocks are the fastest way to
tune the thresholds, and they will shape whatever configuration format lands here.
Rule that must hold
Whatever changes: never break a session. Any malformed input, missing file, timeout, or
internal error must end with the turn completing normally. That property is worth more than any
feature on this list.
- Dominant language
- Rust
- Stars
- 0
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from VectorInstitute/backcheck
-
accuracy false-negative false-positive help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
good first issue help wanted runner
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
enhancement good first issue help wanted
Difficulty 4/5 3-5 days Newbie friendliness 55/100
VectorInstitute/backcheck#10 ·
-
enhancement good first issue help wanted
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
accuracy enhancement help wanted
Difficulty 4/5 3-5 days Newbie friendliness 50/100
All issues in VectorInstitute/backcheck
Similar issues
-
tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
discover: `sudo RTK_DISABLED=$VAR …` is not detected as a bypass when `sudo` is a transparent prefixOpenarea:cli bug good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
skill:code-review
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
component:sight
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
agentic-os-org/ANOLISA#4115 · 1 comment ·
Maintainers usually reply within 1 day