@event4u/agent-config 9.8.0 → 9.10.0

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

@@ -106,14 +106,14 @@ and council-pass notes capture the *why*; checkboxes capture the
 Iron Law #2.
 
 **Bind a `verify:` on behavior-changing steps.** A step that changes
-behavior (a new guard, migration, wired endpoint, mechanism edit) SHOULD
-carry a narrow `verify:` command in an inline annotation —
-`- [ ] Wire the guard <!-- verify: task test -- --filter=GuardTest -->` —
-so its `[x]` flip is machine-checkable, not just agent-asserted (template
+behavior (a new guard, a migration, a wired endpoint, a mechanism edit)
+SHOULD carry a narrow `verify:` command in an inline annotation —
+`- [ ] Wire the guard <!-- verify: task test -- --filter=GuardTest -->`
+— so its `[x]` flip is machine-checkable, not just agent-asserted (template
 rule 23; enforced by the flip-guard). Bind it only where a single narrow
 command (targeted test / grep / build of the touched surface) proves the
-step; leave it off doc-only / prose steps, never the full CI suite
-(`roadmap-ci-steps-policy`).
+step; leave it off doc-only / prose steps and never make it the full CI
+suite (`roadmap-ci-steps-policy`).
 
 ### 4b. Declare the execution mode (frontmatter)
 
@@ -121,22 +121,23 @@ Every new roadmap declares how a later `/roadmap:process-*` run should
 interact, via `execution.mode:` in frontmatter — `autonomous` (one
 run-start execution-contract confirmation, then uninterrupted except
 safety floors), `phase-checkpoints` (halt + compact status per phase
-boundary), or `interactive` (absent-field default; omit field).
-Semantics: [`templates/roadmaps.md` rule 19](../../templates/roadmaps.md);
+boundary), or `interactive` (absent-field default; omit the field).
+Semantics: [`templates/roadmaps.md` rule 18](../../templates/roadmaps.md);
 run mechanics:
 [`roadmap-execution-contract`](../../contexts/execution/roadmap-execution-contract.md).
-Field is intent, never a permission grant — grants happen only at the
-run-start contract. `/roadmap:create` asks this as one question; when
-authoring a roadmap directly, ask it too (follow-ups pre-select the
-parent's mode but always re-ask). **Author every roadmap to be
+The field is intent, never a permission grant — grants happen only at
+the run-start contract. `/roadmap:create` asks this as one question;
+when authoring a roadmap directly, ask it too (follow-ups pre-select
+the parent's mode but always re-ask). **Author every roadmap to be
 autonomy-capable (§ 4c); recommend `autonomous`** when evidence,
 rollback coverage, and risk profile support unattended execution —
-mode remains the user's risk preference, not a property of the
-document. **Authoring duty for `autonomous`:**
-steps must be precise enough to clear `ask-when-uncertain` vague-
-trigger patterns — vagueness resolved at authoring time, not mid-run;
-pre-existing `[~]` items in an `autonomous` roadmap draw a lint
-warning (they guarantee the archival gate fires later).
+the mode remains the user's risk preference, not a property of the
+document. **Authoring duty for `autonomous`:** steps must be precise
+enough to clear the
+`ask-when-uncertain` vague-trigger patterns — vagueness is resolved at
+authoring time, not mid-run; pre-existing `[~]` items in an
+`autonomous` roadmap draw a lint warning (they guarantee the archival
+gate fires later).
 
 ### 4c. Autonomy-first — zero human gates by default
 
@@ -145,8 +146,8 @@ Canonical rule:
 Default human-checkpoint count: **zero**. Every step is
 agent-executable — `- [ ] User verifies X` steps and "Review /
 Sign-off" phases are authoring bugs; replace each with an
-agent-verifiable check (command, targeted test, grep). Never restate
-run-time safety floors as steps.
+agent-verifiable check (a command, a targeted test, a grep). Never
+restate run-time safety floors as steps.
 
 Gate-test before any checkpoint: *"Could the agent clear this with a
 tool or command during the run?"* Yes → step, not gate. No →
@@ -155,8 +156,8 @@ structured `## Blockers` entry (§ 5b), distinguishing per rule 22:
 authorization, billable spend, contested decision) vs **external
 blocker** (agent cannot resolve but CAN probe status — CI run, package
 release, upstream PR; `Resolved when:` carries the probe, owner is
-not a human). Merge is never a completion requirement — may appear as
-a blocker only when later roadmap work depends on the merged state.
+not a human). Merge is never a completion requirement — it may appear
+as a blocker only when later roadmap work depends on the merged state.
 `lint_roadmap_complexity` warns on human-gate patterns in every mode.
 
 ### 5. Exit & rollback per phase
