Conform

---
name: conform
description: "Evaluate this repository against the registry standards that govern it, one context at a time, and keep the verdicts. Reads .ai/registry-map.json (the generated join between this repo's contexts and the registry's subjects), picks the highest-value unevaluated or stale pairs, reads the governing golden path and techniques against the context's real code, and writes back conformant / deviation / not-applicable with file:line evidence - so the map becomes a standing, incrementally-completed deviation backlog instead of a one-off audit. Use to answer 'where does this repo fall short of the standard', before a hardening pass, after a bundle changes, or when a context is about to be rewritten. Invoke with /conform [context-or-path] [--subject <slug>] [--stale] [--budget <n>]."
category: ai-native
memory: project
version: 1.8.4
tags: conformance, deviations, registry, audit, backlog
argument-hint: "[context-or-path] [--subject <slug>] [--stale] [--budget <n>]"
---

# Conform - judge this repo against the standard it declares

The registry states what good looks like; the map says which subject governs which context.
Neither says whether this code *is* good. That question cannot be computed from words - it
needs someone to read the technique and then read the code - so it is this skill's job, and
the verdicts it produces are the expensive part worth keeping.

**The map is the memory.** Every verdict is written back into
`.ai/registry-map.json`, so run N+1 starts from what run N established instead of
re-auditing the repo. A single run judges a handful of pairs well; the backlog completes
over months, and a bundle change invalidates only the pairs it actually touched.

Say the governing rule out loud once per run: **the standard does not bend to the code.**
Where the repo falls short that is a deviation - recorded, with its reason - never an
argument for lowering the standard.

## Project overlay

Everything project-specific is already on disk; this skill declares no config of its own.

| Input | Where | If missing |
| --- | --- | --- |
| the join map | `.ai/registry-map.json` | **only when the file does not exist**: run `node <registry>/scripts/build-registry-map.mjs --project <slug>` once, then judge. A map that exists is never rebuilt inside a run |
| the registry root | `.ai/manifest.yaml` -> `registry.local` (default `../ai-registry`) | stop and say so - a verdict against a corpus you could not read is worthless |
| the gap register | wherever this repo already tracks defects (its backlog, findings doc, or issue tracker) | report in-session only, and say that nothing was persisted outside the map |

## Invocation

```
/conform                           # no argument: step 1's order past "Named" - stale, arrived, then strong unknowns - capped at the budget
/conform <context-or-path>         # judge the pairs of one named context or path
/conform --subject <slug>          # judge one subject's pairs wherever the map lists it
/conform --stale                   # pairs the generator marked stale: true, the registry's landings arriving here
/conform ... --budget <n>          # override the 3-6 pairs per run; combines with any form above
```

There is no whole-repo form: a bare `/conform` is bounded by the budget and never sweeps
every pair, and there is no flag for arrived contexts - they are chosen by the bare order.
Rebuilding the map is not a mode here (step 1); it is `build-registry-map.mjs`, run outside the skill.

## Procedure

### 1. Load and choose the work (cheap, no code reading yet)

Read the map. Report its shape before doing anything: contexts, pairs, how many are
already judged, how many are `weak`, and the digest each bundle was matched at.

Choose the pairs to evaluate, in this order:

1. **Named** - an argument naming a context, a path, or `--subject <slug>` wins outright.
2. **`--stale`** - pairs the generator marked `stale: true`: their `evaluatedAgainst`
   differs from the pair's own `digest`, the digest of that one subject as it is now. The
   standard moved under a verdict; that verdict is now a claim about a document that no
   longer exists in that form. The header's `stats.staleVerdicts` and `staleSubjects` say
   how many and which - read them first, because they are the registry's landings arriving
   in this repo, and a stale `deviation` may already be fixed by the corrected standard or
   a stale `conformant` may now be a deviation. A map built before 2026-09-02 computed
   staleness from the whole bundle's digest, so it may mark every verdict stale or none:
   judge the pairs anyway and report the map's age (§ the map is never regenerated here).
