@event4u/agent-config 9.9.0 → 9.11.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,14 +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.)
-8. *Inbox-sourced only:* roadmap consumed an `agents/tmp/` file as input →
-   file moved to `agents/tmp.old/<name>` in the SAME reply, Source line
-   pointing at the `tmp.old/` path? (Per `agents-layout § User Inbox
-   Workflow`. Move only the named input file(s); never sweep the inbox.)
+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
 
@@ -328,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
@@ -336,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).
@@ -352,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
@@ -366,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/rule-refactor/SKILL.md

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

package/dist/agent-src/skills/security-maturity-assessment/SKILL.md

@@ -11,7 +11,10 @@ packs:
 
 # security-maturity-assessment
 
-Rate how mature a module's security **posture** is — category by category, every rating backed by `file:line` evidence — instead of hunting individual vulnerabilities. Output is a scorecard a maintainer can re-run and diff, not a finding list.
+Rate how mature a module's security **posture** is — category by category,
+every rating backed by `file:line` evidence — instead of hunting individual
+vulnerabilities. The output is a scorecard a maintainer can re-run and diff,
+not a finding list.
 
 ## When to use
 
@@ -53,34 +56,53 @@ Do NOT use when:
 
 ## Procedure
 
-1. **Scope** — name the module/paths under assessment; list entry points (routes, jobs, commands, webhooks). Scorecard without stated scope is not reproducible.
-2. **Assess each category** — inspect the code the category names. Every rating cites evidence:
+1. **Scope** — name the module/paths under assessment; list entry points
+   (routes, jobs, commands, webhooks). A scorecard without a stated scope is
+   not reproducible.
+2. **Assess each category** — inspect the code the category names. Every
+   rating cites evidence:
    - Positive evidence: `file:line` of the control (`app/Http/Requests/…:12`, `src/guards/auth.guard.ts:12`).
-   - Absence evidence: the searches run that came back empty (name the grep patterns) — "not found" beats "probably missing".
-   - Multi-tenant N/A: single-tenant systems rate category 8 `N/A`; drops out of the roll-up.
-3. **Roll up deterministically** — overall rating is computed, not vibed:
+   - Absence evidence: the searches run that came back empty (name the grep
+     patterns) — "not found" beats "probably missing".
+   - Multi-tenant N/A: single-tenant systems rate category 8 `N/A`; it drops
+     out of the roll-up.
+3. **Roll up deterministically** — the overall rating is computed, not vibed:
    - `overall = min( median(all rated categories), one step above the lowest critical-category rating )`
-   - Consequences: any critical category **Missing** caps overall at **Weak**; any critical **Weak** caps overall at **Moderate**. Non-critical categories move the median but never lift the cap.
-4. **Recommend** — max 3 next steps, ordered by which would raise the overall rating (fix the lowest critical category first).
+   - Consequences: any critical category **Missing** caps overall at **Weak**;
+     any critical **Weak** caps overall at **Moderate**. Non-critical
+     categories move the median but can never lift the cap.
+4. **Recommend** — max 3 next steps, ordered by which would raise the overall
+   rating (i.e. fix the lowest critical category first).
 
 ## Output format
 
-1. **Scope block** — module/paths + entry-point list, so the scorecard is re-runnable.
-2. **Scorecard table** — one row per category: `Category | Rating | Evidence (file:line or named empty searches) | Gap`. Every row MUST carry evidence; a rating without a citation is invalid.
-3. **Overall rating** — with the roll-up shown (`median=…, lowest critical=…, cap=… → overall=…`), never a bare verdict.
+1. **Scope block** — module/paths + entry-point list, so the scorecard is
+   re-runnable.
+2. **Scorecard table** — one row per category:
+   `Category | Rating | Evidence (file:line or named empty searches) | Gap`.
+   Every row MUST carry evidence; a rating without a citation is invalid.
+3. **Overall rating** — with the roll-up shown (`median=…, lowest critical=…,
+   cap=… → overall=…`), never a bare verdict.
 4. **Top-3 next steps** — ordered by roll-up impact.
 
 ## Gotcha
 
-- The model tends to rate from vibes ("looks well-structured") — a rating row without `file:line` or named empty searches is invalid; redo it.
-- Don't let a Strong non-critical category mask a Weak critical one — the cap rule exists precisely because a polished logging setup does not offset missing authorization.
-- A vulnerability found mid-assessment is **out of scope** for the scorecard — note it and route to [`security-audit`](../security-audit/SKILL.md) (with its false-positive gate) instead of inlining findings here.
+- The model tends to rate from vibes ("looks well-structured") — a rating
+  row without `file:line` or named empty searches is invalid; redo it.
+- Don't let a Strong non-critical category mask a Weak critical one — the
+  cap rule exists precisely because a polished logging setup does not offset
+  missing authorization.
+- A vulnerability found mid-assessment is **out of scope** for the scorecard
+  — note it and route to [`security-audit`](../security-audit/SKILL.md)
+  (with its false-positive gate) instead of inlining findings here.
 
 ## Do NOT
 