@@ -169,48 +170,51 @@ file exists, test passes — never "user reviews" / "looks good" (§ 4c).
 
 ### 5b. Blockers are structured, not free prose
 
-Gate only user or maintainer can clear — decision, external
-dependency, evidence threshold, kernel-budget soak window — records
-as `## Blockers` entry (`### blocker: <id>` with `Status` / `Owner` /
-`Blocks` / `What to do` / `Resolved when`), never a stray "blocked on
-X" sentence. Dashboard generator parses these into overview's
-`Blocker` column and per-roadmap breakdown. Full shape:
-[`templates/roadmaps.md` rule 20](../../agent-src/templates/roadmaps.md).
-Omit section entirely when roadmap has no such gate; run the § 4c
-gate-test before adding one.
+A gate only the user or a maintainer can clear — a decision, an
+external dependency, an evidence threshold, a kernel-budget soak
+window — is recorded as a `## Blockers` entry (`### blocker: <id>`
+with `Status` / `Owner` / `Blocks` / `What to do` / `Resolved when`),
+never a stray "blocked on X" sentence. The dashboard generator parses
+these into the overview's `Blocker` column and the per-roadmap
+breakdown. Full shape: [`templates/roadmaps.md` rule 20](../../agent-src/templates/roadmaps.md).
+Omit the section entirely when the roadmap has no such gate; run the
+§ 4c gate-test before adding one.
 
 ### 6. Step-marker semantics — pick `[~]` (defer) vs `[-]` (cancel) honestly
 
-Difference carries load when authoring (and especially when rewriting
-mid-flight):
+When authoring (and especially when rewriting a roadmap mid-flight),
+the difference between the two non-`[x]`-non-`[ ]` markers carries
+load:
 
 | Glyph | Semantic | When to use |
 |---|---|---|
-| `[~]` | **deferred** — planned, will be done, just not in this roadmap | Scope-cut + clear intent to revisit. Triggers Iron Law 3 follow-up flow before archive — info preservation enforced. |
-| `[-]` | **cancelled** — won't be done at all | Scope rejected, design changed, replaced by another roadmap. Decision final; no follow-up implied. |
+| `[~]` | **deferred** — planned, will be done, just not in this roadmap | Scope-cut + clear intent to revisit. Triggers the Iron Law 3 follow-up flow before archive — info preservation is enforced. |
+| `[-]` | **cancelled** — won't be done at all | Scope rejected, design changed, replaced by another roadmap. The decision is final; no follow-up implied. |
 
-Optional inline annotations on same line:
+Optional inline annotations live on the same line:
 
 ```markdown
-- [~] Migrate bulk-import job to chunked dispatch. <!-- deferred: ops capacity in Q3 -->
+- [~] Migrate the bulk-import job to chunked dispatch. <!-- deferred: ops capacity in Q3 -->
 - [-] Wire SQS retry topic. <!-- cancelled: superseded by Lambda DLQ in road-to-event-bridge -->
 ```
 
-Annotation for next human reader (and for migration procedure when
-[`roadmap-management`](../roadmap-management/SKILL.md) spawns a follow-up).
-Bare `[~]` / `[-]` allowed; annotated preferred.
+The annotation is for the next human reader (and for the migration
+procedure when [`roadmap-management`](../roadmap-management/SKILL.md)
+spawns a follow-up). Bare `[~]` / `[-]` is allowed; annotated is
+preferred.
 
 ### 7. Follow-up roadmaps spawn from deferred items — frontmatter shape
 
-When parent roadmap closes with `[~]` items,
+When a parent roadmap closes with `[~]` items, the
 [`roadmap-management`](../roadmap-management/SKILL.md) skill spawns a
