@jenga-ai/agent 3.5.0 → 3.6.0

package/skills/j-reconcile/scripts/detect-unlinked-code.sh

@@ -37,7 +37,7 @@
 # SIGNAL A IS BORROWED, NOT REBUILT
 # ---------------------------------------------------------------------------
 # The board-linkage question is answered by
-# `skills/uncharted/scripts/resolve-segment-target.sh` (E40_S02_T01) through its
+# `skills/j-uncharted/scripts/resolve-segment-target.sh` (E40_S02_T01) through its
 # documented batch interface:
 #
 #     git ls-files | resolve-segment-target.sh --paths-from -
@@ -70,7 +70,7 @@
 #
 # This is deliberate. `run-engine.sh` currently renders the out-of-repo
 # `not_checked` case as `unlinked` in its understanding document, which asserts
-# a verified absence that was never verified. `skills/uncharted/SKILL.md` names
+# a verified absence that was never verified. `skills/j-uncharted/SKILL.md` names
 # Step 1 (`resolve-segment-target.sh`) authoritative on linkage where the two
 # disagree, so this script passes the resolver's status through unchanged and
 # does not repeat that conflation.
@@ -104,8 +104,8 @@
 # Classifying files and then reporting directories would assert about a
 # directory something that was only ever verified about its contents. Because
 # the resolver's match is a path-boundary test, a board item naming
-# `skills/convert/` links THAT DIRECTORY without linking
-# `skills/convert/convert_cli.py`. Both facts are true, and the directory-level
+# `skills/j-convert/` links THAT DIRECTORY without linking
+# `skills/j-convert/convert_cli.py`. Both facts are true, and the directory-level
 # one is what decides whether a segment is worth investigating -- offering
 # `/uncharted segment` there would duplicate a board item that already exists.
 #
@@ -125,7 +125,7 @@
 # MIRROR SPELLINGS. Per CLAUDE.md the canonical file lives in the root tree and
 # `.agents/`, `.claude/` are generated build outputs -- but older board items
 # were often written against the mirror path. E17_S05 owns `/reconcile-origin`
-# and names it `.agents/skills/reconcile-origin/SKILL.md`, so a match on the
+# and names it `.agents/skills/j-reconcile-origin/SKILL.md`, so a match on the
 # root path alone misses a board item that plainly owns the directory. Each
 # group directory is therefore asked about under its own name and under both
 # mirror prefixes, and `directory_linkage.matched_as` records which spelling
@@ -187,14 +187,14 @@
 #                  "not_checked_paths": N,
 #                  "groups": N, "covered_groups": N },
 #     "groups": [
-#       { "directory": "skills/skillify",
+#       { "directory": "skills/j-skillify",
 #         "unlinked_count": N,        // files keyed to THIS group
 #         "subtree_candidates": N,    // all candidates under the directory
 #         "subtree_unlinked": N,      // all unlinked under the directory
 #         "fully_unlinked": true,
 #         "directory_linkage": { "status": "unlinked", "reason": "...",
 #                                "items": [], "match_count": 0,
-#                                "matched_as": "skills/skillify" },
+#                                "matched_as": "skills/j-skillify" },
 #         "files": ["..."],           // capped by --limit
 #         "files_truncated": N }
 #     ],
@@ -295,7 +295,7 @@ REPO_ROOT=$(cd -- "$REPO_ROOT" && pwd -P)
 [ -n "$RESOLVER" ] || RESOLVER="$SCRIPT_DIR/../../uncharted/scripts/resolve-segment-target.sh"
 [ -f "$RESOLVER" ] || die 4 "board-linkage checker not found: $RESOLVER
   This script deliberately has no fallback implementation -- see the header. Restore
-  skills/uncharted/scripts/resolve-segment-target.sh or pass --resolver <path>."
+  skills/j-uncharted/scripts/resolve-segment-target.sh or pass --resolver <path>."
 [ -x "$RESOLVER" ] || die 4 "board-linkage checker is not executable: $RESOLVER"
 RESOLVER=$(cd -- "$(dirname -- "$RESOLVER")" && pwd -P)/$(basename -- "$RESOLVER")
 
@@ -572,8 +572,8 @@ for path, status in sorted(status_of.items()):
 # --- second pass: is the GROUP DIRECTORY itself on the board? ---------------------------------
 # Reporting a directory while only ever having checked the files inside it asserts an absence
 # that was never verified -- the same error this script is careful to avoid for `not_checked`.
-# The resolver's match is a path-boundary test, so a board item naming `skills/convert/` links
-# that directory without linking `skills/convert/convert_cli.py`. Both facts are true and the
+# The resolver's match is a path-boundary test, so a board item naming `skills/j-convert/` links
+# that directory without linking `skills/j-convert/convert_cli.py`. Both facts are true and the
 # directory-level one is the one that decides whether a segment is worth investigating.
 #
 # Same borrowed checker, same batch interface, one extra call. No new linkage logic -- the only
@@ -582,7 +582,7 @@ for path, status in sorted(status_of.items()):
 # MIRROR SPELLINGS. Per CLAUDE.md the canonical file lives in the root tree and `.agents/` and
 # `.claude/` are generated build outputs, but plenty of older board items were written against
 # the mirror path -- E17_S05 owns `/reconcile-origin` and names it as
-# `.agents/skills/reconcile-origin/SKILL.md`. A boundary match on the root path alone therefore
+# `.agents/skills/j-reconcile-origin/SKILL.md`. A boundary match on the root path alone therefore
 # misses a board item that plainly owns the directory. So each directory is asked about under its
 # own name and under both mirror prefixes, and a hit on any spelling is board provenance. This
 # adds path spellings to the QUESTION; it does not add a second answer to it.

package/skills/j-redo/SKILL.md

@@ -60,7 +60,7 @@ Compare the user's redo description against the original implementation to deter
 Summarise scope findings to the user in a brief list before continuing.
 
 ### 3. Plan the redo
-Populate `skills/todo/assets/todo_handoff_template.md` with the following pre-collected context:
+Populate `skills/j-todo/assets/todo_handoff_template.md` with the following pre-collected context:
 - **Mission title**: a short name for the redo work
 - **Goal / objective**: the redo objective — what is changing and the desired outcome
 - **Affected files or scope**: code, tests, and documentation files identified in step 2

package/skills/j-spinoff/SKILL.md

