@erclx/aitk 0.38.0 → 0.40.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (53) hide show
  1. package/README.md +1 -1
  2. package/claude/.claude-plugin/plugin.json +1 -1
  3. package/claude/skills/claude-design-extract/SKILL.md +1 -1
  4. package/claude/skills/claude-feature/REQUIREMENT.md +2 -1
  5. package/claude/skills/claude-feature/SKILL.md +9 -1
  6. package/claude/skills/create-rule/REQUIREMENT.md +1 -1
  7. package/claude/skills/create-skill/REQUIREMENT.md +6 -2
  8. package/claude/skills/create-skill/SKILL.md +5 -2
  9. package/claude/skills/create-snippet/REQUIREMENT.md +36 -0
  10. package/claude/skills/create-snippet/SKILL.md +23 -5
  11. package/claude/skills/{create-standard → create-snippet}/references/snippets.md +1 -1
  12. package/claude/skills/create-standard/REQUIREMENT.md +38 -0
  13. package/claude/skills/create-standard/SKILL.md +8 -12
  14. package/claude/skills/migration-claude-md/REQUIREMENT.md +41 -0
  15. package/claude/skills/migration-standards/REQUIREMENT.md +38 -0
  16. package/claude/skills/project-commands/REQUIREMENT.md +42 -0
  17. package/claude/skills/session-resume/REQUIREMENT.md +38 -0
  18. package/claude/skills/setup-indexes/REQUIREMENT.md +42 -0
  19. package/claude/skills/setup-indexes/SKILL.md +1 -1
  20. package/claude/skills/setup-plugins/REQUIREMENT.md +42 -0
  21. package/claude/skills/setup-verify/REQUIREMENT.md +39 -0
  22. package/claude/skills/systematic-debugging/REQUIREMENT.md +41 -0
  23. package/claude/skills/toolkit-cli/REQUIREMENT.md +37 -0
  24. package/claude/skills/toolkit-feedback/REQUIREMENT.md +40 -0
  25. package/claude/skills/toolkit-operator/REQUIREMENT.md +39 -0
  26. package/claude/skills/toolkit-triage/REQUIREMENT.md +40 -0
  27. package/claude/skills/youtube-transcripts/REQUIREMENT.md +38 -0
  28. package/docs/agents/capture.md +31 -0
  29. package/docs/agents/commands.md +57 -0
  30. package/docs/agents/comments.md +32 -0
  31. package/docs/agents/context-audit-checks.md +40 -0
  32. package/docs/agents/context-audit.md +44 -0
  33. package/docs/agents/docs.md +17 -0
  34. package/docs/agents/index.md +23 -0
  35. package/docs/agents/indexes.md +29 -0
  36. package/docs/agents/install-and-sync.md +109 -0
  37. package/docs/agents/output-shape.md +45 -0
  38. package/docs/agents/overview.md +26 -0
  39. package/docs/agents/sandbox.md +65 -0
  40. package/docs/agents/scripting.md +115 -0
  41. package/docs/agents/tasks.md +33 -0
  42. package/docs/index.md +4 -1
  43. package/docs/target-projects.md +2 -2
  44. package/package.json +1 -1
  45. package/scripts/docs/list.sh +36 -17
  46. package/scripts/manage-sandbox.sh +4 -0
  47. package/src/commands/sandbox.ts +1 -1
  48. package/src/sandbox/census.ts +1 -1
  49. package/src/ui.ts +1 -1
  50. package/standards/bundled/snippets.md +1 -1
  51. package/standards/skill.md +4 -4
  52. package/claude/skills/claude-design-propose/SKILL.md +0 -15
  53. package/docs/agents.md +0 -535