-follow-up. Authors and reviewers must recognise the shape:
+follow-up. Authors and reviewers must know the shape so they can
+recognise it:
 
 ```markdown
 ---
 complexity: lightweight
 status: draft                      # optional — draft hides from dashboard
-parent_roadmap: <parent-slug>      # back-link to archived source
+parent_roadmap: <parent-slug>      # back-link to the archived source
 ---
 
 # Roadmap: Follow-up to <parent-title>
@@ -223,24 +227,25 @@ This roadmap collects items deferred from
 [`agents/roadmaps/archive/<parent-slug>.md`](../archive/<parent-slug>.md).
 { … original phases preserved verbatim … }
 
-<!-- For option 2 (ready + blocked), add as body note, NOT in frontmatter: -->
-> Blocked until <condition>. Execution starts when condition clears.
+<!-- For option 2 (ready + blocked), add this as a body note, NOT in frontmatter: -->
+> Blocked until <condition>. Execution starts when the condition clears.
 ```
 
-Two states author picks between (mirrors Iron Law 3 numbered-options
-block in [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)):
+Two states the author picks between (mirrors the Iron Law 3
+numbered-options block in [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)):
 
-- **`status: draft`** → hidden from `agents/roadmaps-progress.md` until
-  flipped. Use for items user wants captured but not surfaced to
-  active backlog yet.
-- **`status: ready` (default; omit key)** plus body `> Blocked until …`
-  note → visible in dashboard, execution gated by documented
-  condition. Blocking is body convention, not enforced by dashboard
-  generator — readers honor the note.
+- **`status: draft`** → hidden from `agents/roadmaps-progress.md`
+  until flipped. Use for items the user wants captured but not
+  surfaced to the active backlog yet.
+- **`status: ready` (default; omit the key)** plus body
+  `> Blocked until …` note → visible in the dashboard, execution
+  gated by the documented condition. The blocking is a body
+  convention, not enforced by the dashboard generator — readers
+  honor the note.
 
-Follow-up is **not** authored from scratch — deferred steps copied
-verbatim (with phase context). Preserves plan exactly as author
-originally wrote it.
+The follow-up roadmap is **not** authored from scratch — the
+deferred steps are copied verbatim (with their phase context). This
+preserves the plan exactly as the author originally wrote it.
 
 ### 8. Source-derived & capability-adoption roadmaps (conditional)
 
@@ -297,10 +302,16 @@ to every roadmap you author.
 5. Is content duplicated from another roadmap (supersession instead)?
 6. Any human-gate steps or sign-off phases (§ 4c violation) —
    agent-verifiable check or structured blocker instead?
-7. *Source-derived/adoption only (§ 8):* gap-table (`KEEP`/`FOLD`/`CUT`)
-   behind the scope? `## Provenance` block with `ENC1:` link? inlined
-   council convergence? anti-dump acceptance criterion? (Internally
-   originated → these must be **absent**, not empty.)
+7. *Source-derived/adoption only (§ 8):* is there a `KEEP`/`FOLD`/`CUT`
+   gap-table behind the scope, a `## Provenance` block with an `ENC1:`
+   link, inlined council convergence, and an anti-dump acceptance
+   criterion? (Internally-originated roadmap → these must be **absent**,
+   not empty.)
+8. *Inbox-sourced only:* if the roadmap consumed an `agents/tmp/` file as
+   its input, is that file moved to `agents/tmp.old/<name>` in the SAME
+   reply, with the Source line pointing at the `tmp.old/` path? (Per
+   `agents-layout § User Inbox Workflow`. Move only the explicitly named
+   input file(s); never sweep the rest of the inbox.)
 
 ## Do NOT
 
@@ -324,7 +335,7 @@ to every roadmap you author.
   `quality.local_auto_run: false` — blocked by
   `task lint-roadmap-ci-steps` per
   [`roadmap-ci-steps-policy`](../../rules/roadmap-ci-steps-policy.md).
-  Reword as narrow verifications, or mark with
+  Reword as narrow verifications, or mark the step with
   `<!-- carve-out: new-gate-verification -->` when it verifies a NEW
   gate this roadmap introduces.
 * Use ALL-CAPS Iron-Law fenced blocks — those belong in
