@erclx/aitk 0.8.0 → 0.10.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 (46) hide show
  1. package/README.md +17 -13
  2. package/claude/.claude-plugin/plugin.json +1 -1
  3. package/claude/skills/claude-address-review/REQUIREMENT.md +39 -0
  4. package/claude/skills/claude-address-review/SKILL.md +3 -4
  5. package/claude/skills/claude-autoship/REQUIREMENT.md +41 -0
  6. package/claude/skills/claude-autoship/SKILL.md +1 -1
  7. package/claude/skills/claude-diagram/SKILL.md +70 -40
  8. package/claude/skills/claude-docs/REQUIREMENT.md +39 -0
  9. package/claude/skills/claude-docs/SKILL.md +1 -1
  10. package/claude/skills/claude-memory-review/SKILL.md +1 -1
  11. package/claude/skills/claude-pr-review/REQUIREMENT.md +38 -0
  12. package/claude/skills/claude-pr-review/SKILL.md +1 -1
  13. package/claude/skills/claude-review/REQUIREMENT.md +39 -0
  14. package/claude/skills/claude-review/SKILL.md +1 -1
  15. package/claude/skills/claude-seed-sync/SKILL.md +1 -1
  16. package/claude/skills/claude-ui-test/SKILL.md +1 -1
  17. package/claude/skills/claude-ux-audit/SKILL.md +1 -1
  18. package/claude/skills/claude-worktree/SKILL.md +2 -2
  19. package/claude/skills/git-followup/SKILL.md +1 -1
  20. package/claude/skills/git-issue/SKILL.md +1 -6
  21. package/claude/skills/git-pr/SKILL.md +1 -6
  22. package/claude/skills/git-split/REQUIREMENT.md +2 -1
  23. package/claude/skills/git-split/SKILL.md +2 -0
  24. package/docs/agents.md +26 -0
  25. package/docs/ai-workflow.md +1 -1
  26. package/docs/target-projects.md +2 -2
  27. package/governance/rules/claude/560-diagrams.md +10 -2
  28. package/governance/rules/claude/570-skill.md +1 -1
  29. package/package.json +1 -1
  30. package/scripts/core/install-check.sh +1 -1
  31. package/src/claude/seeds.ts +7 -1
  32. package/src/cli.ts +4 -0
  33. package/src/commands/comments.ts +234 -0
  34. package/src/comments/scan.ts +338 -0
  35. package/src/comments/trend.ts +207 -0
  36. package/src/comments/vocabulary.ts +85 -0
  37. package/src/git-env.ts +36 -0
  38. package/src/git-ignore.ts +46 -0
  39. package/src/indexes/walk.ts +1 -29
  40. package/standards/diagrams.md +65 -15
  41. package/standards/index.md +2 -2
  42. package/standards/prose.md +14 -1
  43. package/standards/readme.md +15 -1
  44. package/standards/skill.md +14 -0
  45. package/tooling/claude/reference.md +5 -0
  46. package/tooling/claude/seeds/.claude/diagrams/index.md +8 -0
package/README.md CHANGED
@@ -13,29 +13,31 @@ claude plugin marketplace add https://github.com/erclx/aitk
13
13
  claude plugin install aitk@aitk
14
14
  ```
15
15
 
16
- The skills are then available as `/aitk:<name>`. Run `/reload-plugins` to pick them up inside a session that was already open. Updates arrive on release, so a push to this repo does not reach an installed copy.
16
+ The skills land as `/aitk:<name>`. If your session was already open, run `/reload-plugins` to pick them up. Updates arrive on release, so a push to this repo won't reach your installed copy.
17
17
 
18
- Several skills call the `aitk` CLI to read catalogs and run installs, and the plugin does not put it on your path. Install it from the registry.
18
+ Several skills call the `aitk` CLI to read catalogs and run installs, and the plugin doesn't put it on your path. Install it from the registry.
19
19
 
20
20
  ```bash
21
21
  bun install --global @erclx/aitk
