@mrciphersmith/keryx 0.2.97 → 0.2.98

package/dist/core.js

@@ -23978,7 +23978,7 @@ ${filesToRead}
 
 ## Verification
 
-- Current state: not verified.
+- Verification status: see \`verification.md\` (written by \`keryx skills verify\`).
 - Run: \`keryx skills verify ${moduleName}/${skillName}\`
 `;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrciphersmith/keryx",
-  "version": "0.2.97",
+  "version": "0.2.98",
   "description": "Version-controlled project context for AI coding agents: code graph, architecture wiki, project memory, relevant tests, quality signals, and task flows.",
   "private": false,
   "publishConfig": {

package/src/gdskills/bundled/rules/core/api-contracts.mdc

@@ -1,6 +1,7 @@
 ---
 description: "API contract rules: OpenAPI-first design, semantic versioning, no breaking changes without major version bump, contract testing. Use when designing, modifying, or consuming HTTP APIs."
 alwaysApply: false
+stack_requires: "http-server"
 ---
 
 # API Contracts

package/src/gdskills/bundled/rules/core/code-style-patterns.mdc

@@ -1,6 +1,7 @@
 ---
 description: "Code style and architecture patterns for TypeScript, React, and MobX."
 alwaysApply: false
+stack_requires: "react,mobx"
 ---
 
 # Code Style and Architecture Patterns

package/src/gdskills/bundled/rules/core/database-patterns.mdc

@@ -1,6 +1,7 @@
 ---
 description: "Database access patterns: no N+1 queries, indexes before deploy, backward-compatible migrations, transaction discipline. Use when writing queries, migrations, or ORM models."
 alwaysApply: false
+stack_requires: "sql"
 ---
 
 # Database Patterns

package/src/gdskills/bundled/rules/core/documentation-management.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Manage project documentation in <PROJECT_DIR>/docs (default) or $GDMETAPRO_DOCS_ROOT with synchronized multilingual outputs."
+description: "Manage project documentation in <PROJECT_DIR>/docs (default) or $GDMETAPRO_DOCS_ROOT. Language variants are opt-in, not mandatory."
 alwaysApply: false
 ---
 
@@ -11,16 +11,28 @@ Define how the agent creates and updates documentation under `<DOCS_ROOT>` (`<PR
 ## When To Apply
 Apply when the user asks to create or update documentation, plans, requirements, communication notes, reports, or review artifacts.
 
+## Requirements Packages
+Anything under `docs/requirements/<name>/` (README, PRD, specification, and
+their optional companions, including `implementation-plan.md`) follows
+`requirements-package-standard.mdc`. Do not restate or diverge from that
+layout here: no date-stamped subfolders, no mandatory `ru`/`en`/`ai` variants —
+the `Version: x.y.z` field on each document is the versioning mechanism.
+
 ## Mandatory Behavior
 1. Ask for target location and folder name before writing any doc.
-2. Use date-stamped folders; never overwrite previous doc sets.
-3. Keep language variants synchronized.
+2. Do not date-stamp folders. Write into `<category>/<name>/` and update
+   documents in place, bumping their `Version` field where the category's
+   standard defines one (requirements packages always do).
+3. Default to `en` output. Add other language variants only when the user
+   explicitly asks for them, and keep any variants you do create synchronized.
 4. Update `<DOCS_ROOT>/README.md` after doc changes.
 5. Ask whether to apply changes (branch/commit/PR) after edits.
 
 ## Required Locations
 - Root: `<DOCS_ROOT>` (default: `<PROJECT_DIR>/docs`)
-- Standard pattern: `<DOCS_ROOT>/<category>/<name>-<YYYY-MM-DD>/`
+- Standard pattern: `<DOCS_ROOT>/<category>/<name>/`
+- Requirements packages: `<DOCS_ROOT>/requirements/<name>/` per
+  `requirements-package-standard.mdc` (no date folder).
 
 ## DOCS_ROOT Resolution
 
@@ -40,45 +52,27 @@ DOCS_ROOT="${GDMETAPRO_DOCS_ROOT:-$PROJECT_DIR/docs}"
 
 | Category | Path pattern | Description |
 |----------|-------------|-------------|
-| `requirements` | `docs/requirements/<name>/<YYYY-MM-DD>/` | Feature requirements (iterations grouped by name) |
-| `plans` | `docs/plans/<name>/<YYYY-MM-DD>/` | Standalone implementation plans |
-| `report` | `docs/report/<name>/<YYYY-MM-DD>/` | Standalone review/audit reports |
-| `review-testing` | `docs/review-testing/<name>/<YYYY-MM-DD>/` | QA and testing artifacts |
-| `communication` | `docs/communication/<name>/<YYYY-MM-DD>/` | Communication and context docs |
-| `analysis` | `docs/analysis/<name>/<YYYY-MM-DD>/` | Feature/branch analysis (see below) |
+| `requirements` | `docs/requirements/<name>/` | See `requirements-package-standard.mdc`. |
+| `plans` | `docs/plans/<name>/` | Standalone implementation plans not tied to a requirements package. A plan that belongs to one lives inside that package as `implementation-plan.md` instead — see `requirements-package-standard.mdc` and `implementation-plans.mdc`. |
+| `report` | `docs/report/<name>/` | Standalone review/audit reports |
+| `review-testing` | `docs/review-testing/<name>/` | QA and testing artifacts |
+| `communication` | `docs/communication/<name>/` | Communication and context docs |
+| `analysis` | `docs/analysis/<name>/` | Feature/branch analysis (see below) |
 
 ## Analysis Category Structure
 
 The `analysis` category is used by the `feature-analyzer` skill and any branch/feature analysis tasks.
 
 ```
-docs/analysis/<feature-name>/<YYYY-MM-DD>/
-  report/
-    ru/
-      report.md
-    en/
-      report.md
-    ai/
-      report.md
-  plans/
-    ru/
-      implementation-plan.md
-    en/
-      implementation-plan.md
-    ai/
-      implementation-plan.md
+docs/analysis/<feature-name>/
+  report.md
+  implementation-plan.md
 ```
 
-- `report/` — detailed analysis of changes, ticket, cross-repo findings
-- `plans/` — actionable implementation plan derived from the analysis
-- Each subfolder contains `ru/`, `en/`, `ai/` language variants (all three are mandatory)
-
-## Language Matrix
-- Requirements: `ru`, `en`, `ai`
-- Implementation plans: `ru`, `en`, `ai`
-- Communication docs: `ru`, `en`, `ai`
-- Analysis (`report/` + `plans/`): `ru`, `en`, `ai` (mandatory)
-- Other categories: follow explicit user request; default to at least `en`.
+- `report.md` — detailed analysis of changes, ticket, cross-repo findings
+- `implementation-plan.md` — actionable implementation plan derived from the analysis
+- Add `ru`/`en`/`ai` variants only if the user explicitly asks for them; the
+  default is the single `en` files shown above.
 
 ## Naming Rules
 - Ask user for `<name>` first.
@@ -100,7 +94,8 @@ Standalone skill invocations continue to use `docs/analysis/`. Only orchestrator
 See `core/jobs-documentation.mdc` for the `jobs/` system.
 
 ## Prohibited
-- Single-language output when the category requires `ru+en+ai`.
-- Partial language updates.
+- Date-stamped folders anywhere under `<DOCS_ROOT>`.
+- Language variants the user did not ask for.
+- Partial updates to language variants that do exist.
 - Writing docs outside the requested category path without confirmation.
-- Mixing `report/` and `plans/` content in the same file.
+- Mixing `report`/`implementation-plan` content in the same file.

package/src/gdskills/bundled/rules/core/error-handling.mdc

@@ -98,17 +98,7 @@ try {
 ```
 
 ### Rule 4: No Unhandled Promise Rejections
-Every `async` call chain must end with error handling. `Promise.all` rejections must be caught. Fire-and-forget patterns must use `.catch(logger.error)`.
-
-```typescript
-// BAD
-Promise.all([fetchA(), fetchB()]); // unhandled rejection if either fails
-
-// GOOD
-const results = await Promise.allSettled([fetchA(), fetchB()]);
-const failures = results.filter(r => r.status === 'rejected');
-if (failures.length > 0) { /* handle */ }
-```
+See `async-patterns.mdc` Rule 4 ("No Unhandled Promise Rejections") for the full rule, examples, and rationale — it belongs there because it is fundamentally about promise/async control flow, not error typing.
 
 ### Rule 5: Propagate, Don't Wrap Blindly
 When catching and re-throwing, preserve the original error as `cause`:

package/src/gdskills/bundled/rules/core/execution-metrics.md

@@ -38,8 +38,7 @@ gdwiki enrichment, or anything that writes files) MUST also save the report:
 - Otherwise → `.metaproject/data/<primary-module>/metrics/run-<ISO-timestamp>.md`
 
 Create the directory. Use a filesystem-safe timestamp (colons → `-`). Print the
-saved path under the table. This lets the post-commit hook and future runs find
-past reports.
+saved path under the table. This lets future runs find past reports.
 
 ## Honesty rules (do not fabricate)
 

package/src/gdskills/bundled/rules/core/frontend-assistant.mdc

@@ -4,6 +4,7 @@ alwaysApply: false
 globs:
   - "src/**/*.ts"
   - "src/**/*.tsx"
+stack_requires: "react,mobx"
 ---
 
 # Frontend Assistant Guidelines

package/src/gdskills/bundled/rules/core/git-concurrency.mdc

@@ -0,0 +1,101 @@
+---
+description: "Git concurrency rules: no git stash in a shared tree, explicit pathspecs instead of git add -A, git -C <absolute path> in worktrees, commit at task boundaries. Use when multiple agents or sessions share one checkout or work in parallel git worktrees."
+alwaysApply: false
+---
+
+# Git Concurrency
+
+## Purpose
+Prevent one agent's git operation from destroying or corrupting another agent's or session's in-flight work when multiple sessions or subagents share a checkout, a stash stack, or run in parallel git worktrees.
+
+## When To Apply
+Apply whenever more than one agent session or subagent may be active against the same repository — parallel `task-implementer` waves, concurrent flow workers, or any dispatch that runs inside a worktree cut for a specific task. Cited by `flow-orchestrator`, `job-orchestrator`, and `task-implementer`.
+
+---
+
+## Rules
+
+### 1. Never `git stash`, in any form, in a shared tree
+The stash stack is a single list shared by the main checkout and every worktree cut from it. A "scoped" `git stash push -- <file>` still resets that file to its last commit and pushes the diff onto the shared stack — another lane's `git stash pop` can then restore your entry over its own uncommitted work, or vice versa. This happened here: a worker's scoped `git stash push -- <file>` reset the file and briefly wiped another task's uncommitted work.
+
+BAD:
+```bash
+git stash push -- src/foo.ts   # resets the file now; the diff joins a stack every worktree can pop
+```
+
+GOOD — need a temporary revert to test a hypothesis:
+```bash
+# Make the change with the Edit tool; to undo it, edit it back the same way.
+# If you need to keep a copy while you experiment, copy the file out instead:
+cp src/foo.ts /path/to/scratch/foo.ts.bak
+```
+Never reach for `git stash` — scoped or not — to get there and back.
+
+### 2. Explicit pathspecs, never `git add -A` / `--all` / `.`
+An unscoped add stages every changed file in the tree, including another lane's in-flight edits, into a commit that has nothing to do with them. This happened here: `git add -A` staged another lane's in-flight files into an unrelated commit.
+
+BAD:
+```bash
+git add -A && git commit -m "..."
+```
+
+GOOD:
+```bash
+git add src/foo.ts src/foo.test.ts
+git commit -m "..."
+```
+
+### 3. `git -C <absolute-worktree-path>` for every git command in a worktree
+A bare `git` command runs against whatever the shell's cwd happens to be. Across a session's tool calls that cwd can silently persist from a previous command or reset out of the worktree — a bare `git restore` or `git add -A && git commit && git push` then hits the wrong tree. This happened here: it once pushed another session's work to `main`.
+
+BAD:
+```bash
+cd /path/to/worktree
+# ...several tool calls later, the cwd assumption has drifted...
+git commit -am "fix"
+```
+
+GOOD:
+```bash
+git -C /absolute/path/to/worktree status
+git -C /absolute/path/to/worktree add src/foo.ts
+git -C /absolute/path/to/worktree commit -m "fix(foo): ..."
+```
+
+### 4. Commit at every task boundary
+Uncommitted work handed between workers — "the next task can build on my uncommitted edit" — has been destroyed here by a concurrent checkout running in another lane. A task is not done until its diff is committed; leaving it uncommitted is leaving it deletable by someone else's git command.
+
+This holds whether or not the worker itself commits. When auto-commit is enabled, the worker commits its own diff before reporting. When it is disabled, the worker does not commit — but the task is still not done until the diff is committed, so it reports its exact changed-file list (see "Reporting Back" below) and the orchestrator stages and commits those paths at the task boundary. Either way, the task's diff is committed at the boundary by whoever owns commits — never left uncommitted for a later step to inherit.
+
+---
+
+## Pinning A Dispatch To Its Worktree
+
+Every dispatch into a multi-task or multi-agent run MUST pin the exact worktree before its first write:
+
+1. State the absolute worktree root in the dispatch prompt — never a relative path or "the current directory".
+2. The dispatched agent's first action is:
+   ```bash
+   cd <absolute-worktree-root> && pwd && git branch --show-current
+   ```
+   and confirms the printed path and branch match what the dispatch specified.
+3. Re-run that check immediately before the first write, not only at the start — a long-running dispatch can have its cwd reset by an unrelated tool call in between.
+4. Every git command after that uses `git -C <absolute-worktree-root>`, never a bare `git`.
+
+## Reporting Back
+
+A worker reports its **exact file list** — the paths it actually changed, nothing inferred — so "the orchestrator stages those paths only". An orchestrator that runs `git add -A` on the strength of a worker's prose summary has recreated Rule 2 at one level up; the reported file list is what makes an explicit-pathspec `git add` possible at the orchestrator level too.
+
+---
+
+## Red Flags — Stop and re-read this rule if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "It's a scoped stash, I'll pop it right away" | The stash stack is shared by every worktree; "right away" does not stop another lane's `pop` from landing between your push and your pop |
+| "`git add -A` is fine, I only touched my files" | `git add -A` stages whatever is dirty in the tree, not what you touched — another lane's dirty files get staged too, silently |
+| "cwd is still the worktree" | Confirm it, don't assume it — `pwd` costs nothing, and a wrong assumption here ships to the wrong branch |
+| "I'll commit everything at the end in one big commit" | Uncommitted work is exactly what a concurrent stash, add, or checkout destroys; commit at each boundary, not at the end |
+| "This repo isn't shared right now, so it's fine just this once" | The failure mode is a race: correct 99 times and destructive the 100th is still destructive, and nothing here can tell you which run you're on |
+
+**IRON LAW: NEVER `git stash` OR `git add -A`/`--all`/`.` IN A TREE ANOTHER SESSION MIGHT BE TOUCHING, AND NEVER RUN A GIT COMMAND WITHOUT PINNING IT TO AN ABSOLUTE WORKTREE PATH FIRST.**

package/src/gdskills/bundled/rules/core/implementation-plans.mdc

@@ -1,24 +1,34 @@
 ---
-description: "Rules for creating implementation plans in date-stamped requirement folders."
+description: "Rules for creating implementation plans as part of a requirements package. Layout follows requirements-package-standard.mdc."
 alwaysApply: false
 ---
 
 # Implementation Plans Rules
 
 ## Purpose
-Define structure and storage for implementation plans.
+Define structure and storage for an implementation plan that belongs to a
+requirements package.
 
 ## When To Apply
-Apply when creating or updating an implementation plan document.
+Apply when creating or updating an implementation plan document that lives
+inside a requirements package (`docs/requirements/<name>/`). Two other
+locations are outside this rule's scope and are governed by
+`documentation-management.mdc` instead:
+- A standalone plan not tied to a requirements package: `docs/plans/<name>/`.
+- A feature/branch analysis plan written by the `feature-analyzer` skill:
+  `docs/analysis/<feature>/implementation-plan.md`.
 
 ## Location
-`<DOCS_ROOT>/requirements/<requirement-name>/<YYYY-MM-DD>/`
+`implementation-plan.md` for a requirements-package plan lives inside that
+package, per `requirements-package-standard.mdc`:
+`docs/requirements/<requirement-name>/implementation-plan.md`. No date
+folder — the plan is versioned in place alongside README/prd/specification.
+For the standalone and analysis locations, see `documentation-management.mdc`.
 
 ## Mandatory Behavior
-1. Ask for target location and folder name before creation.
-2. If requirement folder does not exist, create requirements first.
-3. Use a new date folder for every new plan iteration.
-4. Generate and keep synchronized language variants: `ru`, `en`, `ai`.
+1. Ask for target location and folder name before creation, if not already established.
+2. If the plan belongs inside a requirements package and that package does not exist yet, create it first (README, prd, specification) before adding the plan.
+3. Update `implementation-plan.md` in place for each new iteration and bump its `Version` field instead of forking a new folder.
 
 ## Required Plan Structure
 1. High-level plan
@@ -28,22 +38,24 @@ Apply when creating or updating an implementation plan document.
 ## Output Contract
 - Plan files MUST be Markdown (`.md`).
 - Code or command examples MUST be fenced code blocks.
+- Include the `Version: x.y.z` field directly under the H1, per `requirements-package-standard.mdc`.
 
 ## Red Flags — Stop and re-read this rule if you are thinking:
 
 | Rationalization | Why it's wrong |
 |---|---|
 | "The plan is in my head, I don't need to write it down" | An unwritten plan cannot be reviewed, versioned, or handed to another agent |
-| "I'll use the existing folder instead of creating a new date folder" | Date folders are the audit trail — overwriting one erases the iteration history |
+| "I'll start a new folder instead of updating the package in place" | The package is the single source of truth; forking a parallel copy is exactly what `requirements-package-standard.mdc` forbids |
 | "The user knows what we discussed, I'll skip asking for the folder name" | The location question is a confirmation gate, not a convenience; skipping it causes misplaced files |
-| "I'll write the plan in English only since that's what the user spoke" | All three variants (ru/en/ai) are required — omitting one breaks downstream tooling |
 
-**IRON LAW: ALWAYS ASK FOR TARGET LOCATION AND FOLDER NAME BEFORE CREATING ANY PLAN FILE, AND GENERATE ALL THREE LANGUAGE VARIANTS.**
+**IRON LAW: ALWAYS ASK FOR TARGET LOCATION AND FOLDER NAME BEFORE CREATING A REQUIREMENTS-PACKAGE PLAN FILE, AND KEEP IT INSIDE ITS REQUIREMENTS PACKAGE. FOR A STANDALONE OR FEATURE-ANALYSIS PLAN, USE `documentation-management.mdc` INSTEAD.**
 
 ## Template
 ```markdown
 # <Plan Name>
 
+Version: 0.1.0
+
 ## 1. High-Level Plan
 - Objective:
 - Scope:

package/src/gdskills/bundled/rules/core/mobx-store-template.mdc

@@ -3,6 +3,7 @@ description: "Reference template and checklist for MobX store structure and asyn
 alwaysApply: false
 globs:
   - "**/*store*.ts"
+stack_requires: "mobx"
 ---
 
 # MobX Store Template

package/src/gdskills/bundled/rules/core/nestjs-dto.mdc

@@ -4,6 +4,7 @@ alwaysApply: false
 globs:
   - "**/*dto*.ts"
   - "**/dto/**/*.ts"
+stack_requires: "nestjs"
 ---
 
 # NestJS DTO Rules

package/src/gdskills/bundled/rules/core/playwright-testing.mdc

@@ -5,6 +5,7 @@ globs:
   - "e2e/**"
   - "**/*.spec.ts"
   - "playwright.config.ts"
+stack_requires: "playwright"
 ---
 
 # Playwright E2E Testing Guidelines

package/src/gdskills/bundled/rules/core/requirements-management.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Rules for creating and updating requirement documents with multilingual outputs."
+description: "Rules for creating and updating requirement documents. Layout and versioning follow requirements-package-standard.mdc."
 alwaysApply: false
 ---
 
@@ -11,15 +11,20 @@ Standardize how requirement sets are created and maintained.
 ## When To Apply
 Apply when creating or updating requirement documents.
 
-## Location
-`<DOCS_ROOT>/requirements/<requirement-name>/<YYYY-MM-DD>/`
+## Location & Layout
+Follow `requirements-package-standard.mdc` for the package layout
+(`docs/requirements/<name>/{README,prd,specification}.md` plus optional
+files), the `Version: x.y.z` field, and the verification/review contracts. Do
+not restate that layout here, and do not date-stamp the folder or fork
+`ru`/`en`/`ai` copies — one set of documents, versioned in place, is the
+standard.
 
 ## Mandatory Behavior
 1. Ask for target location and requirement folder name before writing.
 2. Confirm naming convention before creation.
-3. Always create a new date-stamped subfolder; do not overwrite old sets.
-4. Generate synchronized `ru`, `en`, and `ai` versions.
-5. Document assumptions and open questions explicitly.
+3. Reuse the existing package folder for the topic; update documents in place
+   and bump their `Version` field rather than creating a parallel copy.
+4. Document assumptions and open questions explicitly.
 
 ## Output Contract
 - Use Markdown (`.md`) only.
@@ -28,8 +33,7 @@ Apply when creating or updating requirement documents.
 
 ## Workflow
 1. Capture request.
-2. Clarify folder/location.
-3. Create folder structure.
-4. Create all required language files.
-5. Validate synchronization.
-6. Ask whether to apply changes.
+2. Clarify folder/location under `docs/requirements/<name>/`.
+3. Create or update the package per `requirements-package-standard.mdc`.
+4. Document assumptions and open questions.
+5. Ask whether to apply changes.

package/src/gdskills/bundled/rules/core/rule-management-workflow.mdc

@@ -1,5 +1,5 @@
 ---
-description: "Workflow for adding or editing rules in the AGENTS.mdc + rules/core structure."
+description: "Workflow for adding or editing rules in the AGENTS.md + rules/core structure."
 alwaysApply: false
 ---
 
@@ -12,10 +12,19 @@ Define a deterministic workflow for adding, editing, and syncing rules.
 Apply when user asks to create, update, move, reorganize, or sync rules.
 
 ## Source of Truth
-- Repository source: `.metaproject/rules`
-- Root always-on file (plain): `AGENTS.md`
-- Root always-on file (Cursor): `AGENTS.mdc` (frontmatter wrapper around AGENTS.md)
-- Thematic files: `.metaproject/rules/core/*.mdc`
+- Keryx's own shipped rules: `src/gdskills/bundled/rules/core/*.mdc` in the
+  keryx repository — installed into `.metaproject/rules/core/*.mdc` by `keryx
+  init`/`keryx update` (the installed copy is regenerated wholesale on every
+  run; edit the source, not the installed copy). There is no `keryx install`
+  command.
+- A project's own instructions: the project's root `AGENTS.md`/`CLAUDE.md`.
+  Edit those files directly, then run `keryx rules sync` (or `keryx rules
+  distill` for a large entrypoint) to import them into
+  `.metaproject/rules/<name>.md` (e.g. `agents-md.md`, `claude-md.md`) and
+  refresh the routing index. A project-owned rule never lives under
+  `.metaproject/rules/core/` — that tree mirrors only keryx's own shipped
+  rules and is overwritten wholesale by `keryx init`/`keryx update`.
+- Root always-on file: `AGENTS.md`
 
 ## Mandatory Clarification Step
 Before creating or editing any rule, the agent MUST ask and confirm:
@@ -25,24 +34,30 @@ Before creating or editing any rule, the agent MUST ask and confirm:
 4. Rule scope and trigger conditions
 
 ## Mandatory Behavior
-1. Update or create thematic rule files only under `rules/core`.
+1. Update or create keryx's shipped thematic rule files only under
+   `src/gdskills/bundled/rules/core/` (installed to `.metaproject/rules/core/`).
+   A project's own instructions belong in its root `AGENTS.md`/`CLAUDE.md`,
+   imported via `keryx rules sync`/`keryx rules distill`.
 2. Keep all rule files in English.
 3. Keep frontmatter valid YAML.
-4. If core files changed, update `AGENTS.md` catalog (and keep AGENTS.mdc in sync).
+4. If core files changed, keep `AGENTS.md` consistent and re-run synchronization.
 5. Run synchronization only after source files are updated.
 
 ## How to Run Synchronization
-After editing rules under `.metaproject/rules/` or `AGENTS.md`, sync to all targets:
+After editing rules under `src/gdskills/bundled/rules/`, run `keryx update`
+(or `keryx init` on a fresh project) to regenerate the installed copy at
+`.metaproject/rules/`. This stays inside the project — it never writes to a
+home-directory (`~`) location.
+
+After editing the project's own root `AGENTS.md`/`CLAUDE.md`, run:
 
 ```bash
-keryx update
+keryx rules sync
 ```
 
-### Sync Targets
-- `~/.cursor/rules/AGENTS.md` — Cursor global rules
-- `~/.codex/AGENTS.md` — Codex global rules
-- `~/.config/zed/AGENTS.md` — Zed global rules
-- `~/.config/opencode/AGENTS.md` — OpenCode global rules
+This imports the root `AGENTS.md`/`CLAUDE.md` into `.metaproject/rules/` and
+refreshes the routing index. It is also project-local and writes no
+home-directory (`~`) path.
 
 ## Rule File Standard
 Every core rule MUST include:

package/src/gdskills/bundled/rules/core/shared-definitions.mdc

@@ -69,7 +69,7 @@ Two modules must recognise the same terminal prompt.
 ```ts
 // Wrong — a claim, unchecked. Four attempts to restate this rule from a
 // reading of the other module each got it wrong in a different way.
-/** Same signals scripts/watchdog.ts uses. */
+/** Same signals the watchdog script uses. */
 const SIGNAL = /do you want to proceed\?/i;
 ```
 

package/src/gdskills/bundled/rules/core/skill-lifecycle.mdc

@@ -20,7 +20,9 @@ Whoever is about to rely on a project-skill verifies it first:
 - Find it: `keryx skills route <target>`.
 - Check freshness: `keryx skills verify <module>/<skill>` (or
   `skill-verify-skill`). It classifies the skill `fresh | stale | needs-review |
-  blocked` against current code, graph, wiki, health, memory, and tests.
+  blocked` from its required files, metadata, manifest registration, target
+  path, and evidence artifacts (graph, ctx, wiki, health, memory). It does not
+  read the skill's claims or compare them with the code.
 - If not `fresh`: do NOT follow it blindly — verify each claim against the code
   and record the drift so it feeds the learn step below.
 
@@ -43,10 +45,12 @@ Flow:
    (version bump + `skill-changelog.md` with provenance, respects manual
    sections, file-locked).
 
-`learn` is bounded, mechanical synthesis. **Dispatch it as a subagent; if a
-cheaper / non-flagship model is available in this environment, use it
-(see `model-selection.mdc`), otherwise use the session model.** The flagship's
-only job here is to review the proposal before apply.
+`learn` is bounded, mechanical synthesis. **Dispatch it as a subagent at
+`model_tier: light`, resolved via `keryx review tier --findings 1 --diff-lines 0`
+per `model-selection.mdc` — do not pick a model by hand, and do not substitute
+a different `review tier` invocation (e.g. `--scope narrow`, which resolves
+heavier than `light`).** The flagship's only job here is to review the
+proposal before apply.
 
 ## Never