@event4u/agent-config 14.9.0 → 14.11.0

package/dist/agent-src/skills/receiving-code-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: high
 name: receiving-code-review
-description: "Use when processing code review feedback (bot or human) before changing anything — triages, verifies, and pushes back with technical reasoning — even when the user just says 'fix the comments'."
+description: "When processing code review feedback (bot or human) before changing anything — triages, verifies and pushes back with technical reasoning — even when the user just says 'fix the comments'."
 personas:
   - critical-challenger
 domain: process
@@ -122,7 +122,7 @@ For each comment classified as blocking/important:
 
 Run the relevant tests and linters **between** each group — do not
 batch four changes and then run tests once. See
-[`verify-before-complete`](../verify-before-complete/SKILL.md).
+[`verify-completion-evidence`](../verify-completion-evidence/SKILL.md).
 
 ## Output format
 
@@ -181,7 +181,7 @@ When reporting back to the user after handling review:
 * Executing the fixes across many comments → [`fix-pr-comments`](../../commands/fix-pr-comments.md)
   (handles both bot + human reviewers in one pass)
 * Running the full verification gate before pushing replies →
-  [`verify-before-complete`](../verify-before-complete/SKILL.md)
+  [`verify-completion-evidence`](../verify-completion-evidence/SKILL.md)
 * Writing the commit message that references the review →
   [`conventional-commits-writing`](../conventional-commits-writing/SKILL.md)
 * Digging into *why* the reviewer's scenario actually fails →

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

@@ -7,6 +7,9 @@ personas:
   - senior-engineer
   - ai-agent
 domain: product
+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/refine-ticket/SKILL.md

@@ -10,6 +10,9 @@ personas:
   - critical-challenger
   - ai-agent
 domain: product
+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/requesting-code-review/SKILL.md

@@ -60,7 +60,7 @@ Before asking anyone else:
 * Check for secrets in diff — API keys, connection strings, tokens
 * Check file-system side effects — generated files, lockfile churn,
   IDE configs, `.env` changes
-* Run the linter + tests (see [`verify-before-complete`](../verify-before-complete/SKILL.md))
+* Run the linter + tests (see [`verify-completion-evidence`](../verify-completion-evidence/SKILL.md))
 * If you find issues → fix them, do **not** ship them and hope the
   reviewer flags them
 
@@ -192,7 +192,7 @@ When handing the review request to the reviewer (PR body, Slack, email):
 * Actually opening the PR → [`create-pr`](../../commands/create-pr.md)
 * Writing the commits themselves → [`commit`](../../commands/commit.md),
   [`conventional-commits-writing`](../conventional-commits-writing/SKILL.md)
-* Verifying readiness → [`verify-before-complete`](../verify-before-complete/SKILL.md)
+* Verifying readiness → [`verify-completion-evidence`](../verify-completion-evidence/SKILL.md)
 * Processing the feedback when it arrives → [`receiving-code-review`](../receiving-code-review/SKILL.md)
 
 ## Validation checklist

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

@@ -31,7 +31,7 @@ Do NOT use when:
 - The diff is low-risk and no ownership map exists — fall back to the
   common role vocabulary below.
 - A full PR description is requested — route to
-  [`create-pr-description`](../create-pr:description-only/SKILL.md) and let
+  [`/pr:create:description-only`](../../domains/git/pr/create/description-only/command.md) and let
   it call this skill for the routing block.
 - A threat model is wanted — route to
   [`threat-modeling`](../threat-modeling/SKILL.md).
@@ -210,6 +210,6 @@ Data source: <"ownership-map.yml + historical-bug-patterns.yml"
 
 - [`reviewer-awareness`](../../rules/reviewer-awareness.md) — the rule that routes here: anchor reviewer choice in paths and risk, never seniority
 - [`review-routing-data-format`](../../../docs/guidelines/agent-infra/review-routing-data-format.md)
-- [`create-pr-description`](../create-pr:description-only/SKILL.md)
+- [`/pr:create:description-only`](../../domains/git/pr/create/description-only/command.md)
 - [`judge-test-coverage`](../judge-test-coverage/SKILL.md) — consumes
   the `required_test` entries from matched patterns.

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

@@ -51,8 +51,18 @@ dashboard-sync axis stays in `roadmap-management`.
 Authoring or materially rewriting a roadmap must go through
 Understand → Research → Draft per the
 [`artifact-drafting-protocol`](../../rules/artifact-drafting-protocol.md)