@@ -44,7 +44,7 @@ This file is generated/synced by `scripts/generate-j-alias.sh spinoff` from `ski
 
 4. **Run /brainstorm (if chosen)** — Invoke the `/brainstorm` skill, passing the diverging topic and collected context as the opening prompt. After `/brainstorm` completes, use the refined output as the idea description.
 
-5. **Save via `/idea`** — Populate `skills/idea/assets/idea_handoff_template.md` with the context collected so far:
+5. **Save via `/idea`** — Populate `skills/j-idea/assets/idea_handoff_template.md` with the context collected so far:
    - **Mission title**: the diverging topic name (as confirmed in step 1)
    - **Goal / objective**: what the diverging topic aims to achieve
    - **Affected files or scope**: any files or modules identified during the conversation

package/skills/j-status/SKILL.md

@@ -36,6 +36,21 @@ This file is generated/synced by `scripts/generate-j-alias.sh status` from `skil
 
 6. **Check the queue** — If `project/queue/scrum_triggers.jsonl` is non-empty, note the number of pending triggers awaiting the scrum master.
 
+6.5. **Run the deploy-reconcile pass** (`E51_S05`) before printing the summary — `/status` has no
+`scripts/` directory of its own comparable to `/self-sync`'s, so invoke the shared pipeline
+directly rather than adding a third skill-local wrapper script:
+   ```
+   bash scripts/mark-deployed.sh
+   ```
+   This defaults to invoking its own sibling `scripts/compute-deploy-reconcile.sh`, which
+   discovers any not-yet-reconciled `vX.Y.Z-stage`/`vX.Y.Z` tags on the public `jenga-npm` repo
+   (unauthenticated read — no credential required) and promotes matching `Publicized`/
+   `Deployed to Stage` tickets to `Deployed to Stage`/`Deployed to Prod` (writing
+   `date_deployed_prod` on a Prod promotion) by commit ancestry, before this skill re-scans the
+   board in steps 2-4 above. This step is **non-fatal**: a failure anywhere in the pipeline
+   (including an unreachable public repo) is logged as a warning only and never prevents `/status`
+   from printing whatever board state it already has, and never causes a non-zero exit.
+
 7. **Print the summary** following the layout and icon conventions in `assets/output_format.md`.
 
 8. If no epics exist, print: `No board items found. Run /pi-plan to define epics or /todo to add items.`

package/skills/j-todo/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: j.todo
 description: Polyfill alias of the todo skill under a collision-safe directory name. Identical behavior to /todo — Add missions to the project todo list (project/todo.md), optionally linking them to epics and stories. Loops until the user is done, then optionally executes the list. Use when the bare /todo form is shadowed by another tool's own built-in command of the same name.
+output_types: id_list
+input_types: id_list
 keywords:
   - todo
   - add task
@@ -29,7 +31,7 @@ This file is generated/synced by `scripts/generate-j-alias.sh todo` from `skills
 
 When `--trivial` is present, the mission is written as a **fully-formed task board file immediately** (not just a raw `todo.md` line deferred to `/do`'s own breakdown pass) with `execution_scope: inline` forced unconditionally — no threshold computation is consulted for the scope value itself. See step 4.5 below for the mechanics.
 
-**Human-only override.** `--trivial` is invoked by a human typing `/todo --trivial ...` — it is never applied by the scrum-master to itself during autonomous story/epic breakdown elsewhere (e.g. `/jenga`'s Phase 0.5, or `/do`'s own scrum-master decomposition step in `skills/do/SKILL.md` step 3). Those paths keep using the normal heuristic-only `execution_scope` assignment documented in `agents/scrum-master.md`'s Execution Scope Assignment section, unmodified by this flag.
+**Human-only override.** `--trivial` is invoked by a human typing `/todo --trivial ...` — it is never applied by the scrum-master to itself during autonomous story/epic breakdown elsewhere (e.g. `/jenga`'s Phase 0.5, or `/do`'s own scrum-master decomposition step in `skills/j-do/SKILL.md` step 3). Those paths keep using the normal heuristic-only `execution_scope` assignment documented in `agents/scrum-master.md`'s Execution Scope Assignment section, unmodified by this flag.
 
 **Fallback on failure is out of scope here.** If a `--trivial`-forced inline run fails the smoke-harness or shows scope creep at dispatch time, `/do`'s own `--trivial` handling (a separate task, E32_S14_T02) is responsible for falling back to the full `task` pipeline — this skill only ever writes the initial forced-inline task.
 

package/skills/j-uncharted/SKILL.md

@@ -860,7 +860,7 @@ sections of `project/PROJECT_SUMMARY.md`:
 
 **Step B — Check both sections for existing content before proposing anything.** A section counts
 as a **stub** only if its body is empty, whitespace-only, or is (or is limited to) the literal
-placeholder text from `skills/init/assets/PROJECT_SUMMARY_template.md` — `_To be completed._`.
+placeholder text from `skills/j-init/assets/PROJECT_SUMMARY_template.md` — `_To be completed._`.
 Anything else — a sentence, a partial list, a paragraph someone already wrote by hand — is real,
 non-stub content, however short, and is never silently overwritten. Check the Overview and
 Architecture & Structure sections independently; one can be a stub while the other is not.

package/skills/j-uncharted/scripts/detect-dependencies.sh

@@ -97,7 +97,7 @@ Options:
   -h, --help      Show this help and exit.
 
 Examples:
-  $(basename "$0") skills/reconcile/
+  $(basename "$0") skills/j-reconcile/
   $(basename "$0") scripts/board_resolver.sh
 EOF
 }

package/skills/j-uncharted/scripts/detect-tests.sh

@@ -104,7 +104,7 @@ Options:
   -h, --help      Show this help and exit.
 
 Examples:
-  $(basename "$0") skills/reconcile/
+  $(basename "$0") skills/j-reconcile/
   $(basename "$0") scripts/board_resolver.sh
 EOF
 }

package/skills/j-uncharted/scripts/elicitation-state.sh

@@ -183,7 +183,7 @@ fi
 # and .agents/ — scripts/ (which owns with-lock.sh) is never copied there, so
 # this script — itself shipped under skills/j-uncharted/scripts/ and mirrored
 # alongside it — cannot assume "$REPO_ROOT/scripts/with-lock.sh" exists.
-# Mirrors skills/init/scripts/init.sh's PKG_ROOT fallback: prefer a monorepo
+# Mirrors skills/j-init/scripts/init.sh's PKG_ROOT fallback: prefer a monorepo
 # checkout's sibling scripts/ dir, else fall back to the installed npm
 # package under node_modules/@jenga-ai/agent.
 if [ -f "$SCRIPT_DIR/../../../scripts/with-lock.sh" ]; then

package/skills/j-uncharted/scripts/validate-proposed-items.sh

@@ -53,7 +53,7 @@ REPO_ROOT=$(git -C "$SCRIPT_DIR" rev-parse --show-toplevel 2>/dev/null || true)
 # and .agents/ — scripts/ (which owns both validators) is never copied there,
 # so this script — itself shipped under skills/j-uncharted/scripts/ and mirrored
 # alongside it — cannot assume "$REPO_ROOT/scripts/..." exists. Mirrors
-# skills/init/scripts/init.sh's PKG_ROOT fallback (same pattern already
+# skills/j-init/scripts/init.sh's PKG_ROOT fallback (same pattern already
 # applied to this skill's elicitation-state.sh WITH_LOCK resolution): prefer
 # a monorepo checkout's sibling scripts/ dir, else fall back to the installed
 # npm package under node_modules/@jenga-ai/agent.

package/skills/j-wtf/SKILL.md

@@ -24,4 +24,4 @@ This file is generated/synced by `scripts/generate-j-alias.sh wtf` from `skills/
 
 ## Instructions
 
