@erclx/aitk 0.90.0 → 0.91.1

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.90.0",
+  "version": "0.91.1",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-address-review/REQUIREMENT.md

@@ -11,6 +11,8 @@ Without this skill, review findings are worked in whatever order the author read
 
 A branch also goes stale from `main` moving rather than from anything the branch did. Nothing in the return leg rebases it, so the worker closes every finding, reports the pull request answered, and the branch still cannot merge. Half the resolution is mechanical and wrong to do by hand, since a generated file merged manually produces a diff the next regen discards.
 
+A declined finding fails on a third axis, which is where its reason ends up. A worker answering a dispatch by naming the plan question that already settled the finding, or the constraint the diff never showed, settles it in whichever session heard the answer. Both sessions end, so a reader opening the thread later finds a finding that stopped being mentioned and no record of what stopped it, which is the durability the posted review already has by design.
+
 ## Must
 
 - Treat a failing check as a finding alongside the review comments, so the follow-up closes both
@@ -22,6 +24,7 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Rebuild a generated file through the project check rather than resolving its conflict by hand
 - Push before replying, so the comment never runs ahead of the code it describes
 - Map every finding to what changed, or to a one-line reason when it is a question or a conscious accept
+- Carry the fact behind a declined finding into the posted reply rather than into the message that answered the dispatch, since both sessions end and the thread is what the next reader opens
 - Post the terminal comment only when the findings are addressed and every check passes
 - Say what the run actually did on a rebase-only pass, since a reply mapping findings and a terminal comment claiming they were addressed are both false on a pull request carrying none
 - Scan the reply for banned characters and internal phase labels before posting, since the comment leaves for the remote unchecked
@@ -33,6 +36,8 @@ A branch also goes stale from `main` moving rather than from anything the branch
 - Post the closing comment while a check is failing
 - Reimplement the follow-up push or the doc refresh. Both have owners, and a second copy here drifts from them.
 - Edit silently. A finding answered without a reply leaves the reviewer re-deriving the change from the diff.
+- Answer a finding in the channel alone. A reply that changes what the review concluded is the one the thread has to carry.
+- Post a correction to what the reviewing session believes about the world. That class changes no finding here and belongs in the session record.
 - Take one side of a conflict wholesale. Both sides are valid content, so `--ours` or `--theirs` drops one silently and passes every check.
 - Merge `main` into the branch. The repository squash-merges, so a merge commit reads as noise on the pull request.
 - Guess at a hunk the tree does not settle. That case reaches the operator as an ordinary finding on the next pass only if the worker stops.

package/claude/skills/claude-address-review/SKILL.md

@@ -114,6 +114,23 @@ bullet per finding, each opening with the bolded finding identifier.
 Close the body with `🤖 Addressed by Claude Code` on its own line so the reply
 reads as an independent machine pass, not a human sign-off.
 
+A finding this run declined carries the fact that settled it, inside its own
+bullet rather than in a section of its own. Name the plan question that already
+answered it, the constraint the diff does not show, or the measurement the
+reviewer did not have. Answering the dispatch in the channel and leaving that
+fact there loses it when both sessions end, and the reviewer is left with a
+finding that stopped being mentioned. The rule fires on a bullet the body already
+writes, so nothing depends on judging mid-reply whether a reply was important.
+
+The rule reaches a finding and nothing else. A correction to what the reviewing
+session believes about the world, such as which session holds which branch or
+what an edit passes through before it lands, changes no finding on this pull
+request and belongs in that session's own record rather than on a thread that
+closes. Keep it off the comment, and answer it wherever the dispatch reached this
+session when one did. Nothing tests the reply for either rule, since the scan
+below reads it for banned characters and phase labels alone, so both halves hold
+while a run applies them.
+
 When step 5 rebased the branch, say so in the summary sentence and name which
 files were resolved by hand and which the regen rebuilt. The next review is a
 full pass rather than a delta, and the reader is owed the reason.

package/claude/skills/claude-docs/REQUIREMENT.md