@@ -332,7 +343,7 @@ to every roadmap you author.
   rules, not roadmaps.
 * Adopt items from an external source / harvest **without a
   `KEEP`/`FOLD`/`CUT` gap-table** against the existing surface (§ 8) —
-  skill dump, not integration.
+  that is a skill dump, not integration.
 * Add a `## Provenance` block (or gap-table) to an **internally
   originated** roadmap — § 8 is conditional; an empty Provenance section
   is noise (template rule 19).
@@ -348,8 +359,8 @@ to every roadmap you author.
 - **Vague goal sentence** — "Improve roadmap quality" forces every
   reader to re-derive intent and blocks decidable acceptance.
 - **Human-gate steps sprinkled through phases** — each one interrupts
-  an autonomous run; dashboard counts open work the agent can never
-  close. § 4c: agent-verifiable check or structured blocker.
+  an autonomous run, and the dashboard counts open work the agent can
+  never close. § 4c: agent-verifiable check or structured blocker.
 - **Restating template rules** — pasting structural rules into the
   roadmap body creates two sources of truth that drift over months.
 - **Version numbers in phase names** — `Phase 1 — v1.8.0` violates
@@ -362,14 +373,14 @@ to every roadmap you author.
   operations the user has not authorized. Roadmap completion is
   decoupled from delivery; ship-the-PR is its own decision.
 - **Adopting an external suggestion verbatim** — a harvest/suggestion
-  roadmap copying the source's item list without the § 8
-  `KEEP`/`FOLD`/`CUT` audit becomes a skill dump: existing items get
-  rebuilt, fold-candidates spawn duplicates. The gap-table is the
-  integration discipline.
-- **Council-as-afterthought** — running council only *after* a contested
-  roadmap is written wastes the convergence: the plan still reads as
-  open questions. Source-derived/contested → council *first* (§ 8.B),
-  then author the verdicts.
+  roadmap that copies the source's proposed item list without the § 8
+  `KEEP`/`FOLD`/`CUT` audit becomes a skill dump: items that already
+  exist get rebuilt, items that should fold into an existing artefact
+  spawn a duplicate. The gap-table is the integration discipline.
+- **Council-as-afterthought** — running the council only *after* a
+  contested roadmap is written wastes the convergence: the plan still
+  reads as open questions. For source-derived/contested plans, council
+  *first* (§ 8.B), then author the verdicts.
 
 ## Examples
 

package/dist/agent-src/skills/rtk-output-filtering/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: rtk-output-filtering
-description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer) for 60-90% token savings. Covers installation, configuration, and usage patterns."
+description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer, third-party Apache-2.0; upstream reports 60-90% token savings). Covers installation, configuration, and usage patterns."
 domain: process
 execution:
   type: assisted
@@ -23,9 +23,17 @@ packs:
 
 ## What
 
-High-performance CLI proxy that reduces LLM token consumption by 60-90%
-on common dev commands through intelligent output filtering (whitespace, boilerplate,
+High-performance CLI proxy that reduces LLM token consumption on common dev
+commands through intelligent output filtering (whitespace, boilerplate,
 comments, duplicate log messages). Single Rust binary, <10ms startup overhead.
+**Third-party Apache-2.0 tool** (rtk-ai upstream — an external project, not part of this package).
+
+**Savings, honestly stated:** upstream reports 60-90% (their estimate —
+"actual savings vary"). agent-config's own scoped spot-measurement
+(2026-07-28, one repo, one macOS machine, 8-command corpus) landed at
+**33% overall, 0-57% per command** — verbose commands (`git status`,
+`git log`, `ls -la`) save ~55%, already-compact output (`--oneline`,
+`--stat`) passes through at ~0%. See `internal/bench/rtk-savings/RESULTS.md`.
 
 **Docs:** https://www.mintlify.com/rtk-ai/rtk
 **Repo:** https://github.com/rtk-ai/rtk
@@ -34,9 +42,9 @@ comments, duplicate log messages). Single Rust binary, <10ms startup overhead.
 
 Wrap any CLI command with `rtk`:
 ```bash
-rtk git status        # 80-92% savings
-rtk git log           # compact log output
-rtk cargo test        # 90% savings — only failures shown
+rtk git status        # verbose status → compact (measured ~55% here)
+rtk git log           # compact log output (measured ~55% here)
+rtk cargo test        # upstream: only failures shown
 rtk npm test          # same for JS/TS
 rtk docker compose ps # compact container status
 ```
