feat(agents-canon): AGENTS.md canon everywhere — bootstrap v2.0.0 writes AGENTS.md + CLAUDE.md pointer; 15 skills retarget triggers/rule refs from CLAUDE.md to AGENTS.md (semver bumps); dist rebuilt

skills/project-discipline/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: project-discipline
 author: ours
-version: 0.2.1
+version: 0.2.2
 description: >
-  Codifies five cross-project discipline rules: (1) project CLAUDE.md /
+  Codifies five cross-project discipline rules: (1) project AGENTS.md /
   .wiki/CLAUDE.md / .tasks/ override defaults from other skills (specs →
   .wiki/concepts/, tasks → .tasks/); (2) master-only, no feature branches
   without approval; (3) semver bump on every edit of versioned artifacts
@@ -13,7 +13,7 @@ description: >
   overrides per project; force/delete/non-ff always ask;
   (5) transit/brainstorm workspaces — artifacts to .brainstorm/ or global wiki
   only via explicit user direction. Activated by "follow project discipline"
-  trigger in CLAUDE.md (added by project-bootstrap v1.5.0+).
+  trigger in AGENTS.md (added by project-bootstrap v2.0.0+).
 ---
 
 # project-discipline
@@ -22,7 +22,7 @@ description: >
 
 ## When this runs
 
-**At session start** — when `CLAUDE.md` contains the line `follow project discipline`. The skill is a policy document; the agent reads it and applies the four rules to all subsequent work in the session.
+**At session start** — when `AGENTS.md` contains the line `follow project discipline`. The skill is a policy document; the agent reads it and applies the four rules to all subsequent work in the session.
 
 **On explicit reference** — when the user says "use project discipline", "соблюди дисциплину", "проектные правила", "что у меня по правилам?", or close variants asking about/applying the rules.
 
@@ -32,11 +32,11 @@ The skill itself takes no actions and has no external side-effects. It instructs
 
 Before applying defaults from any other skill (frontend-design, mcp-builder, etc.), read in this order:
 
-1. `CLAUDE.md` in the project root.
+1. `AGENTS.md` in the project root.
 2. `.wiki/CLAUDE.md` (if it exists).
 3. `.tasks/STATUS.md` (if it exists).
 
-Any path, format, or workflow explicitly stated in those files **overrides the skill default**.
+Any path, format, or workflow explicitly stated in those files **overrides the skill default**. (CLAUDE.md, where present, is a legacy pointer — read it, then follow the canon in AGENTS.md.)
 
 Concrete consequences:
 
@@ -102,12 +102,12 @@ Anything else is an ordinary fast-forward push and proceeds without a gate.
 Some workspaces are **transit zones** — discussion areas with no `.tasks/`, where brainstorm artifacts are explicitly NOT auto-promoted to project wikis.
 
 **Default destination for brainstorm artifacts:**
-- **In-progress brainstorm outputs** → `.brainstorm/<topic>.md` (or whatever the workspace's README/CLAUDE.md declares)
+- **In-progress brainstorm outputs** → `.brainstorm/<topic>.md` (or whatever the workspace's README/AGENTS.md declares)
 - **Mature, cross-cutting outputs** → `~/projects/.wiki/concepts/<topic>-design.md` via `mcp__projects-meta__knowledge_ingest` — **only** when user explicitly directs this
 
 **Agent must NOT auto-promote** brainstorm artifacts to global wikis by analogy with Rule 1. Convergence-moment (move from workspace to permanent wiki) is a user decision, not an automatic action.
 
-**Example:** `~/projects/.meeting-room/` is a transit zone. Its CLAUDE.md explicitly states "no `.tasks/`, transit zone, artifacts go to `.brainstorm/` or global wiki via user command." Rule 1's "project conventions override" applies, but the override is explicit in the workspace contract — auto-promotion by analogy would violate that contract.
+**Example:** `~/projects/.meeting-room/` is a transit zone. Its AGENTS.md explicitly states "no `.tasks/`, transit zone, artifacts go to `.brainstorm/` or global wiki via user command." Rule 1's "project conventions override" applies, but the override is explicit in the workspace contract — auto-promotion by analogy would violate that contract.
 
 **When in doubt:** ask the user "this goes to `.brainstorm/`, or should I promote to shared wiki?" rather than assuming.
 
@@ -115,7 +115,7 @@ Some workspaces are **transit zones** — discussion areas with no `.tasks/`, wh
 
 The skill **does not**:
 
-- modify `CLAUDE.md` (that's `project-bootstrap`'s job);
+- modify `AGENTS.md` (that's `project-bootstrap`'s job);
 - enforce rules via git hooks / pre-commit / CI (this is agent discipline, not tooling);
 - manage `settings.json` permissions (that's `update-config`);
 - check the existence of `.wiki/` / `.tasks/` (that's `setup-wiki` / `setup-tasks` / `project-bootstrap`); if a project doesn't have them, Rule 1 simply finds no overrides and falls back to skill defaults.
@@ -124,4 +124,4 @@ The skill **does not**:
 
 In a tightly-disciplined repo (`skills`) the four rules already hold by accident — the agent reads `.wiki/CLAUDE.md`, knows specs go to `.wiki/concepts/`, knows to bump `version:`, knows not to push without confirmation. In **other** projects of the same user, that discipline does not transfer: the agent falls back to vendor-default paths (`docs/specs/`, `docs/plans/`), branches on a whim, forgets `version:` bumps, and pushes without asking. This skill makes the discipline explicit and portable.
 
-Full design rationale (why one skill instead of four, why a skill instead of inline `CLAUDE.md` lines, scope of each rule, push-permission mechanism choice) lives in `.wiki/concepts/project-discipline-design.md` (in this repo; in other projects bootstrapped from this repo, the design lives in `skills`).
+Full design rationale (why one skill instead of four, why a skill instead of inline `AGENTS.md` lines, scope of each rule, push-permission mechanism choice) lives in `.wiki/concepts/project-discipline-design.md` (in this repo; in other projects bootstrapped from this repo, the design lives in `skills`).