3. **Arrived** - pairs on a context marked `arrived: true`: the context entered the
   context map since the last build (a `/project-populate` sweep, a new module) and has
   never been judged. It is not stale - there was never a verdict - but it is the freshest
   unjudged code in the repo and the map's `stats.arrivedContexts` says how many there are.
   A context marked `source: "renamed"` is NOT an arrival: its verdicts were carried over
   from `renamedFrom`, and they are judged by the `--stale` rule like any other.

   **When a context's `paths` have grown since its verdict, check `orphans[]` for a verdict
   on the same subject before trusting the carried one.** Two contexts that merge bring both
   their verdicts, one wins silently, and nothing flags the contradiction — neither
   `staleVerdicts` nor `orphanedVerdicts` can see it, because each row is individually
   ordinary. Measured: a `conformant` and a `deviation` on one subject collided at a merge,
   the `conformant` survived onto the merged context and the deviation was orphaned out of
   sight. It was the true one, and it was still live four weeks later. A merge can promote
   the more flattering of two verdicts, so the carried verdict is the one to distrust.
4. **Otherwise**: `state: "unknown"` pairs with `confidence: "strong"`, preferring contexts
   with many governing subjects (a dense context pays back the read) and contexts whose
   paths were touched recently in git.

**Rank `priorNotApplicable` pairs last.** That field means this project has already judged
the subject not-applicable in at least two other contexts, and more often than it judged it
governing. Measured over 287 verdicts, that predicts a further not-applicable at 69%
precision — so those pairs are the least likely to pay back a read.

It is a hint, not a verdict, and the distinction matters in both directions. Judging one is
allowed and sometimes right: the subject may genuinely govern *this* context even though it
missed the others, and a `conformant` verdict there weakens the prior for everyone after
you. What you must not do is let the flag *become* the answer — an unread `not-applicable`
written because the map suggested one is a guess wearing a verdict's clothes, and it
poisons the same tally the next run will trust.

**Budget: 3-6 pairs per run unless `--budget` says otherwise.** This skill is worth more
run ten times than run once; a pass that skims forty pairs produces forty guesses.

**A `/conform` run never regenerates the map.** The only exception is a map that does not exist
at all. Judging is the job; rebuilding is a separate, deliberate operation, and a rebuild inside
a run re-matches every context at once — measured: one added 628 pairs and turned every existing
verdict into an orphan. This holds however old the map looks, whichever builder wrote it, and
whatever its `bundleDigests` say.

When the map lags the registry — an older builder (`contextKey: null`, `staleVerdicts: 0` because
that builder never computed them), bundle digests behind the pinned corpus, subjects the index
has that the map does not — **judge the pairs that are there and report the lag**, naming the
command the operator can run afterwards: `node <registry>/scripts/build-registry-map.mjs
--project <slug>`. A verdict written against the pair's own `digest` stays valid across that
rebuild; the builder carries verdicts forward. Say in the report which of your verdicts were
made against a lagging map.

Never evaluate a `weak` context's pairs by default. A weak row means the declared domains
barely cover that context - the match itself is the doubtful part, and judging code against
a subject that does not really govern it manufactures a deviation. Report weak contexts as
a **coverage question** for the registry instead (below).

### 2. Read the standard first, then the code - in that order

For each chosen pair:

1. Resolve the subject through `<registry>/knowledge/<bundle>/index.json` ->
   `subjects["<slug>"].file`. **Never construct the path**; bundles are nested and the index
   is the address.
2. Read the golden path, then the techniques it names. Note each technique's decision rule
   - the "when X, do Y, because Z" - because that, not the prose, is what you are testing.
3. Check for an application on this repo's stack (`applications/<stack>--<technique>.md`).
   It is teaching material with real citations, not a mandate, and it usually shows the
   shape a conformant realization takes.
4. **Only now** open the context's code — and not only from the map row's `paths`, which is
   a TWELVE-PATH SAMPLE (`build-registry-map.mjs` publishes `c.paths.slice(0, 12)` while
   matching against up to sixty). Read the project's own `context-map.json` for the real
   list. Measured in one repo on one run: the sole anchor for a surviving deviation was
   absent from the sample in three separate contexts, and a judge working from the sample
   alone returns `conformant` on all three.

Reading the code first is how an audit turns into a description of what the code already
does. The standard has to be in your head before the code is, or you will grade the repo
against itself.

### 3. Judge each technique, not the subject as a whole

A subject is a bundle of techniques and a repo is rarely uniform across them. Produce one
verdict per **pair**, derived from the techniques:

| Verdict | Means | Requires |
| --- | --- | --- |
| `conformant` | every technique that applies here is realized | the techniques you judged, listed by slug, with a `file:line` for **every one you call realized** |
| `deviation` | at least one applicable technique is not realized, or is realized in a way the technique names as a failure | `file:line` for where it should be, and one sentence on the consequence |
| `not-applicable` | the technique's precondition does not hold here (a `stage:` above this repo's rung, a capability it does not have) | one sentence naming the precondition, **plus a `file:line` anchoring the absence** - the manifest, config or module that shows the precondition unmet |

**The evidence floor.** Count the subject's techniques and count the ones you cited. A
`conformant` verdict that names fewer than **half** of them is not conformant, it is `unknown`:
you looked at part of the subject and the rest is unread. This is a floor, not a target - a
subject of four techniques needs two anchors, not four paragraphs about a technique you skimmed.

**Anchors have a shape.** `<path>:<line>`, the path relative to the repository root exactly as
`git ls-files` prints it. A basename (`limiter.ts:41`) is ambiguous the moment the repo has two
packages, and an anchor that does not resolve is not evidence. This applies to all three
verdicts, `not-applicable` included: "the repo has no worker tier" is a sentence;
"`Cargo.toml:1` declares four crates, none a worker" is an anchor.

**"It resolves" is the wrong check — a blank line resolves.** Print every anchor's line back
(`sed -n "<n>p" <path>`) and read it before writing the verdict; the test is whether that line
SAYS what the evidence claims. Measured on one run: four of twenty-three anchors first landed
on a blank line, a `*/`, or the line above the construct, because the author recorded the line
they had scrolled to rather than the line the construct sits on. All four resolved.

Three rules that keep verdicts honest:

- **`not-applicable` is a real verdict and must be argued and anchored.** It is the honest
  answer for a `stage: fleet` technique in a solo repo — and it still shows the reader where
  the missing precondition is visible. It is not a place to put "we disagree".
- **A deviation is a finding about the code, never about the standard.** If the technique
  genuinely seems wrong here, that is a *registry* finding: record it as a proposal
  (below), and still mark the deviation.
- **Uncertain is `unknown`.** Leaving a pair unjudged costs nothing; a confident wrong
  verdict poisons the backlog and is expensive to find later.

### 4. Write the verdicts back

Update each evaluated pair in `.ai/registry-map.json`, in place, changing nothing else:

```json
{ "subject": "rate-limiting", "state": "deviation",
  "evidence": "src/api/limiter.ts:41 buckets by user id only; untrusted-key-derivation requires a bucket the caller cannot choose",
  "evaluatedAt": "2026-08-23", "evaluatedAgainst": "sha256:5c2ad4a129529e33",
  "evaluatedRevision": 4 }
```

- `evaluatedAgainst` is the digest of the subject **as you actually read it** - the subject's
  own content digest, not the bundle's. It is what makes `--stale` work later, and it goes
  stale only when THAT subject changes. Remove a `stale: true` you have re-judged.
  **Take it from the registry's `index.json` when the registry is reachable, and fall back
  to the pair's copy only when it is not.** The pair's copy is the digest the map was BUILT
  with, and a map can lag the corpus by hours: measured on 2026-09-20, five projects' maps
  were rebuilt at 14:35 and a technique landed in `table` the same afternoon, so every pair
  still read revision 4 while every reader was reading revision 5. Copying the pair's digest
  verbatim would have stamped those verdicts as current against a version of the subject
  nobody read - the one error this field exists to make impossible. Say in the report when
  the two disagreed and which you wrote.
- `evaluatedRevision` is the pair's `revision` at the time you judged - the subject's
  revision counter, mirrored from the bundle index beside `changedAt`. Copy it verbatim
  beside `evaluatedAgainst`; it is what makes `revisionsBehind` (`revision -
  evaluatedRevision`) computable, so a later run and `/straighten` can rank how far behind
  a verdict is instead of only whether it is. A verdict without it carries no
  `revisionsBehind` key at all (the builder omits it, never writes `null` or `0`) - "unknown, pre-revision verdict" - until re-judged.
- `evidence` is one line: the anchor plus the consequence. Not a paragraph, not a plan.
- **Never rewrite the matching fields** (`score`, `why`, `confidence`) - those belong to the
  generator, and hand-edited derived values drift silently.

