@event4u/agent-config 14.10.0 → 14.12.0

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

@@ -12,6 +12,13 @@ trust:
 install:
   default: false
   removable: true
+scope:
+  write:
+    - pattern: "components/ui/**"
+      access: "create"
+    - pattern: "components.json"
+      access: "write"
+  verification_command: "npx shadcn@latest add <component> --dry-run"
 execution:
   type: assisted
   handler: shell
@@ -47,7 +54,14 @@ block above:
 
 ## Compatibility
 
-- **Tested against:** `shadcn@2.1`, Tailwind CSS `3.x`, React `18+`.
+- **Tested against:** `shadcn@4`, Tailwind CSS `4.x`, React `19`, primitives from
+  `@base-ui/react@1`, `components.json` style `base-nova` — every major read out
+  of `tests/fixtures/stack/shadcn-current/package.json`, the verbatim output of
+  `npx shadcn@latest init -d --template vite` on 2026-08-24. No version on this
+  line may be stated from prose; move it only by re-running that scaffold and
+  re-committing the fixture.
+- Tailwind `3.x` and Radix primitives stay supported through the **v3 branch**
+  under § Gotcha — the CLI moved on, existing projects did not.
 - The audit step (`directives/ui/audit.ts`) reads the line above and
   compares it with `state.ui_audit.shadcn_inventory.version`; a major
   mismatch triggers a soft halt before this skill runs.
@@ -56,8 +70,8 @@ block above:
 
 Use when `state.stack.frontend == "react-shadcn"` and `directives/ui/apply.ts`,
 `review.ts`, or `polish.ts` dispatches to this skill, or when a React project
-clearly uses shadcn/ui (presence of `components.json`, `@radix-ui/*`
-dependencies, a `components/ui/` folder of generated primitives).
+clearly uses shadcn/ui (presence of `components.json`, a `@base-ui/react` or
+`@radix-ui/*` dependency, a `components/ui/` folder of generated primitives).
 
 Do NOT use when:
 - Project is Blade + Livewire + Flux (use `flux` / `livewire` / `blade-ui`).
@@ -75,13 +89,23 @@ Do NOT use when:
   writes `state.ui_audit.shadcn_inventory` with the detected version —
   when it diverges by a major, audit emits a soft halt before this
   skill runs.
-- shadcn/ui composes Radix primitives. Accessibility is built in via Radix
-  but only when you use the wrapper components correctly (`asChild`,
+- shadcn/ui composes a primitive vendor — `@base-ui/react` in a CLI-4 scaffold,
+  `@radix-ui/*` in older projects. Accessibility is built in either way, but
+  only when the wrapper components are used correctly (`asChild`,
   `<DialogTrigger>` instead of a bare `<button>`).
-- Tailwind tokens come from `tailwind.config.{js,ts}` (`theme.extend.colors`)
-  and CSS custom properties on `:root` and `.dark` (`--background`,
-  `--foreground`, `--primary`, `--ring`, …). Audit writes them into
-  `state.ui_audit.design_tokens`. Use those tokens; do not hardcode values.
+- **Tailwind tokens: branch on the `css` axis, never guess.** `detect_stack()`
+  emits `axes.css` as `tailwind-v4` or `tailwind-v3`
+  (`work_engine/stack/detect.ts:521-524`); `existing-ui-audit` reads tokens on
+  the same key.
+  - `tailwind-v4` — **no config file exists.** Tokens live in the `@theme` block
+    of the entry CSS named by `components.json` → `tailwind.css`, and that file's
+    `"tailwind": {"config": ""}` — an empty `config` string — IS the v4 marker.
+    Never write `tailwind.config.{js,ts}` in a v4 project.
+  - `tailwind-v3` — tokens come from `tailwind.config.{js,ts}`
+    (`theme.extend.colors`).
+  - Either branch — CSS custom properties on `:root` and `.dark`
+    (`--background`, `--foreground`, `--primary`, `--ring`, …). Audit writes them
+    into `state.ui_audit.design_tokens`. Use those tokens; never hardcode values.
 - Dark mode is class-based (`<html class="dark">`). Every color must come
   from `bg-background`, `text-foreground`, etc. — never raw `bg-white`.
 - Every interactive primitive must declare a focus-visible state via
@@ -164,6 +188,40 @@ registries / install-with-natural-language over MCP; configure per the
 dependency. Decision note: **CLI path = default + universal; MCP path = opt-in
 when the user has it configured; registry-JSON literacy underpins both.**
 
+## Publish a registry — the library as a source others install from
+
+The sections above **consume** a registry. This one **publishes** one: a component library in
+this repository can expose its own components the same way, so a consumer installs them with
+the tool they already use instead of copying files.
+
+1. **Author `registry.json`** at the library root — the index — and one
+   `registry-item.json` per exposed component, each naming its files, its
+   `registryDependencies`, and its `cssVars` when it carries token requirements.
+2. **Build** to `public/r` with the registry build command. **The installer gate applies
+   here exactly as it does to `add`**: propose it, run `--dry-run` first, and let the user
+   confirm. A build writes files, so nothing about it being "our own" registry lifts the
+   gate.
+3. **The consumer adds a `registries` map entry** pointing at the published index; from then
+   on `@ns/item` resolves through it.
+
+**Two registry item types are FORBIDDEN**, deprecated in v4: `registry:build` and
+`registry:mcp`. Use **`registry:base`** and **`registry:font`** instead. Writing either
+deprecated type produces an item the current CLI does not understand, and the failure surfaces
+at the consumer rather than at authoring time.
+
+**`dependencies` in a registry item never names `react` or `react-dom`.** They are peers of
+the consuming app, and a registry item that installs its own copy reproduces the "invalid hook
+call" failure one layer up — see
+[`js-library-packaging`](../js-library-packaging/SKILL.md). `check_package_surface` enforces
+this over a registry file.
+
+> **Provenance.** The registry-publishing shape and the deprecated-type list come from an
+> external plugin reference's component-CLI skill, read at a pinned revision. The source is
+> deliberately not named here, per
+> [`source-confidentiality`](../../rules/source-confidentiality.md): a shipped artifact does
+> not carry derivation attribution to a named external project. The identifier and revision
+> stay with the maintainer-side record.
+
 ## Procedure: render a shadcn/ui component for the design brief
 
 ### Step 0: Inspect
@@ -202,12 +260,12 @@ when the user has it configured; registry-JSON literacy underpins both.**
    `bg-primary text-primary-foreground`, `text-muted-foreground`. No
    `bg-white` / `text-black` / hardcoded `#fff`.
 2. Spacing / radius from theme tokens (`rounded-lg` mapped to `--radius`
-   in `tailwind.config.{js,ts}`). Polish refactors hardcoded values
-   when a token equivalent exists.
+   — in the `@theme` block on `tailwind-v4`, in `tailwind.config.{js,ts}` on
+   `tailwind-v3`). Polish refactors hardcoded values when a token exists.
 3. Dark mode: never branch on a `dark` prop; rely on the `.dark` class
    on the root and semantic tokens.
 4. Every interactive primitive: keyboard trigger present (Enter/Space
-   on buttons, Esc on dialogs — Radix free), visible focus ring,
+   on buttons, Esc on dialogs — free from the primitive vendor), focus ring,
    `aria-label` from `state.ui_design.a11y` when icon-only.
 
 ### Step 3: State coverage