-`/wtf` is an alias of `/clearify`. Follow `skills/clearify/SKILL.md` in full — do not duplicate or reimplement its ambiguity-detection logic here. Read that file's `## Instructions` section and execute it exactly as written, using whatever prompt or conversation context is attached to this `/wtf` invocation.
+`/wtf` is an alias of `/clearify`. Follow `skills/j-clearify/SKILL.md` in full — do not duplicate or reimplement its ambiguity-detection logic here. Read that file's `## Instructions` section and execute it exactly as written, using whatever prompt or conversation context is attached to this `/wtf` invocation.

package/skills/jenga/SKILL.md

@@ -169,8 +169,8 @@ This branch is entered when `detect-nl-intent.sh` (invoked above) classifies the
 This branch is entered when `detect-nl-intent.sh` classifies the argument as `nl_intent` — every comma-delimited segment failed the ID grammar, so the raw argument is treated as natural-language intent rather than a malformed ID list. This is purely a new *outcome* of the same argument-shape detection above — no new sigil, trigger prefix, or separate entry point is introduced.
 
 1. **Load the catalog** — invoke `skills/jenga/scripts/load-nl-catalog.sh` with no arguments (E53_S01_T02). Its stdout is the full skill catalog (`name`/`description`/`keywords`/`examples`/`prefered_agent` per skill), sourced exclusively from `lib/generate-skill-allow-list.js`'s generated inventory — see the script's own header for the full contract. Never re-derive this catalog by re-scanning `skills/` inline.