**When the right subject is missing entirely, ADD it.** Lexical matching misses a subject
whose vocabulary differs from the repo's, and it misses it *silently* - scoring zero looks
identical to not existing. Measured on the first run: a context about "Provider
Integrations" is governed by `connector-catalog`, which scored **nothing**, because the repo
says provider/integration where the subject says connector/catalog/adapter. Five wrong
subjects ranked above it.

So a corrected pairing is a first-class output, written into the row as a new entry:

```json
{ "subject": "connector-catalog", "bundle": "software-engineering",
  "source": "conform", "confidence": "strong", "state": "unknown",
  "evidence": "added by /conform: the matcher scored this at zero; the repo's vocabulary differs from the subject's" }
```

`source: "conform"` is what makes it survive regeneration - the builder carries added pairs
forward exactly like verdicts, because a pairing somebody established by reading code is
worth more than one a token overlap produced. Add the pair, then judge it like any other
(usually in the next run; establishing the pairing is enough for this one).

**Before adding a pair the matcher scored at zero, read the golden path's "when NOT to use
this" section.** A subject that scored zero and a surface that should not carry that subject
are indistinguishable from the map, and the correction for the first is the mistake for the
second. The test is cheap and it fires often: in one wave it stopped four unearned pairings
on card grids and a log feed in one repository, and a deck of four cards and a virtualized
collection grid in two others - every one of them a surface the governing subject's own
opening section tells you not to build that way. An unearned pairing is worse than none,
because the next run inherits it as established.

**Commit the map edit — it is the deliverable.** The verdicts are the expensive part of the
run, and an uncommitted `.ai/registry-map.json` is a run that produced nothing durable. Default:
one path-scoped commit, `conform: <n> verdicts on <context>`, naming `.ai/registry-map.json`
(and the gap-register file if this repo keeps one) by explicit path — never `-A`.

**Put the pathspec on the COMMIT, not only on the `git add`.** Staging by explicit path is not
enough: `git commit -F <msg>` with no pathspec commits the whole INDEX, including anything a
sibling session staged before you arrived. Measured on 2026-09-20, that swept another session's
pre-staged file into a conform commit, and in the same wave a second repository was holding
sixty-five staged files from a live feature branch. Write it `git commit -F <msg> --
.ai/registry-map.json`, and read `git diff --cached --name-only` first so you know what you are
standing next to. If it has already happened, `git reset --soft HEAD~1` restores the index
intact; recover, then re-commit with the `--` form.

Commit on the current branch; do not push. If the tree is dirty with another session's work, commit *your*
paths only and say so in the report. If the task forbids committing, say plainly that the map
edit is uncommitted and name the file.

Then land the findings where this repo already tracks work: deviations become backlog items
with their subject slug and anchor. A deviation that lives only in a JSON file is a
deviation nobody will fix.

#### Orphans

When a context leaves the context map, the generator does not discard its verdicts: they
are retained under the map's top-level `orphans[]` as
`{ context, name, group, paths, subjects: [<pairs>] }`, and `stats.orphanedVerdicts` counts
them. Each is a decision waiting for a reader, and this skill is the reader:

**Route an orphan by the files its own `evidence` anchors, not by its bulk path list** — the
list in the map is a twelve-path sample and it disagreed with the anchors twice in one run.
And **never copy an orphan's `digest`**: it is metadata from the build that orphaned it, so
copying it stamps a verdict against a version of the subject that no longer exists. Measured:
three orphans in one repo carried digests the index had moved past. Take the current one, or
leave the pair unjudged.

- **Adopt** - when the code the verdicts were about now lives under another context (a
  split, a move the renamer did not catch), move the pair under that context's
  `subjects[]` with `source: "conform"` and `adoptedFrom: "<orphan key>"`, then remove it
  from `orphans[]`. If the pair carries `stale: true`, re-judge it in the same run - a
  carried verdict is a claim about a document that may have moved twice.
- **Leave** - when nothing governs that code any more, or you cannot tell. The generator
  keeps the orphan across rebuilds; an undecided orphan costs a glance, a deleted one costs
  the verdict somebody paid for. **Never hand-delete an orphan** - dropping one is a
  decision made by adopting nothing and saying so in the report.

`/straighten` surfaces every orphan fleet-wide and hands each project's to this step.

### 5. Report demand back to the registry

Append one line per evaluated context to `.ai/consults.jsonl` (gitignored; the registry's
`scripts/signals-collect.mjs` folds it into the `signals/` lane as counts only):