@@ -70,12 +78,23 @@ outside onboarding, follow the Installation section below and set
 
 ## Installation (on-demand)
 
-Invoked by `/onboard` when rtk is not on `PATH`, or on explicit user
-request. Never fire unsolicited.
-
-1. Ask which installer to use (macOS → Homebrew; otherwise Cargo).
-2. Run the installer. On success:
-   1. `rtk --version` to verify.
+Invoked when rtk is not on `PATH` and the user explicitly asks to install
+it. Never fire unsolicited.
+
+1. Offer the verified per-OS install path (same map as
+   `src/install/rtkDetection.ts` / `docs/contracts/rtk-detection.md`):
+   - macOS → `brew install rtk` (official homebrew-core formula)
+   - Linux → `curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh`
+     (installs to `~/.local/bin`)
+   - Windows → `winget install rtk-ai.rtk` (plus the documented ripgrep
+     dependency: `winget install BurntSushi.ripgrep.MSVC`); winget-less
+     images use the upstream `rtk-x86_64-pc-windows-msvc.zip` release.
+   **NEVER `cargo install rtk`** — the bare crates.io `rtk` crate is the
+   unrelated Rust Type Kit, not Rust Token Killer.
+2. Run the installer only on explicit confirmation. On success:
+   1. `rtk gain` to verify IDENTITY (the savings dashboard prints "RTK
+      Token Savings" only on Rust Token Killer — `rtk --version` cannot
+      distinguish the two same-name tools).
    2. `rtk init --global` to enable auto-rewrite hooks.
    3. Apply **Post-Install Setup** below (telemetry, tee, audit logging).
    4. Generate project-local filters (see Post-Install Setup).

package/dist/agent-src/skills/rule-refactor/SKILL.md

@@ -80,13 +80,13 @@ For each approved verdict:
 
 * **merge** → rewrite the surviving rule to cover both domains;
   delete the absorbed one; update any `routes_to:` references.
-* **delete** → remove the file from `.agent-src.uncondensed/rules/`
+* **delete** → remove the file from `src/rules/`
   and the corresponding `dist/agent-src/rules/` projection.
 * **move-to-context** → extract the body into
-  `.agent-src.uncondensed/contexts/<area>/<name>.md`, replace the
+  `src/agent-src/contexts/<area>/<name>.md`, replace the
   rule body with the obligation + a `load_context:` pointer.
 * **promote-to-skill** → create
-  `.agent-src.uncondensed/skills/<name>/SKILL.md`, replace the rule
+  `src/skills/<name>/SKILL.md`, replace the rule
   with an auto-trigger stub that routes to it (or delete the rule
   entirely if the skill's own trigger suffices).
 
@@ -104,7 +104,7 @@ canonical sequence) before pushing.
 
 ### 7. Record the delta
 