-2. **Match** — run `skills/route/SKILL.md`'s **Step 2 — Match the Prompt to a Skill** (the three-pass keyword → example-similarity → description match, including its tie-break and no-match handling) against this catalog, treating `detect-nl-intent.sh`'s `raw_argument` field as the prompt. Reuse that section's matching logic by reference — do not re-author its prose here.
-3. **Confident single match** — report the routing decision using `skills/route/SKILL.md`'s **Step 7 — Report Routing Decision** format (substitute `/jenga` for `/route` as the invoking command named in the report), then invoke the matched skill exactly as `skills/route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does: load `agents/<prefered_agent>.md` when the matched skill specifies `metadata.prefered_agent`, otherwise execute the skill instructions directly. The matched skill's own execution takes over from here — do not continue into this `/jenga` invocation's Phase 1.
+2. **Match** — run `skills/j-route/SKILL.md`'s **Step 2 — Match the Prompt to a Skill** (the three-pass keyword → example-similarity → description match, including its tie-break and no-match handling) against this catalog, treating `detect-nl-intent.sh`'s `raw_argument` field as the prompt. Reuse that section's matching logic by reference — do not re-author its prose here.
+3. **Confident single match** — report the routing decision using `skills/j-route/SKILL.md`'s **Step 7 — Report Routing Decision** format (substitute `/jenga` for `/route` as the invoking command named in the report), then invoke the matched skill exactly as `skills/j-route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does: load `agents/<prefered_agent>.md` when the matched skill specifies `metadata.prefered_agent`, otherwise execute the skill instructions directly. The matched skill's own execution takes over from here — do not continue into this `/jenga` invocation's Phase 1.
 4. **No match, or an ambiguous multi-way tie (single-skill match)** — before surfacing `/route`'s generic disambiguation options, attempt a **playbook fallback** (E53_S02): invoke `skills/jenga/scripts/match-playbook.sh "<raw_argument>"`. This step only ever runs when step 3 above did NOT already commit to a confident single-skill match — a confident single-skill match always wins outright and this playbook fallback is never even invoked in that case. Branch on `match-playbook.sh`'s `classification` field:
    - `playbook_match` → continue to **step 5 (Playbook proposal and execution)** below.
    - `ambiguous` or `no_match` → continue to **step 6 (Fall through to `/route`'s disambiguation)** below — the exact behavior this branch already had before E53_S02, unchanged.
@@ -208,12 +208,12 @@ This branch is entered when `detect-nl-intent.sh` classifies the argument as `nl
          - **Apply the transform** — when both `forward_from` (successfully resolved immediately above) and `resolve` are present, use your own LLM judgment to reshape/filter/type-bridge the forwarded value per `resolve`'s natural-language instructions (e.g. "pick the first three items", "convert this file_list to a text summary"). The transformed value — never the raw forwarded value — becomes this step's actual invocation input.
          - **Hard-fail, never silent pass-through** — if the transform cannot cleanly produce a usable, type-compatible result (the instructions don't plausibly apply to the actual value, the value is empty/malformed for what's being asked, or the result would not plausibly satisfy the target step's expected input shape), do **not** invoke this step and do **not** guess or pass through a differently-shaped value. Instead call `skills/jenga/scripts/run-playbook-step.sh advance <state_file> failed "<note>"`, where `<note>` follows the format `resolve failed on step '<step name>': could not apply "<resolve text>" to raw value <raw pre-transform value> — <short reason>` (the raw pre-transform value is always included, for debugging). Then follow the `halted` handling in 5e-vi below exactly as any other step failure — immediately stop executing further steps, report `failed_step`/`failed_note`/`completed`/`skipped`/`never_run` verbatim.
 
-         Then invoke the step exactly as `skills/route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does for a single matched skill: load `agents/<prefered_agent>.md` when that step's own `SKILL.md` specifies `metadata.prefered_agent`, otherwise execute its instructions directly.
+         Then invoke the step exactly as `skills/j-route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does for a single matched skill: load `agents/<prefered_agent>.md` when that step's own `SKILL.md` specifies `metadata.prefered_agent`, otherwise execute its instructions directly.
       iii. After a normally-invoked step's execution concludes, call `skills/jenga/scripts/run-playbook-step.sh advance <state_file> passed ["<typed-output-value>"]` (the step completed successfully — supply the step's declared typed output, per its `output_types`, if it produced one) or `... advance <state_file> failed "<short failure note>"` (the step failed).
       iv. On a `step_ready` result, repeat step 5e for the newly-named step.
       v. On a `complete` result, report the full lists of `completed` AND `skipped` steps to the user and stop — the playbook run is finished; do not continue into this `/jenga` invocation's Phase 1.
       vi. On a `halted` result, **immediately stop executing any further steps** — no silent skip-ahead. Report `failed_step`, `failed_note`, `completed`, `skipped` (steps that already finished or were skipped), and `never_run` (steps that never got a chance to run) to the user verbatim from the halt report. Do not continue into this `/jenga` invocation's Phase 1.
-6. **Fall through to `/route`'s disambiguation** — entered when step 4 found no playbook match (`ambiguous` or `no_match`). Surface the same disambiguation options `skills/route/SKILL.md`'s **Step 2** already defines for these cases (browse `/help`, create a new skill via `/btw`, or proceed with the raw prompt) by reference to that section — do not re-copy its prose. Halt this `/jenga` invocation once the user picks an option; none of Phase 0.75's remaining steps or Phases 1-4 run for this branch.
+6. **Fall through to `/route`'s disambiguation** — entered when step 4 found no playbook match (`ambiguous` or `no_match`). Surface the same disambiguation options `skills/j-route/SKILL.md`'s **Step 2** already defines for these cases (browse `/help`, create a new skill via `/btw`, or proceed with the raw prompt) by reference to that section — do not re-copy its prose. Halt this `/jenga` invocation once the user picks an option; none of Phase 0.75's remaining steps or Phases 1-4 run for this branch.
 
 #### Shared confirmation step (bare and scoped branches only)
 
@@ -228,6 +228,39 @@ After this phase completes (bare and scoped branches via confirmation, wildcard
 
 ---
 
+### Phase 0.9 — Generate the Run's Shared `orchestrator_session_id`
+
+This phase runs for every entry mode that reaches Phase 1 at all — bare, scoped, and wildcard (`*`) —
+immediately after Phase 0.75 completes and before Phase 1 begins. It does not run for the
+natural-language branch's playbook/single-skill-match outcomes (E53_S01/E53_S02), since those hand off
+entirely to another skill or playbook and never reach Phase 1-4 of this document.
+
+Generate exactly **one** `orchestrator_session_id` for this entire `/jenga` run, here and only here.
+Both Phase 3.5's bundle dispatch and Phase 4's first (and every later) wave dispatch need this same
+value, which is why it is generated once, early, before either call site runs.
+
+**Format.** Generate it as `jenga-<UTC ISO 8601 basic-format timestamp>` (e.g.
+`jenga-20260917T162349Z`) — a short prefix naming the orchestrating skill, plus a UTC timestamp, with no
+`/` or `..` characters. This follows the same session-id string convention this repo already uses for
+other orchestrator-minted session ids (e.g. `/do`'s own dispatch sessions), and stays compatible with
+`scripts/acquire-concurrency-slot.sh`'s own validation, which refuses a `<session_id>` argument
+containing a path separator or traversal sequence, because the value is used verbatim in filenames such
+as `project/queue/concurrency-slots-<session_id>.json`.
+
+**Generate once, reuse everywhere in this run — never regenerate.** This value MUST be reused,
+byte-for-byte unchanged, across:
+- Phase 3.5 step 7b's bundle `/do <E##_S##>` call.
+- Every wave dispatched by Phase 4 step 3, across every loop-back at Phase 4 step 5b. The loop-back
+  never mints a new value — it only ever references the one value generated here.
+
+This is what allows `E32_S15`'s per-session `max_concurrent_developers`/`max_concurrent_testers` cap
+(`skills/j-do/SKILL.md`'s `### 4.4`) to actually contend across an entire `/jenga` run's dispatches,
+instead of every spawned `/do` sub-agent minting its own private `orchestrator_session_id` and getting
+its own private, uncontended `project/queue/concurrency-slots-<id>.json` counter file — the root-cause
+defect this story (`E32_S16`) fixes.
+
+---
+
 ### Phase 1 — Decompose Epics into Stories
 
 If Phase 0.75 produced a scoped set, restrict this phase to epics that are members of that set (directly selected, or flagged in its `undecomposed` list). Under `/jenga *`, this phase is unrestricted, exactly as before.
@@ -272,7 +305,7 @@ For each in-scope story that has one or more tasks listed in `todo.md`:
       BUNDLE DETECTED: story <E##_S##> — <N> story-scoped tasks will execute as a bundle.
       ```
       where `<E##_S##>` is the story ID and `<N>` is the count of tasks in the list.
-   b. Call `/do <E##_S##>` once (with the story ID, not individual task IDs). This invokes the bundle execution path in `/do` (implemented in E32_S05_T02), which runs all tasks sequentially in one shared worktree.
+   b. Call `/do <E##_S##>` once (with the story ID, not individual task IDs), passing this run's shared `orchestrator_session_id` (generated once in Phase 0.9) into the bundle's sender object as its `session_id` field — a caller-supplied session id per `skills/j-do/SKILL.md`'s standalone-vs-caller-supplied contract (`### 4.4`/`### 5`, `E32_S16_T02`), so the bundle path's own `### 4.4` slot acquire shares this run's one counter file too, rather than minting a private one. This invokes the bundle execution path in `/do` (implemented in E32_S05_T02), which runs all tasks sequentially in one shared worktree.
    c. **Mark these tasks as bundled** — record their task IDs so Phase 4 skips individual dispatch for them.
 8. **Non-bundle stories** — stories with a mixed scope, a zero-length task list, any task missing `execution_scope: story`, or any task with `crucial_level: locked` (step 5) use the normal per-task dispatch in Phase 4 without any change.
 
@@ -282,11 +315,11 @@ Loop through `todo.md` and execute all eligible items, running independent ones
 
 1. **Collect eligible items** — from `todo.md`, find all items whose board file has `status: Pending` and no unresolved dependencies, **excluding tasks already dispatched as part of a story bundle in Phase 3.5**. If Phase 0.75 produced a scoped set, also exclude any item not a member of that set — execution never runs outside the confirmed/resolved scope. Under `/jenga *`, no such exclusion applies. A dependency is resolved if the blocking item's status is at least `In Progress` or `Passed`.
 2. **Group by parallelism** — items with no shared dependencies and no overlapping output files can run concurrently. Items that depend on each other must be sequenced.
-3. **Invoke `/do` in parallel** — launch each independent item as a **background sub-agent** simultaneously. Do not wait for one to finish before starting another if they are independent.
+3. **Invoke `/do` in parallel** — launch each independent item as a **background sub-agent** simultaneously. Do not wait for one to finish before starting another if they are independent. Pass this run's shared `orchestrator_session_id` (generated once in Phase 0.9, unchanged across every wave) into each sub-agent's sender object as its `session_id` field, per `assets/sender_template.json`'s existing shape and `skills/j-do/SKILL.md`'s caller-supplied-session-id case (`### 4.4`/`### 5`, `E32_S16_T02`) — this is what lets `E32_S15`'s per-session developer/tester concurrency cap actually contend across every sub-agent dispatched within (and across) this run's waves, instead of each one minting its own private session id and its own private, uncontended counter file.
 4. **Mark In Progress** — update `status: In Progress` in each launched item's board file (YAML front-matter) immediately after launch.
 5. **Wait, drain, and loop** — once all active background agents in the wave have completed:
    a. **Drain the scrum triggers queue** — invoke the `## Drain Scrum Triggers Queue` procedure from `agents/scrum-master.md` against `project/queue/scrum_triggers.jsonl`. `/jenga`'s orchestrating agent is the scrum-master, and this is the same session-start procedure applied mid-run: process any `rapport_review`, `status_review`, and `story_rollup` triggers written by the tester sub-sessions that just completed, then clear the file. This ensures rollups become visible on the board (story/epic status updates) before the next wave is collected, instead of sitting unprocessed until some future scrum-master session start.
-   b. **Return to step 1** of this phase to pick up any newly unblocked items — including items unblocked by the rollups just processed in (a).
+   b. **Return to step 1** of this phase to pick up any newly unblocked items — including items unblocked by the rollups just processed in (a). This loop-back reuses the SAME `orchestrator_session_id` generated once in Phase 0.9 for every subsequent wave's `/do` dispatches — it is never regenerated here or anywhere else in this phase.
 
 ### Exit condition
 
@@ -312,8 +345,8 @@ When no eligible candidates remain in Phase 4, exit and output:
 - **Picker cancelled (bare branch)** — the entire `/jenga` run halts immediately after relaying the cancellation acknowledgement; no phase past 0.75 runs, and nothing on the board is modified.
 - **Confirmation cancelled (bare or scoped branch)** — same as picker cancellation: the entire `/jenga` run halts immediately; no scoped set is produced and no later phase runs.
 - **`detect-nl-intent.sh` classifies the argument as `mixed` (scoped branch)** — the whole invocation halts at Phase 0.75 with each rejected segment's `input`/`reason` reported verbatim, per `detect-nl-intent.sh`'s own classification contract (E53_S01_T01); no partial scope is assembled from the segments that did resolve, and no fallback guess is made for the rejected ones. The user must re-invoke `/jenga <ids>` with corrected input.
-- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` (E53_S02) also finds no playbook match** — the natural-language branch's step 4 attempts the playbook fallback first (see the Natural-language branch's step 4/6), and only THEN surfaces `skills/route/SKILL.md`'s Step 2 no-match disambiguation options (browse `/help`, create a new skill via `/btw`, proceed with the raw prompt) instead of guessing; no phase past 0.75 runs until the user picks one.
-- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` returns an ambiguous multi-way tie between playbooks** — treated the same as the no-playbook-match case above: falls through to `skills/route/SKILL.md`'s Step 2 tie-break prompt (top candidates + a "neither, describe what you need" option) instead of guessing; no phase past 0.75 runs until the user picks one. (`match-playbook.sh`'s own `ambiguous` result — a tie between playbooks — is intentionally not given its own separate disambiguation UI; it is treated identically to `no_match` and routed to the same `/route` Step 2 fallback prose, which already has its own tie-break handling.)
+- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` (E53_S02) also finds no playbook match** — the natural-language branch's step 4 attempts the playbook fallback first (see the Natural-language branch's step 4/6), and only THEN surfaces `skills/j-route/SKILL.md`'s Step 2 no-match disambiguation options (browse `/help`, create a new skill via `/btw`, proceed with the raw prompt) instead of guessing; no phase past 0.75 runs until the user picks one.
+- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` returns an ambiguous multi-way tie between playbooks** — treated the same as the no-playbook-match case above: falls through to `skills/j-route/SKILL.md`'s Step 2 tie-break prompt (top candidates + a "neither, describe what you need" option) instead of guessing; no phase past 0.75 runs until the user picks one. (`match-playbook.sh`'s own `ambiguous` result — a tie between playbooks — is intentionally not given its own separate disambiguation UI; it is treated identically to `no_match` and routed to the same `/route` Step 2 fallback prose, which already has its own tie-break handling.)
 - **`match-playbook.sh` returns `playbook_match` and the user confirms the full chain, and every step succeeds** — the Natural-language branch's step 5e reports the full `completed` AND `skipped` steps lists to the user and stops; `/jenga`'s own Phase 1 never runs for this invocation (execution was already fully handled by the playbook's own steps, e.g. `j.do`/`j.dev-done`).
 - **`match-playbook.sh` returns `playbook_match` but the user cancels at the chain confirmation step (step 5c)** — identical posture to the existing picker/confirmation cancellation cases above: the entire `/jenga` run halts immediately after relaying the cancellation acknowledgement, with NO step of the chain executed; nothing on the board is modified by this invocation.
 - **`match-playbook.sh` returns `playbook_match`, the user confirms, and a step mid-chain fails** — the Natural-language branch's step 5e(vi) halts immediately on `run-playbook-step.sh`'s `halted` result: no step after the failed one runs (no silent skip-ahead), and the user is shown exactly which steps already completed or were skipped, which step failed (with its note), and which steps never ran.
@@ -329,3 +362,4 @@ When no eligible candidates remain in Phase 4, exit and output:
 - **A playbook step carries composition origin metadata (depth > 1), shown at confirmation (`E53_S05_T03`)** — the Natural-language branch's step 5b relays `render-playbook-confirmation.sh`'s rendered chain, which now visibly indents and labels that step's line with "(from playbook: <id>, depth N)" — composing another playbook's steps into a chain never hides where one playbook ends and another begins from the user, even though the whole chain is still ONE numbered, editable, confirmable list (never a separate confirmation per nested playbook) and checking/unchecking a composed step still works exactly like any other step.
 - **`/jenga *` (wildcard branch)** — never produces a scoped set; Phases 1-4 run fully unrestricted over the entire board, identical to `/jenga`'s behavior before Phase 0.75 existed.
 - **Stale out-of-scope story queued in `todo.md` from an earlier run (scoped run only)** — Phase 3.5's scoped-set guard skips it entirely (not considered for bundling), so it cannot be dispatched via a bundle `/do <E##_S##>` call that would otherwise bypass Phase 4's own scoped-set exclusion; it remains untouched in `todo.md` until a future run's scope includes it.
+- **`orchestrator_session_id` reuse across waves and phases (`E32_S16_T01`)** — the value generated once in Phase 0.9 is the exact same value threaded into Phase 3.5's bundle `/do` call and into every wave's `/do` sub-agent sender objects dispatched by Phase 4, for the entire duration of a single `/jenga` run; Phase 4 step 5b's loop-back never mints a new one. A run that halts before Phase 0.9 completes (e.g. cancelled at Phase 0.75's picker/confirmation) never reaches Phase 3.5 or Phase 4, so the value it would have generated is simply never used.