-rule. Inspect existing roadmaps under `agents/roadmaps/` for overlap
-or supersession before opening a new one. **Gate C first** — "write a
+rule. **Run the probe, do not eyeball the directory:**
+
+```bash
+agent-config roadmap:context
+```
+
+It reports sibling roadmaps on the same topic across all four roadmap
+directories, inbox notes, and open PRs on the cited paths — the semantic axis a
+filename scan cannot see. Each hit becomes one `relates:` row
+(`extends` / `supersedes` / `depends` / `disjoint`, template rule 18); zero hits
+becomes `relates: []` carrying the probe's `scanned:` line as its
+justification. **Gate C first** — "write a
 plan/roadmap" is a gated surface, so run
 [`plan-confidence-gate`](../../contexts/execution/plan-confidence-gate.md)
 before drafting (95%-conditions, marker, interview-or-degrade, C→R1 handoff).
@@ -218,45 +228,12 @@ preferred.
 
 When a parent roadmap closes with `[~]` items, the
 [`roadmap-management`](../roadmap-management/SKILL.md) skill spawns a
-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 the archived source
----
-
-# Roadmap: Follow-up to <parent-title>
-
-> <One sentence: carried-over outcome.>
-
-## Context
-
-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 this as a body note, NOT in frontmatter: -->
-> Blocked until <condition>. Execution starts when the condition clears.
-```
-
-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 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.
-
-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.
+follow-up. Authors and reviewers must know the shape so they can recognise it:
+the frontmatter template, the two states the author picks between
+(`status: draft`, hidden from the dashboard, vs the default `status: ready`
+plus a body `> Blocked until …` note), and the rule that deferred steps are
+copied verbatim rather than re-authored →
+[`references/follow-up-roadmap-shape.md`](references/follow-up-roadmap-shape.md).
 
 ### 8. Source-derived & capability-adoption roadmaps (conditional)
 
@@ -311,6 +288,11 @@ to every roadmap you author.
 3. Are checkboxes present in every non-intro phase?
 4. Are exit criteria decidable, or vibe-based ("looks good")?
 5. Is content duplicated from another roadmap (supersession instead)?
+5b. Does the frontmatter carry a `relates:` block — one row per probe hit with
+   an `extends`/`supersedes`/`depends`/`disjoint` relation, or an explicit
+   `relates: []` whose note carries the probe's `scanned:` line? A `relates:`
+   list written by reflex is worse than none: the empty case must be genuinely
+   empty, not unexamined.
 6. Any human-gate steps or sign-off phases (§ 4c violation) —
    agent-verifiable check or structured blocker instead?
 7. *Source-derived/adoption only (§ 8):* is there a `KEEP`/`FOLD`/`CUT`

package/dist/agent-src/skills/roadmap-writing/references/follow-up-roadmap-shape.md

@@ -0,0 +1,47 @@
+# roadmap-writing — follow-up roadmap shape
+
+> Mode body of the [`roadmap-writing`](../SKILL.md) skill (router-head
+> retrofit, 2026-08-23 — SKILL.md reached the K6 400-line cap). Content moved
+> VERBATIM from SKILL.md § 7; load this file when § 7 routes here.
+
+When a parent roadmap closes with `[~]` items, the
+[`roadmap-management`](../../roadmap-management/SKILL.md) skill spawns a
+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 the archived source
+---
+
+# Roadmap: Follow-up to <parent-title>
+
+> <One sentence: carried-over outcome.>
+
+## Context
+
+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 this as a body note, NOT in frontmatter: -->
+> Blocked until <condition>. Execution starts when the condition clears.
+```
+
+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 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.
+
+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.

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

@@ -3,6 +3,9 @@ model_tier: medium
 name: rtk-output-filtering
 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
+scope:
+  write: []
+  verification_reason: "this skill wraps another command's stdout; it has no output path of its own. Absence of a write is not something a command can prove."
 execution:
   type: assisted
   handler: shell