-Append a snapshot to `agents/.augment-budget-history.jsonl`:
+Append a snapshot to `agents/runtime/.augment-budget-history.jsonl`:
 
 ```bash
 ./scripts-run src/scripts/measure_augment_budget --trend-append

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

@@ -0,0 +1,92 @@
+---
+model_tier: medium
+name: schema-review
+description: "Use when reviewing a migration diff or schema change for scale hazards — indexes, unsafe migrations, unbounded growth, N+1. Triggers on 'review this migration', 'will this scale'."
+domain: engineering
+workspaces:
+  - engineering
+packs:
+  - scale-discipline
+trust:
+  level: professional
+install:
+  default: false
+  removable: true
+---
+
+# schema-review
+
+## When to use
+
+- A migration diff, new migration file, or schema change is under review
+  and the question is scale-shaped: indexes, reversibility, growth,
+  query patterns against the new columns.
+- The user asks "will this scale", "review this migration", "check the
+  schema", or a PR touches `migrations/`, `schema.prisma`, or raw `.sql`
+  migration files.
+- NOT for runtime performance analysis of live traffic (no APM here —
+  route to `performance-analysis`) and NOT for authoring a new migration
+  from scratch (route to `laravel-migration` or the stack-native tool,
+  then come back with the diff).
+
+## Procedure
+
+1. **Detect the stack surface** in the diff: Laravel migrations
+   (`database/migrations/*.php`), Prisma (`schema.prisma` +
+   `prisma/migrations/**/migration.sql`), raw SQL (`*.sql`). One diff can
+   carry several.
+2. **Run the deterministic linter** on the touched files plus the query
+   surface that references the changed tables:
+
+   ```bash
+   npx tsx node_modules/@event4u/agent-config/src/scripts/lint_persistence.ts -- --dir <path> [--stack eloquent|prisma|raw-sql] --format json
+   ```
+
+   The linter emits `gate` findings (pattern-detected: F1 N+1, F2
+   index-parity, F3 unbounded reads, F6 migration-safety, F7
+   growth-budget, F8 audit-coverage, F9 sync-in-handler, F11 non-durable
+   async) and `advice` findings (heuristics — never treat as blockers).
+3. **Walk the gap table** — for every `gate` finding decide: fix, or
+   waiver with a reason (`// no-index: <reason>`, `// sync-required:
+   <reason>`, `-- no-retention: <reason>`, …). An empty waiver reason is
+   itself a finding.
+4. **Check the R-A6/R-A7 invariants by hand** where the linter is blind:
+   reversibility of data transformations, retention policy for any new
+   append-only table (the `-- retention: <policy>` line), backfill plan
+   for new NOT NULL columns on large tables.
+5. **Report waiver density neutrally** — count waivers per rule; state
+   both readings (informed exceptions vs rule misfit) and let the human
+   decide. Density alone is never a verdict.
+
+## Output
+
+The review MUST contain:
+
+1. **Gap table** — one row per finding: `rule · file:line · finding ·
+   proposed action (fix | waiver | accepted)`, gate findings first,
+   advice findings clearly marked as advice.
+2. **Waiver-density line** — `N waivers across M findings` with the
+   two-reading note (informed exceptions vs rule misfit).
+3. A one-line verdict: ready / needs fixes / needs human schema decision
+   — never a bare "looks good" without the table.
+
+## Gotcha
+
+- The linter proves **pattern presence**, not instance-level correctness
+  — a flagged `Http::` call in a controller may be legitimately sync
+  (then it gets a `// sync-required:` waiver with a reason), and a clean
+  run does not prove the schema scales. Say what was checked, not more.
+- Prisma's `@relation` fields are indexed implicitly on some connectors
+  and not on others — when the linter reports a missing FK index on a
+  Prisma model, verify the connector before calling it a defect.
+
+## Do NOT
+
+- Do NOT gate a review on `advice`-tier findings (F4 denormalization,
+  F10 event-decoupling heuristics) — they are review inputs, not
+  blockers.
+- Do NOT strip or rewrite existing waivers — surface stale-looking ones
+  and ask.
+- Do NOT invent index recommendations for columns the query surface
+  never filters or orders by — index parity cuts both ways; unused
+  indexes cost write throughput.

package/dist/agent-src/skills/schema-review/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+    "skill": "schema-review",
+    "last_eval": "2026-07-27",
+    "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers DE+EN phrasings for reviewing a migration/schema diff for scale hazards. Should-not-trigger covers near-miss neighbours: authoring a migration (laravel-migration), live-traffic performance (performance-analysis), audit-tier selection (history-design), generic code review.",
+    "queries": [
+        { "q": "review this migration for missing indexes before I merge", "trigger": true },
+        { "q": "will this schema change scale to 100k rows?", "trigger": true },
+        { "q": "prüfe meine Migration auf Skalierungsprobleme", "trigger": true },
+        { "q": "check the new schema.prisma diff for unsafe changes", "trigger": true },
+        { "q": "does this ALTER TABLE need CONCURRENTLY and a default?", "trigger": true },
+        { "q": "create a migration that adds a status column to orders", "trigger": false },
+        { "q": "the dashboard endpoint is slow in production, profile it", "trigger": false },
+        { "q": "which audit log mechanism should we use for tenants?", "trigger": false },
+        { "q": "review my pull request for code quality", "trigger": false },
+        { "q": "wie lege ich einen Index in MySQL an?", "trigger": false }
+    ]
+}

