dkj-policy

Find out whether a dispatched fan-out discarded any of THIS session's uncommitted work -- take a baseline of the working copy before dispatching subagents, compare after they return, and report shrinkage only: a path that was changed and no longer is, a worktree edit that has been reverted, or a stash entry that has gone. Use it whenever work is handed to subagents while the checkout holds uncommitted edits, which is exactly what a parallel review chain is. It reads and reports, refuses nothing, and cannot restore -- discarded uncommitted content is in no reflog, so knowing WHICH file to write again is the whole available remedy. Growth is expected and stays silent, so a subagent legitimately writing files never trips it.

Lay out every document that legislates in this repo in RANK ORDER -- the installed plugins' portable pages above this repo's own workflow folder, above its always-on CLAUDE.md closure -- and then read them against each other for contradictions. Use it when adopting this workflow into a repo that already had its own rules, when a session and a page disagree about how the cycle works, or before folding a shared rule into a root CLAUDE.md. The script locates and hands over; the judgement is yours, and nothing is ever edited.

Claim a GitHub issue on the tracker before any work on it begins -- assign it to the account THIS checkout commits as, and refuse when the issue is closed, missing, or already somebody else's. Use it the moment an issue number is named as the work -- "fix issue 1234", "pick up #87", "take this one", in whatever language the request arrives -- and again when resuming one, BEFORE reading the code or opening a branch. It writes one assignee and nothing else -- no branch, no commit, no comment -- so it is the step that runs first and not a replacement for new-branch: claim, then carry straight on into the work in the same turn.

