@event4u/agent-config 14.10.0 → 14.12.0

package/dist/agent-src/skills/md-language-check/SKILL.md

@@ -3,6 +3,9 @@ model_tier: lite
 name: md-language-check
 description: "Use BEFORE saving any .md under .augment/, dist/agent-src*/, or agents/ — scans umlauts, German function words, and German phrases outside DE:/EN: anchor blocks. Hard gate per language-and-tone."
 domain: process
+scope:
+  write: []
+  verification_reason: "the declared command is a read-only checker: grep -c 'writeFileSync|mkdirSync|appendFileSync' src/scripts/check_md_language.ts returns 0. Absence of a write is not something a command can prove."
 execution:
   type: assisted
   handler: shell

package/dist/agent-src/skills/monorepo-workspace/SKILL.md

@@ -0,0 +1,149 @@
+---
+model_tier: medium
+name: monorepo-workspace
+description: "Use to orient in a monorepo — which package manager, which workspaces, which task runner and its tasks — derived from the repository's own config and the runner's own listing, never guessed."
+domain: engineering
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+---
+
+# Monorepo workspace orientation
+
+Read-only. Answers "what is this repository, structurally" before anything
+edits it: the package manager, the workspace list, the task runner, and the
+tasks the runner actually defines.
+
+Every answer is a **pointer plus a digest** — the file that states the fact and
+a short quotation of it — never a flattened claim. This is the Class-A shape
+[`standards-from-config`](../standards-from-config/SKILL.md) uses, and for the
+same reason: a digest the reader can check beats a summary they have to trust.
+
+## When to use
+
+- Before editing anything in a repository with `apps/`, `packages/`, `libs/`,
+  a `pnpm-workspace.yaml`, a `turbo.json`, or an `nx.json`.
+- "Which packages depend on `@org/ui`?", "what does `build` run here?",
+  "which workspace owns this file?"
+- Before a cross-workspace change, as the input to
+  [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md) § Monorepo.
+
+**Not** for authoring a component or picking a UI idiom — the stack detector
+already reports the frontend workspace as `state.stack.scope_root`, and the UI
+lane routes on that.
+
+## Procedure
+
+### 1. Package manager — from the declaration, then the lockfile
+
+`packageManager` in the root `package.json` is the declaration and wins when
+present (it is what Corepack enforces). Otherwise infer from the lockfile:
+`pnpm-lock.yaml` → pnpm, `yarn.lock` → yarn, `bun.lock` / `bun.lockb` → bun,
+`package-lock.json` → npm. Two lockfiles is a finding, not a tie to break —
+report both and stop.
+
+### 2. Workspaces — from the declarative source
+
+In precedence order, and report which one answered:
+
+| Source | Field |
+|---|---|
+| `pnpm-workspace.yaml` | `packages:` |
+| `package.json` | `workspaces` (array, or `{ packages: [...] }`) |
+| `nx.json` beside per-project `project.json` | Nx infers; use step 3 |
+| `lerna.json` | `packages` |
+
+Globs are globs: `packages/*` means every direct child carrying a manifest, not
+every directory.
+
+### 3. Task runner — ask the runner, do not read its config
+
+When a runner is present, its own listing is the source of truth, because a
+runner infers projects that appear in no config file you can read:
+
+```bash
+# Nx — never read project.json by hand for the project list
+npx nx show projects
+npx nx show project <name>   # targets for one project
+
+# Turborepo
+npx turbo ls
+```
+
+Print the task list **with each task's `description` field when it has one** —
+`turbo.json` tasks carry an optional `description`, and it is the only place the
+repository says what a task is *for* rather than what it depends on.
+
+### 4. No runner on PATH — walk the manifests and say so
+
+`turbo` and `nx` are the **consumer project's** binaries, invoked through its
+own `npx` / `pnpm dlx`. This package never installs them. When neither
+resolves, build the graph from the manifests instead: for each workspace, read
+its `dependencies` / `devDependencies` and keep the entries whose names match
+another workspace's `name`. That is the dependency graph, and it is complete
+for `workspace:`-linked packages.
+
+State plainly that the listing came from manifests rather than the runner — an
+inferred target list can miss runner-inferred targets. This is the posture
+[`react-shadcn-ui`](../react-shadcn-ui/SKILL.md) already takes for the shadcn
+CLI; the stop condition is `missing-tool-handling` (never install it silently,
+never fake the output).
+
+## Output format
+
+An orientation report MUST contain, in order:
+
+1. **The package manager**, with the source that decided it — `packageManager`
+   when declared, otherwise the lockfile filename. Two lockfiles is reported as
+   a finding, never resolved by picking one.
+2. **The workspace table** — one row per workspace: directory path, package
+   `name`, and its workspace-internal dependencies. Both the path and the name,
+   because the graph links on `name` and humans talk in paths.
+3. **The task runner and its tasks**, each task with its `description` field
+   when the config carries one, and its `dependsOn` when it has one.
+4. **A source line** naming which of the two paths produced the listing — the
+   runner's own (`turbo ls` / `nx show projects`) or the manifest walk. When it
+   was the manifest walk, the line also says that runner-inferred targets may be
+   missing.
+```
+Package manager: pnpm@9.12.0   [package.json#packageManager]
+Workspaces (2)                 [pnpm-workspace.yaml#packages: apps/*, packages/*]
+  apps/web        @fixture/web   deps: @fixture/ui
+  packages/ui     @fixture/ui    deps: —
+Task runner: turbo             [turbo.json#tasks]
+  build   "Compile every workspace to its dist/ output."   dependsOn: ^build
+  lint    "Run the workspace linter over its own sources."
+  test    "Run the workspace unit tests."                  dependsOn: ^build
+Source: turbo ls  (runner listing)
+```
+
+When the runner was absent, the last line reads
+`Source: manifest walk (turbo not on PATH — runner-inferred targets may be missing)`.
+
+## Gotcha
+
+- A workspace's directory name and its package `name` are different keys. The
+  graph links on `name`; humans talk in paths. Print both.
+- `packages/eslint-config` is a workspace. It is not a frontend, and it is not
+  a scope candidate for a UI change.
+- An `nx.json` with no `workspaces` key in `package.json` is normal, not broken.
+- `packageManager` pinning a manager whose lockfile is absent means the install
+  was never run with it. Report the mismatch.
+
+## Do NOT
+
+- Read `project.json` by hand to enumerate Nx projects — `nx show projects` is
+  the source of truth and includes inferred targets.
+- Install `turbo` or `nx` to answer a question. They are the consumer's
+  binaries; when absent, walk the manifests and say that is what you did.
+- Flatten the answer into prose without the file that states it.
+- Report a workspace list from the conventional directories when a declarative
+  source exists — the declaration is authoritative, and the two can disagree.
+
+## See also
+
+- [`standards-from-config`](../standards-from-config/SKILL.md) — the Class-A pointer+digest shape this follows.
+- [`workspace-link`](../workspace-link/SKILL.md) — when a cross-workspace import will not resolve.
+- [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md) — § Monorepo consumes this graph.
+- [`monorepo-antipatterns`](../../../docs/guidelines/monorepo-antipatterns.md) — diff-detectable task-graph mistakes.

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

@@ -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/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/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/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/project-analysis-core/SKILL.md

@@ -129,6 +129,29 @@ Check:
 6. Known uncertainties
 7. Recommended next specialist skill
 
+## Improvement mode — check for an existing artefact first
+
+Before a full analysis, ask whether this target has already been analysed:
+
+```bash
+npx tsx node_modules/@event4u/agent-config/src/scripts/select_analysis_mode.ts "<target>"
+```
+
+`full` → run steps 1-8 as written. `delta` → **read the named artefact first**,
+then analyse only what it does not cover: gaps, sections the tree has moved past,
+patterns that are new since it was written. The output format is unchanged; the
+reading is narrower.
+
+This changes **write economics only**. A concept page is a hypothesis cache,
+never truth — the delta path re-verifies every structural claim it carries
+forward against a live source, exactly as a full run would
+([`source-discovery-gate`](../../rules/source-discovery-gate.md) § v1↔v2
+isolation). A cheaper write is not a licence to trust a cached read, and
+"the page already says so" is not evidence.
+
+An empty page counts as absent: it carries no conclusions to delta against, so
+the router answers `full`.
+
 ## Knowledge capture (`convention_detected` events)
 
 An architecture map or stack finding that recurs (a naming convention,

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/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