HN 표시: WIP 축적에 대해 알려주는 Claude Code 후크

An AI agent has no visibility into accumulating work-in-progress. It works on the current prompt. Meanwhile, uncommitted changes grow, commits pile up without a push, changesets go unwritten, and a release PR sits open for days. The accumulation happens silently. This matters because work-in-progress is risk. In Lean terms, it is internal inventory: work that has been started but has not yet delivered value to a customer. Uncommitted changes can be lost to a crash or a branch switch. Unpushed commits are invisible to the pipeline. Missing changesets mean no release PR will be created. A stale release PR means tested, reviewed code is sitting in a queue instead of running in production. I built a Claude Code hook that surfaces all of this. Four checks monitor four queues where code accumulates on its way to production. Local checks run every prompt. Remote checks run on push. No blocking. The AI keeps working but both it and I can see the state of things. Four queues Code flows through four queues between your editor and production. Each queue is a place where work can stall. Each check monitors one queue. The first two queues are local. Checking them requires only git commands against the local repo, which complete in milliseconds. The last two queues are remote. Checking them requires gh CLI calls that hit the GitHub API, taking 500ms to 2 seconds each. Running those on every prompt would add noticeable latency, so they run once on push. The remote state only changes when you push, so there's no need to re-check between pushes. Local checks (every prompt) The hook lives in .claude/hooks/wip-nudge.sh and fires on UserPromptSubmit , the same event used by the pipeline discipline hooks. Every check is independent. If one fails silently (no remote, no gh CLI), the others still run. 1. Uncommitted changes too large DIFF_STAT=$(git diff HEAD --stat 2>/dev/null | tail -1) git diff HEAD captures both staged and unstaged changes. The --stat summary line looks like 5 files changed, 180 insertions(+), 42 deletions(-) . The script extracts the insertion and deletion counts and adds them. If the total is 200 or more: WIP: ~222 lines of uncommitted changes. Consider committing before continuing. The threshold of 200 is a judgment call. Below that, you're mid-task. Above it, you have enough work that losing it would hurt. The check also counts lines in untracked files (excluding .DS_Store and node_modules ) and adds them to the total. A 250-line file you haven't staged yet still counts toward the threshold. There's a related check for stale modifications. If a tracked file has been modified but not committed for more than 24 hours, the hook flags it: WIP: 2 modified file(s) uncommitted for over 24h. Forgotten or should be reverted? A day-old uncommitted change is either forgotten work or something that should be reverted. Either way, it shouldn't sit there silently. 2. Unpushed commits piling up UNPUSHED=$(git rev-list --count origin/master..HEAD 2>/dev/null || echo "0") If the count is 3 or more: WIP: 5 unpushed commits on master. Consider running npm run push:watch . One or two unpushed commits is normal mid-task flow. Three or more means multiple units of work are sitting locally. The pipeline can't run against them. The release PR can't include them. If the push eventually fails CI, you're debugging a larger delta than necessary. The nudge suggests npm run push:watch rather than bare git push because of the pipeline discipline hooks already wired into this project. That script pushes, watches the pipeline, and surfaces the deploy URL. Remote checks (on push) Checks 3 and 4 run inside scripts/push-watch.sh after the push completes and the remote refs are updated. The warnings print to stdout alongside the pipeline status and deploy URLs. Since the remote state only changes when you push, running the checks at push time is both the right moment and the only moment they need to run. 3. No release preview UNRELEASED=$(git rev-list --count origin/publish..origin/master 2>/dev/null || echo "0") CHANGESET_COUNT=$(find .changeset -name '*.md' ! -name 'README.md' 2>/dev/null | head -20 | wc -l) OLDEST_UNRELEASED=$(git log --format='%aI' --reverse origin/publish..origin/master 2>/dev/null | head -1) If there are pushed commits ahead of publish , no changeset files, and the oldest of those commits is more than 24 hours old or there are 3 or more: WIP: 8 unreleased commits with no changeset (oldest: 3 day(s) ago). Run npx changeset to describe what's shipping. Without a changeset file, the changesets action won't create a release PR. Changes accumulate on trunk with no release preview, no version bump, no CHANGELOG entry. This is internal inventory: work that has been done but is not flowing toward a release. The check fires on either condition: the oldest pushed commit is over 24 hours old, or there are 3 or more pushed commits without a changeset. A single recent commit is normal mid-task flow. Three commits in one day without