@@ -11,8 +11,11 @@ Without this skill, the planning docs describe the scope the session opened with
 
 A decision's verification anchor has the same shape of gap in the other direction. The reasoning keeps reading as current while the number it cites moves underneath, and an amendment written without an anchor leaves nothing recording which numbers were checked and which nobody has read since.
 
+The trigger side carries a gap of its own. "Sync the docs" names either corpus to the person saying it, so a description leaving its corpus to the opening clause alone competes with its public-facing sibling on nothing the routing field states, and the planning surface the request was about goes untouched.
+
 ## Must
 
+- Name the `.claude/` corpus in a trigger phrase rather than in the opening clause alone, so a bare request to sync the docs separates this skill from `docs-sync` on something both descriptions state
 - Take completion from the diff and everything else from the session, since completion is a fact about the repository rather than about the conversation
 - Match an outcome on the behavior it names, never on a filename or a commit subject
 - Leave an outcome unchecked when the diff is ambiguous. An unmarked shipped outcome costs one manual edit and a wrongly marked one hides work that never happened.
@@ -40,7 +43,7 @@ A decision's verification anchor has the same shape of gap in the other directio
 ## Out of scope
 
 - Creating a task file or moving one off the board, which `claude-tasks` owns
-- Public-facing docs, which `docs-sync` owns. This skill reconciles the `.claude/` planning surface.
+- Public-facing docs, which `docs-sync` owns. This skill reconciles the `.claude/` planning surface, and both descriptions name their corpus in the trigger so a request saying only "sync the docs" lands on one of the pair rather than on either.
 - Regenerating the task index, owned by a hook
 - Redrawing diagrams, which `claude-diagram` owns. This skill flags staleness and leaves the re-run to the author.
 - Re-measuring an architecture claim to decide whether its number moved. The sweep keys on a cited path entering the diff, so a claim whose number moved with no cited path in the diff goes unflagged.

package/claude/skills/claude-docs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: claude-docs
-description: Updates `.claude/` planning docs to reflect decisions made during the session, marks outcomes the diff shipped `[x]`, and archives the plans those tasks cite. Use when design or requirements changed mid-cycle, after discussing a pivot, or before shipping. Do NOT use to create a task file or move one out of the live folder. That is `claude-tasks`.
+description: Updates `.claude/` planning docs to reflect decisions made during the session, marks outcomes the diff shipped `[x]`, and archives the plans those tasks cite. Use when asked to "sync the .claude docs", when design or requirements changed mid-cycle, after discussing a pivot, or before shipping. Do NOT use to create a task file or move one out of the live folder. That is `claude-tasks`.
 ---
 
 # Claude docs

package/claude/skills/claude-orchestrate/REQUIREMENT.md

@@ -33,6 +33,8 @@ The runbooks the session cannot run from memory fail on a third axis, which is w
 
 Every one of them therefore has to ship inside the skill, the four covering the moments the loop cannot detect and the fifth holding the review trigger. That last one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
 
+The dispatch's return leg is unplaced for the same reason. A reply reaches this session as a message and settles a finding, corrects which session holds which branch, or names a gate a worker's edits pass through, and reading it is the whole of what happens to it. Both sessions then end, so the half that belonged on the pull request never reaches it and the half that belonged on the board is rediscovered by whoever needs it next.
+
 The session also records nothing of what it learns. Both other callers of memory capture are ship-chain skills and this one never ships, so the session taking every operator correction is the session with no moment that writes one down. Hanging that moment on the merge sweep answers it and bills the operator a capture pass per batch of merges while nothing is being built, which is a cost paid on the days shipping is fastest.
 
 ## Must
@@ -42,6 +44,7 @@ The session also records nothing of what it learns. Both other callers of memory
 - Verify a plan against the tree before handing it over, counting the sites it claims and opening the files it describes
 - List a candidate's file set against every track in flight, and serialize when the sets are not disjoint
 - Place every finding a merged pull request produced against the surface that owns it