22
22
  ```
23
23
 
24
- [Bun](https://bun.sh) is the CLI runtime and has to be on the path first. Confirm the install by resolving `aitk --help`.
24
+ [Bun](https://bun.sh) is the CLI runtime and has to be on your path first. Confirm the install by resolving `aitk --help`.
25
25
 
26
26
  ## Why
27
27
 
28
- Every AI coding setup accumulates the same assets. Prompts to reuse, rules agents should follow, slash commands, skills, seed docs, sync scripts. Across enough projects the copies drift, and agents stop getting consistent signals.
28
+ Every AI coding setup accumulates the same assets. Prompts to reuse, rules agents should follow, slash commands, skills, seed docs, sync scripts. Once you have enough projects, your copies drift and your agents stop getting consistent signals.
29
29
 
30
30
  Three design choices shape the toolkit.
31
31
 
32
32
  - Agent-first: every command has a non-interactive path and a JSON catalog. If a Claude Code skill or any other agent cannot drive the CLI without prompts, the design is wrong.
33
- - Text-native: conventions, rules, and prompts are authored as markdown that humans and agents read the same way. No hidden behavior, no compiled state.
34
- - One source, many consumers: this repo is the authoritative copy. Target projects install and sync on demand, never author in place.
33
+ - Text-native: conventions, rules, and prompts are authored as markdown that you and your agents read the same way. No hidden behavior, no compiled state.
34
+ - One source, many consumers: this repo is the authoritative copy. Your projects install and sync on demand, never author in place.
35
+
36
+ Two limits worth knowing before you install. Claude Code is the only agent runtime the plugin targets, and the CLI needs Bun on your path. Snippets are the one surface that also travels to Gemini chat.
35
37
 
36
38
  ## What is inside
37
39
 
38
- Each domain has a canonical source in this repo and a thin install or sync CLI on the target side. The links run to internal narrative, written for someone maintaining the toolkit rather than installing it.
40
+ Each domain has a canonical source in this repo and a thin install or sync CLI on your side. The links run to internal narrative, written for someone maintaining the toolkit rather than installing it, so skip them on a first pass.
39
41
 
40
42
  - [Claude Code plugin](.claude/context/claude-plugin.md): skills for planning, review, docs sync, and the git ship chain
41
43
  - [Governance rules](.claude/context/governance.md): Cursor rules and stacks, installable per project
@@ -49,6 +51,8 @@ Each domain has a canonical source in this repo and a thin install or sync CLI o
49
51
 
50
52
  ## Documentation
51
53
 
54
+ Scaffolding your first project? Start with target projects, then the AI workflow loop. Everything else answers questions that arrive later.
55
+
52
56
  - [AI workflow](docs/ai-workflow.md): feature-development loop inside a toolkit-managed project
53
57
  - [Operating model](docs/operating-model.md): orchestrator and worker roles for building across parallel sessions
54
58
  - [Visual design workflow](docs/visual-design-workflow.md): tiered guide for design and wireframe authoring
@@ -58,7 +62,7 @@ Each domain has a canonical source in this repo and a thin install or sync CLI o
58
62
 
59
63
  ## Development
60
64
 
61
- Working on the toolkit starts from a clone. Running the CLI does not, since it installs from the registry.
65
+ Working on the toolkit starts from a clone. Running the CLI doesn't, since it installs from the registry. Skip this section unless you're changing the toolkit itself.
62
66
 
63
67
  ### Prerequisites
64
68
 
@@ -67,7 +71,7 @@ Working on the toolkit starts from a clone. Running the CLI does not, since it i
67
71
  - [GitHub CLI](https://cli.github.com) (optional) for ship flows
68
72
  - Shell: `zsh` or bash 4+ (`brew install bash` on macOS).
69
73
 
70
- Clone the repo, then run the bootstrap script. It installs dependencies, links the CLI globally, and adds the Claude Code shell aliases to `~/.zshrc`.
74
+ Clone the repo, then run the bootstrap script. It installs dependencies, links the CLI globally, and adds the Claude Code shell aliases to your `~/.zshrc`.
71
75
 
72
76
  ```bash
73
77
  git clone https://github.com/erclx/aitk.git
@@ -76,7 +80,7 @@ bun install
76
80
  bun run bootstrap
77
81
  ```
78
82
 
79
- The script is idempotent. Re-run it after pulling upstream changes without duplicating anything. It confirms the install by resolving `aitk --help` on the last step. See [zshrc aliases](docs/zshrc-aliases.md) for what each alias does.
83
+ The script is idempotent, so re-run it after pulling upstream changes without duplicating anything. It confirms the install by resolving `aitk --help` on the last step. See [zshrc aliases](docs/zshrc-aliases.md) for what each alias does.
80
84
 
81
85
  With the CLI linked, scaffold a fresh project.
82
86
 
@@ -86,13 +90,13 @@ git init
86
90
  aitk init
87
91
  ```
88
92
 
89
- `aitk init` installs base tooling configs, Claude seeds, governance rules, standards, and snippets in one pass, and scaffolds a `.claude/wiki/` stub for the project's own reference pages. Governance defaults to the `base` stack, so a bare init lands the coding and doc-authoring rules in `.claude/rules/` alongside the standards they route to. Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. Run `aitk tooling list --json` to see the catalog.
93
+ `aitk init` installs base tooling configs, Claude seeds, governance rules, standards, and snippets in one pass, and scaffolds a `.claude/wiki/` stub for your project's own reference pages. Governance defaults to the `base` stack, so a bare init lands the coding and doc-authoring rules in `.claude/rules/` alongside the standards they route to. Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. Run `aitk tooling list --json` to see the catalog.
90
94
 
91
- For the full outsider journey (scaffold, add a domain later, sync upstream drift), see [target projects](docs/target-projects.md).
95
+ For the full journey from scaffold through adding a domain later to syncing upstream drift, see [target projects](docs/target-projects.md).
92
96
 
93
97
  ## Contributing
94
98
 
95
- Portfolio project. Issues are welcome. Pull requests are accepted by invitation only. See the [contributing guidelines](CONTRIBUTING.md) for the local loop, the authoring split, and the commit convention.
99
+ Portfolio project. Issues are welcome. Pull requests are accepted by invitation only, so open an issue rather than a branch. Read the [contributing guidelines](CONTRIBUTING.md) for the local loop, the authoring split, and the commit convention before you file anything.
96
100
 
97
101
  ## License
98
102
 
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "aitk",
3
3
  "description": "Automated governance, versioning, and discovery tools for Claude Code.",
