@erclx/aitk 3.25.2 → 3.26.1
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/claude/.claude-plugin/plugin.json +1 -1
- package/governance/rules/claude/510-context.md +0 -1
- package/governance/rules/claude/520-wireframes.md +0 -8
- package/governance/rules/claude/530-requirements.md +0 -8
- package/governance/rules/claude/540-architecture.md +0 -10
- package/governance/rules/claude/550-design.md +0 -8
- package/governance/rules/claude/555-tasks.md +0 -8
- package/governance/rules/claude/556-groundwork.md +0 -9
- package/governance/rules/claude/557-intake.md +0 -9
- package/governance/rules/claude/559-memory.md +0 -9
- package/governance/rules/claude/560-diagrams.md +0 -1
- package/governance/rules/claude/561-teach.md +1 -9
- package/governance/rules/claude/562-session.md +0 -4
- package/governance/rules/claude/570-skill.md +2 -3
- package/governance/rules/claude/580-readme.md +0 -8
- package/governance/rules/claude/590-rule-authoring.md +0 -13
- package/governance/rules/claude/591-standard-authoring.md +0 -8
- package/governance/rules/core/045-memory.md +2 -2
- package/governance/rules/lang/120-bash.md +3 -2
- package/package.json +1 -1
- package/standards/markdown.md +1 -1
- package/standards/teach.md +1 -1
- package/tooling/claude/seeds/CLAUDE.md +1 -0
|
@@ -10,7 +10,6 @@ paths:
|
|
|
10
10
|
|
|
11
11
|
- Before non-trivial work in a domain, read its `.claude/context/<domain>.md` entry. Use `.claude/context/index.md` to find it.
|
|
12
12
|
- Leave the entry conforming when work in its domain changes what it describes.
|
|
13
|
-
- Rewrite the decision a change supersedes rather than appending a second one narrating the transition.
|
|
14
13
|
|
|
15
14
|
## Narration pronouns
|
|
16
15
|
|
|
@@ -6,14 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Wireframe standards
|
|
8
8
|
|
|
9
|
-
## Layout and intent
|
|
10
|
-
|
|
11
|
-
- Draw each surface as an ASCII block inside a `plaintext` fence, one fence per distinct layout.
|
|
12
|
-
- Label a region with its role. Never label one with a class name, a token name, or a computed value.
|
|
13
|
-
- Carry on-screen copy verbatim, and mark copy the surface templates.
|
|
14
|
-
- State interaction intent, never the mechanism behind it. Send algorithms, handlers, and thresholds to a `.claude/context/` entry.
|
|
15
|
-
- Update a surface's wireframe in the same pull request that changes its layout or its interaction.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the wireframes standard for layout and interaction intent: ASCII layout, region labels, variants, copy, and what moves to `.claude/context/`. It is the single source. Read it with `aitk standards wireframes`.
|
|
@@ -6,14 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Requirements standards
|
|
8
8
|
|
|
9
|
-
## Scope and non-goals
|
|
10
|
-
|
|
11
|
-
- State a goal as a user-facing outcome, never as the implementation delivering it.
|
|
12
|
-
- Record explicit non-goals. Mark a deferred item `(deferred)`.
|
|
13
|
-
- Leave the MVP list as written once its features ship. Do not renumber it, extend it, or annotate an entry with status.
|
|
14
|
-
- Add later scope as a new section rather than as an extension of the MVP list.
|
|
15
|
-
- Drop a section rather than pad it. Include `## Distribution` only when the project ships outside its own repository.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the requirements standard for what belongs in the problem, goals, non-goals, MVP features, tech stack, and constraints. It is the single source. Read it with `aitk standards requirements`.
|
|
@@ -6,16 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Architecture standards
|
|
8
8
|
|
|
9
|
-
## Decisions
|
|
10
|
-
|
|
11
|
-
- Give each decision its own H3 under `## Key technical decisions`, naming what it chose and the alternative it passed over.
|
|
12
|
-
- Keep line-by-line function behavior and full type definitions out.
|
|
13
|
-
|
|
14
|
-
## Verification anchors
|
|
15
|
-
|
|
16
|
-
- Close a decision citing a measured number with `Measured at <short-sha> on <YYYY-MM-DD>.` Leave a decision citing none unanchored.
|
|
17
|
-
- Refresh that anchor whenever the number is re-read, whether or not it moved.
|
|
18
|
-
|
|
19
9
|
## Authority
|
|
20
10
|
|
|
21
11
|
- Follow the architecture standard for the overview, named decision entries, and risks. It is the single source. Read it with `aitk standards architecture`.
|
|
@@ -6,14 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Design standards
|
|
8
8
|
|
|
9
|
-
## Tokens
|
|
10
|
-
|
|
11
|
-
- Describe a token as intent rather than as a computed value.
|
|
12
|
-
- Keep CSS classes, component filenames, and prop names out.
|
|
13
|
-
- Carry a token system as a table, one row per token, and a component rule as a short bullet.
|
|
14
|
-
- Keep the token table headers verbatim.
|
|
15
|
-
- Record a non-obvious omission, such as no motion or no custom icons.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the design standard for visual intent, the token tables, and the render contract. It is the single source. Read it with `aitk standards design`.
|
|
@@ -6,14 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Tasks standards
|
|
8
8
|
|
|
9
|
-
## What a task carries
|
|
10
|
-
|
|
11
|
-
- Name where the task came from, through a `Plan:`, `Groundwork:`, `Intake:`, or `Issue:` line under the title.
|
|
12
|
-
- Size the outcomes so one pull request closes all of them. Split the task before handing it off.
|
|
13
|
-
- Use `## Outcomes` and `## Findings` and add no third heading. Note status inline on an outcome.
|
|
14
|
-
- Keep class names, file paths, function names, and prop names out of every entry and title.
|
|
15
|
-
- Never delete a task file. A shipped task moves to the archive under its own name.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the tasks standard for filenames, frontmatter, what belongs, and the task file format. It is the single source. Read it with `aitk standards tasks`.
|
|
@@ -6,15 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Groundwork standards
|
|
8
8
|
|
|
9
|
-
## Folder name
|
|
10
|
-
|
|
11
|
-
- Name a new track `.claude/groundwork/<nn>-<slug>/`, a two-digit zero-padded ordinal followed by a kebab-case slug. Take the ordinal from the highest one already present across both `.claude/groundwork/` and `.claude/intake/`, incremented, or `01` when neither folder holds an entry. Never renumber an existing folder.
|
|
12
|
-
|
|
13
|
-
## Measuring and closing
|
|
14
|
-
|
|
15
|
-
- Never carry a figure from an earlier session without re-measuring it. Mark an inference as an inference.
|
|
16
|
-
- Never close a track while an open question quietly fails an outcome. Resolve it, or record it as knowingly accepted.
|
|
17
|
-
|
|
18
9
|
## Authority
|
|
19
10
|
|
|
20
11
|
- Follow the groundwork standard for reserved numbering, frontmatter and dating, what each required file holds, and the conventions a track keeps. It is the single source. Read it with `aitk standards groundwork`.
|
|
@@ -6,15 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Intake standards
|
|
8
8
|
|
|
9
|
-
## Folder name
|
|
10
|
-
|
|
11
|
-
- Name a new dump `.claude/intake/<nn>-<slug>/`, a two-digit zero-padded ordinal followed by a kebab-case slug. Take the ordinal from the highest one already present across both `.claude/intake/` and `.claude/groundwork/`, incremented, or `01` when neither folder holds an entry. Never renumber an existing folder.
|
|
12
|
-
|
|
13
|
-
## The answer contract
|
|
14
|
-
|
|
15
|
-
- Never fill a `You:` slot and never infer a disposition from an empty one. Empty means unread, never agreement.
|
|
16
|
-
- Report unread items by count on a resume pass. Do not decide one.
|
|
17
|
-
|
|
18
9
|
## Authority
|
|
19
10
|
|
|
20
11
|
- Follow the intake standard for the folder layout, frontmatter and dating, the item format, and retrieval. It is the single source. Read it with `aitk standards intake`.
|
|
@@ -6,15 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Memory standards
|
|
8
8
|
|
|
9
|
-
## Routing
|
|
10
|
-
|
|
11
|
-
- Write no memory entry for a fact a per-domain context entry already owns.
|
|
12
|
-
|
|
13
|
-
## The pen
|
|
14
|
-
|
|
15
|
-
- Never delete a memory entry. Retire one by moving it to an archive under its own name, since the folder is gitignored and a wrong call has no undo.
|
|
16
|
-
- Never hand-edit `.claude/memory/index.md`. A hook regenerates it from sibling frontmatter.
|
|
17
|
-
|
|
18
9
|
## Authority
|
|
19
10
|
|
|
20
11
|
- Follow the memory standard for the filename and type prefix, the frontmatter, the body shape per type, links between entries, and the lifecycle. It is the single source. Read it with `aitk standards memory`.
|
|
@@ -16,4 +16,3 @@ paths:
|
|
|
16
16
|
|
|
17
17
|
- Write a new diagram to `.claude/diagrams/<kind>.md`, never to `.claude/DIAGRAMS.md`
|
|
18
18
|
- Convert a `.claude/DIAGRAMS.md` left by an older install into per-kind entries before editing it
|
|
19
|
-
- Refresh only the entries whose source signal moved. Do not rewrite the folder wholesale.
|
|
@@ -6,16 +6,8 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Teach standards
|
|
8
8
|
|
|
9
|
-
## What a workspace keeps
|
|
10
|
-
|
|
11
|
-
- Never renumber an existing folder, lesson, or record. A later reader cites it by the name it opened under.
|
|
12
|
-
- Write every success line as a task the learner can be asked to perform, never as something they will understand.
|
|
13
|
-
- Keep a reference page free of the learner. A page carrying second person or a quiz belongs under `lessons/`.
|
|
14
|
-
- Record the wrong answer a learner gave, never a count of what they missed.
|
|
15
|
-
- Date the workspace once, in the `MISSION.md` frontmatter. Never repeat the date in the body of any file.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the teach standard for the folder layout, ordinal naming, frontmatter, and the mission and learning-record formats. It is the single source. Read it with `aitk standards teach`.
|
|
20
|
-
- Read `references/glossary.md` inside the `claude-teach` skill for the glossary every workspace carries at its root. It is the single source for the entry shape, the ordering, and which terms the file carries. Read it rather than invoking the skill, which resumes a workspace and runs lessons.
|
|
12
|
+
- Read `references/glossary.md` inside the `aitk:claude-teach` skill for the glossary every workspace carries at its root. It is the single source for the entry shape, the ordering, and which terms the file carries. Read it rather than invoking the skill, which resumes a workspace and runs lessons.
|
|
21
13
|
- Report it rather than proceeding silently when that file does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.
|
|
@@ -9,10 +9,6 @@ paths:
|
|
|
9
9
|
## What a handoff carries
|
|
10
10
|
|
|
11
11
|
- Follow this rule rather than `555-tasks.md` for a `session-` file. A handoff is not a task and carries neither `## Outcomes` nor `## Findings`.
|
|
12
|
-
- Never write into a file another session owns. Overwrite only the file the writing session already wrote.
|
|
13
|
-
- Resolve the containing folder at the main worktree root, never inside a linked worktree.
|
|
14
|
-
- Write only what a compaction destroys. Do not restate the board and do not summarize what shipped.
|
|
15
|
-
- Cite a commit, a task, or a file and line for every claim, so a reader can tell a read from a recall.
|
|
16
12
|
|
|
17
13
|
## Authority
|
|
18
14
|
|
|
@@ -11,9 +11,8 @@ paths:
|
|
|
11
11
|
|
|
12
12
|
## Before editing
|
|
13
13
|
|
|
14
|
-
-
|
|
15
|
-
-
|
|
16
|
-
- Report it rather than proceeding silently when `create-skill` does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.
|
|
14
|
+
- Confirm `aitk:create-skill`'s two creation-time questions are answered before a new `SKILL.md` lands, whether drafted by hand, by another skill, or by `aitk:create-skill` itself. Carry the third question into the sibling `REQUIREMENT.md`'s `Must not` section as a review criterion rather than a gate.
|
|
15
|
+
- Report it rather than proceeding silently when `aitk:create-skill` does not resolve. It ships with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have it.
|
|
17
16
|
|
|
18
17
|
## After editing
|
|
19
18
|
|
|
@@ -6,14 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# README standards
|
|
8
8
|
|
|
9
|
-
## Audience and voice
|
|
10
|
-
|
|
11
|
-
- Write a repository-root README for someone deciding whether to commit to the project. A nested README keeps the reference voice.
|
|
12
|
-
- Address the reader in second person.
|
|
13
|
-
- Ground a claim in a command, a number, or a named constraint rather than an adjective.
|
|
14
|
-
- Name what the project does not do.
|
|
15
|
-
- Link out to full API documentation, license text, contribution guidelines, and troubleshooting rather than carrying them.
|
|
16
|
-
|
|
17
9
|
## Authority
|
|
18
10
|
|
|
19
11
|
- Follow the readme standard for voice, structure, required and optional sections, heading hierarchy, badge classes, per-project-type content, and what to link out rather than inline. It is the single source. Read it with `aitk standards readme`.
|
|
@@ -6,19 +6,6 @@ paths:
|
|
|
6
6
|
|
|
7
7
|
# Rule authoring standards
|
|
8
8
|
|
|
9
|
-
## Numbering
|
|
10
|
-
|
|
11
|
-
- Name a rule `.claude/rules/<subdirectory>/<n>-<slug>.md`. Give every rule a numeric prefix and keep the slug to one to three kebab words.
|
|
12
|
-
- Treat `000-899` as reserved for a rule set that ships to targets, `000-599` across the shared subdirectories and `600-899` held for ones it has not added.
|
|
13
|
-
- Number a rule the project authored itself in `900-999` and write it at `.claude/rules/project/<subdirectory>/<n>-<slug>.md`.
|
|
14
|
-
- Do not take a reserved number for a project-authored rule because nothing installed holds it today. A later release can ship into it.
|
|
15
|
-
|
|
16
|
-
## Body
|
|
17
|
-
|
|
18
|
-
- State one directive per bullet in imperative voice. Do not explain the reasoning behind a rule.
|
|
19
|
-
- Cut a rule that resists crisp one-line phrasing.
|
|
20
|
-
- Do not restate a rule a sibling rule or `CLAUDE.md` already owns. Point once.
|
|
21
|
-
|
|
22
9
|
## Authority
|
|
23
10
|
|
|
24
11
|
- Follow the rule-authoring standard for rule frontmatter, body shape, and voice. It is the single source. Read it with `aitk standards rule`.
|
|
@@ -7,14 +7,6 @@ paths:
|
|
|
7
7
|
|
|
8
8
|
# Standard authoring standards
|
|
9
9
|
|
|
10
|
-
## The scope statement
|
|
11
|
-
|
|
12
|
-
- Govern one document type per standard, or one attribute across every document.
|
|
13
|
-
- Open with a `## Scope` section naming what the standard governs and a `Does not govern:` list, placed above the shape rules.
|
|
14
|
-
- Put the governed path in backticks in the first sentence, anchored deep enough to resolve from a project root. Keep an attribute standard's first sentence free of backticks and say in it that it governs an attribute.
|
|
15
|
-
- Give each `Does not govern:` entry an excluded concern and the owner it goes to. Cut an entry naming no owner.
|
|
16
|
-
- Declare a yield, an exemption, or a handoff from both sides of the boundary.
|
|
17
|
-
|
|
18
10
|
## Authority
|
|
19
11
|
|
|
20
12
|
- Follow the standard-authoring standard for a standard's frontmatter, shape, scope, and success criterion. It is the single source. Read it with `aitk standards standard`.
|
|
@@ -7,6 +7,6 @@ description: Keep memory writes scoped to .claude/memory/ and out of context-own
|
|
|
7
7
|
## Writing memory
|
|
8
8
|
|
|
9
9
|
- Write all memory files to `.claude/memory/`, not `~/.claude/projects/`
|
|
10
|
-
- A fact about a domain goes to that domain's `.claude/context/` entry, not to memory. `claude-memory-capture` routes it there and `claude-docs` folds it in. Memory keeps only what no context entry owns.
|
|
10
|
+
- A fact about a domain goes to that domain's `.claude/context/` entry, not to memory. `aitk:claude-memory-capture` routes it there and `aitk:claude-docs` folds it in. Memory keeps only what no context entry owns. Report it rather than proceeding silently when either skill does not resolve. Both ship with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have them.
|
|
11
11
|
- Never delete a memory entry. Retire one by moving it to `.claude/.tmp/memory-archive/`. A bulk retire runs through the shell, where no file edit fires a path-scoped rule, and the folder is gitignored with nothing to recover from.
|
|
12
|
-
- Follow the memory standard
|
|
12
|
+
- Follow the memory standard for the filename and type prefix, the frontmatter, the body shape each type carries, and the lifecycle. Read it with `aitk standards memory`. Check every entry in the pen against that standard and fix what breaks it, since nothing keeps the folder conforming on its own.
|
|
@@ -8,9 +8,10 @@ paths:
|
|
|
8
8
|
|
|
9
9
|
## Skill routing
|
|
10
10
|
|
|
11
|
-
- Use `bash-script` for an interactive or human-facing script: prompts, a visual timeline UI, framed terminal output.
|
|
12
|
-
- Use `cli-script` for a non-interactive script: automation, CI, cron, a pipeline helper, or anything run by an agent rather than watched by a person.
|
|
11
|
+
- Use `aitk:bash-script` for an interactive or human-facing script: prompts, a visual timeline UI, framed terminal output.
|
|
12
|
+
- Use `aitk:cli-script` for a non-interactive script: automation, CI, cron, a pipeline helper, or anything run by an agent rather than watched by a person.
|
|
13
13
|
- Load the matched skill's own reference templates rather than hand-rolling interactivity or logging patterns outside them.
|
|
14
|
+
- Report it rather than proceeding silently when the matched skill does not resolve. Both ship with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have them.
|
|
14
15
|
|
|
15
16
|
## Lint gate
|
|
16
17
|
|
package/package.json
CHANGED
package/standards/markdown.md
CHANGED
|
@@ -13,7 +13,7 @@ Governs what a check can decide about a markdown file: headings, paragraph and l
|
|
|
13
13
|
|
|
14
14
|
The two frontmatter fields it reaches are `title` and `description`. They are named here rather than in the statement above, since a backticked token in a scope statement's first sentence is published as the standard's jurisdiction.
|
|
15
15
|
|
|
16
|
-
The split with the voice guidance is what reads the rule rather than what the rule covers. Every ban below ships as data `aitk markdown audit` and the installed audit hook both read, so a violation is measured on every run. Cadence, rhythm, and information density are judgments a reader settles, and those travel in the `write-human` skill, which a markdown edit routes to.
|
|
16
|
+
The split with the voice guidance is what reads the rule rather than what the rule covers. Every ban below ships as data `aitk markdown audit` and the installed audit hook both read, so a violation is measured on every run. Cadence, rhythm, and information density are judgments a reader settles, and those travel in the `aitk:write-human` skill, which a markdown edit routes to.
|
|
17
17
|
|
|
18
18
|
Does not govern:
|
|
19
19
|
|
package/standards/teach.md
CHANGED
|
@@ -97,7 +97,7 @@ Record the wrong answer rather than the fact of an error. A wrong answer names t
|
|
|
97
97
|
|
|
98
98
|
## GLOSSARY.md
|
|
99
99
|
|
|
100
|
-
Required in every workspace, holding one entry per term the subject defines. The glossary reference the `claude-teach` skill carries fixes what an entry looks like, how the file orders and groups them, and which terms it carries, so this standard states only that the file exists and sits at the workspace root. That reference ships with the plugin rather than installing here, because a promoted glossary keeps its shape wherever it lands and no project folder covers every destination. Say so and stop rather than working the shape from memory when the project has no plugin to read it from.
|
|
100
|
+
Required in every workspace, holding one entry per term the subject defines. The glossary reference the `aitk:claude-teach` skill carries fixes what an entry looks like, how the file orders and groups them, and which terms it carries, so this standard states only that the file exists and sits at the workspace root. That reference ships with the plugin rather than installing here, because a promoted glossary keeps its shape wherever it lands and no project folder covers every destination. Say so and stop rather than working the shape from memory when the project has no plugin to read it from.
|
|
101
101
|
|
|
102
102
|
Name the lesson or reference page a term first appears in as that reference requires. A workspace is the case it was written for, so a glossary here has a first appearance to name.
|
|
103
103
|
|
|
@@ -15,6 +15,7 @@
|
|
|
15
15
|
|
|
16
16
|
## Commands
|
|
17
17
|
|
|
18
|
+
- These conventions came from a toolkit with its own CLI. A rule or standard naming a command is naming that CLI, present only where this project installed it.
|
|
18
19
|
- Run `bun run check` before committing. Full script reference in the development entry under `.claude/context/`.
|
|
19
20
|
|
|
20
21
|
## Key paths
|