package/dist/agent-src/skills/screenshot-hygiene/evals/triggers.json

@@ -0,0 +1,52 @@
+{
+    "skill": "screenshot-hygiene",
+    "last_eval": "2026-07-30",
+    "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger covers DE + EN phrasings for capturing and anonymising a screenshot that is about to ship into documentation — risk tier, OCR detection, deterministic redaction, the pre-embed human gate. Should-not-trigger covers the near-miss neighbours (image analysis, image editing/inpaint, image generation, the provided-design spec path, PII scrubbing on text surfaces) whose vocabulary overlaps.",
+    "queries": [
+        {
+            "q": "capture a screenshot of the admin dashboard for the feature docs",
+            "trigger": true
+        },
+        {
+            "q": "I want to embed a screenshot of this settings page in the README — is it safe to ship?",
+            "trigger": true
+        },
+        {
+            "q": "redact the customer names and the local path in this screenshot before it lands in docs/media/",
+            "trigger": true
+        },
+        {
+            "q": "mach einen Screenshot für das Doku-Kapitel und anonymisiere vorher alles Sensible",
+            "trigger": true
+        },
+        {
+            "q": "can this dashboard screenshot go on the docs site, or does it leak PII?",
+            "trigger": true
+        },
+        {
+            "q": "analyse this character image feature by feature and diff it against the canon",
+            "trigger": false,
+            "note": "per-feature image analysis / canon drift, not doc-shipping anonymisation → image-analyser (this skill only borrows its OCR read)"
+        },
+        {
+            "q": "inpaint the background out of this photo and give me a couple of variations",
+            "trigger": false,
+            "note": "image editing / lossy inpaint — explicitly forbidden as a redaction method here → image-editing"
+        },
+        {
+            "q": "generate a banner image for the launch post",
+            "trigger": false,
+            "note": "image generation from a brief, not a captured screenshot → image-generation (brand assets → brand-asset-generation)"
+        },
+        {
+            "q": "here's a screenshot of the mockup — build the UI to match it 1:1",
+            "trigger": false,
+            "note": "a user-supplied screenshot used as a design spec to build against → design-fidelity (rule) / cross-source-consistency"
+        },
+        {
+            "q": "scrub the email addresses and tokens out of these log lines before we ship them",
+            "trigger": false,
+            "note": "PII redaction on a text surface (drafts / logs / exports), not inside an image → domain-safety-pii (rule)"
+        }
+    ]
+}

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

@@ -104,14 +104,13 @@ Telemetry / APM     → strip from request/response captures; allowlist headers.
 The scanning gates (Step 4) are the CI/pre-commit nets. The **earliest** gate is
 the agent itself: before it writes a credential into a tracked file or stages a
 commit, the [`secret-vcs-guard`](../../rules/secret-vcs-guard.md) rule runs the
-`secret_detector` library (`src/scripts/_lib/secret_detector.ts`) and, on a hit,
+`secret_detector` library and, on a hit,
 STOPS → shows the match (`file:line` · kind · masked · why) → asks via numbered
 options → offers the tiered alternative below. It never silently commits and
 never silently strips. VCS-agnostic: the same detector runs against the diff for
 git, SVN, and Mercurial (SVN/hg native hooks are server-side, a stronger but
-later net). The deterministic CI backstop is `check_secret_leak`
-(`src/scripts/check_secret_leak.ts`) — the agent gate is one layer, not the whole
-defense.
+later net). The deterministic CI backstop is `check_secret_leak` — the agent
+gate is one layer, not the whole defense.
 
 **False positives — audited allowlist, never a global mute.** Suppress a
 confirmed non-secret with an inline `# secret-allow` marker on the line, or a

package/dist/agent-src/skills/security-audit/SKILL.md

@@ -42,13 +42,18 @@ Do NOT use when:
 
 ### 0. False-positive gate — restate the claim before reporting
 
-Before any finding enters report, restate as one falsifiable sentence naming all three:
+Before any finding enters the report, restate it as one falsifiable sentence
+naming all three of:
 