+- Place what the return leg carries by what it changes, sending an answer that settles a finding onto the pull request and one that corrects this session's model of the world to the task owning that surface, since neither becomes a record by being read
 - Date the roadmap line from that file's last commit, so an old sequence reads as old
 - Keep one planned, non-conflicting task in reserve beyond what is running
 - Refill the queue while a wave is still building, rather than on a merge and a thinning list alone, since neither of those fires across the window planning costs nothing

package/claude/skills/claude-orchestrate/SKILL.md

@@ -120,6 +120,8 @@ A session is reachable when it appears in a live listing, which reads what each
 
 The channel runs both ways and the return leg carries what the pull request cannot. A worker answering a posted finding by naming the plan question that had already declined it changes the outcome in the moment, where a thread comment waits on whoever reads it next. Read what a worker volunteers as part of the review rather than as an aside.
 
+What arrives there does not become a record by being read, so place it by what it changes. An answer that settles a finding goes onto the pull request through the next pass, which withdraws or regrades that finding and names the fact behind it, per `claude-pr-review`. An answer that changes what this session believes about the world instead, which is a mapping correction or a constraint on what a worker can do, settles no finding and reaches no thread, so route it the way Boundaries below routes a change found while orchestrating, which lands it on the task owning the surface it describes. Writing a tracked file to hold either is forbidden here, which leaves the pull request and the board as the two surfaces this session writes.
+
 A plan written here is written against a tree several branches are already changing, so it names the file set of every track in flight as a constraint, one set per track, read from the Touches column of that track's row. State for each set which of the two acts it forbids, per Constraints in `.claude/standards/plan.md`, or `${CLAUDE_SKILL_DIR}/../../standards/plan.md` when the project does not have it. A bare path list leaves the worker guessing, which is how a plan ends up forbidding the repair of a citation the change broke.
 
 ## Boundaries

package/claude/skills/claude-pr-review/REQUIREMENT.md

@@ -9,6 +9,8 @@ description: What the independent pull request review is for, the gaps it closes
 
 Without this skill, a pull request is reviewed only by the session that wrote it, which cannot see the roadmap sequence or a sibling branch in flight. Findings land in chat, where they are read once and leave the thread with no record. A review that opens and never closes is worse than none, since a reader scanning the thread cannot tell an unanswered review from a confirmed one, and the author's claim that findings are fixed is the only evidence they are.
 
+A finding also stops being true by argument rather than by a fix. A worker naming the plan question that already declined it, or a constraint the pass could not see, settles it in the exchange that carried the answer, and the pass that accepts the argument drops the finding from its next body. A reader then sees a finding raised once and never mentioned again, which is indistinguishable from one everyone forgot.
+
 ## Must
 
 - Post until the review closes. A first pass opens against the whole change, and each later pass checks whether the prior findings landed.
@@ -17,6 +19,7 @@ Without this skill, a pull request is reviewed only by the session that wrote it
 - Scope a later pass to the commits added since the prior one, once that commit is confirmed to still reach the head
 - Apply the integration, contract, and consumer lenses a self-review structurally cannot
 - Post the closing pass even with nothing to report, since a review left unanswered reads as one nobody closed
+- State a withdrawal or a regrade on the thread with the fact that settled it, since a finding dropped in silence reads the same as one nobody answered
 - Key the body file on the pull request number and the head commit, and on the response it answers once the head repeats, so no two passes overwrite each other
 - Scan the comment for banned characters and internal phase labels before posting, since a finding phrased against a phase label reaches a reader with no task board
 

package/claude/skills/claude-pr-review/SKILL.md

@@ -87,6 +87,8 @@ Apply the high-signal filter: flag only what will cause incorrect behavior, brea
 
 A later pass applies the same axes to the delta, and adds one check the first pass cannot make: did each prior finding land, and did the fix regress anything it touched. Findings of its own are normal findings, stated at the same severity and counted the same way. That count is what Step 4 reads to pick the heading, so a pass raising one of its own is not a close-out.
 