package/skills/jenga/playbooks/board-hygiene.json

@@ -0,0 +1,32 @@
+{
+  "id": "board-hygiene",
+  "name": "Board Hygiene",
+  "description": "Reconciles the scrum board against what is actually implemented, captures whatever drift that turns up as follow-up todos, and reports the resulting board state -- a read-only triage chain that writes no code and produces no commit of its own.",
+  "keywords": [
+    "board hygiene",
+    "board triage",
+    "board health",
+    "tidy the board",
+    "board audit"
+  ],
+  "examples": [
+    "reconcile the board, capture whatever drift you find as todos, then show me the status",
+    "do a full board hygiene pass -- sync it with what's really implemented, queue follow-ups for anything off, and report where we stand",
+    "check the board against reality, turn any discrepancies into todo items, and give me an overview at the end",
+    "the board feels out of sync -- triage it, capture the fixes, and summarise the state afterwards",
+    "audit the board end to end and only queue follow-up work if something is actually wrong"
+  ],
+  "steps": [
+    "j-reconcile",
+    {
+      "skill": "j-todo",
+      "forward_from": "j-reconcile",
+      "conditional": {
+        "depends_on": "j-reconcile",
+        "predicate": "non_empty"
+      },
+      "instruction": "capture each reconciliation finding as a follow-up todo"
+    },
+    "j-status"
+  ]
+}