-1. **Privilege level** — access attacker already has (anonymous, authenticated user, tenant admin, CI runner).
-2. **Execution context** — where vulnerable code runs (request handler, queue worker, sandboxed template, build step).
-3. **Attacker precondition** — concrete state or input attacker must control to trigger it.
+1. **Privilege level** — what access the attacker already has (anonymous,
+   authenticated user, tenant admin, CI runner).
+2. **Execution context** — where the vulnerable code runs (request handler,
+   queue worker, sandboxed template, build step).
+3. **Attacker precondition** — the concrete state or input the attacker must
+   control to trigger it.
 
-Any of the three not concretely nameable → **not a finding yet** — trace further or drop with one-line reason.
+If any of the three cannot be named concretely, the item is **not a finding
+yet** — trace further or drop it with a one-line reason.
 
 **Rationalizations to Reject:**
 
@@ -61,8 +66,14 @@ Any of the three not concretely nameable → **not a finding yet** — trace fur
 
 **Standard vs. Deep verification routing:**
 
-- **Standard** — traced data flow + all three claim elements named → report with normal field list.
-- **Deep** — severity High/Critical, OR precondition chain crosses trust boundary you did not trace → devil's-advocate pass first: actively try to refute finding (existing middleware? framework default? type system? config?). Report only what survives; killed findings listed one-line under *Rejected candidates* so triage is auditable.
+- **Standard** — traced data flow + all three claim elements named → report
+  with the normal field list.
+- **Deep** — severity would be High/Critical, OR the precondition chain
+  crosses a trust boundary you did not personally trace → run a
+  devil's-advocate pass first: actively try to refute the finding (existing
+  middleware? framework default? type system? config?). Report only what
+  survives; findings the pass killed are listed one-line under
+  *Rejected candidates* so the triage is auditable.
 
 ### 1. Map attack surface
 
@@ -104,7 +115,10 @@ User Input → Controller → Validation → Service → DB/File/External
 | **Header injection** | User input in response headers, email headers |
 | **Insecure defaults / fail-open** | Guards that allow on error (`catch { return true }` in an authz check), default-allow matchers, debug mode defaulting on, permissive CORS/`verify=false` fallbacks, feature flags whose missing value grants access |
 
-Worked example (fail-open): `if (!$gate->check($user)) { … }` wrapped in `try/catch` that logs and **continues** fails open — exception in gate grants access. Finding shape: Category *Insecure defaults*, Evidence the catch block `file:line`, Fix *fail closed — rethrow or deny on gate error*.
+Worked example (fail-open): `if (!$gate->check($user)) { … }` wrapped in a
+`try/catch` that logs and **continues** fails open — an exception in the gate
+grants access. Finding shape: Category *Insecure defaults*, Evidence the
+catch block `file:line`, Fix *fail closed — rethrow or deny on gate error*.
 
 ### 4. Framework-specific checks
 
@@ -135,7 +149,10 @@ For each vulnerability:
 - **Fix:** concrete mitigation
 - **Confidence:** Low / Medium / High
 
-After findings, add **Rejected candidates** section: one line per look-dangerous-but-benign pattern the Step-0 gate killed, with traced reason ("raw SQL string is a static migration constant — no user input reaches it"). Audit that rejects nothing has usually skipped the gate.
+After the findings, add a **Rejected candidates** section: one line per
+look-dangerous-but-benign pattern the Step-0 gate killed, with the traced
+reason ("raw SQL string is a static migration constant — no user input
+reaches it"). An audit that rejects nothing has usually skipped the gate.
 
 ## Integration with other skills
 
@@ -148,7 +165,7 @@ After findings, add **Rejected candidates** section: one line per look-dangerous
 ## Gotcha
 
 - Don't report theoretical vulnerabilities without a concrete attack vector — false positives erode trust.
-- The model tends to flag framework-handled security as issues (e.g., Laravel's CSRF is already handled).
+- The model tends to flag framework-handled security as issues (e.g., Laravel's CSRF or Rails' `protect_from_forgery` is already handled).
 - Always check if a finding is already mitigated by middleware or configuration before reporting it.
 
 ## Do NOT