```json
{"ts":"<ISO>","bundle":"<name>","subjects":["<slug>"],"techniques":["<slug>"],"deviations":<n>}
```

This is the only channel by which the registry learns which of its standards are actually
being tested, and where they are being failed. A deviation count is the strongest demand
signal the corpus can receive - it means somebody measured a claim against real code.

**And write the run's own result, for whoever dispatched it.** Everything above is
written for a reader; nothing tells a *program* whether this run judged four pairs,
declined to judge any, or could not read the map. **This skill runs inside the consuming
project, not in the registry**, so its result does not go to the registry's
`librarian/runs/` lane - it lands beside `.ai/consults.jsonl`, in the repo it judged:

```sh
node <registry>/scripts/lib/run-result.mjs write <draft.json> \
  --root . --path .ai/conform-runs/<run-id>.json
```

Same `rkb-run-result/1` schema, same refusals. Paths there are **project-relative** -
this file stays in the project, so `files[]` naming `.ai/registry-map.json` is correct
and an absolute path is still refused. Use `conform-<YYYY-MM-DD>-<n>` as the run id.
Fill `skill_version` from this file's frontmatter, `mode` (`named` / `stale` / `arrived` /
`unknown`), `domain: null` (a run spans whatever bundles the pairs came from),
`counts.landed` = pairs judged, `counts.declined` = pairs deliberately left unjudged with
their reason in `declined[]` - an unread pair left for the next run is a decline, and this
skill's own rule is that uncertain is `unknown`, which is only honest when it is written
down. One `subjects[]` row per subject judged, whose `outcome` is the counts vocabulary
(`landed` / `declined` / `idled` / `contended` / `dispatched`) - **never `conformant` or
`deviation`**, which are map states and would be a second copy of a judgment that already
has a home. `verdicts[]` is for the apply/A-B lane and is usually **empty here**: a
`conformant` / `deviation` / `not-applicable` verdict belongs in the map, and forcing it
into that field would be a second, disagreeing copy. `pr: null` - step 4 commits.

### 6. Close with what the registry owes

Two outputs go **to the registry**, not into this repo, and a run that produces them has
done more good than one that only fixed code:

- **Coverage questions** - the `weak` contexts, and any pair where the governing subject
  turned out not to govern. Distinguish three outcomes, because they have different fixes:
  the corpus has a **hole** (forge lead); the corpus has the subject but the **matcher
  missed it** (add the pair, as above); or the match was a **technique-shaped resonance** -
  the context genuinely realizes one technique's doctrine, but that technique lives inside a
  subject whose stated precondition the context fails. The last is the subtle one and it has
  a cheap test: **route by the subject's precondition, not by its vocabulary.** Ask what the
  golden path says it is *about* before asking whether any of its words appear here.
- **Upward lessons** - where this repo does something *better* than the technique describes,
  or where the technique's rule broke down against a real case. That is how the corpus got
  good; it is worth a proposal, and the application layer is where evidence with a real
  `file:line` belongs.

## Anti-patterns

- **Reading the code before the standard.** Produces a description of the repo wearing the
  vocabulary of the corpus, and every verdict comes back `conformant`.
- **Judging a whole subject from one technique**, in either direction.
- **Marking `deviation` without an anchor.** An unanchored deviation cannot be verified,
  fixed, or falsified, and it will be re-found forever.
- **Evaluating weak pairs to raise the count.** The number of judged pairs is not the goal;
  a small honest map beats a large speculative one.
- **Regenerating the map, for any reason, inside a run.** Not to "fix" a verdict, not to
  refresh a stale digest, not because the builder looks old. Judge, report the lag, leave the
  rebuild to a deliberate operation outside this skill.
- **A bare-slug or basename anchor.** Repo-root-relative or it is not evidence.

---

<!-- clause: skill-reflection v6 - stamped by scripts/apply-skill-clauses.mjs from docs/skill-clauses/skill-reflection.md; edit the template, then re-stamp -->
## Skill Reflection

After the work, record only useful observations supported by this run. No lesson is
a valid result. Reflection inherits the task's authorization; it grants no additional
permission to edit another repository, send data, commit, or publish.