package/skills/jenga/playbooks/schema.json

@@ -2,7 +2,7 @@
   "$schema": "http://json-schema.org/draft-07/schema#",
   "$id": "https://jenga.local/schemas/jenga-playbook.schema.json",
   "title": "Jenga Multi-Skill Playbook",
-  "description": "Schema for a single multi-skill playbook definition consumed by skills/jenga/scripts/load-playbooks.sh (E53_S02_T01). A playbook is a dedicated, versionable data file describing an ORDERED chain of skills that /jenga's natural-language branch may propose (as an editable, confirmable numbered list -- see skills/jenga/scripts/render-playbook-confirmation.sh, E53_S02_T03) when free-text intent spans more than one skill and does not cleanly resolve to a single one via skills/route/SKILL.md's Step 2 matching. This file itself (schema.json) is never treated as a playbook -- load-playbooks.sh explicitly excludes it by filename when scanning skills/jenga/playbooks/*.json.",
+  "description": "Schema for a single multi-skill playbook definition consumed by skills/jenga/scripts/load-playbooks.sh (E53_S02_T01). A playbook is a dedicated, versionable data file describing an ORDERED chain of skills that /jenga's natural-language branch may propose (as an editable, confirmable numbered list -- see skills/jenga/scripts/render-playbook-confirmation.sh, E53_S02_T03) when free-text intent spans more than one skill and does not cleanly resolve to a single one via skills/j-route/SKILL.md's Step 2 matching. This file itself (schema.json) is never treated as a playbook -- load-playbooks.sh explicitly excludes it by filename when scanning skills/jenga/playbooks/*.json.",
   "type": "object",
   "required": ["id", "name", "description", "keywords", "examples", "steps"],
   "additionalProperties": false,
