@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.
- package/README.md +17 -13
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/claude-address-review/REQUIREMENT.md +39 -0
- package/claude/skills/claude-address-review/SKILL.md +3 -4
- package/claude/skills/claude-autoship/REQUIREMENT.md +41 -0
- package/claude/skills/claude-autoship/SKILL.md +1 -1
- package/claude/skills/claude-diagram/SKILL.md +70 -40
- package/claude/skills/claude-docs/REQUIREMENT.md +39 -0
- package/claude/skills/claude-docs/SKILL.md +1 -1
- package/claude/skills/claude-memory-review/SKILL.md +1 -1
- package/claude/skills/claude-pr-review/REQUIREMENT.md +38 -0
- package/claude/skills/claude-pr-review/SKILL.md +1 -1
- package/claude/skills/claude-review/REQUIREMENT.md +39 -0
- package/claude/skills/claude-review/SKILL.md +1 -1
- package/claude/skills/claude-seed-sync/SKILL.md +1 -1
- package/claude/skills/claude-ui-test/SKILL.md +1 -1
- package/claude/skills/claude-ux-audit/SKILL.md +1 -1
- package/claude/skills/claude-worktree/SKILL.md +2 -2
- package/claude/skills/git-followup/SKILL.md +1 -1
- package/claude/skills/git-issue/SKILL.md +1 -6
- package/claude/skills/git-pr/SKILL.md +1 -6
- package/claude/skills/git-split/REQUIREMENT.md +2 -1
- package/claude/skills/git-split/SKILL.md +2 -0
- package/docs/agents.md +26 -0
- package/docs/ai-workflow.md +1 -1
- package/docs/target-projects.md +2 -2
- package/governance/rules/claude/560-diagrams.md +10 -2
- package/governance/rules/claude/570-skill.md +1 -1
- package/package.json +1 -1
- package/scripts/core/install-check.sh +1 -1
- package/src/claude/seeds.ts +7 -1
- package/src/cli.ts +4 -0
- package/src/commands/comments.ts +234 -0
- package/src/comments/scan.ts +338 -0
- package/src/comments/trend.ts +207 -0
- package/src/comments/vocabulary.ts +85 -0
- package/src/git-env.ts +36 -0
- package/src/git-ignore.ts +46 -0
- package/src/indexes/walk.ts +1 -29
- package/standards/diagrams.md +65 -15
- package/standards/index.md +2 -2
- package/standards/prose.md +14 -1
- package/standards/readme.md +15 -1
- package/standards/skill.md +14 -0
- package/tooling/claude/reference.md +5 -0
- 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
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
34
|
-
- One source, many consumers: this repo is the authoritative copy.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
|
@@ -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,
|
|
77
|
-
|
|
78
|
-
|
|
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
|
-
-
|
|
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:
|
|
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
|
|
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
|
-
|
|
25
|
+
Do not recurse speculatively.
|
|
23
26
|
|
|
24
|
-
|
|
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
|
-
|
|
29
|
+
### Migrating a pre-split flat file
|
|
27
30
|
|
|
28
|
-
|
|
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
|
-
|
|
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
|
-
|
|
35
|
+
## Step 2: pick which entries this pass writes
|
|
36
36
|
|
|
37
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
44
|
-
|
|
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
|
-
|
|
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
|
-
|
|
60
|
+
# <Same as title>
|
|
49
61
|
|
|
50
|
-
<one-line
|
|
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
|
-
|
|
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
|
|
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
|
-
|
|
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:
|
|
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
|
|
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/<
|
|
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
|
|
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
|
|
118
|
+
## Step 6: read the renders back
|
|
95
119
|
|
|
96
|
-
Read each PNG and judge the picture against what the
|
|
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
|
|
122
|
+
Fix the source and re-render. Stop after two correction passes on an entry.
|
|
99
123
|
|
|
100
|
-
When a defect survives,
|
|
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
|
|
126
|
+
## Step 7: chat output
|
|
103
127
|
|
|
104
128
|
```plaintext
|
|
105
|
-
📝 Wrote .claude/
|
|
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
|
|
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/
|
|
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
|
|
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>`
|
|
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
|
|
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,
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|