-- Do NOT emit a rating without evidence — every row cites `file:line` or the empty searches that prove absence.
+- Do NOT emit a rating without evidence — every row cites `file:line` or the
+  empty searches that prove absence.
 - Do NOT average away critical categories — the deterministic cap always wins.
-- Do NOT turn the scorecard into a finding list — posture assessment and vulnerability hunting are different deliverables.
+- Do NOT turn the scorecard into a finding list — posture assessment and
+  vulnerability hunting are different deliverables.
 - Do NOT assess unscoped ("the whole app") when the user named a module.
 
 ## See also

package/dist/agent-src/skills/skill-improvement-pipeline/SKILL.md

@@ -11,6 +11,8 @@ workspaces:
   - agent-config-maintainer
 packs:
   - meta
+requires_skills:
+  - learning-to-rule-or-skill
 ---
 
 # skill-improvement-pipeline
@@ -66,19 +68,21 @@ Show the user:
 
 #### Cross-project promotion signal (surfacing only — never an auto-writer)
 
-Same learning now seen in **≥ 2 distinct projects** → strong candidate for a
-*shared* surface (global rule/skill or a `src/patterns/` recipe), not a
-project-local note. **Surface** it; do **not** auto-write:
+If the **same learning** has now been observed in **≥ 2 distinct projects**, it
+is a strong promotion candidate for a *shared* surface (a global rule/skill or a
+`src/patterns/` recipe) rather than a project-local note. **Surface** that signal
+to the user — do **not** auto-write it:
 
 ```
-> Cross-project: also seen in {other-project}.
+> Cross-project: this learning was also seen in {other-project}.
 > ≥2 projects ⇒ candidate for a shared surface (global rule / skill / pattern).
 > → surface for promotion (human decides; no auto-write)
 ```
 
-A *signal*, not a store: no auto-write, no decay, no runtime (the writable
-per-project learning store stays rejected — [[council-agent-memory-sunset]]).
-The human decides whether the cross-project recurrence justifies promotion.
+This is a *signal*, not a store: there is no auto-write, no decay, no runtime
+(the writable per-project learning store stays rejected —
+[[council-agent-memory-sunset]]). The human decides whether the cross-project
+recurrence justifies promotion.
 
 ### Step 3: Classify
 
@@ -122,11 +126,10 @@ Decide what to create:
 After creation:
 1. Run `./scripts-run src/scripts/skill_linter {path}` — must pass (0 fail)
 2. Copy to `.augment/`
-3. Mark hash: `./scripts-run src/scripts/condense --mark-done "{relative_path}"`
-4. Regenerate tools: `./scripts-run src/scripts/condense --generate-tools`
-5. **If from a knowledge page** (`agents/knowledge/procedures/skill-candidates.md`
+3. Regenerate tools: `./scripts-run src/scripts/condense --generate-tools`
+4. **If the learning came from a knowledge page** (`agents/knowledge/procedures/skill-candidates.md`
    or any `agents/knowledge/` page) — degrade the source to a pointer;
-   promotion isn't complete otherwise (double-maintenance risk):
+   promotion is not complete otherwise (double-maintenance risk):
    `./scripts-run src/scripts/degrade_to_pointer --source "<knowledge-path>[#<anchor>]" --artifact "{relative_path}" --date "<YYYY-MM-DD>"`
 
 ### Step 5: Decide scope

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

@@ -454,14 +454,15 @@ to every skill you author.
 ## Read-only-by-default scripts
 
 A script shipped inside a skill (`scripts/**`) is **side-effect-free by
-default** — inspects, computes, prints; does not mutate. Mutation (write /
-delete / rename / copy) gates behind an explicit flag named in this SKILL.md —
-`--writable` / `--apply` / `--write` / `--output` / `--fix` — so the default
-invocation is safe. A generator whose *declared purpose* is to write (emits an
-artifact to a caller-supplied path) is allowlisted with a rationale in
-`src/scripts/lint_skill_scripts_readonly_allowlist.json` instead of a redundant
-flag. `lint_skill_scripts_readonly` enforces this: an ungated, non-allowlisted
-write fails the build.
+default** — it inspects, computes, and prints; it does not mutate the
+filesystem. Any mutation (writing a file, deleting, rename/copy) must be gated
+behind an explicit flag named in this SKILL.md — `--writable` / `--apply` /
+`--write` / `--output` / `--fix` — so the default invocation is safe to run
+blind. A generator whose *declared purpose* is to write (it emits an artifact
+to a caller-supplied path) is allowlisted with a rationale in
+`src/scripts/lint_skill_scripts_readonly_allowlist.json` rather than carrying a
+redundant flag. `lint_skill_scripts_readonly` enforces this: an ungated,
+non-allowlisted write fails the build.
 
 ## Description-optimizer loop (U1 — held-out, not vibes)