@@ -18,25 +18,92 @@
     },
     "description": {
       "type": "string",
-      "description": "One-sentence explanation of what this playbook accomplishes end-to-end, used as the lowest-priority match signal (description match, same as skills/route/SKILL.md's Step 2 Pass 3) when keywords/examples don't produce a confident match."
+      "description": "One-sentence explanation of what this playbook accomplishes end-to-end, used as the lowest-priority match signal (description match, same as skills/j-route/SKILL.md's Step 2 Pass 3) when keywords/examples don't produce a confident match."
     },
     "keywords": {
       "type": "array",
-      "description": "Short phrases (1-3 words) for verbatim, case-insensitive keyword matching against the raw natural-language prompt -- the highest-priority match signal (Pass 1), mirroring skills/route/SKILL.md's Step 2 Pass 1 semantics exactly, but scoped to this playbook's catalog rather than the single-skill catalog.",
+      "description": "Short phrases (1-3 words) for verbatim, case-insensitive keyword matching against the raw natural-language prompt -- the highest-priority match signal (Pass 1), mirroring skills/j-route/SKILL.md's Step 2 Pass 1 semantics exactly, but scoped to this playbook's catalog rather than the single-skill catalog.",
       "items": { "type": "string" },
       "minItems": 1
     },
     "examples": {
       "type": "array",
-      "description": "Natural-language example prompts a user might type that should resolve to this playbook. Used for the semantic similarity match (Pass 2), mirroring skills/route/SKILL.md's Step 2 Pass 2 semantics. At least one example must plausibly span the full breadth of this playbook's steps (not just its first step) so it is distinguishable from a plain single-skill match.",
+      "description": "Natural-language example prompts a user might type that should resolve to this playbook. Used for the semantic similarity match (Pass 2), mirroring skills/j-route/SKILL.md's Step 2 Pass 2 semantics. At least one example must plausibly span the full breadth of this playbook's steps (not just its first step) so it is distinguishable from a plain single-skill match.",
       "items": { "type": "string" },
       "minItems": 1
     },
     "steps": {
       "type": "array",
-      "description": "Ordered list of canonical skill DIRECTORY names (the directory under skills/<dir>/SKILL.md, e.g. \"j-brainstorm\", not the \"j.brainstorm\" frontmatter/invocation form and not the retired bare \"brainstorm\") that make up this playbook's chain, in the exact execution order. Per E50_S10's canonical naming contract the canonical directory is skills/j-<name>/, so a step value carries the j- prefix; the three permanent exceptions (jenga, jenga-permission-level, index) keep their bare directory names and are written bare. Each entry MUST resolve to an existing skills/<dir>/SKILL.md at load time -- load-playbooks.sh skips (with a stderr warning) any playbook referencing a nonexistent skill rather than silently including a broken chain in the catalog.",
-      "items": { "type": "string" },
+      "description": "Ordered list of steps making up this playbook's chain, in the exact execution order. A step is either a BARE STRING or a STEPOBJECT (E53_S03; composition added by E53_S05). A bare string is shorthand for {\"skill\": \"<name>\"} -- \"bare\" describes the JSON shape, never a bare skill NAME. A skill name is always a canonical skill DIRECTORY name (the directory under skills/<dir>/SKILL.md, e.g. \"j-brainstorm\", not the \"j.brainstorm\" frontmatter/invocation form and not the retired bare \"brainstorm\"); per E50_S10's canonical naming contract the canonical directory is skills/j-<name>/, so a step value carries the j- prefix, while the three permanent exceptions (jenga, jenga-permission-level, index) keep their bare directory names and are written bare. Each skill name MUST resolve to an existing skills/<dir>/SKILL.md at load time -- load-playbooks.sh skips (with a stderr warning) any playbook referencing a nonexistent skill rather than silently including a broken chain in the catalog. NOTE: this schema documents SHAPE only. The cross-step rules -- forward_from naming an EARLIER step whose skill declares a non-empty output_types, conditional.depends_on naming an EARLIER step, composition cycle/depth limits -- are not expressible here and are enforced by load-playbooks.sh, which remains the single source of truth for validation.",
+      "items": {
+        "oneOf": [
+          {
+            "type": "string",
+            "description": "Bare-string step: shorthand for {\"skill\": \"<name>\"}, unchanged original behavior. An all-bare-string playbook loads byte-for-byte the same as it did before E53_S03, and a bare-string step is never rewritten into object form in the loader's output."
+          },
+          { "$ref": "#/definitions/stepObject" }
+        ]
+      },
       "minItems": 2
     }
+  },
+  "definitions": {
+    "stepObject": {
+      "type": "object",
+      "description": "A StepObject step (E53_S03_T01). Carries EXACTLY ONE of the mutually exclusive target fields `skill` or `playbook` -- a step naming both, or naming neither, is rejected by load-playbooks.sh.",
+      "additionalProperties": false,
+      "oneOf": [
+        { "required": ["skill"], "not": { "required": ["playbook"] } },
+        { "required": ["playbook"], "not": { "required": ["skill"] } }
+      ],
+      "properties": {
+        "skill": {
+          "type": "string",
+          "description": "Invokes a single skill, same as a bare string. Value is a canonical skill directory name (see the `steps` description above)."
+        },
+        "playbook": {
+          "type": "string",
+          "description": "Composes another playbook by ID (E53_S05). Resolved and flattened in place at load time, so the emitted catalog's `steps` array never contains a raw playbook-type entry. Existence validation, cycle detection, and a configurable nesting-depth limit (project/configs/playbook-config.json's max_composition_depth, default 3) all apply."
+        },
+        "instruction": {
+          "type": "string",
+          "description": "Static natural-language text appended to this step's own invocation message."
+        },
+        "forward_from": {
+          "type": "string",
+          "description": "Names an EARLIER step in the same playbook (by that step's skill name) whose typed output becomes this step's actual invocation input. The named source's SKILL.md must declare a non-empty output_types -- a skill declaring nothing can never be a forward source. Transparent across composition boundaries, since composition resolution runs before this validation."
+        },
+        "resolve": {
+          "type": "string",
+          "description": "Natural-language instructions for reshaping/filtering/type-bridging the value forwarded into this step (e.g. \"pick the first three items\"). A step carrying both `resolve` and `playbook` is rejected at load time: resolve may never pre-authorize a downstream confirmation gate (E53_S07's safety review, permanently rejected)."
+        },
+        "conditional": {
+          "type": "object",
+          "description": "Runs this step only when the predicate holds against a named earlier step's captured output; otherwise the step is marked `skipped` and the chain continues without halting (E53_S04_T02). Unlike forward_from, this does NOT require the depended-on step to declare output_types.",
+          "additionalProperties": false,
+          "required": ["depends_on", "predicate"],
+          "properties": {
+            "depends_on": {
+              "type": "string",
+              "description": "Names an EARLIER skill step in this playbook whose captured output the predicate is evaluated against.",
+              "minLength": 1
+            },
+            "predicate": {
+              "type": "string",
+              "description": "The recognized predicate grammar, whose single source of truth is skills/jenga/scripts/run-playbook-step.sh: non_empty | empty | equals:<value> | not_equals:<value>.",
+              "pattern": "^(non_empty|empty|equals:.+|not_equals:.+)$"
+            }
+          }
+        },
+        "version": {
+          "type": "string",
+          "description": "RESERVED, currently a no-op. Accepted and passed through unchanged; not acted upon by anything yet. Exists so a future schema revision has a place to declare itself without a retroactive migration of every existing playbook."
+        },
+        "schema_version": {
+          "type": "string",
+          "description": "Alternate key name for `version`. Same reserved no-op semantics."
+        }
+      }
+    }
   }
 }

package/skills/jenga/playbooks/understand-then-commit.json

@@ -0,0 +1,19 @@
+{
+  "id": "understand-then-commit",
+  "name": "Understand Then Build",
+  "description": "Investigates existing or unfamiliar code first, then runs the full idea-to-commit pipeline on top of what was learned -- a composed chain built from the canonical idea-to-committed playbook, terminating at the commit.",
+  "keywords": [
+    "understand then build",
+    "investigate then build",
+    "explore then implement",
+    "onboard and build",
+    "learn the codebase first"
+  ],
+  "examples": [
+    "help me understand this codebase first, then plan a change here, build it, and commit it",
+    "investigate this existing code, then take an idea through planning, implementation, and a commit",
+    "look into what's already here, then brainstorm a fix, build it, and commit the work",
+    "onboard me to this project and then walk a new idea from planning through to a committed change"
+  ],
+  "steps": ["j-uncharted", {"playbook": "idea-to-committed"}]
+}