+A prior finding can also be settled by argument rather than by a fix. A reply naming the plan question that already declined it, or a constraint this session could not see, withdraws the finding or moves its grade. State that outcome in the body under the finding it changes, naming the fact that produced it, whether the argument arrived on the thread or through the channel that carried the dispatch. Dropping the finding from this body instead leaves a reader unable to tell a withdrawal from an oversight, and the reasoning goes with the session that heard it. A withdrawal removes the finding from the count, so a pass that withdrew every open item is a close-out. Write the withdrawal and its cause into that body rather than taking the short close-out line Step 4 supplies, which reports prior findings addressed and would credit a fix nobody made.
+
 Use severity: `critical` (blocks merge), `should-fix` (fix before merge), `minor` (visibility only).
 
 ## Step 4: post to the PR
@@ -166,6 +168,8 @@ gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>
 
 A pass with no findings takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No blocking findings. Reviewed against project docs and roadmap.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`
 
+A pass that closed by withdrawing a finding rather than by reading its fix takes neither line, per the withdrawal rule in Step 3. Both claim a fix landed, and the second names it, so posting either over a withdrawal credits work nobody did on the one comment a reader treats as the verdict. Write the withdrawal and the fact that settled it in place of the canned line, keeping the heading and the footer.
+
 Post that one even when there is nothing to report. A review left with no closing comment reads as one nobody answered.
 
 ## Step 5: output

package/claude/skills/claude-seed-sync/REQUIREMENT.md

@@ -11,6 +11,8 @@ Without this skill, a project that edited an installed seed or standard has two
 
 A whole-file diff does not close it either. It cannot separate a section the user rewrote on purpose from a section the toolkit moved on without them, so the choice reaches the user as accept everything or lose everything, and the safe answer is always to skip.
 
+Naming the bulk command carries a failure of its own. This skill decides which files the bulk sync should take and then hands that command over without stating what it does to them, and the boundary line below names the reference holding that answer where no session reads it. Claude Code loads the skill entry alone, so a sibling named here reaches nobody.
+
 Two failures belong to the audit rather than to the diff. A decision taken in chat dies with the session, so an audit half applied cannot be resumed and the second run starts over. And a file the toolkit generates rather than ships, such as an index rebuilt from sibling frontmatter, is absent from every source catalog by design, so a naive comparison reports it as a local addition and invites the user to reconcile something nothing owns.
 
 ## Must
@@ -20,6 +22,7 @@ Two failures belong to the audit rather than to the diff. A decision taken in ch
 - Separate a customized section from a stale one by reading the attribution the drift report records, not by how the section looks, and default the customized one to no action
 - Fall back to appearance only when attribution is unavailable, and mark every verdict reached that way as unverified
 - Leave a file the report proves untouched to the bulk sync that owns it, rather than auditing what carries no edits
+- Route to the overwrite contract from the body, at the point the bulk command is named, since the boundary below is read by an author and never by a session
 - Persist the proposal and every decision to a review file that stays the source of truth across re-pings
 - Apply one section at a time, never by rewriting a file
 

package/claude/skills/claude-seed-sync/SKILL.md

@@ -34,6 +34,8 @@ Keep every seed regardless of state. `CLAUDE.md` is the file a project edits mos
 
 Record the dropped standards as one line in the scope table rather than as rows: `<n> standards stale, taken by aitk standards sync`.
 
+Read the `toolkit-cli` skill before naming that command in the output. It states which surfaces a sync overwrites, merges, or writes once, and this skill hands the user a command against files its own attribution pass cleared as carrying no edits.
+
 Fall back to the appearance heuristic in step 3 when the report cannot attribute, which is `historyUnavailable` set on the relevant section or the command failing outright. Say so in the summary block, because a fallback audit reports guesses rather than facts.
 
 ## Step 2: read installed copies

package/claude/skills/claude-worktree/REQUIREMENT.md

@@ -13,6 +13,8 @@ Entry also writes the bare flag into the shared config, which strands the main w
 
 The tree the entry hands over is also not one the session can run. Dependencies live in a folder git ignores and never shares between working directories, so a fresh worktree arrives with none, and nothing on the entry path says so. The session finds out from whichever command needs them first, and the message it gets names a missing module rather than an empty working directory.
 
+A declined request also has to land somewhere. The description turns away a list, cleanup, or rotation request and names no destination, so the session that reads it picks one, while the sibling owning those requests already points back here. One half of a pair carrying the pointer reads as the boundary running one way.
+
 A stack that derives its ports from the working directory has the same shape. The number is correct and invisible, and `claude-orchestrate` sends a reader here to read it rather than assign one, so the entry that knows the working directory is the surface that owes it.
 
 ## Must
@@ -28,6 +30,7 @@ A stack that derives its ports from the working directory has the same shape. Th
 - Report on one line whether the entered worktree carries its dependencies, naming the command that installs them when it does not
 - Report the same way when the project declares no package manifest, since silence there reads as a passing check
 - Report the port offset this worktree derives, and say so when the project installs no derivation
+- Name `git-worktree` where the description declines a list, cleanup, or rotation request, matching the pointer that skill already carries back
 
 ## Must not
 
@@ -47,6 +50,6 @@ A stack that derives its ports from the working directory has the same shape. Th
 
 ## Out of scope
 
-- Listing, cleaning up, or rotating worktrees, which `git-worktree` owns
+- Listing, cleaning up, or rotating worktrees, which `git-worktree` owns and the description names, since this file routes no session
 - Leaving a worktree, which the user decides
 - What runs inside the worktree once entered, which the caller drives

package/claude/skills/claude-worktree/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: claude-worktree
-description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/claude-feature`. Do NOT use to list, clean up, or rotate worktrees.
+description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/claude-feature`. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
 ---
 
 # Claude worktree

package/claude/skills/docs-sync/REQUIREMENT.md

@@ -11,10 +11,13 @@ Without this skill, a rename or a dropped flag ships with the README still descr
 
 Three failures belong to the sync itself rather than to the drift. A session that syncs by rewriting whole files churns sections the change never reached, which costs the reviewer the ability to tell the sync from the feature. A doc edited earlier in the same session reads as current while a later change leaves one of its sections stale, so file-level classification passes where section-level would not. And a hardcoded doc list never checks the file someone added after the list was written.
 
+The trigger is a failure of its own. "Sync the docs" names either corpus to the person saying it, so a description claiming the bare phrase takes the request meant for the planning surface its sibling owns, and the run rewrites a README nobody asked about while the `.claude/` docs it was called for stay stale.
+
 The quiet one is the baseline. A diff resolved against a bare local ref equals HEAD on `main` and on a branch before its first commit, so every committed change drops out of the set. The skill then reports nothing to sync, which reads as a clean result rather than as an admission that it could not see the work.
 
 ## Must
 
+- Name the corpus in every trigger phrase, so a request naming neither reaches one skill of the pair rather than either
 - Resolve one merge base, prefer the remote ref over the local one, and reuse it everywhere the skill reads the diff
 - Say so in the output when the baseline degrades, rather than reporting a clean pass off a set it could not build
 - Discover the doc set by glob at run time

package/claude/skills/docs-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: docs-sync
-description: Rewrites stale `README.md` and `docs/*.md` sections based on changes since main. Use before staging, or when asked to "sync docs" or "update the docs". Do NOT use for changelog updates or `CLAUDE.md` updates.
+description: Rewrites stale `README.md` and `docs/*.md` sections based on changes since main. Use before staging, or when asked to "sync the public docs", "update the docs in docs/", or "update the README". Do NOT use for the `.claude/` planning surface, which `claude-docs` owns, or for changelog and `CLAUDE.md` updates.
 ---
 
 # Docs sync

package/claude/skills/git-commit/REQUIREMENT.md

@@ -9,12 +9,15 @@ description: What commit generation is for, the gaps it closes, and where the fa
 
 Without this skill, a commit message takes whatever shape the session settled on. The type and scope drift from the convention the history already follows, the subject runs past the length the log renders, and a lockfile diff floods the context the message is derived from so the message describes the lockfile.
 
+A second failure is routing rather than shape. A plain request to commit reaches this skill and its grouping sibling alike, and the sibling's first step is to unstage everything and restage whole files, so a selection staged hunk by hand comes back widened to the files it sat in. The user reviewed one thing and shipped another, and nothing in the run says the set changed.
+
 ## Must
 
 - Read the commit format reference and the versioning standard before generating, so the type, the scope, and the version discipline come from one source
 - Derive the message from the staged diff, with lockfiles excluded
 - Show the message and its length against the limit before committing, so an over-length subject is visible while it is still cheap to fix
 - Execute immediately after the preview. The tool permission dialog is the confirmation gate, and a second prompt trains the user to skim it.
+- Claim the single-concern and the hunk-level staged set in the description, and name the sibling for the multi-concern one. A boundary stated only here routes nothing, since the description is the field the choice is made from.
 
 ## Must not
 
@@ -28,6 +31,6 @@ Without this skill, a commit message takes whatever shape the session settled on
 
 ## Out of scope
 
-- Splitting a mixed diff across several commits, which `git-stage` owns
+- Splitting a mixed diff across several commits, which `git-stage` owns. That skill restages whole files, so a hunk-level selection survives here and not there, and both descriptions carry the difference rather than leaving it stated only in these two files.
 - Naming the branch, which `git-branch` owns. The family shares its triggers and not its gaps: this one turns on the staged diff, the length limit, and lockfile exclusion, none of which a branch name has.
 - Pushing or opening a pull request, which `git-pr` owns

package/claude/skills/git-commit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: git-commit
-description: Generates conventional commit messages from staged changes. Use for any git commit.
+description: Generates one conventional commit message from the staged changes and commits them exactly as staged, so a hunk-level selection survives. Use when asked to "commit this" or "commit the staged changes" and the staged set covers one concern, or whenever the selection was staged hunk by hand. Do NOT use when the staged changes span several concerns and need separate commits. That is `git-stage`.
 ---
 
 # Git commit

package/claude/skills/git-stage/REQUIREMENT.md

@@ -9,9 +9,12 @@ description: What commit grouping is for, the gaps it closes, and how it differs
 
 Without this skill, a staged diff spanning several concerns lands as one commit, so a later revert takes unrelated work with it. A renamed file staged as two separate paths records an add and a delete, losing the rename git would otherwise detect. Commits also land in the order the files happened to be listed rather than the order they depend on, so a bisect stops on a commit that cannot build.
 
+The routing failure sits on top of those. A description claiming every commit request pulls in the single-concern one this skill has no grouping to do on, and a staged set carrying a hunk-level selection reaches the unstage below and comes back widened to whole files, which is the one case the staged-set rule cannot hold.
+
 ## Must
 
 - Read the commit format reference and the prose standard before generating
+- Decline the single-concern and the hunk-level staged set in the description, naming the sibling that takes each. The widening is a property of the unstage, so it cannot be fixed here and has to be routed around.
 - Derive the groups from the staged diff, with lockfiles excluded from the derivation context
 - Account for every staged file in the preview, so a dropped file is visible before execution
 - Order the commits so a dependency lands before the file that imports it
@@ -31,6 +34,6 @@ Without this skill, a staged diff spanning several concerns lands as one commit,
 
 ## Out of scope
 
-- Composing a single commit from the whole staged diff, which `git-commit` owns
+- Composing a single commit from the whole staged diff, which `git-commit` owns. That skill commits the staged set untouched, so a hunk-level selection belongs there and never here.
 - Splitting commits across branches, which `git-split` owns. The two partition different things: this one takes a staged diff and emits commits, that one takes commits and emits branches.
 - Pushing and opening the pull request, which `git-pr` owns

package/claude/skills/git-stage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: git-stage
-description: Groups staged files by concern and generates one conventional commit per group. Use when staged changes span multiple concerns and need to ship as separate commits.
+description: Groups staged files by concern and generates one conventional commit per group. Use when staged changes span multiple concerns and need to ship as separate commits. Do NOT use on a single-concern staged set. That is `git-commit`, which also preserves a hunk-level selection this skill's unstage and restage over whole files would widen.
 ---
 
 # Git stage

package/claude/skills/migration-standards/REQUIREMENT.md

@@ -13,6 +13,8 @@ A fourth failure comes before those three, from deciding what is unmigrated by l
 
 Taking detection from a command opens a failure the listing never had. A CLI predating the field exits zero with a well-formed report that never mentions it, so a skill treating an absent key as an empty answer tells a project whose every domain sits at the root that it has nothing to relocate. That is the population this skill exists for, and a silent false negative there costs more than the unfiltered count reading the folder would have produced.
 
+The re-sync the skill names has the same gap in the other direction. The relocation is what makes those commands land on a path that held nothing before, so the run hands over a command whose overwrite behavior it never states, and the reference holding that answer is named in the boundary below where no session reads it. Claude Code loads the skill entry alone.
+
 Three failures follow from acting without looking first. A move onto an existing `.claude/standards/` copy overwrites the files already installed there, which is the case the relocation was supposed to be unnecessary for. A `git mv` on a dirty tree lands the relocation in the same commit as unrelated work, so neither can be reviewed or reverted alone. And a session that rewrites every inbound reference spends its effort on toolkit-owned rules and skills, which the next sync overwrites, while the author-owned lines that actually break go unmentioned.
 
 ## Must
@@ -24,6 +26,7 @@ Three failures follow from acting without looking first. A move onto an existing
 - Propose `git mv` so history follows each file
 - Report author-owned inbound references as TODO lines the user fixes, and leave the reference itself untouched
 - Name the re-sync commands that reinstall toolkit-owned content at the new path, since the move alone leaves the install stale
+- Route to the overwrite contract from the body where those commands are printed, and carry its destructive rows into the reminder
 - Report the already-relocated case as a pass
 
 ## Must not

package/claude/skills/migration-standards/SKILL.md

@@ -92,4 +92,6 @@ Two states produce no proposal at all, and each gets its own line rather than an
 - Both folders already live under `.claude/`: `✅ standards/ and snippets/ already live under .claude/. Nothing to relocate.`
 - A root folder exists and no domain names it in `unmigrated`: `✅ <folder>/ holds no file the toolkit installed. Nothing to relocate.` Name every such folder. The guard passed because the folder is there, so a session that printed nothing would leave the user reading silence as a failed run rather than as the answer.
 
+Read the `toolkit-cli` skill before printing the re-sync block, and name in the reminder any surface it lists as overwritten. The user runs those commands against a tree the moves above relocated, and that relocation is what puts an overwrite onto files never installed at the new path.
+
 Do not run the `git mv` commands. Do not edit `CLAUDE.md`, rule files, or docs. The user runs the commands and fixes author-owned references after reviewing.

package/claude/skills/toolkit-cli/REQUIREMENT.md

@@ -13,6 +13,10 @@ The damage lands on the files a project owns. A golden config carrying local edi
 
 The inverse failure is quieter. A session that assumes a sync will pick up a change edits a seed and waits for an update that never comes, because the seed is copy-once and no sync command writes it again. Both failures are one missing fact available before the command runs.
 
+Being reachable is a separate problem from being right. This is a pure reference whose moment happens inside another skill's run, so nothing brings it up unless a body names it. Three sibling requirement files named it and routed nothing, because Claude Code loads `SKILL.md` as the entry and never opens the sibling. A route lives in a body or it does not exist, and a fourth requirement mention would repeat the same defect.
+
+The three bodies now carrying an inline pointer are `claude-seed-sync`, `migration-standards`, and `toolkit-operator`, each at the point it runs or prints an overwriting command.
+
 ## Must
 
 - State per surface and per command whether an existing file is overwritten, merged, written once, or left alone
@@ -24,6 +28,7 @@ The inverse failure is quieter. A session that assumes a sync will pick up a cha
 
 - Run any `aitk` command. The skill is read before acting.
 - Restate the full semantics. It is a target-session summary and the detail lives with its owner.
+- Take a mention in a sibling's requirement file as an inbound route. The three bodies named in the gap above carry the pointer, and adding a fourth means editing that body rather than its requirement.
 
 ## Guards
 

package/claude/skills/toolkit-operator/REQUIREMENT.md

@@ -13,6 +13,8 @@ Two failures come from acting on memory. A session that names a stack, rule, or
 
 The third failure is duplication. A front door that answers everything itself reimplements first-time detection and seed diffing inline, badly, beside the skills that already do both. The value of a router is that it stops at the handoff.
 
+A fourth failure sits between the router and what it runs. This skill executes the install and sync commands whose effect on an existing file is invisible from the command line, and the reference stating that effect per surface is named in the boundary below, which Claude Code never loads. The router therefore overwrites a customized golden config with the answer sitting one skill away and unread.
+
 The last failure is writing without re-checking. A domain sync brought a stricter standard into a target and left ten of its eleven context entries non-compliant in the same moment, and the run reported success because reporting the command was where its work ended. A person found the breakage afterwards by running an audit by hand. The audit that would have caught it is built and reachable from nothing the router offers, so one session held both the defect and its detector and connected neither to the other.
 
 ## Must
@@ -21,6 +23,7 @@ The last failure is writing without re-checking. A domain sync brought a stricte
 - Map the stated intent to one lifecycle phase, then either run the simplest command that satisfies it or hand off
 - Resolve every stack, rule, snippet, and standard name from a catalog at runtime
 - Run the CLI non-interactively and report the command run, what changed, and the full path of anything written
+- Read the overwrite contract from the body before any install or sync, and name each surface it lists as overwritten before running one
 - Read the reverse walk beside the forward sections, so a folder the toolkit stopped shipping and a migration with a live case both reach the user
 - Hand off a named migration to the skill the report names, the way an unmigrated domain reaches `migration-standards`
 - Offer every audit whose surface the target carries, and offer none whose surface it lacks

package/claude/skills/toolkit-operator/SKILL.md

@@ -80,6 +80,7 @@ The markdown row is the one every target satisfies, since a project with no mark
 For operations this skill runs directly:
 
 - Read the catalog first with `aitk <domain> list --json`, then match against project context
+- Read the `toolkit-cli` skill before any install or sync, and warn the user by name about each surface it lists as overwritten. A command name says nothing about what it does to a file already there, and this skill is the one running it.
 - Run the CLI with `AITK_NON_INTERACTIVE=1` so it skips prompts. The tool permission dialog is the confirmation gate.
 - Report the command run and what changed. Emit the full relative path for any file written.
 - Re-run `aitk sync --check . --json` after any operation that wrote, and compare it against the report `## Diagnose` read before acting

package/docs/operating-model.md

@@ -74,6 +74,19 @@ reply that changes an outcome, such as a worker naming the plan question that
 already declined a finding, still belongs back on the PR, since the session
 holding it ends and the thread is what a later reader opens.
 
+Two rules put it there rather than leaving that to whoever remembers. A finding
+the worker declines carries the fact that settled it in the same reply body that
+already maps every finding, and a pass accepting that argument states the
+withdrawal or the regrade with what produced it instead of dropping the finding
+from its next comment. Both fire on a line the body already writes, so neither
+asks a session to judge mid-reply whether its own message mattered.
+
+A reply that corrects the reviewing session rather than a finding stays off the
+thread. Which session holds which branch, or what gate a worker's edits pass
+through, changes no finding on a pull request that closes, so it goes to the task
+owning that surface. Nothing checks either rule, so both hold while a session
+applies them.
+
 A finding answered without a commit leaves the head where the first pass read it,
 which a gitignored record and a finding accepted as recorded both produce. The
 close-out is still owed there, since the newest heading is what tells an operator

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.90.0",
+  "version": "0.91.1",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {