Kevin Veen-BirkenbachandClaude Opus 5.5
3c2f6c44b5
Every loaded SKILL.md and every listed description is paid on every turn of every session, and every delivered message costs its recipient a full turn. scripts/budget.py gains SKILL_WORDS = 600, enforced by test_lock, and test_naming forbids a skill naming its own slash command; 53 descriptions and 10 body lines drop it. The 18 longest skills move details into 31 side files read only in their situation (organize's capacity, succession, peers, offices, relay and lineage; cleanup's docker, worktrees, execute and ask; code-tune, changelog, triage, dream, split and others), so all SKILL.md files shrink from 33866 to 26291 words without dropping a rule; an independent review of HEAD against the new text found no loss in 60 of 64 skills and three weakenings, now restored (WSJF re-estimates after an objective change, cleanup's volume checklist, essence's absolute dates). The kvb-org-organize Peer protocol sends status that asks nothing to the news board, answers nothing that asks nothing, keeps messages terse, and lets light runs admit themselves in the operator's wording; the skills follow it (operator reads the register, relax and wakeup reply through the news, evening collects them there, wsjf asks only for missing estimates, cleanup and triage batch their questions). Skills that explore code ask the codebase-memory-mcp graph first, subagent briefs scale with the stakes and cap their answers, and the skills that need the full register or council tables call show --wide or list --long. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.2 KiB
name, description
| name | description |
|---|---|
| kvb-git-issue-close | Close finished issues, of one pull request or the whole repository, each verified and confirmed. |
Closing an issue is outward-facing: nothing is closed or edited before the operator confirms the list, and every closed issue names the pull request or commit that fixed it.
Step 1: candidates
-
A pull request named (or the current branch's,
gh pr view --json number):${CLAUDE_SKILL_DIR}/scripts/issues.pylists every issue it references: closing keywords and mentions in the body and the commits, a trailing number in the branch name, and the issues GitHub already links.gh pr view <pr> --json number,body,headRefName,commits,closingIssuesReferences | issues.py --repo <owner/name> -
No pull request: every open issue of the repository. After
git fetch,${CLAUDE_SKILL_DIR}/scripts/done.pylists the default-branch commits that reference each one:gh issue list --state open --limit 1000 --json number | done.py --repo <owner/name> --git-dir . --ref origin/<default>An open issue no commit references can still be fixed: search the default branch by its description with the kvb-git-merge-fix skill's
find_fix.py.
Step 2: verify
Per candidate, gh issue view <n> --json state,title,body,comments (with
--repo for a foreign one); skip a closed issue. Judge it fixed, partly
or unrelated against the diff, with evidence: the change addressing each
point of the issue and the test or CI run proving it. Only fixed goes on;
partly gets a progress comment instead.
Step 3: confirm
AskUserQuestion with multiSelect: true, one option per fixed issue, the
evidence in its description, nothing preselected.
Step 4: close
Where the fix lives decides how:
- On the default branch:
gh issue close <n> --reason completed --comment "Fixed by #<pr> (<sha>).", or the commit alone when no pull request carried it. - In an open pull request, or merged into another branch: add one
Closes #<n>line per issue to the pull request body (gh pr edit <pr> --body-file <file>, keeping the existing body), so the merge into the default branch closes them; never close them early.
Output
| Issue | Verdict | Evidence | Action |