Checklist for the closing steps of cutting a release: the git tag + push, the internal summary and the consumer-document edit, then a GitHub Release (body = the highest tier the repo has, every other tier as an attachment -- gh's release-notes body has a hard 125,000-character limit), plus branch cleanup. Where the repo has a separate "go live" stage (Get-LiveStage in scripts/repo-config.ps1), also the push to that live target and moving the "<- LIVE" marker. Where the repo is a marketplace source with a business publication target (Get-BusinessMarketplaceRepo), also the separate, deliberate publish step (publish-to-business.ps1). Prints ready-to-paste command blocks in a fixed order -- a checklist that imposes itself, not automation: no script is run or mirrored. Use this once a release has been cut (version bumped, committed) and its closing git/gh steps need to be walked through without skipping one. Inbound issue #177.

Repair double-encoded characters (mojibake) in text files via the shared, centralized fix-mojibake script from the plugin (single source of truth, issue #413) -- so a consumer does not keep its own copy. Damage of this kind is silent: the file stays valid UTF-8, nothing errors, it just says something else, and a mangled separator can stop a release script from reading its own input. Repairs by running the corruption backwards rather than by matching a table of known sequences, so it reaches characters nobody thought to list. Use -Check for a gate or a dry run. Use this when non-ASCII text has been mangled, or to verify that it has not been.

Fold a branch's changelog entry into CHANGELOG.md via the shared, centralized fold script from the plugin (single source of truth, issue #81) -- so a consumer does not have to duplicate this script locally. Use this on main, immediately after merging a branch, to fold the entry (the DEPLOY section of dkj-policy/<branch>.md, or an older branch/ pair, or a pre-split <branch-name>.md in the repo root) into CHANGELOG.md -- a flat ranked list with no section headings, where each entry lands at the position its own Significance sections rank it at (furthest reach first, highest significance first within a tier) -- and then clear it: every folded entry's file is deleted, the development document included, so the trunk carries no branch document between branches.

Measure how the CLOSE-OUT actually behaves on this machine against its stated three-line ceiling, across every recorded session -- so a change to the close-out rule can be evaluated instead of guessed at. Use it before and after any repair to close-out wording or mechanism, when a receipt keeps over-running and you want the rate rather than an impression, and to see the delta against a stored baseline. It reads the session transcripts in place and emits only counts -- never transcript content -- always exits 0, and is deliberately not a gate.

Measure what a skill COSTS and how fast the script behind it runs -- always-on tokens (paid by every session whether the skill fires or not), on-invoke tokens (paid per firing), the delta against a stored baseline, and the wall-clock of the script it drives. Use it before adding a skill, when a plugin's session cost has grown, or to find which skills are carrying that cost. It drives `claude plugin details` rather than estimating from file sizes, so the figure is the authoritative one; it is read-only by default and is not a gate. It also covers the always-on document path -- `CLAUDE.md` plus everything it `@`-imports -- measured per document and per section.

Create (or idempotently resume) a git branch AND its development document -- dkj-policy/<branch>.md, the branch's plan and the DEPLOY section that becomes its changelog entry -- in one move, via the shared, centralized new-branch script from the plugin (single source of truth, issue #81), so a consumer does not have to duplicate this script locally. Use this whenever a new piece of work starts: a branch is never entry-less -- creating it brings that document to life in the same step, instead of a separate later scaffolding step.

Push the current branch and open a Pull Request to main via the shared, centralized open-pr script from the plugin (single source of truth, issue #81) -- so a consumer does not have to duplicate this script locally. Runs the repo's own lint and test gate first; on an error, nothing is pushed and no PR is opened. Also forces the issue-closing decision: a branch that mentions an open issue must pass -Resolves or -NoResolves, so a repaired issue cannot stay open after the merge. And it refuses a changelog entry that still carries its scaffold wording, which would otherwise become permanent in the release notes and the consumer-facing plugin CHANGELOGs. Use this when a branch is ready and the repo's governance rule allows the PR to be opened.

Park the current branch via the shared, centralized park-branch script from the plugin (single source of truth, issue #81) -- so a consumer does not have to duplicate this script locally. Commits any outstanding work on the current branch and pushes it to origin with `git push -u`, so the exact state is immediately continuable on another device. Opens NO pull request and performs NO live/deploy action -- it only backs the branch up to the remote. Use when you want to set a branch aside for later ("park it for next time") without opening a PR.

Show, per enabled plugin, the version installed IN THIS CHECKOUT against the version the local marketplace clone holds, and a verdict on whether a plugin update is due -- so you can tell, on this machine, whether to run `claude plugin update` or `claude plugin marketplace update`. Read-only, no arguments, runs in any checkout on any machine. Use it when you are unsure whether this checkout is on the current plugin release, when a session behaves as if it loaded an older plugin, or before deciding to refresh the marketplace.

Tidy the local clone after merges via the shared, centralized prune-merged script from the plugin (single source of truth, issue #81) -- so a consumer does not have to duplicate this script locally. Fast-forwards the trunk, drops stale remote-tracking refs, and deletes only the local branches whose merge can be PROVEN: an ancestor of the trunk, or a branch whose PR is merged. A branch with neither proof -- unfinished work, a parked branch, a branch pushed from another machine -- is left alone and reported. Touches NO remote branch: -IncludeRemote additionally CLASSIFIES the heads on the remote with those same two proofs and hands the delete command over paste-ready, rather than running it. Use when merged branches have piled up in the clone, as the closing tidy-up of a working session, or when you need to know what a `git ls-remote --heads` line actually means.

Build the hand-written release notes into one browsable page -- a picker per release, the document rendered -- and, optionally, into a Cloudflare Worker that serves it at an unguessable path. Use this when the people a release is written for are not developers: the note is markdown in a repository, which is the right home for it and the wrong place to read it. The page is a SNAPSHOT, so it is rebuilt and redeployed after a release rather than following one. The script builds and never publishes -- `npx wrangler deploy` is a separate, deliberate step, because publishing is outward-facing. Needs no configuration to build the page; hosting needs two optional seam values.

Ship a finished branch in one command via the shared, centralized ship-pr script from the plugin (single source of truth, issue #411) -- open the PR, wait for CI, merge, fold the changelog entry, and verify the issues the PR declared it closes. Stops on the first failure and never forces: a failing gate means nothing is pushed, a red CI means nothing is merged. This is the sequence the registry classifies safety-critical, because it merges to the main branch and then commits directly to it under the fold exception. Use this when a branch is finished, committed, and the repo's governance rule allows the PR to be opened.

Work an open-issue backlog with SEVERAL machines at once, without two of them building the same thing. Each session claims by TAG -- machine/account, written as a marker comment -- so a claim names the machine even where two checkouts share one GitHub account, and a two-session race is settled on the tracker's own timestamps: earliest marker wins, and only the losers let go. Use it when issues have piled up and you want them worked through rather than picked at one by one. It claims, builds, runs the gates and STOPS where a result has to be judged by eye -- it never opens a pull request on work nobody has looked at, and it never pushes anything live.

Clear the clutter this workflow leaves behind on a machine, in one command and twelve lanes: finished branches, stale worktree lanes, branches whose pull request was CLOSED without merging, expired backup branches, old stashes, an unfolded changelog entry, the ~/.claude plugin administration, install records pointing at a checkout that is gone or naming a plugin the marketplace has retired, plugin/marketplace staleness, extracted plugin payload no install record points at any more, and fixture trees under the scratch root. It DELETES only what prune-merged can already prove -- an ancestor of the trunk, or a tip that is the head commit of a merged PR -- and everything else it classifies and hands over with the command, paste-ready. Use it when branches have piled up, as the closing tidy-up of a working session, when a lane worktree has outlived its branch, or when you want to know which of the trees under your temp directory belong to runs that have ended.

Update every plugin this checkout enables, in one command instead of 1 + N -- refreshes the marketplace clone once, then runs `claude plugin update <id>` for each enabled plugin at the scope that plugin is installed at, then prints plugin-versions' receipt so the run's own result is verifiable. Use it whenever plugin-versions (or connector-sessioncheck's -Brief line) reports something behind and you want to close the gap without typing one command per plugin. Scoped to this checkout plus the machine-wide marketplace clone -- never a walk into another repo.

Open a branch in its own git worktree -- a "lane" -- so one branch can be BUILT while another one SHIPS, and hand a lane's branch back to the primary checkout when it is ready to ship. Use this when a session would otherwise sit idle waiting on the blocking CI check that ship-pr watches before it can merge, and you want to start the next piece of work instead. Also use it with -HandBack to release a finished lane's branch so ship-pr can run on it from the primary checkout.