@erclx/aitk 0.91.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.91.0",
+  "version": "0.91.1",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

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-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/package.json

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