**Run log.** Unlike a lesson, this is written on every run that started work - failed and
aborted runs included; skip read-only info modes and runs cancelled before any work. Append
ONE line to `.ai/skill-runs.local.jsonl` at the root of the task's MAIN checkout: local,
gitignored run output inside the task's own repository, never a write into the registry.
A run that worked in a linked worktree logs in the main checkout that worktree belongs to
(`git rev-parse --git-common-dir`, minus `/.git`) - a disposable worktree takes the line
with it when it is removed. `log-run.mjs` resolves this on its own.
The registry pulls it later (`/librarian skills` on the same machine). When a registry
checkout is reachable (`registry.local` in `.ai/manifest.yaml`), prefer its writer, which
stamps project, device and version for you:

```sh
node <registry>/scripts/log-run.mjs --skill conform --outcome <o> --difficulty <1-5> \
  --provider <claude|openai|xai|qwen|google|other> --model <your model id> [--effort <level>] \
  [--tokens-est <n>] --result "<one sentence>" --comment "<self-reflection>"
```

Otherwise write the line yourself: `{"ts":"<ISO, UTC Z>","skill":"conform","outcome":…,
"difficulty":…,"provider":…,"model":…,"effort":…|null,"tokensEst":…|null,"result":…,"comment":…}`.

- `outcome`: `shipped` (the goal landed) / `partial` / `no-op` (ran correctly, nothing to
  do) / `parked` (designed or staged, deliberately not landed) / `failed` / `aborted`.
- `difficulty` rates the task as this run met it: 1 trivial - mechanical; 2 routine - the
  method as written; 3 demanding - real judgment calls or one detour; 4 hard - dead ends,
  rework or an operator course-correction; 5 at the edge - partial or failed on the merits.
- `model`/`effort` as your harness states them (`null` effort when you cannot see it).
  `tokensEst` is the drop in the harness's remaining-token counter since this skill was
  invoked, or `null` (with `log-run.mjs`, omit `--tokens-est`); exact figures are measured
  later from transcripts - never guess one.
- `result` is one line (max 240 chars). `comment` (max 2000) is the self-reflection a
  reviewer reads: what worked, what the method made harder, where its instructions were
  wrong, missing or ignored. No filesystem paths or email addresses.
- Never read run logs during a run. They are evidence ABOUT this skill for its reviewer;
  an executor that reads its own diagnosis contaminates the next measurement.

**Project learning.** Only when this run produced an observation that would change how a
future run behaves. A run that went as the method describes writes nothing: an entry that
restates the procedure, records "no issues", or repeats the task is a defect, not a
deliverable. When there is such an observation and local edits are within scope, put one
dated line in the overlay this skill's `## Project overlay` section names, under
`## Skill improvement log`. **Write only into an overlay that already exists.** If the
project has none, put the observation in the response instead - creating a new tracked
file for a reflection is scope the task did not ask for, and a reader who never asked for
the skill has to review it. If the overlay is a structured config (YAML, TOML, JSON),
record the note as comments so the file keeps parsing, or use the response.
Use a supplied memory contract only when its destination and writes are authorized.
Keep project details out of the shared method.

**Method learning.** Identify the installation before editing anything. A local
`.ai/registry-installation.local.json` receipt can identify development versus release,
the registry revision, and selected skill versions. Verify any link's actual target;
do not assume a skill directory is a writable registry link.

- For a pinned release, marketplace cache, ordinary copy, or unknown installation,
  keep a proposal in the project overlay or response. Do not edit the installed method
  or silently relink it. Adoption and rollback are explicit installation operations.
- For a development link, edit the registry only when that checkout is already within
  the accepted task scope. Otherwise report a proposal. Authorized changes belong in
  the source checkout, followed by its gates; commit only when the task authorizes it.
- Record an actual lesson in `LESSONS.md` against the version **used**:
  `## <version-used> - <YYYY-MM-DD> - <project-name>` and concise bullets. A proposal
  must be labeled as such; structural checks are not evidence of field effectiveness.
- Applied skill changes require a version bump: patch for wording, minor for a step
  refinement, major for method redesign. A lesson alone needs no bump. Shared stamped
  clauses are edited in the registry's `docs/skill-clauses/` and regenerated with
  `scripts/apply-skill-clauses.mjs`, never patched in individual installed skills.

**Domain learning.** Follow `## Knowledge sync` when present, within the same scope
and privacy boundaries. A method lesson and a domain knowledge lead are different
artifacts; do not fabricate either to fill a reflection quota.
<!-- /clause: skill-reflection -->