@@ -277,27 +335,17 @@ current state on the next polish round.
 
 When `DESIGN.md` declares `## Taste Dials`, honour them: Variance → layout-family spread + asymmetry tolerance; Motion → animation budget + reduced-motion posture; Density → spacing scale + information-per-viewport. Absent → follow the design brief's inferred dials.
 
-## Component workshop (Storybook) — when the library is large enough
-
-The generic "isolate + document reusable components" principle lives in
-[`fe-design`](../fe-design/SKILL.md) § Component Architecture; this is the React
-carve-out for the tool-specific part.
-
-- **When it pays off** — a real, growing shared-component library (roughly: more
-  than a handful of reused primitives, multiple consumers, ongoing UI work).
-  Storybook makes each component discoverable, reviewable in isolation, and
-  reused instead of re-invented. **Skip it** for a small surface of one-off
-  components — the setup + maintenance is not worth it yet.
-- **Story per reusable primitive, not per screen** — a story covers a component
-  and its states (default / loading / empty / error / dark), mirroring the
-  Step 3 state-coverage matrix. Screens are composed, not story-fied.
-- **Reuse the token layer** — stories render under the same semantic tokens +
-  `.dark` class; never hardcode a preview theme (same token discipline as Step 2).
-- **A11y in-workshop** — run the a11y addon so the isolation catches contrast /
-  role / focus issues before the component reaches a screen.
-- Do NOT let stories drift from the component API — a story that props-drills
-  values the component no longer accepts is stale documentation; keep them beside
-  the component and update them in the same change.
+## Component workshop (Storybook) — pointer
+
+The workshop discipline (one concept per story, `@summary` on every export, stories run as
+tests, the `!manifest` tag, the opt-in MCP channel) lives in
+[`storybook-workshop`](../storybook-workshop/SKILL.md). It is stack-agnostic and was lifted
+out of here rather than duplicated beside it.
+
+What stays React-specific and therefore stays here: the state-coverage matrix in Step 3 that
+the story set is derived from, the token discipline of Step 2 that stories render under, and
+the `(rule, selector, severity)` a11y shape in § Review pass that the workshop's validate
+step writes into.
 
 ## Security constraints
 

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

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

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

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

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

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

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

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

@@ -11,6 +11,10 @@ workspaces:
   - engineering
 packs:
   - engineering-base
+triggers:
+  - phrase: "secret rotation"
+  - phrase: "secrets store"
+  - phrase: "secret scanning"
 ---
 
 # secrets-management