package/skills/jenga/scripts/load-nl-catalog.sh

@@ -46,7 +46,7 @@ fi
 
 # Resolve the jenga-agent PACKAGE root (where lib/generate-skill-allow-list.js and the canonical
 # skills/ tree actually live) — same monorepo-checkout vs. installed-npm-package detection used
-# by skills/init/scripts/init.sh's PKG_ROOT resolution.
+# by skills/j-init/scripts/init.sh's PKG_ROOT resolution.
 if [ -d "$SCRIPT_DIR/../../../templates" ]; then
   PKG_ROOT="$SCRIPT_DIR/../../.."
 elif [ -d "$JENGA_PROJECT_DIR/node_modules/@jenga-ai/agent/templates" ]; then

package/skills/jenga/scripts/load-playbooks.sh

@@ -474,7 +474,7 @@ else
 
   # Resolve the jenga-agent PACKAGE root (where the canonical skills/ tree actually lives) — same
   # monorepo-checkout vs. installed-npm-package detection used by
-  # skills/jenga/scripts/load-nl-catalog.sh's PKG_ROOT resolution and skills/init/scripts/init.sh.
+  # skills/jenga/scripts/load-nl-catalog.sh's PKG_ROOT resolution and skills/j-init/scripts/init.sh.
   if [ -d "$SCRIPT_DIR/../../../templates" ]; then
     PKG_ROOT="$SCRIPT_DIR/../../.."
     PROJECT_DIR="$JENGA_PROJECT_DIR"

package/skills/jenga/scripts/match-playbook.sh

@@ -3,7 +3,7 @@
 # skills/jenga/scripts/match-playbook.sh
 #
 # Deterministic PLAYBOOK matcher for `/jenga`'s natural-language branch (E53_S02_T02). Runs the
-# same three-pass matching *philosophy* as `skills/route/SKILL.md`'s Step 2 (keyword ->
+# same three-pass matching *philosophy* as `skills/j-route/SKILL.md`'s Step 2 (keyword ->
 # example similarity -> description), but scoped to the playbook catalog produced by
 # `load-playbooks.sh` (E53_S02_T01) instead of the single-skill catalog `load-nl-catalog.sh`
 # produces for `/route`/`/jenga`'s existing single-skill matching.

package/templates/SCRUM_BOARD_SCHEMA.md

@@ -297,7 +297,7 @@ currently gates on its presence.
 
 ### `[SPIKE]` — Bounded Research
 
-**Scope:** story and task level only.
+**Scope:** story and task level, **and rapports** (extended by `E35_S03_T01`, see below).
 
 **Meaning:** a time-boxed research or exploration effort whose output is a decision, a design note,
 or an answered question — **not** shippable implementation code. Existing usage (`E06_S03_spike-editable-board.md`,
@@ -312,6 +312,19 @@ or an answered question — **not** shippable implementation code. Existing usag
 `[SPIKE]` predates this document; this section formalizes an existing informal convention rather
 than introducing new behavior.
 
+**Rapport scope extension (`E35_S03_T01`):** `[SPIKE]` also applies to a problem rapport (see
+`project/rapports/problems/`) via the same title-text convention — a `[SPIKE] <Topic>` prefix on
+the rapport's own title/header field, not a frontmatter key (rapports don't carry board
+frontmatter at all). This marks a rapport as itself surfacing a bounded research question or a
+distinct idea worth tracking, independent of whatever problem the rapport was originally filed
+to report. In practice this happens as part of the idea-lifecycle outcome-record mechanism
+(`E35_S03`): when a `project/ideas.md` entry that originated from a rapport (see
+`skills/idea/SKILL.md`'s "Source-Rapport Link Convention") is later promoted or rejected, the
+outcome-record step updates that rapport with the decision and prefixes its title `[SPIKE]` if
+it isn't already tagged. As with the story/task usage above, this is advisory only — nothing
+validates or enforces the prefix's presence, and a rapport's normal `Type:`/`Related
+Epic/Story/Task` fields (per `templates/PROBLEM_RAPPORT_TEMPLATE.md`) are unaffected by it.
+
 ### `[ARCH]` — Durable Architectural Inventory
 
 **Scope:** epic, story, and task level. This is the **first tag extended to epic level** — `[SPIKE]`

package/templates/SKILL_TEMPLATE.md

@@ -3,8 +3,20 @@ name: <skill-name>
 description: <One-sentence description of what this skill does and when to use it.>
 metadata:
   prefered_agent: <agent-name>   # optional — remove if not applicable
+output_types: <type>             # optional — forwardable output type(s) this skill produces; a single
+                                 #   type string or a list of {when, type} entries. Declare only if this
+                                 #   skill genuinely produces output a playbook step could consume
+                                 #   (honesty over breadth, E53_S11). Remove if not applicable.
+input_types: <type>              # optional — forwarded input type(s) this skill accepts; same two
+                                 #   shapes as output_types. May be broadly declared — honesty over
+                                 #   breadth is scoped to output_types only (E62_S01_T03).
+                                 #   Remove if not applicable.
 ---
 
+> Type values come from the canonical vocabulary in `templates/playbook-types.json`. See
+> `docs/skill-authoring.md`'s `output_types` and `input_types` sections for the full contract,
+> including the `text` rule and the normalize-versus-convert boundary.
+
 # <Skill Title> — <Short tagline>
 
 ## Instructions

package/templates/permission-levels/level-4-elevated.json

@@ -6,7 +6,7 @@
   "autoMode": {
     "allow": [
       "$defaults",
-      "Bash(bash skills/mirror-public/scripts/mirror.sh*)"
+      "Bash(bash skills/j-mirror-public/scripts/mirror.sh*)"
     ]
   },
   "permissions": {

package/templates/permission-levels/level-5-unrestricted.json

@@ -6,7 +6,7 @@
   "autoMode": {
     "allow": [
       "$defaults",
-      "Bash(bash skills/mirror-public/scripts/mirror.sh*)"
+      "Bash(bash skills/j-mirror-public/scripts/mirror.sh*)"
     ]
   },
   "permissions": {