@@ -0,0 +1,41 @@
1
+ ---
2
+ name: systematic-debugging
3
+ description: Why a fix is blocked until investigation completes, and what the three-attempt stop is measuring
4
+ ---
5
+
6
+ # Systematic debugging requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, a session handed a failure proposes a fix from the first plausible reading of the error, and the fix is judged by whether the symptom moved. A symptom that moves is the normal result of changing something near it, so the session reports success and the cause is still there.
11
+
12
+ The compounding failures come next. Several changes go in at once, so a pass says nothing about which one mattered. A fix that fails gets another fix stacked on top of it rather than a new hypothesis, and the code accumulates changes nobody can trace to a reason. A bad value gets corrected where it was observed rather than where it was produced, which moves the failure downstream instead of removing it.
13
+
14
+ Two failures are about stopping rather than about fixing. A session that never counts its attempts keeps fixing through the pattern where each fix reveals a problem elsewhere, which is architectural and cannot be reached from inside the loop. And a session that concludes an issue is environmental usually has an incomplete investigation rather than an environmental issue, because that conclusion is available at any point and is never contradicted by evidence.
15
+
16
+ ## Must
17
+
18
+ - Complete the investigation before any fix is proposed, reading the failure in full and reproducing it
19
+ - Trace a bad value back to where it was produced and fix there
20
+ - Compare the broken code against working code in the same codebase before hypothesizing
21
+ - State one hypothesis and change one variable to test it
22
+ - Write the failing test before the fix, so the fix is judged against a reproduction rather than against the symptom
23
+ - Stop after three failed attempts and hand the architectural question to the user
24
+
25
+ ## Must not
26
+
27
+ - Stack a second fix on a failed one rather than forming a new hypothesis
28
+ - Bundle a refactor or an unrelated improvement into the fix
29
+ - Accept an environmental or timing conclusion before the investigation is exhausted
30
+ - Claim an understanding it does not have
31
+
32
+ ## Guards
33
+
34
+ - An incomplete investigation blocks the fix proposal, which is the skill's one refusal and the reason it exists
35
+ - Three failed attempts stop the loop, since the pattern is evidence about the design rather than about the bug
36
+
37
+ ## Out of scope
38
+
39
+ - A typo fix and a cause already agreed on, where the phases cost more than they return
40
+ - Reviewing a change for defects it has not yet exhibited: `claude-review`
41
+ - Deciding whether the architecture should change, which the three-attempt stop hands to the user rather than answering
@@ -0,0 +1,37 @@
1
+ ---
2
+ name: toolkit-cli
3
+ description: Why the overwrite contract is stated before a sync runs, and why the skill reads rather than executes
4
+ ---
5
+
6
+ # Toolkit cli requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, a session runs an `aitk` sync and finds out afterward what it did. The command names give nothing away. `install` and `sync` differ per domain, some surfaces overwrite unconditionally, some merge, some are written once and never touched again, and none of that is visible from the command line the user typed.
11
+
12
+ The damage lands on the files a project owns. A golden config carrying local edits is replaced without a warning anyone saw, and a standards install overwrites every standard in a project that only needed the two it had drifted on. The user learns which category a file was in by losing the edit.
13
+
14
+ 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.
15
+
16
+ ## Must
17
+
18
+ - State per surface and per command whether an existing file is overwritten, merged, written once, or left alone
19
+ - Warn about a destructive run before it happens, naming the surface that will be lost
20
+ - Name the section-preserving path for a standard or seed the project has customized
21
+ - Defer to the toolkit's own context docs when they and this summary disagree, since the summary is a copy and they are the source
22
+
23
+ ## Must not
24
+
25
+ - Run any `aitk` command. The skill is read before acting.
26
+ - Restate the full semantics. It is a target-session summary and the detail lives with its owner.
27
+
28
+ ## Guards
29
+
30
+ - A surface or command the contract does not cover routes to the context docs rather than to an inference from a similar row
31
+
32
+ ## Out of scope
33
+
34
+ - Executing the sync, which the user runs or `toolkit-operator` routes
35
+ - Reconciling a customized seed section by section: `claude-seed-sync`
36
+ - Relocating a project's folders into the layout a newer version expects: `migration-standards`
37
+ - Deciding which stack, rule, or standard a project should install, which the setup skills resolve from live catalogs
@@ -0,0 +1,40 @@
1
+ ---
2
+ name: toolkit-feedback
3
+ description: Why a toolkit defect is reported from session context alone, and what shipping through the CLI replaces
4
+ ---
5
+
6
+ # Toolkit feedback requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, a toolkit defect noticed inside a target project dies with the session. The user is told to mention it in the toolkit repository later, which means retyping a report they no longer have the context to write, so the defect is either reported badly or not at all.
11
+
12
+ The report itself fails two ways. A block printed in chat needs a copy-paste into another repository, and a step that manual is skipped under any time pressure. A report that names no surface cannot be routed, because the toolkit acts on a plugin skill, a snippet, a CLI command, and a seed through different paths, and the difference is not recoverable from the symptom.
13
+
14
+ The last failure is the session's own effort. Asked to report, a session starts diagnosing instead, searching the toolkit and reading its surfaces to find the cause. That spends the context the report was meant to capture cheaply, and it produces a diagnosis from a project that cannot see the toolkit's current source.
15
+
16
+ ## Must
17
+
18
+ - Build the report from what the session already holds
19
+ - Name the surface and its type, since the toolkit routes on that rather than on the symptom
20
+ - Write the stated fallback for a field the session cannot fill, so an empty field reads as absent rather than as unreported
21
+ - Ship through the CLI so the report lands without a copy-paste, and print the returned path on its own line
22
+ - Offer the durable route for a report worth keeping across sessions and machines
23
+ - Fall back to printing the block when the CLI is absent, so the report still exists
24
+
25
+ ## Must not
26
+
27
+ - Probe the project, list files, grep, or read toolkit surfaces to enrich the report
28
+ - Guess the surface type when the session is ambiguous. Ask one line.
29
+ - Diagnose or fix, which needs the toolkit's source rather than the target's
30
+
31
+ ## Guards
32
+
33
+ - Nothing in session context pointing at a toolkit issue stops, since a report assembled from nothing wastes the triage it reaches
34
+
35
+ ## Out of scope
36
+
37
+ - Fixing the defect, which happens in the toolkit repository against its own source
38
+ - Draining the queue this fills: `toolkit-triage`
39
+ - Filing an issue against the current project: `git-issue`
40
+ - Complaints about tooling the toolkit does not own
@@ -0,0 +1,39 @@
1
+ ---
2
+ name: toolkit-operator
3
+ description: Why the toolkit has one front door, what orienting on live catalogs prevents, and where it hands off
4
+ ---
5
+
6
+ # Toolkit operator requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, using the toolkit means knowing which skill to pick, and the user who most needs it is the one who cannot. A plain-language intent has no obvious owner among a dozen setup and sync skills, so the session guesses a command instead of resolving one, and a wrong guess installs into a project rather than reporting a mismatch.
11
+
12
+ Two failures come from acting on memory. A session that names a stack, rule, or snippet from what it remembers rather than from the live catalog runs against an entry that has been renamed or removed. And a session that edits a managed file by hand produces a change the next sync overwrites, which reads as the toolkit undoing work rather than as the edit having been made in the wrong place.
13
+
14
+ The last 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.
15
+
16
+ ## Must
17
+
18
+ - Orient on the toolkit's own docs and the live catalogs before acting
19
+ - Map the stated intent to one lifecycle phase, then either run the simplest command that satisfies it or hand off
20
+ - Resolve every stack, rule, snippet, and standard name from a catalog at runtime
21
+ - Run the CLI non-interactively and report the command run, what changed, and the full path of anything written
22
+
23
+ ## Must not
24
+
25
+ - Edit a managed file by hand instead of running the CLI that owns it
26
+ - Reimplement a flow another skill owns
27
+ - Hardcode a catalog name
28
+ - Auto-trigger. It is a door the user opens, and a router that fires on its own routes requests nobody made.
29
+
30
+ ## Guards
31
+
32
+ - An intent matching a deep flow hands off rather than running a shallow version of it, since a partial scaffold is harder to recover from than none
33
+
34
+ ## Out of scope
35
+
36
+ - First-time scaffold of a fresh project: `setup-init`
37
+ - Seed and preamble drift in installed files: `claude-seed-sync`
38
+ - Governance rule install and index bootstrap: `setup-gov` and `setup-indexes`
39
+ - What a given sync overwrites once it runs: `toolkit-cli`
@@ -0,0 +1,40 @@
1
+ ---
2
+ name: toolkit-triage
3
+ description: Why the feedback queue is read from GitHub rather than local scratch, and why triage routes instead of implementing
4
+ ---
5
+
6
+ # Toolkit triage requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, the feedback queue fills and nothing drains it. Reports arrive from projects the toolkit never sees, and a queue nobody reads on a schedule is the same as no queue. The local review folder looks like the right place to read, and it is the wrong one, because that content is per-machine session scratch that any cleanup removes.
11
+
12
+ Triage fails three ways once it starts. Unrelated issues get batched into one branch, so review has to judge several unconnected changes at once and can approve none of them cleanly. An issue needing a plan gets implemented inline from a paragraph of description, which skips the step where scope is argued. And an issue whose report contradicts itself gets a guess rather than a question, so the fix addresses a defect nobody confirmed.
13
+
14
+ The queue also fails to drain even when the work ships. A fix merged with no link back leaves its issue open, and the next triage re-reads work already done.
15
+
16
+ ## Must
17
+
18
+ - Read the durable queue rather than local session scratch
19
+ - Classify each issue in a fixed order and stop at the first match, stating the class and its one-line reason before routing
20
+ - Route to the skills that own planning, branch naming, and the pull request body rather than restating them
21
+ - Keep one issue to one branch and one pull request
22
+ - Link a fix to its issue so merge closes it, and preserve that link when the body is regenerated
23
+ - Ask on the issue when the report is unreadable, then move on rather than blocking the batch
24
+
25
+ ## Must not
26
+
27
+ - Batch unrelated fixes into one branch
28
+ - Implement a plan-worthy issue, which stops at the plan handed back to the user
29
+ - Close an issue whose pull request has yet to merge
30
+
31
+ ## Guards
32
+
33
+ - The `gh` CLI absent or unauthenticated stops, since the queue is unreachable
34
+ - An empty queue reports nothing open rather than widening the label to find work
35
+
36
+ ## Out of scope
37
+
38
+ - Filing new feedback: `toolkit-feedback`
39
+ - Writing the plan a plan-worthy issue needs: `claude-feature`
40
+ - Triage of issues carrying any other label, which surface here by design only under the feedback label
@@ -0,0 +1,38 @@
1
+ ---
2
+ name: youtube-transcripts
3
+ description: Why the transcript fetch stays in the CLI, and why fetching stops short of reading
4
+ ---
5
+
6
+ # Youtube transcripts requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, a pasted video link turns into captions printed in chat, which persist nowhere and cannot be cited by a later session. The file is the point. A transcript saved with its metadata is context the repository holds, and a transcript in a message is context that ends with the turn.
11
+
12
+ A session that fetches on its own gets the shape wrong. Raw captions carry timing cues and duplicated lines, and a file written without frontmatter has no title, no source URL, and no way to tell which video it came from. Reimplementing the cleanup also duplicates logic the CLI already owns, so the two drift and the drift shows up as inconsistent files rather than as an error.
13
+
14
+ Two smaller failures follow the fetch. A video with no captions produces a file that looks empty rather than one reported as having none, so the user reads it as a failed fetch. And a session that summarizes what it fetched answers a question nobody asked, spending context on a reading the user may not want yet.
15
+
16
+ ## Must
17
+
18
+ - Run the CLI, which owns the fetch, the caption cleanup, and the frontmatter
19
+ - Surface the written path as a full relative path so the terminal makes it clickable
20
+ - Report a video with no captions as a fact about the video, since the file still exists and carries its metadata
21
+ - Name the missing external binary and stop, leaving the install to the user
22
+
23
+ ## Must not
24
+
25
+ - Reimplement the fetch or the cleanup
26
+ - Summarize or annotate the transcript unasked, which is a separate request against the file
27
+ - Install the external binary the command shells out to
28
+
29
+ ## Guards
30
+
31
+ - No URL stops, since there is nothing to fetch
32
+ - A link that is not a YouTube URL stops rather than attempting a generic fetch the command cannot do
33
+
34
+ ## Out of scope
35
+
36
+ - Downloading the video or its audio
37
+ - Summarizing a transcript already on disk, which is a read of that file
38
+ - Choosing where transcripts live, which the command defaults and a flag overrides
@@ -0,0 +1,31 @@
1
+ ---
2
+ title: Capture
3
+ description: Rendering committed HTML sources to PNG, what the command asserts about fonts, and why it is toolkit-only
4
+ ---
5
+
6
+ # Capture
7
+
8
+ `aitk capture [source]` renders HTML capture sources to PNG, which is how a committed documentation image regenerates from its committed source. The source defaults to `assets/`, where a directory expands to every `.html` directly inside it, so adding a capture means dropping a file beside the first one and running the same bare command.
9
+
10
+ ```bash
11
+ aitk capture
12
+ aitk capture assets/install.html
13
+ aitk capture assets --out .claude/review/captures
14
+ ```
15
+
16
+ `assets/` now holds two sources, so a bare `aitk capture` rebuilds both. `install.html` is hand-authored and its text came from a real run. `hero.html` is generated by `scripts/core/regen-hero.sh` from the CLI catalogs and must not be edited by hand, since `bun run check` regenerates it and fails on the difference. Only the HTML is asserted for drift. The PNG is a chromium render whose bytes move with the browser version, so rebuild it with `aitk capture assets/hero.html` when the check reports the HTML changed.
17
+
18
+ | Option | Behavior |
19
+ | ------------------ | ------------------------------------------------- |
20
+ | `--out <dir>` | Write every PNG here instead of beside its source |
21
+ | `--selector <sel>` | Element to capture (default: `.window`) |
22
+
23
+ ## What the command asserts
24
+
25
+ Each source renders at `deviceScaleFactor` 2 with a transparent background, and the success line reports the pixel dimensions the element wrapped to. Size is reported and never asserted. The height of a terminal frame is whatever its text wrapped to at a fixed width, so pinning that number would harden an accident.
26
+
27
+ What is asserted is the font. The command reads the first family the captured element declares and fails when the browser did not resolve it, because a fallback face rewraps the block and silently changes the output. Sources therefore name a real font rather than relying on `monospace`. A source that cannot render reports its own line and exits 1 without dropping the rest of the batch.
28
+
29
+ The browser binary installs separately from the package. A fresh clone runs `bunx playwright install chromium` once, and a run that cannot launch one reports the engine's own remediation inside the frame and exits 1 rather than escaping as a stack trace.
30
+
31
+ The command is toolkit-only. Its render module holds every browser reference in the toolkit and `files` in `package.json` excludes it, so an installed `aitk` carries the command, reports it as absent on one line, and exits 1. Every other command is unaffected, which is the reason the browser import sits behind a dynamic import rather than at a command's top level.
@@ -0,0 +1,57 @@
1
+ ---
2
+ title: Command catalog
3
+ description: Every project-level command and every domain subcommand, plus the shape each domain exposes
4
+ ---
5
+
6
+ # Command catalog
7
+
8
+ Full help: `aitk <command> --help`. Behavior notes for the install and sync verbs live in `install-and-sync.md`.
9
+
10
+ ## Project-level
11
+
12
+ | Command | Purpose |
13
+ | ------------------------ | ---------------------------------------------------------------------------------------------- |
14
+ | `aitk init [path]` | Bootstrap a project with selected toolkit domains |
15
+ | `aitk sync [path]` | Sync all installed domains in a target project |
16
+ | `aitk sync --check` | Report toolkit drift without writing (`--json`, `--exit-code`) |
17
+ | `aitk sandbox [cat:cmd]` | Run sandbox scenarios (interactive or routed), toolkit-only like the tree it reads |
18
+ | `aitk sandbox reset` | Reset sandbox to baseline |
19
+ | `aitk sandbox clean` | Wipe the sandbox |
20
+ | `aitk sandbox check` | Score a provisioned sandbox against a scenario expectation (`--json` for the verdict) |
21
+ | `aitk sandbox coverage` | Report which scenarios declare expectations (`--json`, `--strict`, `--skills`) |
22
+ | `aitk indexes regen` | Regenerate `index.md` files from sibling frontmatter |
23
+ | `aitk docs [topic]` | Emit toolkit reference docs (`list`, or a topic by name) |
24
+ | `aitk design render` | Render `.claude/DESIGN.md` tokens to HTML and CSS |
25
+ | `aitk slides render` | Render a `.claude/SLIDES.md` source into a PowerPoint deck |
26
+ | `aitk slides list` | List the available slide layouts (`--json` for the catalog) |
27
+ | `aitk feedback` | Write toolkit feedback from stdin to `.claude/review/`, or open a GitHub issue with `--github` |
28
+ | `aitk transcripts <url>` | Fetch a YouTube transcript with metadata frontmatter (needs `yt-dlp`) |
29
+ | `aitk tasks archive` | Move a shipped task off the board, clear its ordering row, and regenerate the index |
30
+ | `aitk comments scan` | Measure comment density by language and comment kind, with a trend recomputed from git |
31
+ | `aitk context audit` | Report required sections, length, depth, bullet weight, cited paths, provenance, and drift |
32
+ | `aitk capture [source]` | Render HTML capture sources to PNG, toolkit-only and absent from an installed package |
33
+
34
+ ## Domain commands
35
+
36
+ Each domain exposes a consistent shape where applicable: `list`, `install`, `sync`, `create`.
37
+
38
+ | Domain | Subcommands |
39
+ | ----------- | ---------------------------------------------------------------------- |
40
+ | `tooling` | `list`, `sync`, `ref`, `create`, `verify`, `inject`, `prune-gitignore` |
41
+ | `snippets` | `list`, `install`, `sync`, `create` |
42
+ | `standards` | `list`, `install`, `sync` |
43
+ | `gov` | `list`, `install`, `sync`, `build` |
44
+ | `claude` | `init`, `sync`, `seeds list`, `skills list`, `setup [dest]` |
45
+ | `wiki` | `init` |
46
+ | `design` | `render` |
47
+ | `slides` | `render`, `list` |
48
+ | `tasks` | `archive` |
49
+ | `comments` | `scan` |
50
+ | `context` | `audit` |
51
+
52
+ Common patterns:
53
+
54
+ - `list --json` → machine-readable catalog on stdout.
55
+ - `install <name> <path>` → install a specific entry into a target project.
56
+ - `sync <path>` → reapply all installed entries in a target project.
57
+ - `create [name]` → scaffold a new authoring entry in this repo.
@@ -0,0 +1,32 @@
1
+ ---
2
+ title: Comments
3
+ description: Comment density by language and kind, the two structural exclusions, and how the degradation sweep finds its vocabulary
4
+ ---
5
+
6
+ # Comments
7
+
8
+ `aitk comments scan [path]` reports comment density for a tree, split by language and by comment kind. It is the only command that parses the target's own source, so its scope stays deliberately narrow: TypeScript and bash, line-oriented, no AST.
9
+
10
+ ```bash
11
+ aitk comments scan
12
+ aitk comments scan src --json
13
+ aitk comments scan --since v0.5.0
14
+ ```
15
+
16
+ | Option | Behavior |
17
+ | -------------------- | --------------------------------------------------------------- |
18
+ | `--json` | Add a machine-readable record on stdout, keeping the frame |
19
+ | `--since <rev>` | Report the trend from this revision instead of a snapshot alone |
20
+ | `--languages <list>` | Comma-separated subset of `ts,sh` (default: both) |
21
+
22
+ A line counts as a comment when its first non-whitespace token opens one, which is what keeps a URL in a string literal from reading as a `//` comment without a parser. Density is `commentLines / lines`, reported and never graded. The command produces the number and a rule produces the judgment.
23
+
24
+ Two exclusions are structural rather than tuning. Heredoc bodies are dropped from both the numerator and the denominator, because a scenario script carrying markdown inside one has `#` opening a heading rather than a comment, which inflated a measured 112 comment lines to 427. Fixture trees are pruned by path segment for the same reason. The line-1 shebang is not a comment, since every script has one and counting it puts a floor under density that reports the file count.
25
+
26
+ `--since` recomputes each point from git via `ls-tree` and `cat-file --batch`, checking nothing out. No ledger is written or read. Six points spread evenly across the window by default, and the boundary revision is always included so the series keeps the reading it is measured against. This works only because density is a pure function of a tree. Which author or session wrote a comment is not recoverable from git and does not belong here.
27
+
28
+ ## Degradation sweep
29
+
30
+ The degradation sweep reads its vocabulary from whichever rule publishes a `## Degradation vocabulary` heading, preferring `.claude/rules/` over `governance/rules/`, so one definition serves the toolkit and every target. Discovery anchors on the heading rather than a filename, because a renumbered rule would otherwise empty the vocabulary while the sweep still reported clean. With no such rule the sweep reports **skipped** rather than zero hits, since finding nothing and looking for nothing mean opposite things.
31
+
32
+ `090-code-comments` is the rule that publishes the list, and it ships on the `base` stack. A project that installs or syncs governance for the first time after that rule landed gets a sweep that previously reported skipped, so hits appear where the command used to stay quiet. Edit the backticked terms in the installed copy to change what that project sweeps for. The sweep matches comment text, so a comment naming a term as an example is a hit, and a hit is a prompt to read the line rather than a verdict on it.
@@ -0,0 +1,40 @@
1
+ ---
2
+ title: Context audit checks
3
+ description: What each non-gating check reports, the unit each checkpoint is measured in, and which folders each check reaches
4
+ ---
5
+
6
+ # Context audit checks
7
+
8
+ What each finding from `aitk context audit` means. The command surface, its flags, and the one gating check are in `context-audit.md`.
9
+
10
+ ## Required sections
11
+
12
+ The required-section check reports what does not declare `## Overview` and `## Layout`, the two sections `.claude/standards/context.md` marks required. The list is held in code beside the numeric checkpoints rather than parsed out of the standard, so it fails on a defect rather than on a rewrite of the wording around it. A heading at any level counts, because a domain that split into a folder carries its overview in a sibling named `overview.md` where the section is the `#` title and an `##` beneath it would repeat the filename. Matching exactly is what keeps `## Layout catalog` from satisfying `Layout`.
13
+
14
+ Which unit answers depends on the folder. Entries of the folder named under `.claude/` are one domain each, so each answers for itself and a finding names the entry. Entries of a folder a domain split into describe that one domain between them, so any sibling answers and a finding names the folder. Holding a split folder to the rule per file would report every child beside its `overview.md`, and rolling the named folder up would let one conforming entry stand in for every other domain sitting next to it.
15
+
16
+ It reports rather than gates, the closer call because a missing section reads more like a fact than the other judgments. What settles it is that the standard sanctions omitting `## Layout` from a domain owning no paths in the repo, and no measure separates that from an entry that forgot it. A domain covering only external tools is that case, and it reports on every run. The JSON record carries the findings as `missingSections` and the list as `checkpoints.requiredSections`.
17
+
18
+ ## Length and depth
19
+
20
+ Length and depth quote their checkpoints from `.claude/standards/context.md`: roughly 150 rendered lines for an entry, roughly 40 for a run no heading breaks. Depth measures the longest such run rather than everything under one `##`, skips fenced blocks so a markdown example does not read as three headings, and exempts a run whose lines are all list items at one indent averaging under 130 characters. The weight condition is what separates a scannable catalog of one-liners from a stack of paragraph-bullets, which reach the same count and read nothing alike.
21
+
22
+ Both checks count rendered lines rather than source lines, wrapping each line at 80 columns and summing the heights. Entries here are authored one line per bullet, so a block of fifteen paragraph-bullets occupies fifteen source lines and renders past sixty, which source counting cannot see. Measuring one checkpoint in each unit would put an entry length beside a run length that mean different things. Their exclusions still differ: the file measure counts fenced blocks and frontmatter, while the run measure skips a fence so an example cannot break the run around it. A reference-heavy entry therefore ranks by its examples, which the length legend states on every run. Runs count blank lines, which the standard leaves open, so a hand reader who drops them lands a line or two lower. Both sections state the width on every run, since a number in rendered lines cannot be reproduced without it.
23
+
24
+ ## Bullet weight and tables
25
+
26
+ The bullet check reports a top-level bullet past roughly 400 characters, which is where a bullet stops carrying a decision alone and starts carrying the incident that motivated it beside the decision. Continuation lines fold into the bullet they belong to, so a heavy bullet cannot fall under the checkpoint by wrapping across two source lines, while a nested item is left out because the parent's own text is what the checkpoint asks about. Findings group by entry and narrow to `.claude/context/` for the reasons the provenance ones do both. Unlike the peer-list threshold above it, this corpus has no gap behind the number: bullet weight decays smoothly from a median near 170, so the number is a judgment where that one was a measurement, and a bullet reading well past it means the number is wrong rather than the rule.
27
+
28
+ The table check reports a catalog that grows a row per shipped thing, not a table count. A fixed comparison table never reflows, so its size costs nothing. A table qualifies at six or more body rows whose first column mostly carries a path, command, or link, which is what separates a catalog from a comparison without reading the prose.
29
+
30
+ ## Provenance
31
+
32
+ The provenance check reports the markers narrating how a domain reached its shape rather than describing what it is: a date, a change number, or a release label. The standard admits a rejected alternative and the reasoning that killed it while refusing the provenance attached to it, so a marker names a line to read rather than a line to delete. Findings group by entry and sort left to right within a line, since what a reader acts on is which file to open. Fenced blocks are excluded, which keeps a pinned version in an install command from reading as a claim the entry makes. Frontmatter is excluded with them, since the content checks read the body alone, and that is what keeps a diagram entry's dated `verified` stamp a record of its last check rather than a marker to settle. Length is the exception, counting the whole file, so a reader applying the 150-rendered-line checkpoint against the body alone lands a few lines under what the tool reports.
33
+
34
+ ## Which folders each check reaches
35
+
36
+ The provenance, bullet-weight, and required-section checks cover `.claude/context/` alone, while length, depth, and the table finding reach every audited folder. The rule is stated in `.claude/standards/context.md`, which opens its scope by handing diagrams and wireframes to `diagrams.md` and `wireframes.md`, and the sibling standards do not restate it. A marker reported in a diagram entry would cite a rule that entry's own standard routes elsewhere. The split is between kinds of rule rather than kinds of folder, and what decides it is whether the remedy is actionable rather than what the check measures. Subdividing a run and splitting a file mean something in any entry, so length and depth generalize. Moving an incident out of a bullet and keeping the decision means nothing in a folder whose entries declare no decisions, which is why bullet weight narrows despite measuring a distance like the two that do not. Required sections narrow for a plainer reason: the names are the context standard's own, and neither sibling standard states a required section at all. The scoping key is the folder an entry was audited under, so `--folder` still reaches a folder the default list does not carry, and a domain split into `context/<sub-area>/` is governed as `context`. Every run states the reach, including a run where no audited folder is the governed one. The JSON record carries it as `checkpoints.provenanceFolder` and a per-folder `governsContent`.
37
+
38
+ ## Index drift
39
+
40
+ Index drift compares an index against its siblings in both directions. An entry the index does not link is invisible to a session choosing what to open, and a linked name resolving to nothing sends one to a path that opens nothing.
@@ -0,0 +1,44 @@
1
+ ---
2
+ title: Context audit
3
+ description: Running the audit, its flags and folder scope, the exit codes, and the citation gate that is the only failing one
4
+ ---
5
+
6
+ # Context audit
7
+
8
+ `aitk context audit [path]` reports the structural state of the folders following the index-plus-entry contract, meaning a generated `index.md` beside entries carrying frontmatter. It reads and reports. Fixing what it finds is separate work. What each finding means is in `context-audit-checks.md`.
9
+
10
+ ```bash
11
+ aitk context audit
12
+ aitk context audit --json
13
+ aitk context audit --citations-only
14
+ aitk context audit --folder context,diagrams
15
+ aitk context audit --folder docs
16
+ ```
17
+
18
+ | Option | Behavior |
19
+ | ------------------ | -------------------------------------------------------------------- |
20
+ | `--json` | Add a machine-readable record on stdout, keeping the frame |
21
+ | `--folder <list>` | Comma-separated folder names (default: the three below) |
22
+ | `--citations-only` | Run the gating citation check alone, printing nothing when it passes |
23
+
24
+ ## Folder scope
25
+
26
+ Scope defaults to `context`, `diagrams`, and `wireframes`, and a folder the project does not carry is skipped rather than reported. A domain that outgrew one file and split into `<domain>/` is audited as its own folder, so a split entry measures at the same grain as a flat one.
27
+
28
+ A name passed to `--folder` resolves under `.claude/` first and at the project root second, which is what puts `docs/` and any later corpus in reach of the same engine. The root base is reached only by a name the caller passes, so the default list still resolves under `.claude/` alone and a project holding a root `wireframes/` is not audited against a standard it never adopted. The scope line prints the resolved path, so a project carrying both spellings reads which one was taken. The JSON record carries the base per folder as `folders[].base`.
29
+
30
+ A run where no requested name resolves refuses, whichever list it read. Naming the absent ones narrows to `--folder`, since a project carrying one of the three default folders is the ordinary case and a name it never asked for is not a typo. The JSON record carries those names as `unresolvedFolders`.
31
+
32
+ ## Exit codes
33
+
34
+ Exit codes are `0` for a clean run, `1` for a refusal, and `2` for an unresolved citation. Only the citation check sets a failing code. Required-section, length, depth, bullet weight, table, provenance, and index findings print and return `0`, because each is a judgment and failing a push on one would make the check something to route around.
35
+
36
+ ## The citation gate
37
+
38
+ The citation check resolves every path into an audited folder that appears anywhere in the repository, and it is the half wired into `bun run check`. A stale reference has a silent failure mode: the session opens nothing and carries on.
39
+
40
+ Three exclusions keep it from firing on prose about paths. Fenced blocks are skipped in markdown, which covers a standard displaying a path as an example. Fixture and harness trees are skipped by location, covering sandbox scenarios that describe their own scratch tree, the eval harness naming its target project, and `*.test.ts`. A path into a folder the project does not carry is skipped, so a skill directing a reader to `.claude/wireframes/index.md` stays valid in a project that has wireframes and silent in one that does not.
41
+
42
+ What remains is a sentence naming a hypothetical entry to show the shape of a name, which no syntax separates from a real reference. Append `<!-- audit-ignore-citations -->` to that source line. The marker suppresses citation checking for its own line only.
43
+
44
+ The pattern spells the `.claude/` prefix, so a folder resolved at the project root is measured by every other check and contributes nothing here. Widening it to a bare `docs/x.md` would match prose that references nothing, which is a separate decision from where entries come from. A run whose folders all resolved at the root says the check is out of scope rather than reporting that zero paths resolved, and the same run under `--citations-only` refuses, because a gate exiting clean on a scope it could not build is the failure the gate exists to catch.
@@ -0,0 +1,17 @@
1
+ ---
2
+ title: Docs
3
+ description: How aitk docs resolves the toolkit's own reference surface from an install root, and how a split domain is named
4
+ ---
5
+
6
+ # Docs
7
+
8
+ `aitk docs` emits the toolkit's own reference docs so an agent in a target project can orient without the toolkit source checked out. The CLI resolves `docs/` and `.claude/context/` from its install root, and which of the two it finds depends on how the CLI was installed. A registry install carries `docs/` alone, since `.claude/` is not published. A clone or a linked worktree carries both.
9
+
10
+ - `aitk docs list [--json]` lists the downstream catalog: the consumer-facing `docs/` surface plus per-domain narrative from `.claude/context/` when that root is present. Toolkit-internal context entries (`ci`, `development`, `extensions`, `sandbox`) are dropped. From a registry install the context section is absent rather than empty.
11
+ - `aitk docs <topic>` prints one doc to stdout, resolved by exact name from `docs/` first, then `.claude/context/`. Any doc the install carries is reachable by name, including the toolkit-internal topics the list omits.
12
+
13
+ A domain too large for one file splits into `<domain>/` with a generated `index.md`, and both verbs name it by the folder. `aitk docs <domain>` prints that index, which is the catalog routing to the sub-area files, and the listing describes it from the index's `subtitle` where a sibling file supplies `description`. A sibling file wins over a folder of the same name. A folder carrying no `index.md` is absent from both, since a catalog is what makes the sub-areas reachable.
14
+
15
+ Data prints to stdout and the frame to stderr, so `aitk docs <topic> > out.md` captures clean markdown. With no topic and no verb, `aitk docs` runs `list`. An unknown topic names the available topics on stderr and exits 1.
16
+
17
+ Only a `---` block opening on the first line counts as frontmatter, so a document body carrying horizontal rules emits whole.
@@ -0,0 +1,23 @@
1
+ ---
2
+ title: Agents
3
+ subtitle: CLI catalog and invocation rules for agents, split by command domain. Start with overview.
4
+ category: Agent surface
5
+ ---
6
+
7
+ # Agents
8
+
9
+ CLI catalog and invocation rules for agents, split by command domain. Start with overview.
10
+
11
+ - [Capture](capture.md): Rendering committed HTML sources to PNG, what the command asserts about fonts, and why it is toolkit-only
12
+ - [Command catalog](commands.md): Every project-level command and every domain subcommand, plus the shape each domain exposes
13
+ - [Comments](comments.md): Comment density by language and kind, the two structural exclusions, and how the degradation sweep finds its vocabulary
14
+ - [Context audit checks](context-audit-checks.md): What each non-gating check reports, the unit each checkpoint is measured in, and which folders each check reaches
15
+ - [Context audit](context-audit.md): Running the audit, its flags and folder scope, the exit codes, and the citation gate that is the only failing one
16
+ - [Docs](docs.md): How aitk docs resolves the toolkit's own reference surface from an install root, and how a split domain is named
17
+ - [Indexes](indexes.md): Flags, exit codes, and JSON shape for aitk indexes regen, plus when it auto-stages what it rewrote
18
+ - [Install and sync](install-and-sync.md): What each install and sync verb writes, refuses, or leaves alone, and how drift is attributed in a target project
19
+ - [Output shape](output-shape.md): The two framed shapes every command renders into, and how JSON and --names modes keep stdout clean
20
+ - [Overview](overview.md): What this folder covers, the invocation rules every command inherits, and where domain behavior is documented instead
21
+ - [Sandbox](sandbox.md): Scenario routing, the expectation scoring surface, and the coverage census over scenarios and skills
22
+ - [Scripting](scripting.md): The runtime catalogs that replace hardcoded names, what each carries, and a headless invocation per domain
23
+ - [Tasks](tasks.md): Selecting a shipped task by stem or pull request, the refusal reasons, and why the board root defaults to the main worktree
@@ -0,0 +1,29 @@
1
+ ---
2
+ title: Indexes
3
+ description: Flags, exit codes, and JSON shape for aitk indexes regen, plus when it auto-stages what it rewrote
4
+ ---
5
+
6
+ # Indexes
7
+
8
+ `aitk indexes regen` rewrites `index.md` files from sibling frontmatter. With no positional paths, it walks the current directory. With paths, each resolves by walking up to the nearest indexed ancestor, bounded by `--root`. Duplicates dedupe. The whole-repo walk prunes `.git`, `node_modules`, and anything `.gitignore` covers via `git check-ignore`.
9
+
10
+ A positional path is not filtered that way, because the walk-up resolves on the filesystem and never consults git. That is the only way to regenerate an index inside a gitignored folder, and it is how `.claude/tasks/` stays current.
11
+
12
+ | Option | Behavior |
13
+ | --------------- | ---------------------------------------------------------------- |
14
+ | `--dry-run` | Report which indexes would change without writing |
15
+ | `--json` | Emit a machine-readable record per index on stdout |
16
+ | `--root <path>` | Walk-up boundary when positional paths are passed (default: CWD) |
17
+ | `--no-stage` | Skip the auto `git add` on modified indexes |
18
+
19
+ Exit codes: `0` clean, `1` frontmatter error or missing index, `2` drift found in `--dry-run`.
20
+
21
+ When positional paths are passed inside a git repo, modified `index.md` files are staged so lint-staged and Claude `PostToolUse` hooks commit the regenerated catalog. Whole-repo walks never auto-stage, and neither does a path git ignores, since staging one always fails and the warning would fire on every edit.
22
+
23
+ Skills can parse drift without branching on exit code:
24
+
25
+ ```bash
26
+ aitk indexes regen --dry-run --json | jq '.results[] | select(.action == "would-write")'
27
+ ```
28
+
29
+ For the system rationale, frontmatter contract, when to adopt, and bootstrap path, see `.claude/context/indexes.md`.