4
- "version": "0.8.0",
4
+ "version": "0.10.0",
5
5
  "author": {
6
6
  "name": "Eric Le",
7
7
  "url": "https://github.com/erclx"
@@ -0,0 +1,39 @@
1
+ ---
2
+ name: claude-address-review
3
+ description: What the review return leg is for, the gaps it closes, and why the push lands before the reply
4
+ ---
5
+
6
+ # Claude address review requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, review findings are worked in whatever order the author read them and the thread never records which landed. A reply posted before the push describes code the remote does not have, so a reviewer checks the branch and finds the old version. A failing check gets treated as separate from the review, which produces a follow-up that answers every comment and leaves continuous integration red. One finding nobody can resolve stalls the rest.
11
+
12
+ ## Must
13
+
14
+ - Treat a failing check as a finding alongside the review comments, so the follow-up closes both
15
+ - Handle each finding independently, so one unresolved item does not block the others
16
+ - Verify before pushing, since a red follow-up costs the reviewer a second pass
17
+ - Push before replying, so the comment never runs ahead of the code it describes
18
+ - Map every finding to what changed, or to a one-line reason when it is a question or a conscious accept
19
+ - Post the terminal comment only when the findings are addressed and every check passes
20
+
21
+ ## Must not
22
+
23
+ - Merge, or read the closing comment as an approval. The author cannot approve their own pull request.
24
+ - Write a review. This skill consumes findings and does not produce them.
25
+ - Post the closing comment while a check is failing
26
+ - Reimplement the follow-up push or the doc refresh. Both have owners, and a second copy here drifts from them.
27
+ - Edit silently. A finding answered without a reply leaves the reviewer re-deriving the change from the diff.
28
+
29
+ ## Guards
30
+
31
+ - No open pull request for the current branch: stop
32
+ - The pull request carries no review comments or threads: stop with a pass
33
+
34
+ ## Out of scope
35
+
36
+ - Writing the review, which `claude-pr-review` owns. The split is by side of the channel: that one posts findings from an independent session and this one is the worker's return leg.
37
+ - Staging, committing, and pushing the follow-up, which `git-followup` owns under this skill's direction
38
+ - Refreshing the `.claude/` docs the fixes made stale, which `claude-docs` owns
39
+ - Re-reviewing its own fixes, which hands back to the orchestrator
@@ -73,10 +73,9 @@ bullet per finding, each opening with the bolded finding identifier.
73
73
  Close the body with `🤖 Addressed by Claude Code` on its own line so the reply
74
74
  reads as an independent machine pass, not a human sign-off.
75
75
 
76
- Before posting, scan the reply for em dashes and semicolons and rewrite each,
77
- splitting into two sentences or using a comma. The standards-audit hook skips
78
- `.claude/.tmp/`, so this scan is the only gate on the published reply. Post it to
79
- the PR:
76
+ Before posting, run the banned-character scan in `.claude/standards/prose.md`
77
+ against the reply. The hook skips `.claude/.tmp/`, so this scan is the only gate
78
+ on the published reply. Post it to the PR:
80
79
 
81
80
  ```bash
82
81
  gh pr comment <number> --body-file .claude/.tmp/address-review/reply-<number>.md
@@ -0,0 +1,41 @@
1
+ ---
2
+ name: claude-autoship
3
+ description: What the post-plan pipeline is for, the gaps it closes, and why every stop leaves the work recoverable
4
+ ---
5
+
6
+ # Claude autoship requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, the run from an approved plan to an open pull request is a conversation. A session implements, then asks what comes next, and the answer varies by session. Review gets skipped on a diff that needed one, or spent on prose already gated by a hook. A run that halts leaves no stated resume point, so the user reconstructs how far it got from the working tree.
11
+
12
+ ## Must
13
+
14
+ - Take the approved plan for the branch as the scope, and implement only what it describes
15
+ - Give every step a stop condition, and leave the code on the branch and the receipts on disk at each one
16
+ - Classify the changed-file list before review, so a prose-only diff skips a code review with no signal on it
17
+ - Stop on any critical or should-fix finding rather than acting on it
18
+ - Open the pull request as a draft, then watch continuous integration to a terminal state
19
+ - Name the recovery for the stop it took, since the value of stopping is that the user knows where to resume
20
+
21
+ ## Must not
22
+
23
+ - Expand past the plan, refactor a neighbor, or touch a file outside it without reason
24
+ - Loop on a failed verify. One fix attempt against the reported errors, then stop.
25
+ - Fix a review finding or a failing check. Both stops are deliberate, since a green pull request reached by auto-fix hides what broke.
26
+ - Run the memory Apply phase. Promoting an entry changes how the agent operates and ships as its own change.
27
+ - Read an empty changed-file list as prose-only. It satisfies that test vacuously and would route the branch past review instead of through it.
28
+
29
+ ## Guards
30
+
31
+ - Detached HEAD: stop, no slug resolves
32
+ - No approved plan at the branch's plan path: stop and route to the planning skill
33
+ - Uncommitted changes unrelated to the plan: stop
34
+ - No diff baseline against main: stop
35
+ - Empty changed-file list: stop, and never advise removing the output from `.gitignore` to get past it
36
+
37
+ ## Out of scope
38
+
39
+ - Writing the plan, which `claude-feature` owns. This chain starts from one already approved.
40
+ - The behavior of each step, owned by the skill invoked. This skill owns the order and the stop conditions.
41
+ - The resume path after a stop, which `git-ship` owns. That skill is the tail of this same sequence, which is why the two overlap by design.
@@ -11,7 +11,7 @@ Chain the post-plan pipeline in a single run. Every step has a stop condition. S
11
11
  ## Guards
12
12
 
13
13
  - All `.claude/plans/` and `.claude/review/` reads resolve at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`.
14
- - Run `git branch --show-current` and replace `/` with `-` to derive `<slug>`. If empty, stop: `❌ Detached HEAD. Checkout the feature branch first.`
14
+ - Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. This skill takes the stop rather than the `latest` fallback, since it commits and opens a pull request. If empty, stop: `❌ Detached HEAD. Checkout the feature branch first.`
15
15
  - If `.claude/plans/feature-<slug>.md` does not exist at the main worktree root, stop: `❌ No approved plan at .claude/plans/feature-<slug>.md. Run /claude-feature first.`
16
16
  - If the working tree has uncommitted changes unrelated to the plan, stop: `❌ Uncommitted changes outside the plan. Commit or stash before autoshipping.`
17
17
 
@@ -1,53 +1,65 @@
1
1
  ---
2
2
  name: claude-diagram
3
- description: Drafts `.claude/DIAGRAMS.md` with one or more Mermaid diagrams describing the project's architecture, request flow, retrieval or data pipeline, and deployment. Reads `.claude/ARCHITECTURE.md` and `REQUIREMENTS.md` when present, falls back to a code-structure scan. Use when asked to "draw the architecture", "diagram the system", "show the components", "give me a flow chart", or "visualize the project". Do NOT use for design tokens (use `claude-design-extract`) or UI audits (use `claude-ux-audit`).
3
+ description: Writes per-kind Mermaid diagram entries into `.claude/diagrams/`, covering system context, components, request flow, data pipeline, and deployment. Reads `.claude/ARCHITECTURE.md` and `REQUIREMENTS.md` when present, falls back to a code-structure scan. Use when asked to "draw the architecture", "diagram the system", "show the components", "give me a flow chart", "refresh the deploy diagram", or "visualize the project". Do NOT use for design tokens (use `claude-design-extract`) or UI audits (use `claude-ux-audit`).
4
4
  ---
5
5
 
6
6
  # Claude diagram
7
7
 
8
+ Write one entry per diagram kind. Never rewrite the folder wholesale. A pass that refreshes the deploy view leaves the other four files byte-identical, which is the whole reason the surface is a folder.
9
+
8
10
  ## Guards
9
11
 
10
12
  - If no `.claude/ARCHITECTURE.md`, no `.claude/REQUIREMENTS.md`, and no top-level folder structure to scan, stop: `❌ No source signal. Add .claude/ARCHITECTURE.md or run inside a project folder.`
11
13
 
12
- ## Step 1: read sources in parallel
14
+ ## Step 1: read sources and locate the surface
13
15
 
14
- Read these from the project root, skipping any that do not exist:
16
+ Read these from the project root in parallel, skipping any that do not exist:
15
17
 
18
+ - `.claude/diagrams/index.md` and every `.claude/diagrams/*.md`: which entries exist and what they already say
19
+ - `.claude/REQUIREMENTS.md`: users, external dependencies, tech stack, MVP feature list
16
20
  - `.claude/ARCHITECTURE.md`: layered components, key technical decisions
17
- - `.claude/REQUIREMENTS.md`: tech stack, MVP feature list
18
21
  - `CLAUDE.md`: project type, conventions
19
22
  - `package.json`, `pyproject.toml`, `Cargo.toml`: language and framework markers
20
23
  - Top-level folder layout and root config files via `ls`: deploy targets, infrastructure config, component boundaries
21
24
 
22
- Run all reads in parallel. Do not recurse speculatively.
25
+ Do not recurse speculatively.
23
26
 
24
- ## Step 2: pick which diagrams to emit
27
+ Follow `.claude/standards/diagrams.md` for frontmatter, entry kinds, layout, budgets, accessibility, verification, and explanation rules, or `${CLAUDE_SKILL_DIR}/../../standards/diagrams.md` when the project does not have it.
25
28
 
26
- Emit a diagram only when its source signal exists. Skip the rest, do not pad the file.
29
+ ### Migrating a pre-split flat file
27
30
 
28
- - **Components** (`flowchart TB` with `subgraph` boundaries): always, when any signal exists. Shows the layered structure of the system.
29
- - **Request flow** (`sequenceDiagram`): when prose describes a request lifecycle, an agent loop, or interaction between actors
30
- - **Data pipeline** (`flowchart TB`): when prose mentions retrieval, ranking, queues, ETL, or pipelines
31
- - **Deployment** (`flowchart TB`): when the top-level listing contains deploy or infrastructure config, or `.claude/ARCHITECTURE.md` has a deploy section
31
+ When `.claude/diagrams/` holds no entry and `.claude/DIAGRAMS.md` exists, this pass converts it. An entry is any `*.md` in the folder other than `index.md`. The seed ships `index.md` alone, so a folder holding only the catalog is an empty set and still converts. Split each H2 section into the entry whose kind it matches, carry its mermaid body and explanation prose across unchanged, and add the frontmatter the standard requires. Leave `.claude/DIAGRAMS.md` on disk so the split can be compared against its source, and say in Step 7 that deleting it is the user's call.
32
32
 
33
- Stay inside `flowchart` and `sequenceDiagram`. Do not emit C4, state, ER, or class diagrams. They render inconsistently across viewers.
33
+ Convert only. Do not redraw a diagram during a migration pass, since a rewrite and a move landing together leaves no way to tell which one broke a diagram.
34
34
 
35
- Follow `.claude/standards/diagrams.md` for layout, budgets, accessibility, verification, labeling, narrative, and explanation rules, or `${CLAUDE_SKILL_DIR}/../../standards/diagrams.md` when the project does not have it. `flowchart TB` is the default. Reach for `flowchart LR` only when a pipeline genuinely cannot read top-to-bottom, and call it out in the explanation paragraph.
35
+ ## Step 2: pick which entries this pass writes
36
36
 
37
- ## Step 3: write the file
37
+ Write an entry only when its source signal exists, and only when this pass has a reason to touch it. Skip the rest and leave their files alone.
38
38
 
39
- Read the existing `.claude/DIAGRAMS.md` from the project root when it is present, then write to that path. Always overwrite. The prior content is what tells Step 4 which mermaid bodies this pass actually changed.
39
+ Count entries the way Step 1 does, excluding `index.md`. Counting the catalog as an entry sends a first pass down the compare branch with nothing to compare, and it writes nothing.
40
40
 
41
- File format:
41
+ - The user named a kind: write that one.
42
+ - The user asked broadly and the folder holds no entry: write every kind whose signal exists.
43
+ - The user asked broadly and at least one entry exists: compare each entry against its source signal and write only the ones whose signal moved. Report the untouched ones as current.
42
44
 
43
- ````markdown
44
- # Diagrams
45
+ The standard fixes one filename and one `category` value per kind. Use them verbatim rather than inventing a name, since a refresh finds its target by filename and a new name writes a duplicate entry beside the old one. Emit `system-context.md` whenever `.claude/REQUIREMENTS.md` exists, since it is the entry a reader outside the team opens first and the set is incomplete without it.
46
+
47
+ Stay inside `flowchart` and `sequenceDiagram`. C4, state, ER, and class diagrams render inconsistently across viewers.
48
+
49
+ ## Step 3: write the entries
50
+
51
+ One file per kind at `.claude/diagrams/<kind>.md`. Write only the files Step 2 selected.
45
52
 
46
- <one-paragraph note on what this file contains and which sources drove it>
53
+ ````markdown
54
+ ---
55
+ title: <what the entry answers, sentence case>
56
+ description: <the question it settles and the signal that drives it>
57
+ category: <the kind, matching the standard>
58
+ ---
47
59
 
48
- ## <Section title>
60
+ # <Same as title>
49
61
 
50
- <one-line description of what this diagram shows>
62
+ <one-line statement of what the diagram shows>
51
63
 
52
64
  ```mermaid
53
65
  <diagram type>
@@ -56,22 +68,34 @@ File format:
56
68
  <body>
57
69
  ```
58
70
 
59
- ## <Next section>
60
-
61
- ...
71
+ <one to three explanation paragraphs>
62
72
  ````
63
73
 
64
- When sources came from a code scan rather than planning prose, lead the intro paragraph with `Source: code.` and add `Fidelity is lower than prose-driven diagrams. Verify against the project's intent.`
74
+ When sources came from a code scan rather than planning prose, lead the explanation with `Source: code.` and add `Fidelity is lower than prose-driven diagrams. Verify against the project's intent.`
65
75
 
66
76
  Quote node labels containing spaces or special characters with double quotes (`A["Web shell"]`). Avoid parentheses inside labels, they break some renderers. Use `<br/>` for line breaks inside labels.
67
77
 
68
- Apply the toolkit's prose bans to the entire file, including inside mermaid `subgraph` labels and node text. No em-dashes, no semicolons. Use a colon or split into two sentences instead. The standards-audit hook treats mermaid syntax as prose and will reject the file on every violation, forcing a retry per label.
78
+ Run the banned-character scan in `.claude/standards/prose.md` against the whole file, including inside mermaid `subgraph` labels and node text, or `${CLAUDE_SKILL_DIR}/../../standards/prose.md` when the project does not have it. A colon also works as a replacement inside a label. The pedagogical voice the diagram standard asks for is a yield on voice alone and buys no exemption from these bans.
79
+
80
+ Nothing enforces the ban inside the diagram. The standards-audit hook toggles on a fence and skips every line within it, so a label carrying an em dash passes silently while the same character in the explanation paragraph below is caught. Check the labels by reading them. This is the one place in the file where the author is the only gate.
69
81
 
70
- ## Step 4: render what this pass changed
82
+ ## Step 4: regenerate the catalog
83
+
84
+ ```bash
85
+ aitk indexes regen
86
+ ```
87
+
88
+ Run it after the last entry is written. It rebuilds `.claude/diagrams/index.md` from sibling frontmatter and groups entries under their `category`. Never hand-edit that file.
89
+
90
+ When `aitk` is not on PATH, say so in Step 7 and name `.claude/diagrams/index.md` as stale rather than writing it by hand.
91
+
92
+ Scaffold `.claude/diagrams/index.md` with `title` and `subtitle` frontmatter before the first regen when the folder is new and the seed did not provide one. The subtitle routes a first-time reader to the system context entry, since the catalog sorts categories alphabetically rather than in narrative order.
93
+
94
+ ## Step 5: render what this pass changed
71
95
 
72
96
  A source that satisfies every rule in the standard can still render as a picture that asserts something false about the system. Verification runs on the image.
73
97
 
74
- Render each diagram this pass wrote or changed. Skip any whose mermaid body is unchanged from the content read in Step 3, since an untouched diagram cannot develop a new render defect and the cost is linear in diagram count.
98
+ Render each entry this pass wrote. Skip every entry Step 2 left alone, since an untouched diagram cannot develop a new render defect.
75
99
 
76
100
  Before the first render in a project, say what is about to block:
77
101
 
@@ -82,44 +106,50 @@ Rendering to verify layout. The first run downloads the Mermaid CLI and takes ab
82
106
  Write each diagram's mermaid body to its own scratch file, then render it:
83
107
 
84
108
  ```bash
85
- mkdir -p .claude/.tmp/diagrams && bunx -y @mermaid-js/mermaid-cli -i .claude/.tmp/diagrams/<slug>.mmd -o .claude/.tmp/diagrams/<slug>.png
109
+ mkdir -p .claude/.tmp/diagrams && bunx -y @mermaid-js/mermaid-cli -i .claude/.tmp/diagrams/<kind>.mmd -o .claude/.tmp/diagrams/<kind>.png
86
110
  ```
87
111
 
88
112
  Render to PNG. An SVG export reads back as markup with no recoverable spatial meaning, so it cannot be verified. Use `bunx` when bun is available. Fall back to `npx -y @mermaid-js/mermaid-cli ...` otherwise.
89
113
 
90
114
  Renders are verification artifacts, not deliverables. They stay in `.claude/.tmp/diagrams/` and are never committed.
91
115
 
92
- When the render fails for any reason (no browser engine, no network, no package manager), continue to Step 6 and name the skipped check in the chat output. A missing renderer degrades the loop, it does not fail it.
116
+ When the render fails for any reason (no browser engine, no network, no package manager), continue to Step 7 and name the skipped check in the chat output. A missing renderer degrades the loop, it does not fail it.
93
117
 
94
- ## Step 5: read the render back
118
+ ## Step 6: read the renders back
95
119
 
96
- Read each PNG and judge the picture against what the diagram means to say. Follow the verification properties in `.claude/standards/diagrams.md`, or `${CLAUDE_SKILL_DIR}/../../standards/diagrams.md` when the project does not have it.
120
+ Read each PNG and judge the picture against what the entry means to say. Apply the verification properties in the standard.
97
121
 
98
- Fix the source and re-render. Stop after two correction passes on a diagram.
122
+ Fix the source and re-render. Stop after two correction passes on an entry.
99
123
 
100
- When a defect survives, write the diagram and name the defect in the chat output. A diagram whose author states the flaw is recoverable. A wrong diagram reported as verified is not.
124
+ When a defect survives, keep the entry and name the defect in the chat output. A diagram whose author states the flaw is recoverable. A wrong diagram reported as verified is not.
101
125
 
102
- ## Step 6: chat output
126
+ ## Step 7: chat output
103
127
 
104
128
  ```plaintext
105
- 📝 Wrote .claude/DIAGRAMS.md with N diagrams.
129
+ 📝 Wrote N entries to .claude/diagrams/
130
+ .claude/diagrams/<kind>.md
131
+ <one line per entry written>
132
+
133
+ Left untouched: <kind, kind> <omitted when the folder was empty>
106
134
 
107
135
  Verified N renders. <defect or skipped check, one line each, omitted when clean>
108
136
 
109
137
  Open in any viewer with native Mermaid support (VS Code with `bierner.markdown-mermaid`, GitHub, Cursor) to render. Ask to export if you want SVG or PNG files.
110
138
  ```
111
139
 
112
- Do not echo the diagram bodies in chat. Never report a clean verification when a render was skipped or a defect survived.
140
+ Emit the full path for every file written. Do not echo the diagram bodies in chat. Never report a clean verification when a render was skipped or a defect survived. Never report an entry as written when this pass left it alone.
141
+
142
+ After a migration pass, add: `Converted .claude/DIAGRAMS.md into N entries. The original is untouched, delete it once you have compared the split against it.`
113
143
 
114
- ## Step 7: export on request
144
+ ## Step 8: export on request
115
145
 
116
146
  If the user asks to export the diagrams (`export to svg`, `give me images`, `render to png`), run:
117
147
 
118
148
  ```bash
119
- mkdir -p .claude/review/diagrams && bunx -y @mermaid-js/mermaid-cli -i .claude/DIAGRAMS.md -o .claude/review/diagrams/diagram.png
149
+ mkdir -p .claude/review/diagrams && bunx -y @mermaid-js/mermaid-cli -i .claude/diagrams/<kind>.md -o .claude/review/diagrams/<kind>.png
120
150
  ```
121
151
 
122
- Export PNG by default. Swap `diagram.png` for `diagram.svg` only when the user asks for vector, and never for the Step 4 verification path. The CLI writes one file per `mermaid` block (`diagram-1.png`, `diagram-2.png`, ...). Output line:
152
+ Export PNG by default. Swap the extension for `.svg` only when the user asks for vector, and never for the Step 5 verification path. The CLI writes one file per `mermaid` block, suffixing when an entry holds more than one. Export every entry when the user names no kind. Output line:
123
153
 
124
154
  ```plaintext
125
155
  📝 Wrote N files to .claude/review/diagrams/
@@ -0,0 +1,39 @@
1
+ ---
2
+ name: claude-docs
3
+ description: What the planning-doc reconcile is for, the gaps it closes, and why the diff decides completion alone
4
+ ---
5
+
6
+ # Claude docs requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, the planning docs describe the scope the session opened with. An outcome the diff shipped stays unchecked, so the board reports finished work as open and the next session re-plans it. A requirement or architecture decision that changed mid-cycle lives only in the conversation and dies with it. Plans for closed tasks accumulate in the live folder, so the folder stops indicating what is in flight.
11
+
12
+ ## Must
13
+
14
+ - Take completion from the diff and everything else from the session, since completion is a fact about the repository rather than about the conversation
15
+ - Match an outcome on the behavior it names, never on a filename or a commit subject
16
+ - 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.
17
+ - Write tracked docs at the current worktree root and the task board at the main root, since only the first commits with the branch
18
+ - Count every other citation before archiving a plan, comparing resolved targets rather than raw strings or bare filenames
19
+ - Retarget a closed task at the archived plan, so the reasoning behind finished work stays reachable
20
+
21
+ ## Must not
22
+
23
+ - Infer a new task from the diff. Only outcomes already on the board get marked.
24
+ - Touch task files the session did not change, outside the board-wide plans sweep that exists to clear a missed archive
25
+ - Widen what a writing step reads when the baseline is unusable. Widening a read is safe and widening a write stubs a surface for every file in the repository.
26
+ - Edit `CLAUDE.md` inline. Every change there goes through a diff-and-approve gate, so this skill only flags.
27
+ - Create a context entry or delete a plan
28
+
29
+ ## Guards
30
+
31
+ - No `.claude/` directory: stop and name the command that sets one up
32
+ - No session divergence and no queued outcome the diff shipped: stop with a pass, since both conditions have to hold
33
+
34
+ ## Out of scope
35
+
36
+ - Creating a task file or moving one off the board, which `claude-tasks` owns
37
+ - Public-facing docs, which `docs-sync` owns. This skill reconciles the `.claude/` planning surface.
38
+ - Regenerating the task index, owned by a hook
39
+ - Redrawing diagrams, which `claude-diagram` owns. This skill flags staleness and leaves the re-run to the author.
@@ -181,7 +181,7 @@ A plan can serve more than one task, and archiving on the first task to close st
181
181
 
182
182
  Write the retarget as a markdown link, `Plan: [feature-<slug>](../.tmp/plans-archive/feature-<slug>.md)`, updating both halves so the text and the target stay in step. This branch is the only writer that produces a `Plan:` line nobody authored by hand, so a retarget that emits a bare path converts every task to the old form as it closes and drifts the board back to two shapes on its own.
183
183
 
184
- **Reviews.** Derive `<slug>` from the current branch name (replace `/` with `-`). If `.claude/review/review-<slug>.md` exists, delete it. `claude-review` writes with this convention. Do not sweep any other `review-*.md` file.
184
+ **Reviews.** Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result. If `.claude/review/review-<slug>.md` exists, delete it. `claude-review` writes with this convention. Do not sweep any other `review-*.md` file.
185
185
 
186
186
  Do not sweep `ui-checklist-*.md` (pending human verification) or `ux-audit-*.md` (standalone deliverable).
187
187
 
@@ -78,7 +78,7 @@ Rules that resist crisp one-line phrasing default to **Delete** over promote. Ne
78
78
 
79
79
  ### Step 4: write the proposal to the review file
80
80
 
81
- Derive a slug from the current git branch: run `git branch --show-current` and replace `/` with `-`. Fall back to `latest` on empty output.
81
+ Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result.
82
82
 
83
83
  Write the full proposal to `.claude/review/memory-review-<slug>.md` at the main worktree root. Do not print it inline.
84
84
 
@@ -0,0 +1,38 @@
1
+ ---
2
+ name: claude-pr-review
3
+ description: What the independent pull request review is for, the gaps it closes, and why it posts twice
4
+ ---
5
+
6
+ # Claude PR review requirement
7
+
8
+ ## Gap
9
+
10
+ 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.
11
+
12
+ ## Must
13
+
14
+ - Post both passes. A first pass opens the review against the whole change, and a close-out confirms the prior findings landed.
15
+ - Detect the pass from the thread rather than taking it from the caller, matching the heading for equality so a neighboring comment cannot be read as a prior pass
16
+ - Scope a close-out to the commits added since the prior pass, once that commit is confirmed to still reach the head
17
+ - Apply the integration, contract, and consumer lenses a self-review structurally cannot
18
+ - Post a close-out even with nothing to report, since a first pass left unanswered reads as a review nobody closed
19
+ - Key the body file on both the pull request number and the head commit, so no two passes overwrite each other
20
+
21
+ ## Must not
22
+
23
+ - Merge. Review and post, and leave the gate to the human.
24
+ - Publish a claim the skill did not check. A failed fetch and a rebase both strand the prior commit, and only one of them is a rebase.
25
+ - Invent a third heading, or append a number GitHub already renders
26
+ - Review local uncommitted changes
27
+ - Lecture on process. The lenses land as findings, not as asides.
28
+
29
+ ## Guards
30
+
31
+ - No open pull request for the target branch: stop and route to the local review skill
32
+ - The fetch of the pull request head fails: stop rather than falling through to a full pass
33
+
34
+ ## Out of scope
35
+
36
+ - Fixing what it finds, which `claude-address-review` owns. The split is by side of the channel: this one posts findings from an independent session and that one consumes them.
37
+ - Reviewing local uncommitted work, which `claude-review` owns. That one writes to disk for the session that wrote the code, and this one posts to a pull request it did not write.
38
+ - Merging, which stays the human's decision
@@ -131,7 +131,7 @@ The `What is right` section is optional, capped at three bullets, and included o
131
131
 
132
132
  Close the body with `🤖 Reviewed by Claude Code` on its own line so the review reads as an independent machine pass, not a human sign-off.
133
133
 
134
- Before posting, scan the body for em dashes and semicolons and rewrite each, splitting into two sentences or using a comma. The standards-audit hook skips `.claude/.tmp/`, so this scan is the only gate on the published comment.
134
+ Before posting, run the banned-character scan in `.claude/standards/prose.md` against the body. The hook skips `.claude/.tmp/`, so this scan is the only gate on the published comment.
135
135
 
136
136
  ```bash
137
137
  gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>-<short-sha>.md
@@ -0,0 +1,39 @@
1
+ ---
2
+ name: claude-review
3
+ description: What local review is for, the gaps it closes, and why it reports without fixing
4
+ ---
5
+
6
+ # Claude review requirement
7
+
8
+ ## Gap
9
+
10
+ Without this skill, a branch ships on the confidence of the session that wrote it. Review happens in chat and evaporates, so the ship step has no receipt to gate on. What review does happen mixes style opinion with real defects at one severity, and a reader cannot tell which blocks the merge. Worst, a diff that resolves empty against a stale base reports a clean branch instead of admitting the skill could not see the work.
11
+
12
+ ## Must
13
+
14
+ - Read the project's own context before the diff, so a decision already settled is not reported as a defect
15
+ - Resolve the base ref once, preferring the remote over local `main`, and reuse it in the guard and the read
16
+ - Say when the baseline is unusable and name the narrowed scope, rather than letting a clean summary read as a clean branch
17
+ - Flag only what will cause incorrect behavior or break a documented rule
18
+ - Grade every finding, since the caller gates on the counts rather than on the prose
19
+ - Write the report to disk under a branch-derived slug, so what the ship step reads outlives the session
20
+
21
+ ## Must not
22
+
23
+ - Fix, rewrite, or suggest a refactor outside a finding. Reporting is the whole job.
24
+ - Flag style, linter territory, or anything resting on unverified state. A false positive erodes trust in the pass.
25
+ - Substitute the whole tree for a missing baseline
26
+ - Repeat the full report in chat. The file is the report and a chat copy of it goes stale immediately.
27
+ - Stage or commit the receipt, which is gitignored scratch
28
+ - Auto-trigger on a vague signal. Require an explicit request or a pipeline invocation.
29
+
30
+ ## Guards
31
+
32
+ - The staged set, the branch set, and the working set are all empty: stop with a pass
33
+ - Baseline unusable: continue on the uncommitted set and lead the report with the warning
34
+
35
+ ## Out of scope
36
+
37
+ - Reviewing an open pull request, which `claude-pr-review` owns. The split is by vantage: this one reviews local work for the session that wrote it and writes to disk.
38
+ - Deciding whether the findings block the ship. This skill grades and the caller gates.
39
+ - Fixing anything it found, which `claude-address-review` owns once the work is on a pull request
@@ -116,7 +116,7 @@ If nothing is wrong, use: `✅ No findings.`
116
116
 
117
117
  ### Persist
118
118
 
119
- Derive a slug from the current git branch: run `git branch --show-current` and replace any `/` with `-`. If the result is empty (detached HEAD), use `latest`.
119
+ Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result.
120
120
 
121
121
  Write the full report directly to `.claude/review/review-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
122
122
 
@@ -52,7 +52,7 @@ Before proposing an Update, grep the target section for the seed text's keywords
52
52
 
53
53
  ## Step 4: write the proposal to the review file
54
54
 
55
- Derive a slug from the current git branch: run `git branch --show-current` and replace `/` with `-`. Fall back to `latest` on empty output.
55
+ Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result.
56
56
 
57
57
  Write the full proposal to `.claude/review/seed-audit-<slug>.md` at the main worktree root. Do not print the proposal inline.
58
58
 
@@ -57,7 +57,7 @@ If all changes are automatable, skip the manual checklist:
57
57
 
58
58
  ### Persist the checklist
59
59
 
60
- Derive a slug from the current git branch: run `git branch --show-current` and replace any `/` with `-`. If the result is empty (detached HEAD), use `latest`.
60
+ Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result.
61
61
 
62
62
  When a manual checklist is produced, write it directly to `.claude/review/ui-checklist-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
63
63
 
@@ -58,7 +58,7 @@ If nothing is wrong, use: `✅ No observations.`
58
58
 
59
59
  ### Persist
60
60
 
61
- Derive a slug from the current git branch: run `git branch --show-current` and replace any `/` with `-`. If the result is empty (detached HEAD), use `latest`.
61
+ Derive `<slug>` per Deriving the branch slug in `.claude/standards/skill.md`, or `${CLAUDE_SKILL_DIR}/../../standards/skill.md` when the project does not have it. Fall back to `latest` on an empty result.
62
62
 
63
63
  Write the full report directly to `.claude/review/ux-audit-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
64
64