@@ -28,12 +31,25 @@ 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`.
+**Savings — STALE, and scoped. Do not quote the number without this label.**
+Upstream reports 60-90% (their estimate — "actual savings vary").
+agent-config's own figure is **33% overall, 0-57% per command**, and it is a
+**single spot-measurement from 2026-07-28: one repo, one macOS machine, an
+8-command corpus.** It has **not** been superseded by a wider run, and the
+widened re-bench is **deferred** — `road-to-terminal-token-economy` steps
+3.2-3.4. **The reason changed on 2026-08-23 and the label is updated with it:** the
+original deferral was ordering (Phase 2 had not chosen the wrapper mechanism, so a
+re-bench would measure the wrong subject). Phase 2 has now chosen — the existing
+warn-only nudge — so that objection is discharged. What defers it now is the
+re-bench's own registered design, which requires **at least two machines**, and only
+one is reachable. A one-machine re-bench would reproduce exactly the narrowness the
+widening exists to fix. AI council 2026-08-23, 2/2 convergent, on both readings.
+
+Treat it as an order of magnitude for *that* corpus, never as this package's
+general claim. Verbose commands (`git status`, `git log`, `ls -la`) save ~55%;
+already-compact output (`--oneline`, `--stat`) passes through at ~0%, which is
+why an overall percentage is meaningless without the corpus that produced it.
+See `internal/bench/rtk-savings/RESULTS.md`.
 
 **Docs:** https://www.mintlify.com/rtk-ai/rtk
 **Repo:** https://github.com/rtk-ai/rtk

package/dist/agent-src/skills/runway-cognition/SKILL.md

@@ -15,6 +15,9 @@ trust:
   level: professional
 install:
   removable: true
+triggers:
+  - phrase: "cash runway"
+  - phrase: "burn rate"
 ---
 
 # runway-cognition

package/dist/agent-src/skills/scene-expander/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: scene-expander
-description: "Use when expanding a one-line idea into the 12-block Cinematic Scene Blueprint — optional dialogue + ambient. Triggers 'expand this scene', 'blueprint for X'. 11-block refine → video-director."
+description: "When expanding a one-line idea into the 12-block Cinematic Scene Blueprint — optional dialogue + ambient. Triggers 'expand this scene', 'blueprint for X'. 11-block refine → video-director."
 personas:
   - hollywood-director
 domain: product

package/dist/agent-src/skills/scene-expander/scene-blueprint.schema.yaml

@@ -82,6 +82,31 @@ blocks:
     target: negative
     description: "Clichés to reject, load-bearing top-first."
 
+# Chain directives — NOT one of the 12 blocks.
+#
+# A block above describes the shot. A chain directive describes how this scene
+# JOINS ITS NEIGHBOUR, which is a property of the assembly, not of the prompt —
+# so it is listed separately and the blueprint stays a 12-block IR everywhere
+# else in the tree. `parse-blueprint.sh` accepts the label like any other and
+# emits the value at the top level; the chain itself is read by
+# `scripts/ai-video/lib/seam-plan.sh`, which this file's parser never sees.
+chain_directives:
+  CONTINUITY:
+    required: false
+    target: continuity
+    default: cut
+    values: [cut, handoff, connector]
+    description: >
+      How this scene joins the PREVIOUS one. `cut` is a hard cut and is the
+      value assumed when the label is absent, so every blueprint written before
+      this directive existed keeps its exact meaning. `handoff` means this
+      scene's ref_images[0] is the extracted last frame of the previous scene's
+      RENDERED clip rather than its own still, which forces the two clips to
+      render sequentially. `connector` is a handoff plus one extra bridging
+      clip, and needs a probed `end_frame: true` on both adjacent models.
+      An unknown value is a parse error naming the value — never a silent
+      downgrade to `cut`.
+
 # Adapter-contract JSON shape produced by parse-blueprint.sh
 output_shape: |
   {
@@ -102,6 +127,7 @@ output_shape: |
     },
     "duration": 5.0,
     "negative": ["...", "..."],
+    "continuity": "cut" | "handoff" | "connector",
     "requires": {
       "audio_native": true | false
     }

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

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: secrets-management
-description: "Use when picking a secrets store, designing rotation, or wiring scanning gates — multi-cloud (Vault, AWS, Azure, GCP), CI, and Kubernetes — decision framework, provider deep-dives externalized."
+description: "When picking a secrets store, designing rotation, or wiring scanning gates — multi-cloud (Vault, AWS, Azure, GCP), CI and Kubernetes — decision framework, provider deep-dives externalized."
 domain: devops
 status: active
 refresh_trigger: "A cited provider deprecates an auth method, OR External Secrets Operator ships a major version with breaking CRD changes, OR ≥30% of cited scanner tools change their gate semantics."
@@ -11,6 +11,10 @@ workspaces:
   - engineering
 packs:
   - engineering-base
+triggers:
+  - phrase: "secret rotation"
+  - phrase: "secrets store"
+  - phrase: "secret scanning"
 ---
 
 # secrets-management

package/dist/agent-src/skills/server-hardening/SKILL.md

@@ -0,0 +1,159 @@
+---
+model_tier: medium
+name: server-hardening
+description: "Use when hardening a Linux host you operate — SSH posture, a default-deny firewall baseline, and unattended security upgrades, each verified on the box rather than assumed from a config file."
+domain: devops
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+---
+
+# server-hardening
+
+## When to use
+
+Use when a host is yours to operate — a VPS, a bare-metal box, a long-lived VM —
+and its own security posture is the question. Three surfaces: who may log in, what
+may reach the network, and how patches arrive.
+
+Do NOT use when:
+- The workload runs on a managed runtime with no host you control — there is no
+  host posture to set, and `operational-readiness` records that as `unavailable`
+  with that reason
+- Auditing application code for vulnerabilities (use `security-audit`)
+- Application-level auth and authorization (use `security`, `authz-review`)
+- Provisioning cloud infrastructure (use `terraform`, `aws-infrastructure`)
+- Container image hardening (use `docker`)
+
+## The three surfaces
+
+### 1. SSH posture
+
+The one remote-entry door. Harden in this order, and **keep an open session while
+you change it** — a mistake here locks you out of the machine you are fixing.
+
+| Setting | Target | Why |
+|---|---|---|
+| `PasswordAuthentication` | `no` | Ends credential-stuffing against the host outright |
+| `PubkeyAuthentication` | `yes` | The replacement must work before passwords are removed |
+| `PermitRootLogin` | `no` (or `prohibit-password`) | Forces an audit trail through a named account |
+| `AllowUsers` / `AllowGroups` | Explicit allow-list | Default is every account on the box |
+| Port | Non-default is optional | Cuts log noise, not risk — never the primary control |
+
+Verify from a **second** connection before closing the first:
+
+```bash
+sudo sshd -t                                  # config parses; do this before reload
+sudo systemctl reload ssh                     # or sshd, per distro
+sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'
+```
+
+`sshd -T` prints the **effective** configuration. A file under
+`sshd_config.d/` or a `Match` block can override what you just edited, so the
+file you wrote is not evidence — the effective dump is.
+
+### 2. Firewall baseline
+
+Default-deny inbound, allow-list outbound where the workload permits.
+
+```bash
+sudo ufw default deny incoming
+sudo ufw default allow outgoing
+sudo ufw allow OpenSSH                        # before enabling, or you are locked out
+sudo ufw enable
+sudo ufw status verbose                       # the verification, not the intent
+```
+
+Two traps worth naming. A container runtime can write its own forwarding rules
+that bypass the host firewall entirely — check the actual rule table
+(`sudo iptables -S` / `sudo nft list ruleset`), not just the friendly front-end.
+And a cloud security group sits *in front* of the host: both must agree, and the
+narrower one is the effective policy.
+
+Optionally add an SSH brute-force throttle (`fail2ban` or equivalent). It is
+noise reduction and a small real gain once password auth is already off — never
+a substitute for it.
+
+### 3. Unattended security upgrades
+
+Patches that require a human are patches that arrive late.
+
+```bash
+sudo apt install unattended-upgrades          # Debian/Ubuntu family
+sudo dpkg-reconfigure -plow unattended-upgrades
+sudo unattended-upgrade --dry-run --debug     # proves it would act
+```
+
+Decide and record two things, because the default is silence: whether the host
+**reboots automatically** when a patch needs it, and where the **failure
+notification** goes. An upgrade timer that has been failing for six weeks is
+indistinguishable from one that is working, unless something reports it.
+
+Security patches only. Automatic *feature* upgrades change behaviour under you,
+which is a different risk with a different owner.
+
+## Procedure: Harden a host
+
+1. **Confirm the host is yours to harden.** Managed runtime with no shell → stop;
+   there is no posture here, and that is a recordable `unavailable`.
+2. **Open a second session and keep it open** for the whole SSH and firewall
+   work. This is the entire rollback mechanism.
+3. **Set the SSH posture**, then verify with `sshd -T` from the second session —
+   effective config, not the file.
+4. **Set the firewall baseline**, allowing SSH *before* enabling. Verify with
+   `ufw status verbose` and against the raw rule table.
+5. **Enable unattended security upgrades**, then prove with `--dry-run` that it
+   would act. Record the reboot policy and the failure destination.
+6. **Re-verify from a fresh connection.** Close every old session and reconnect.
+   A posture that only holds inside an already-authenticated session is
+   unverified.
+7. **Report each surface as met, unmet or uninspected.** Uninspected is not met —
+   `operational-readiness` reads an uninspected host posture as a red.
+
+### Validate
+
+- Verify `sshd -T` reports `passwordauthentication no`.
+- Verify `sshd -T` reports `permitrootlogin no` or `prohibit-password`.
+- Verify a key-based login succeeds from a **fresh** connection.
+- Verify the firewall default is deny-inbound and SSH is explicitly allowed.
+- Verify the raw rule table agrees with the front-end.
+- Verify `unattended-upgrade --dry-run` reports it would act.
+- Confirm the reboot policy and the failure-notification destination are recorded.
+
+## Output format
+
+1. One row per surface — SSH, firewall, unattended upgrades — with met / unmet /
+   uninspected and the verifying command's output.
+2. The reboot policy and where upgrade failures are reported.
+3. Anything left unmet, with what would close it.
+
+## Gotcha
+
+- Changing SSH without a second open session is how a host becomes unreachable.
+- The config file is not the posture. `sshd -T` is; a drop-in or `Match` block
+  silently wins.
+- Enabling a firewall before allowing SSH locks you out immediately.
+- A container runtime's own rules can bypass the host firewall.
+- A cloud security group and the host firewall must both allow a port; the
+  narrower wins.
+- A silently failing upgrade timer looks exactly like a working one.
+- A non-default SSH port reduces log volume, not risk.
+
+## Do NOT
+
+- Do NOT disable password authentication before a key login is proven to work.
+- Do NOT enable the firewall before allowing SSH.
+- Do NOT enable automatic feature upgrades — security patches only.
+- Do NOT treat an installed package as an enabled control; prove it acts.
+- Do NOT report an uninspected surface as met.
+- Do NOT rely on a non-default port as a control.
+
+## Auto-trigger keywords
+
+- server hardening
+- host hardening
+- ssh hardening
+- firewall baseline
+- unattended upgrades
+- fail2ban

package/dist/agent-src/skills/server-hardening/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+  "skill": "server-hardening",
+  "last_eval": "2026-08-23",
+  "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers the three host surfaces — SSH posture, firewall baseline, unattended upgrades. Should-not-trigger covers the neighbours: application-code vulnerability work (security-audit), application authorization (authz-review), cloud provisioning (terraform, aws-infrastructure), container images (docker) and adjudicating the resulting posture (operational-readiness).",
+  "queries": [
+    {"q": "harden ssh on this server — disable password login", "trigger": true},
+    {"q": "set up a default-deny firewall baseline on the VPS", "trigger": true},
+    {"q": "how do I get automatic security patches on this box?", "trigger": true},
+    {"q": "should I install fail2ban on the host?", "trigger": true},
+    {"q": "host hardening checklist for a new bare-metal server", "trigger": true},
+    {"q": "audit this codebase for injection vulnerabilities", "trigger": false, "note": "application-code vulnerability sweep → security-audit"},
+    {"q": "can user A read user B's records through this endpoint?", "trigger": false, "note": "application authorization → authz-review"},
+    {"q": "write the Terraform for a new ECS service", "trigger": false, "note": "cloud provisioning → terraform / aws-infrastructure"},
+    {"q": "reduce the attack surface of this Dockerfile", "trigger": false, "note": "container image hardening → docker"},
+    {"q": "is the overall system ready to operate given the host posture?", "trigger": false, "note": "adjudicating the verdict → operational-readiness"}
+  ]
+}

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

@@ -3,6 +3,9 @@ model_tier: inherit
 name: skill-improvement-pipeline
 description: "Run the skill-improvement pipeline after a learning was detected — capture, classify, create, validate, apply; explicit request only."
 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/skill-management/SKILL.md

@@ -4,6 +4,9 @@ name: skill-management
 description: "Use when condensing, decondenseing, refactoring, or improving existing skills. Covers the full skill lifecycle from verbose → sharp → maintained."
 source: project
 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/skill-reviewer/SKILL.md

@@ -3,6 +3,9 @@ model_tier: high
 name: skill-reviewer
 description: "Use when reviewing, auditing, or optimizing skills — validates against the 7 Skill Killers checklist and produces fix recommendations."
 domain: quality
+scope:
+  write: []
+  verification_reason: "execution.handler is internal, so this skill spawns no subprocess — writes happen through the agent's declared allowed_tools. No command can prove a scope the skill never executes."
 execution:
   type: assisted
   handler: internal

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

@@ -229,6 +229,12 @@ to every skill you author.
 - Per the post-action summary suppression, the example output ships
   the artifact, not a wrapping `## Status` / `## Summary` block.
 
+**Scope-exclusion clause.** A skill can shed assumed-knowledge prose without
+losing correctness by naming what it does NOT cover: "this skill covers only
+`<X>`; standard `<Y>` is assumed". One sentence replaces the paragraph that
+would otherwise re-teach `<Y>`, and it is stronger than silence — a reader who
+does not have `<Y>` learns that from the clause instead of from a wrong result.
+
 **Pre-save self-check:**
 1. Does any procedure step open with "Let me", "Now I will", "Found
    it", "OK", or "Alright"?

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

@@ -11,6 +11,9 @@ trust:
   level: professional
 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
 ---