@event4u/agent-config 14.9.0 → 14.11.0

package/dist/agent-src/skills/motion-choreographer/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: motion-choreographer
-description: "Use when turning a locked still + blueprint into a provider-tuned motion prompt — camera, primary + secondary motion, physics, native-audio sync. Triggers 'motion prompt for Veo/Kling/Sora'."
+description: "When turning a locked still + blueprint into a provider-tuned motion prompt — camera, primary + secondary motion, physics, native-audio sync. Triggers 'motion prompt for Veo/Kling/Sora'."
 personas:
   - ai-video-technical-director
 domain: product
@@ -59,6 +59,12 @@ Do NOT use when:
    for Step 3.
 4. If a `character.json` lock exists, load it verbatim — identity
    tokens are immutable.
+5. Continuous take or connector asked for? Read the model's
+   `start_frame` / `end_frame` first —
+   `scripts/ai-video/adapters/<id>.sh capability --model <m>`. `null` is
+   unknown, never `true`. A model that cannot frame-lock is **declined
+   with a one-line why**, never substituted in
+   ([`adapter-contract.md#end_image`](../../../scripts/media/lib/adapter-contract.md#end_image)).
 
 ### Step 1: Camera choreography
 

package/dist/agent-src/skills/multi-tenancy/SKILL.md

@@ -8,6 +8,10 @@ workspaces:
   - engineering
 packs:
   - engineering-base
+triggers:
+  - phrase: "tenant isolation"
+  - phrase: "cross-tenant"
+  - phrase: "tenant scoping"
 ---
 
 <!-- Framework scope: Laravel only. Uses Eloquent model conventions,

package/dist/agent-src/skills/onboarding-program/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: onboarding-program
-description: "Use when shaping employee onboarding — time-to-productivity, role-by-role program, mentor pairing, 30/60/90 milestones. Triggers on 'design our onboarding', 'why are new hires ramping slow'."
+description: "When shaping employee onboarding — time-to-productivity, role-by-role program, mentor pairing, 30/60/90 milestones. Triggers on 'design our onboarding', 'why are new hires ramping slow'."
 status: active
 tier: senior
 domain: process

package/dist/agent-src/skills/operational-readiness/SKILL.md

@@ -0,0 +1,184 @@
+---
+model_tier: medium
+name: operational-readiness
+description: "Use when adjudicating an operational go/no-go from typed evidence — a readiness enum with an explicit floor where one red is not-ready, unknown is never green, and no score can average a red away."
+domain: devops
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+---
+
+# operational-readiness
+
+## When to use
+
+Use when turning evidence that already exists into a **verdict**: is this system
+ready to operate. The inputs come from other skills; this one adjudicates them
+and refuses to average.
+
+Do NOT use when:
+- Producing the observability evidence itself (use `logging-monitoring`)
+- Deciding what earns a page (use `alerting-doctrine`)
+- Hardening the host (use `server-hardening`)
+- Working through a release checklist and rollout plan (use `launch-readiness` —
+  that is a pre-merge procedure; this is a verdict over operational evidence)
+- Running an incident already in progress (use `incident-commander`)
+
+## The verdict is an enum with a floor
+
+```
+ONE RED MAKES THE VERDICT not-ready, WHATEVER SITS BESIDE IT.
+UNKNOWN IS NEVER GREEN. THERE IS NO SCORE, NO WEIGHT, NO AVERAGE.
+```
+
+| Verdict | Condition |
+|---|---|
+| `ready` | Every input is green. No reds, no unknowns. |
+| `ready-with-risk` | Every input is green or amber, at least one amber, **no** reds and **no** unknowns. Each amber names its accepted risk and an owner. |
+| `not-ready` | **At least one** red — or at least one unknown. |
+
+Three properties, each load-bearing:
+
+- **The floor is absolute.** One red among nineteen greens is `not-ready`. The
+  red is the interesting input precisely because the greens cannot answer it.
+- **`unknown` lands in `not-ready`, not in `ready-with-risk`.** An uninspected
+  input is not a small risk, it is an unmeasured one, and treating it as amber is
+  how "we never checked" becomes "we accepted it". Amber requires someone to have
+  looked and named what they are accepting.
+- **There is no numeric path.** No readiness percentage, no weighted score, no
+  count of greens, no "N of M passing". Any such construct can hide a red, which
+  is the only failure mode this skill exists to prevent. If you catch yourself
+  producing a number, the verdict has already been lost.
+
+## Typed evidence intake
+
+Each input arrives from an owning surface and keeps its provenance. This skill
+does not re-derive an input — it reads the verdict the owner produced.
+
+| Input | Owner | Red when |
+|---|---|---|
+| Observability posture | `logging-monitoring` | A required Golden Signal is `unavailable` or `unknown` |
+| Alert set | `alerting-doctrine` | Any `malformed-alert`, or no page exists for a user-visible failure |
+| Finite-resource headroom | `scale-discipline` R-A12 | A constrained resource has no known ceiling, or headroom is unquantified |
+| Host posture | `server-hardening` | SSH, firewall or patch baseline unmet or uninspected |
+| Deploy safety | `engineering-safety-floor` | Any of blast radius, rollback path, pre-flight checks, observability or named risk owner is missing |
+
+An input the intake cannot obtain is `unknown` — never omitted, and never
+defaulted to green. Omission is the silent failure; recording it as `unknown` is
+what makes it visible in the verdict.
+
+A threshold reaching this skill with `proposed` provenance is not evidence. It is
+a suggestion, and adjudicating against it produces a verdict about a number
+nobody committed to — see `logging-monitoring` § Evidence states.
+
+## Procedure: Adjudicate readiness
+
+1. **Enumerate the five inputs.** The list does not shrink to the ones that are
+   convenient to obtain.
+2. **Read each owner's verdict.** Do not re-derive it here; a second derivation
+   is a second opinion, and the owner holds the authority.
+3. **Mark every input `green`, `amber`, `red` or `unknown`.** An input you could
+   not obtain is `unknown`, stated with what blocked the inspection.
+4. **Apply the floor, in this order.** Any red or any unknown → `not-ready`,
+   stop. Else any amber → `ready-with-risk`. Else `ready`.
+5. **Name every red and every unknown in the output**, each with the input it
+   came from and what would clear it. A `not-ready` verdict that does not say
+   what to fix is an obstruction rather than a finding.
+6. **For `ready-with-risk`, record each amber's accepted risk and its owner.**
+   An accepted risk with no owner is an unaccepted risk.
+
+### Validate
+
+- Verify all five inputs appear in the output, including the ones scored
+  `unknown`.
+- Confirm any red or any unknown produced `not-ready`.
+- Confirm no amber was used to absorb a red or an unknown.
+- Confirm the output contains no score, percentage, weight or pass-count.
+- Confirm every red and unknown names what would clear it.
+- Confirm every amber names an accepted risk and an owner.
+
+## Output format
+
+1. The verdict — one of `ready`, `ready-with-risk`, `not-ready`.
+2. One row per input — input, owner, state, evidence pointer.
+3. Every red and unknown with what would clear it; every amber with its accepted
+   risk and owner.
+
+## Examples
+
+Contract fixtures. The pair differs **only** in the condition under test, and
+each case states the verdict it must produce. Contract evidence for review, not
+an executable suite.
+
+### One red among greens — malformed vs clean
+
+```yaml
+# malformed input set — four greens and one red.
+# The floor applies: the greens do not outvote the red.
+inputs:
+  observability:   { state: green, evidence: "4/4 signals present" }
+  alert_set:       { state: green, evidence: "0 malformed-alert" }
+  finite_resource: { state: green, evidence: "pool ceiling 100, peak 61" }
+  host_posture:    { state: green, evidence: "ssh keys-only, ufw default deny" }
+  deploy_safety:   { state: red,   evidence: "no rollback path stated" }
+verdict: not-ready
+blocking: ["deploy_safety: no rollback path stated"]
+clears_when: "a rollback path is stated and its time-to-rollback estimated"
+```
+
+```yaml
+# clean — only the red input is replaced.
+inputs:
+  observability:   { state: green, evidence: "4/4 signals present" }
+  alert_set:       { state: green, evidence: "0 malformed-alert" }
+  finite_resource: { state: green, evidence: "pool ceiling 100, peak 61" }
+  host_posture:    { state: green, evidence: "ssh keys-only, ufw default deny" }
+  deploy_safety:   { state: green, evidence: "rollback: revert + redeploy, ~4min" }
+verdict: ready
+```
+
+### Unknown is not amber — malformed vs clean
+
+```yaml
+# malformed — an uninspected input recorded as an accepted risk.
+inputs:
+  host_posture: { state: amber, accepted_risk: "probably fine", owner: null }
+verdict: invalid-unknown-as-amber
+reason: "nobody inspected the host; amber requires a named accepted risk and owner"
+```
+
+```yaml
+# clean — the same uninspected input recorded honestly.
+inputs:
+  host_posture:
+    state: unknown
+    reason: "no shell access to the managed runtime; posture not inspectable"
+verdict: not-ready
+blocking: ["host_posture: not inspectable"]
+```
+
+## Gotcha
+
+- A count of passing inputs is a score wearing different clothes.
+- `ready-with-risk` is not a softer `not-ready`; it is unreachable while any red
+  or unknown exists.
+- An amber with no named owner is a red that has been rounded down.
+- Re-deriving an owner's verdict here produces a disagreement with no tiebreak.
+- A green built on a `proposed` threshold is a green built on a guess.
+
+## Do NOT
+
+- Do NOT compute a readiness percentage, weighted score or pass-count.
+- Do NOT let greens outvote a red — the floor is absolute.
+- Do NOT record an uninspected input as amber, or omit it.
+- Do NOT treat `unknown` as green, compliant, or "probably fine".
+- Do NOT return `not-ready` without naming what would clear it.
+
+## Auto-trigger keywords
+
+- operational readiness
+- readiness verdict
+- go/no-go
+- ready to operate
+- production readiness

package/dist/agent-src/skills/operational-readiness/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "operational-readiness",
+  "last_eval": "2026-08-23",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers adjudicating a go/no-go from typed evidence and the one-red floor. Should-not-trigger covers the neighbours that PRODUCE the evidence rather than adjudicate it (logging-monitoring, alerting-doctrine, server-hardening), the pre-merge release checklist (launch-readiness) and an incident already running (incident-commander).",
+  "queries": [
+    {"q": "are we operationally ready to run this in production?", "trigger": true},
+    {"q": "give me a go/no-go verdict from what we know about this service", "trigger": true},
+    {"q": "four checks are green and one is red — what is the overall verdict?", "trigger": true},
+    {"q": "can we call this ready if we never inspected the host?", "trigger": true},
+    {"q": "adjudicate operational readiness for the payments service", "trigger": true},
+    {"q": "which Golden Signal is this project missing?", "trigger": false, "note": "produces the observability evidence → logging-monitoring"},
+    {"q": "should this alert wake the on-call engineer?", "trigger": false, "note": "alert classification → alerting-doctrine"},
+    {"q": "write the pre-merge checklist and rollout plan for this release", "trigger": false, "note": "pre-merge release procedure → launch-readiness"},
+    {"q": "we are in an outage right now, who does what?", "trigger": false, "note": "incident already running → incident-commander"},
+    {"q": "configure the firewall baseline on the new server", "trigger": false, "note": "host hardening execution → server-hardening"}
+  ]
+}

package/dist/agent-src/skills/override-management/SKILL.md

@@ -3,6 +3,9 @@ model_tier: inherit
 name: override-management
 description: "Creates and manages project-level overrides for shared skills, rules, and commands — extending or replacing originals from .augment/ with project-specific behavior in agents/overrides/."
 domain: process
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal

package/dist/agent-src/skills/perf-feedback-craft/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: perf-feedback-craft
-description: "Use when shaping feedback — situation-behavior-impact, growth-vs-corrective split, cadence design, ladder-of-inference checks. Triggers on 'how do I give this feedback', 'perf review shape'."
+description: "When shaping feedback — situation-behavior-impact, growth-vs-corrective split, cadence design, ladder-of-inference checks. Triggers on 'how do I give this feedback', 'perf review shape'."
 status: active
 tier: senior
 domain: process

package/dist/agent-src/skills/persona-improvement/SKILL.md

@@ -3,6 +3,9 @@ model_tier: inherit
 name: persona-improvement
 description: "Refine a persona from recent corrections — tightens its Unique Questions, governance-gated; explicit request only. Skill analog → skill-improvement-pipeline."
 domain: process
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal

package/dist/agent-src/skills/pest-testing/SKILL.md

@@ -12,6 +12,9 @@ trust:
 install:
   default: false
   removable: true
+triggers:
+  - phrase: "pest test"
+  - phrase: "pest suite"
 ---
 
 # pest-testing

package/dist/agent-src/skills/playbook-authoring/SKILL.md

@@ -0,0 +1,162 @@
+---
+model_tier: medium
+name: playbook-authoring
+description: "Use when a repo has its own generators, scripts or turbo tasks and an agent reaches for a generic skill instead — derive a Playbook context (ADR-244) from the real config, graded by the tree."
+domain: engineering
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+---
+
+# playbook-authoring
+
+A shipped skill is a generic answer to a generic question. A **playbook** is *this*
+repository's answer, and it outranks the shipped skill whenever both match — because it
+carries decisions the repository already made (file layout, barrel exports, test
+co-location, the project's own naming) that no generic skill can know.
+
+This skill derives playbooks from the repository's own configuration. It is the procedure
+half of `standards-from-config`'s Class-A rule: the config **is** the standard, so a
+playbook step is only trustworthy when the thing it invokes was **seen in the tree**.
+
+## The Iron Law
+
+```
+NEVER WRITE A `configured` STEP FOR A GENERATOR YOU DID NOT SEE IN THE TREE.
+RESOLVE EVERY `invokes` ID TO A FILE OR A DECLARED TASK, OR GRADE IT `observed`.
+INVOKE WHAT THE WRAPPER POINTS AT, NEVER THE WRAPPER.
+A KIND THIS RELEASE CANNOT RESOLVE IS REPORTED, NEVER GUESSED AT.
+```
+
+## When to use
+
+A repository carries its own generators, task-runner tasks, or creation scripts, **and** an
+agent has been observed producing a generic component / module / package instead of running
+them. Also on an explicit ask — *"write playbooks for this repo"*, *"why does the agent not
+use our generator"*.
+
+## Procedure
+
+1. **Derive, and write nothing yet.** Enumerate the sources in the scope table below and
+   list one candidate per repeated procedure, each with its grade — nothing written.
+   - **Source of truth:** the repository's own task declarations — see the scope table below
+     for which of them this release resolves.
+   - **Verify:** every line printed names an id you can run by hand.
+2. **Read every proposal, including the graded-`observed` ones.** An unresolved id means go
+   look at the tree before deciding what it means.
+   - **Verify:** each `configured` proposal's `source_of_truth` points at a file you opened.
+3. **Drop the candidates that are not procedures.** A one-off, or a single command wearing a
+   playbook's formatting, is a rename — delete it from the set.
+   - **Verify:** every surviving candidate is something done repeatedly the same way.
+4. **Write, then read the written file.** Write each surviving candidate, then open it.
+   - **Verify:** the frontmatter `grade` matches what step 2 established, and a
+     `configured` file has no step without an `invokes` entry.
+5. **Register the staleness expectation.** The `invokes` ids are what the Phase-3 check
+   resolves; a playbook whose ids you cannot name is not finished.
+   - **Verify:** every written playbook's `invokes` list is non-empty, and each id can be
+     run by hand in the repository.
+
+## The derivation — deterministic, and maintainer-side today
+
+A `derive_playbooks` script implements the enumeration above in this package's own source
+tree. It is deterministic and makes no model call: it prints one line per proposal with its
+grade, and `⚠️  … grade=observed` is a signal to go look rather than a warning to dismiss.
+
+**It is not exposed as a consumer command.** A consumer install receives this skill and not
+that script, so in a consumer repository the procedure above is carried out **by hand
+against the grading rules below** — which is why those rules, not the script, are the
+substance of this skill. Saying so is the point: a skill that told a consumer to run a
+command they do not have would fail on their first attempt.
+
+Either way, read every proposal before writing: the derivation finds *candidates*, and
+whether a repeated procedure deserves a playbook is a judgement it does not make.
+
+## Scope of the derivation — and what "not covered" means
+
+A playbook is **ecosystem-neutral**: a Python monorepo's `nox`/`invoke` sessions, a Go
+repo's `make` targets, a Rust workspace's `just` recipes and a PHP repo's console commands
+are all repeated procedures a playbook can encode, and the artefact class does not care
+which. What varies is whether a *deterministic* reader can resolve an invoked id **without
+running a consumer binary** — the constraint that decides this release's set, per
+[ADR-244](../../../docs/decisions/ADR-244-playbook-is-a-sixth-context-type.md).
+
+| Declared where | Resolvable without a binary? |
+|---|---|
+| a Node manifest's script map (root and each workspace) | yes — read from the manifest |
+| Turborepo task declarations | yes — read from the task file |
+| Turborepo generator templates, by the **registered name** rather than the filename | yes — read from the config |
+| Nx generators | **no** — the list comes from `nx list` |
+| Plop generators | **no** — the list comes from `plop --help` |
+| Make / just / nox / invoke / console targets in other ecosystems | **not yet read** — no reader written; the artefact class covers them |
+
+The `no` rows are a decision, not an omission: their discovery requires running a binary the
+consumer owns, and the Phase-3 staleness check must run without one. A repo carrying either
+is **reported** on stdout, so its maintainer sees the gap rather than receiving a silently
+partial set. The last row is honest scope: nothing reads those yet, and a playbook for them
+is written by hand against this skill's grading rules.
+
+## The wrapper trap — the one that silently rots
+
+A script like `"new:component": "turbo gen component"` is a **pointer**, not a procedure. A
+playbook that invoked `new:component` would keep passing the staleness check after the
+generator is renamed, because the script still exists — the exact drift Phase 3 gates.
+The derivation therefore unwraps a thin wrapper and records what it points at, and the
+`source_of_truth` line on each step names where the id was resolved.
+
+## Grading, in one sentence each
+
+- **`configured`** — every step's id resolved to something in the tree, and each step cites
+  where. The reader may follow it without checking.
+- **`observed`** — at least one id did **not** resolve. The steps are a hypothesis to
+  confirm, and the file says which id failed. Downgrading is the honest outcome; writing
+  the stronger claim and hoping is the failure this skill exists to prevent.
+
+## Output format
+
+1. One playbook per file in the playbook home, frontmatter first: `task`, `scope`, `grade`,
+  `invokes`.
+2. Report the grade of every proposal in the reply, including the downgraded ones — a set
+   reported as "playbooks written" with the `observed` ones unmentioned reads stronger than
+   it is.
+3. Name any out-of-scope kind the script reported (`nx`, `plop`) rather than dropping it.
+4. State the count written and the count read — they must be the same number.
+
+## Gotchas
+
+- **The wrapper trap, and it is the common case.** `"new:component": "turbo gen component"`
+  is a pointer. A playbook invoking `new:component` survives the generator being renamed —
+  the script still exists — so the staleness check stays green over a broken procedure.
+- **The filename is not the generator id.** A Turborepo generator config registers
+  `component` inside the file; reading the *filename* yields `turbo gen config`, which
+  nobody can run.
+- **`observed` reads like a lesser `configured` and is not.** It means an id did not
+  resolve. Shipping it unread is shipping a procedure nobody verified.
+- **A playbook per declared script grows the estate for nothing.** `build` and `test` are
+  one command each; the derivation deliberately proposes nothing for them.
+
+## Do NOT
+
+- Do NOT write `grade: configured` for an id you did not resolve in the tree.
+- Do NOT invoke a wrapper script when it points at a generator — invoke the generator.
+- Do NOT infer an Nx or Plop generator from a lockfile or a dependency, and do NOT hand a
+  Make / just / nox target a `configured` grade this release cannot resolve — report the
+  gap; that is the decision, not a shortfall to paper over.
+- Do NOT write a playbook for a one-off, or for a procedure the repository does not
+  actually repeat.
+- Do NOT `--write` a proposal set you have not read.
+
+## When NOT to use this
+
+- The repository has no generators, no task runner, and a handful of one-line scripts —
+  there is no repeated procedure to encode, and a playbook per npm script is a rename.
+- The procedure is a **one-off**. A playbook is for something done repeatedly the same way.
+- The question is *how should this be built in general* — that is the shipped skill's job,
+  and a playbook that answers it is a generic skill in the wrong directory.
+
+## See also
+
+- [ADR-244](../../../docs/decisions/ADR-244-playbook-is-a-sixth-context-type.md) — the artefact class, its grades, its home, and the two deferred kinds.
+- [`standards-from-config`](../standards-from-config/SKILL.md) — the Class-A rule this applies to procedure rather than to style.
+- [`context-document`](../context-document/SKILL.md) — the contexts machinery a playbook reuses as its sixth type.
+- [`command-writing`](../command-writing/SKILL.md) — the numbered-step shape the body follows.

package/dist/agent-src/skills/playwright-testing/SKILL.md

@@ -7,6 +7,9 @@ workspaces:
   - engineering
 packs:
   - engineering-base
+triggers:
+  - phrase: "playwright spec"
+  - phrase: "playwright test"
 ---
 
 # playwright-testing

package/dist/agent-src/skills/privacy-review/SKILL.md

@@ -11,6 +11,9 @@ workspaces:
   - engineering
 packs:
   - engineering-base
+triggers:
+  - phrase: "gdpr-safe"
+  - phrase: "pii redaction"
 ---
 
 # privacy-review

package/dist/agent-src/skills/prompt-engineering-image/SKILL.md

@@ -12,6 +12,9 @@ trust:
   level: experimental
 install:
   removable: true
+scope:
+  write: []
+  verification_reason: "execution declares no handler, so this skill runs nothing of its own — every write is the calling agent's, under the rules that govern it. No command can prove a scope the skill never executes."
 execution:
   type: manual
 ---

package/dist/agent-src/skills/prompt-optimizer/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: prompt-optimizer
-description: "Use when the user wants a prompt optimized for ChatGPT, Claude, Gemini, or another AI — 'make this prompt better', 'optimize for ChatGPT', 'rewrite my prompt' — even without saying 'optimize'."
+description: "When the user wants a prompt optimized for ChatGPT, Claude, Gemini, or another AI — 'make this prompt better', 'optimize for ChatGPT', 'rewrite my prompt' — even without saying 'optimize'."
 domain: product
 workspaces:
   - agent-config-maintainer

package/dist/agent-src/skills/quality-tools/SKILL.md

@@ -3,6 +3,11 @@ model_tier: medium
 name: quality-tools
 description: "Use when PHPStan, Rector, or ECS output appears — \"phpstan says mixed\", type errors, \"fix code style\", \"run rector\" — even when Eloquent/Laravel/model code is also mentioned."
 domain: quality
+scope:
+  write:
+    - pattern: "**"
+      access: "write"
+  verification_reason: "the project's own formatters and fixers rewrite source in place, and WHICH paths is decided by the consumer's tool config rather than by this skill. A narrower glob would be a guess about a tree this package does not own."
 execution:
   type: assisted
   handler: shell

package/dist/agent-src/skills/react-shadcn-ui/SKILL.md

@@ -12,6 +12,13 @@ trust:
 install:
   default: false
   removable: true
+scope:
+  write:
+    - pattern: "components/ui/**"
+      access: "create"
+    - pattern: "components.json"
+      access: "write"
+  verification_command: "npx shadcn@latest add <component> --dry-run"
 execution:
   type: assisted
   handler: shell
@@ -164,6 +171,40 @@ registries / install-with-natural-language over MCP; configure per the
 dependency. Decision note: **CLI path = default + universal; MCP path = opt-in
 when the user has it configured; registry-JSON literacy underpins both.**
 
+## Publish a registry — the library as a source others install from
+
+The sections above **consume** a registry. This one **publishes** one: a component library in
+this repository can expose its own components the same way, so a consumer installs them with
+the tool they already use instead of copying files.
+
+1. **Author `registry.json`** at the library root — the index — and one
+   `registry-item.json` per exposed component, each naming its files, its
+   `registryDependencies`, and its `cssVars` when it carries token requirements.
+2. **Build** to `public/r` with the registry build command. **The installer gate applies
+   here exactly as it does to `add`**: propose it, run `--dry-run` first, and let the user
+   confirm. A build writes files, so nothing about it being "our own" registry lifts the
+   gate.
+3. **The consumer adds a `registries` map entry** pointing at the published index; from then
+   on `@ns/item` resolves through it.
+
+**Two registry item types are FORBIDDEN**, deprecated in v4: `registry:build` and
+`registry:mcp`. Use **`registry:base`** and **`registry:font`** instead. Writing either
+deprecated type produces an item the current CLI does not understand, and the failure surfaces
+at the consumer rather than at authoring time.
+
+**`dependencies` in a registry item never names `react` or `react-dom`.** They are peers of
+the consuming app, and a registry item that installs its own copy reproduces the "invalid hook
+call" failure one layer up — see
+[`js-library-packaging`](../js-library-packaging/SKILL.md). `check_package_surface` enforces
+this over a registry file.
+
+> **Provenance.** The registry-publishing shape and the deprecated-type list come from an
+> external plugin reference's component-CLI skill, read at a pinned revision. The source is
+> deliberately not named here, per
+> [`source-confidentiality`](../../rules/source-confidentiality.md): a shipped artifact does
+> not carry derivation attribution to a named external project. The identifier and revision
+> stay with the maintainer-side record.
+
 ## Procedure: render a shadcn/ui component for the design brief
 
 ### Step 0: Inspect
@@ -277,27 +318,17 @@ current state on the next polish round.
 
 When `DESIGN.md` declares `## Taste Dials`, honour them: Variance → layout-family spread + asymmetry tolerance; Motion → animation budget + reduced-motion posture; Density → spacing scale + information-per-viewport. Absent → follow the design brief's inferred dials.
 
-## Component workshop (Storybook) — when the library is large enough
-
-The generic "isolate + document reusable components" principle lives in
-[`fe-design`](../fe-design/SKILL.md) § Component Architecture; this is the React
-carve-out for the tool-specific part.
-
-- **When it pays off** — a real, growing shared-component library (roughly: more
-  than a handful of reused primitives, multiple consumers, ongoing UI work).
-  Storybook makes each component discoverable, reviewable in isolation, and
-  reused instead of re-invented. **Skip it** for a small surface of one-off
-  components — the setup + maintenance is not worth it yet.
-- **Story per reusable primitive, not per screen** — a story covers a component
-  and its states (default / loading / empty / error / dark), mirroring the
-  Step 3 state-coverage matrix. Screens are composed, not story-fied.
-- **Reuse the token layer** — stories render under the same semantic tokens +
-  `.dark` class; never hardcode a preview theme (same token discipline as Step 2).
-- **A11y in-workshop** — run the a11y addon so the isolation catches contrast /
-  role / focus issues before the component reaches a screen.
-- Do NOT let stories drift from the component API — a story that props-drills
-  values the component no longer accepts is stale documentation; keep them beside
-  the component and update them in the same change.
+## Component workshop (Storybook) — pointer
+
+The workshop discipline (one concept per story, `@summary` on every export, stories run as
+tests, the `!manifest` tag, the opt-in MCP channel) lives in
+[`storybook-workshop`](../storybook-workshop/SKILL.md). It is stack-agnostic and was lifted
+out of here rather than duplicated beside it.
+
+What stays React-specific and therefore stays here: the state-coverage matrix in Step 3 that
+the story set is derived from, the token discipline of Step 2 that stories render under, and
+the `(rule, selector, severity)` a11y shape in § Review pass that the workshop's validate
+step writes into.
 
 ## Security constraints
 

package/dist/agent-src/skills/readme-reviewer/SKILL.md

@@ -3,6 +3,9 @@ model_tier: high
 name: readme-reviewer
 description: "Use when reviewing a README for accuracy, usability, and alignment with the actual repository. Detects invented content, broken setup steps, and structural issues."
 domain: quality
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal

package/dist/agent-src/skills/readme-writing/SKILL.md

@@ -3,6 +3,9 @@ model_tier: medium
 name: readme-writing
 description: "Use when creating, rewriting, or significantly improving a README based on the actual repository structure, commands, and intended audience."
 domain: process
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal

package/dist/agent-src/skills/readme-writing-package/SKILL.md

@@ -3,6 +3,9 @@ model_tier: medium
 name: readme-writing-package
 description: "Use when creating or rewriting a README for a reusable package or library. Focus on installability, minimal usage example, compatibility, and developer onboarding."
 domain: process
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal