@jenga-ai/agent 2.0.0 → 3.0.0

package/skills/{reconcile-origin → j-reconcile-origin}/SKILL.md

@@ -1,19 +1,26 @@
 ---
-name: j:reconcile-origin
-description: Sync the current (or specified) branch with origin by rebasing local commits on top of the latest upstream state.
+name: j.reconcile-origin
+description: Polyfill alias of the reconcile-origin skill under a collision-safe directory name. Identical behavior to /reconcile-origin — Sync the current (or specified) branch with origin by rebasing local commits on top of the latest upstream state. Use when the bare /reconcile-origin form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - "sync branch"
   - "rebase origin"
   - "reconcile origin"
   - "pull rebase"
+  - j-reconcile-origin
+  - polyfill
 examples:
   - "sync my branch with origin"
   - "rebase local commits on top of origin"
   - "reconcile-origin feature/my-branch"
+  - "j-reconcile-origin"
 ---
 
 # Reconcile Origin
 
+This skill is a literal-directory-name duplicate of `skills/reconcile-origin/`. It exists so that `/j-reconcile-origin` (and `j.j-reconcile-origin`) give a guaranteed-unshadowed way to reach the same flow as `/reconcile-origin`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/reconcile-origin` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh reconcile-origin` from `skills/reconcile-origin/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 Use this skill to rebase local work on top of the latest `origin/<branch>` state without re-implementing git logic inline.
 
 ## Instructions
@@ -22,7 +29,7 @@ Use this skill to rebase local work on top of the latest `origin/<branch>` state
    - If the user passed an argument, use that branch name.
    - Otherwise, use the current branch name.
 
-2. Invoke `.agents/skills/reconcile-origin/scripts/reconcile-origin.sh [<branch>]` and capture stdout.
+2. Invoke `.agents/skills/j-reconcile-origin/scripts/reconcile-origin.sh [<branch>]` and capture stdout.
    - Do not run any inline git commands in this skill — all git work is handled by the script.
    - The script handles dirty-worktree detection internally and returns `{"status":"error","code":"uncommitted_changes",...}` if the working tree is not clean.
 
@@ -38,7 +45,7 @@ Use this skill to rebase local work on top of the latest `origin/<branch>` state
        2. Cancel and inspect the branch setup manually
        3. Other (describe below)
 
-     - If the user chooses option 1, invoke `.agents/skills/reconcile-origin/scripts/reconcile-origin.sh <branch> --create-tracking`.
+     - If the user chooses option 1, invoke `.agents/skills/j-reconcile-origin/scripts/reconcile-origin.sh <branch> --create-tracking`.
      - If `remote_exists` is `false`, explain that neither a local branch nor `origin/<branch>` was found and stop.
    - `conflict`
      - Present one structured conflict rapport per item in `conflicts`.
@@ -55,7 +62,7 @@ Use this skill to rebase local work on top of the latest `origin/<branch>` state
        3. Handle it later — leave annotated conflict markers in the file and continue the scripted flow
        4. Other (describe below)
 
-     - If the user chooses “Handle it later”, invoke `.agents/skills/reconcile-origin/scripts/reconcile-origin.sh <branch> --handle-later <file>` for the selected conflict file.
+     - If the user chooses “Handle it later”, invoke `.agents/skills/j-reconcile-origin/scripts/reconcile-origin.sh <branch> --handle-later <file>` for the selected conflict file.
    - `handled_later`
      - Confirm that the selected file was annotated for later resolution.
      - Tell the user the conflict markers were intentionally preserved with a `# RECONCILE-ORIGIN CONFLICT:` note.
@@ -71,5 +78,5 @@ Use this skill to rebase local work on top of the latest `origin/<branch>` state
 
 ## Guard Rails
 
-- All git work must go through `.agents/skills/reconcile-origin/scripts/reconcile-origin.sh`.
+- All git work must go through `.agents/skills/j-reconcile-origin/scripts/reconcile-origin.sh`.
 - Do not inline fetch, checkout, pull, merge, rebase, or status commands in this skill body.

package/skills/{redo → j-redo}/SKILL.md

@@ -1,21 +1,28 @@
 ---
-name: j:redo
-description: Redo parts or entire previous implementations identified by a commit SHA or an Epic/Story number (e.g. E01, E02_S03). Expects an identifier and a description of what to redo and why. Use when the user wants to revisit, rework, or rewrite previously completed work, including updating all affected documentation.
+name: j.redo
+description: Polyfill alias of the redo skill under a collision-safe directory name. Identical behavior to /redo — Redo parts or entire previous implementations identified by a commit SHA or an Epic/Story number (e.g. E01, E02_S03). Expects an identifier and a description of what to redo and why. Use when the user wants to revisit, rework, or rewrite previously completed work, including updating all affected documentation. Use when the bare /redo form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - redo
   - rework
   - rewrite
   - revisit
   - redo task
+  - j-redo
+  - polyfill
 examples:
   - "redo the login implementation"
   - "rewrite story E02_S01"
+  - "j-redo"
 metadata: 
   prefered_agent: scrum-master
 ---
 
 # Redo — Rework a Previous Implementation
 
+This skill is a literal-directory-name duplicate of `skills/redo/`. It exists so that `/j-redo` (and `j.j-redo`) give a guaranteed-unshadowed way to reach the same flow as `/redo`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/redo` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh redo` from `skills/redo/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Input Format
 
 ```

package/skills/{skillify → j-skillify}/SKILL.md

@@ -1,10 +1,17 @@
 ---
-name: j:skillify
-description: Refactor one or more existing skills into a cleaner, more maintainable structure — extracting hardcoded content into asset files, offloading deterministic steps into scripts, and reorganizing the skill body to reflect the leaner result. Use this whenever the user wants to clean up, improve, or restructure an existing skill, mentions that a skill has hardcoded content that could be templated, or asks to "skillify", "refactor", or "tidy up" a skill. Trigger even if the user just pastes a skill and says something like "can we make this better?".
+name: j.skillify
+description: Polyfill alias of the skillify skill under a collision-safe directory name. Identical behavior to /skillify — Refactor one or more existing skills into a cleaner, more maintainable structure — extracting hardcoded content into asset files, offloading deterministic steps into scripts, and reorganizing the skill body to reflect the leaner result. Use this whenever the user wants to clean up, improve, or restructure an existing skill, mentions that a skill has hardcoded content that could be templated, or asks to "skillify", "refactor", or "tidy up" a skill. Trigger even if the user just pastes a skill and says something like "can we make this better?". Use when the bare /skillify form is shadowed by another tool's own built-in command of the same name.
+keywords:
+  - j-skillify
+  - polyfill
 ---
 
 # Skillify — Refactor a Skill into a Cleaner Structure
 
+This skill is a literal-directory-name duplicate of `skills/skillify/`. It exists so that `/j-skillify` (and `j.j-skillify`) give a guaranteed-unshadowed way to reach the same flow as `/skillify`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/skillify` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh skillify` from `skills/skillify/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## What this skill does
 
 Takes one or more existing skills and refactors them by:
@@ -65,4 +72,4 @@ The rewritten SKILL.md should:
 - `assets/init-old/SKILL.md` — The init skill before refactoring (hardcoded heredocs, inline JSON, hardcoded directory list)
 - `assets/init-new/SKILL.md` — The init skill after refactoring (all content in assets, steps delegated to `init.sh`)
 
-Read these when you need a concrete example of the before/after pattern.
+Read these when you need a concrete example of the before/after pattern.

package/skills/{spinoff → j-spinoff}/SKILL.md

@@ -1,21 +1,28 @@
 ---
-name: j:spinoff
-description: Capture a diverging topic mid-conversation. Collects context and a mandatory origin, optionally runs /brainstorm for prerequisites, saves an /idea entry, and returns focus to the primary thread.
+name: j.spinoff
+description: Polyfill alias of the spinoff skill under a collision-safe directory name. Identical behavior to /spinoff — Capture a diverging topic mid-conversation. Collects context and a mandatory origin, optionally runs /brainstorm for prerequisites, saves an /idea entry, and returns focus to the primary thread. Use when the bare /spinoff form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - spinoff
   - diverge
   - side topic
   - capture topic
   - new thread
+  - j-spinoff
+  - polyfill
 examples:
   - "let's spinoff this idea"
   - "capture this as a separate thread"
+  - "j-spinoff"
 metadata:
   prefered_agent: scrum-master
 ---
 
 # Spinoff — Capture a Diverging Topic
 
+This skill is a literal-directory-name duplicate of `skills/spinoff/`. It exists so that `/j-spinoff` (and `j.j-spinoff`) give a guaranteed-unshadowed way to reach the same flow as `/spinoff`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/spinoff` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh spinoff` from `skills/spinoff/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Instructions
 
 1. **Identify the diverging topic** — Ask the user to confirm or briefly describe the diverging topic.

package/skills/{status → j-status}/SKILL.md

@@ -1,19 +1,26 @@
 ---
-name: j:status
-description: Print a human-readable summary of the entire scrum board — all epics, stories, and tasks with their statuses — plus any open rapports and unprocessed queue triggers. Use when you want a quick overview of project state without reading raw files.
+name: j.status
+description: Polyfill alias of the status skill under a collision-safe directory name. Identical behavior to /status — Print a human-readable summary of the entire scrum board — all epics, stories, and tasks with their statuses — plus any open rapports and unprocessed queue triggers. Use when you want a quick overview of project state without reading raw files. Use when the bare /status form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - status
   - board summary
   - overview
   - project state
   - what's done
+  - j-status
+  - polyfill
 examples:
   - "show me the project status"
   - "what's the state of the board?"
+  - "j-status"
 ---
 
 # Status — Board Overview
 
+This skill is a literal-directory-name duplicate of `skills/status/`. It exists so that `/j-status` (and `j.j-status`) give a guaranteed-unshadowed way to reach the same flow as `/status`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/status` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh status` from `skills/status/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Instructions
 
 1. **Read `project/configs/workflow.json`** to confirm board paths. Fall back to `project/board/` if the file does not exist.

package/skills/{todo → j-todo}/SKILL.md

@@ -1,21 +1,28 @@
 ---
-name: j:todo
-description: 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.
+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.
 keywords:
   - todo
   - add task
   - queue work
   - backlog
   - add to list
+  - j-todo
+  - polyfill
 examples:
   - "add this to the todo list"
   - "queue this as a task"
+  - "j-todo"
 metadata: 
   prefered_agent: scrum-master
 ---
 
 # Todo — Add Missions to the Todo List
 
+This skill is a literal-directory-name duplicate of `skills/todo/`. It exists so that `/j-todo` (and `j.j-todo`) give a guaranteed-unshadowed way to reach the same flow as `/todo`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/todo` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh todo` from `skills/todo/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## `--trivial` Flag
 
 **Syntax:** `/todo --trivial <description>` — optionally combined with the same `: <Epic no.>_<Story no.>` linkage syntax normal `/todo` entries use, e.g. `/todo --trivial Fix typo in error message: E12_S03`.
@@ -58,7 +65,7 @@ When `--trivial` is present, the mission is written as a **fully-formed task boa
 
    c. **Run the helper script**, which handles everything mechanical — next task-ID assignment, writing the task board file with `execution_scope: inline` forced, registering the new task ID into the parent story's `tasks:` frontmatter list, and adding the `project/todo.md` entry using the full task ID (so `/do` routes straight into its Inline Execution Path with no redundant breakdown pass):
       ```
-      bash skills/todo/scripts/add_trivial_task.sh \
+      bash skills/j-todo/scripts/add_trivial_task.sh \
         --story <E##_S##> \
         --title "<mission title>" \
         --description "<mission description>" \

package/skills/{todo → j-todo}/assets/todo_handoff_template.md

@@ -13,7 +13,7 @@
 <!-- PLACEHOLDER: what this todo is trying to achieve -->
 
 ## Affected Files or Scope
-<!-- PLACEHOLDER: which files, modules, or areas are involved, e.g. src/auth/, skills/todo/ -->
+<!-- PLACEHOLDER: which files, modules, or areas are involved, e.g. src/auth/, skills/j-todo/ -->
 
 ## Intended Approach
 <!-- PLACEHOLDER: step-by-step or high-level approach to the work -->

package/skills/{todo → j-todo}/scripts/add_trivial_task.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# skills/todo/scripts/add_trivial_task.sh
+# skills/j-todo/scripts/add_trivial_task.sh
 #
 # Creates a fully-formed task board file for a `/todo --trivial` mission,
 # forced to execution_scope: inline unconditionally, and registers it both
@@ -10,7 +10,7 @@
 # The JUDGMENT half — estimating file/line counts and deciding what
 # execution_scope the normal heuristic in agents/scrum-master.md would have
 # assigned (computed_tier) — happens in the calling agent's instructions
-# (skills/todo/SKILL.md), per the Skill Implementation Principle: a step that
+# (skills/j-todo/SKILL.md), per the Skill Implementation Principle: a step that
 # requires reasoning about branching logic, new dependencies, etc. does not
 # belong in a script. This script never reads project/configs/scope-thresholds.json
 # or recomputes computed_tier itself — it only records what it was told.
@@ -33,7 +33,7 @@ cd "$REPO_ROOT"
 
 TASKS_DIR="project/board/tasks"
 STORIES_DIR="project/board/stories"
-UPDATE_STORY_SCRIPT="skills/todo/scripts/update_story_tasks.py"
+UPDATE_STORY_SCRIPT="skills/j-todo/scripts/update_story_tasks.py"
 
 story_id=""
 title=""

package/skills/{todo → j-todo}/scripts/update_story_tasks.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 """
-skills/todo/scripts/update_story_tasks.py
+skills/j-todo/scripts/update_story_tasks.py
 
 Mechanically inserts a task ID into a story board file's `tasks:` frontmatter
 list, if it is not already present. Idempotent (a re-run with the same
@@ -12,7 +12,7 @@ scripts/with-lock.sh, keyed to the story file, per templates/SCRUM_BOARD_SCHEMA.
 File Locking section (board frontmatter writes must go through the lock wrapper).
 
 Usage:
-    python3 skills/todo/scripts/update_story_tasks.py <story-file> <task-id>
+    python3 skills/j-todo/scripts/update_story_tasks.py <story-file> <task-id>
 
 Exit codes:
     0   success (task_id inserted, or already present)

package/skills/{uncharted → j-uncharted}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: j:uncharted
-description: Investigate code that has no Jenga board provenance — a foreign file, an external source being pulled in, or an entire pre-existing codebase — and give it a consistent understanding document plus proper board representation.
+name: j.uncharted
+description: Polyfill alias of the uncharted skill under a collision-safe directory name. Identical behavior to /uncharted — Investigate code that has no Jenga board provenance — a foreign file, an external source being pulled in, or an entire pre-existing codebase — and give it a consistent understanding document plus proper board representation. Use when the bare /uncharted form is shadowed by another tool's own built-in command of the same name.
 metadata:
   prefered_agent: scrum-master
 keywords:
@@ -12,6 +12,8 @@ keywords:
   - "import source"
   - "unlinked code"
   - "no board history"
+  - j-uncharted
+  - polyfill
 examples:
   - "what does this file actually do?"
   - "help me understand this directory I inherited"
@@ -20,10 +22,15 @@ examples:
   - "this code has no board history, get it onto the board"
   - "analyse the legacy module nobody understands"
   - "onboard this existing codebase"
+  - "j-uncharted"
 ---
 
 # Uncharted — Investigative Workflow for Foreign & Pre-Existing Code
 
+This skill is a literal-directory-name duplicate of `skills/uncharted/`. It exists so that `/j-uncharted` (and `j.j-uncharted`) give a guaranteed-unshadowed way to reach the same flow as `/uncharted`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/uncharted` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh uncharted` from `skills/uncharted/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 `/uncharted` is the entry point for code with **no board provenance** — code that was never planned, decomposed, or executed through the Jenga workflow.
 
 It fills a gap the existing investigative skills leave open:
@@ -62,7 +69,7 @@ Every mode runs the same shared investigative engine and emits the same understa
 
 ## Shared Investigative Engine
 
-All three modes call the same engine rather than reimplementing analysis. Per the Skill Implementation Principle in `CLAUDE.md`, the deterministic work lives in scripts under `skills/uncharted/scripts/`, not in this file:
+All three modes call the same engine rather than reimplementing analysis. Per the Skill Implementation Principle in `CLAUDE.md`, the deterministic work lives in scripts under `skills/j-uncharted/scripts/`, not in this file:
 
 | Script | Responsibility | Implemented by |
 |---|---|---|
@@ -74,7 +81,7 @@ All three modes call the same engine rather than reimplementing analysis. Per th
 **Invoke `run-engine.sh`, never the individual detectors.** It is the only supported entry point; calling a detector directly gets you raw JSON and no document.
 
 ```bash
-DOC=$(bash skills/uncharted/scripts/run-engine.sh --mode segment <target>)
+DOC=$(bash skills/j-uncharted/scripts/run-engine.sh --mode segment <target>)
 ```
 
 | Option | Effect |
@@ -106,7 +113,7 @@ Do not restate in prose what these scripts do step by step, and do not reimpleme
 
 ## Output: the Understanding Document
 
-Every mode produces exactly one document per target, rendered from `skills/uncharted/assets/UNDERSTANDING_DOC_TEMPLATE.md`.
+Every mode produces exactly one document per target, rendered from `skills/j-uncharted/assets/UNDERSTANDING_DOC_TEMPLATE.md`.
 
 **Where it goes:** `project/rapports/analysis/`, named `uncharted-<mode>-<slug>-<YYYYMMDDTHHMMSSZ>.md`. Nothing is ever overwritten — a name collision gets a `-2`, `-3`… suffix, so repeated runs against one target leave a diffable history.
 
@@ -170,7 +177,7 @@ Runs once per elicitation, between discovery and the first Investigative Mode di
 
 ```bash
 discover-subsystems.sh <root> | jq -r '.candidates[].path' \
-  | bash skills/uncharted/scripts/directory-triage.sh <root>
+  | bash skills/j-uncharted/scripts/directory-triage.sh <root>
 ```
 
 Read `ignored` (already excluded by `.gitignore`, or matching the fixed vendor/generated pattern list — see the script's own header for the full list) and `remaining`. This is a mechanical classification; do not second-guess it or re-run judgement over an `ignored` entry.
@@ -211,7 +218,7 @@ Runs once per surviving candidate (a subsystem, a named flow, a directory) after
 4. **Confirm/correct, one round per call to `elicitation-state.sh turn`.** For a node requiring confirmation, present the draft and ask the user to confirm or correct it (per the Interaction Pattern in `CLAUDE.md` — confirm / correct-with-detail / defer as "unconfirmed" / other). Each round, call:
 
    ```bash
-   bash skills/uncharted/scripts/elicitation-state.sh turn --id <elicitation-id> --node <node-id>
+   bash skills/j-uncharted/scripts/elicitation-state.sh turn --id <elicitation-id> --node <node-id>
    ```
 
    Exit `0` means keep looping (cap not yet reached) if the user corrected rather than confirmed. Exit `3` means **the hard turn cap has been reached** — the node is now marked `flagged` in the state file. **Do not loop again on that node.** Instead present it as unresolved and offer an explicit choice rather than looping indefinitely (solution assessment, Problem 10, Solution A — RECOMMENDED):
@@ -228,7 +235,7 @@ Runs once per surviving candidate (a subsystem, a named flow, a directory) after
 5. **On convergence** (confirmed, corrected-and-accepted, or resolved via the cap choice above), call:
 
    ```bash
-   bash skills/uncharted/scripts/elicitation-state.sh converge --id <elicitation-id> --node <node-id> --note "<one-line summary of what was confirmed>"
+   bash skills/j-uncharted/scripts/elicitation-state.sh converge --id <elicitation-id> --node <node-id> --note "<one-line summary of what was confirmed>"
    ```
 
    then write the node/edge to `project/knowledge-graph/graph.json` per the stub schema, and checkpoint the elicitation state (next section) — **after every converged node**, not only at the end of the whole run.
@@ -240,7 +247,7 @@ A whole-codebase `onboard` conversation, or an investigation of a large director
 - **`init` once, at the start of an elicitation:**
 
   ```bash
-  bash skills/uncharted/scripts/elicitation-state.sh init --id <elicitation-id> --target "<path or description>" --cap 5
+  bash skills/j-uncharted/scripts/elicitation-state.sh init --id <elicitation-id> --target "<path or description>" --cap 5
   ```
 
   Idempotent — safe to call again on a resumed `<elicitation-id>` without resetting progress. Choose `<elicitation-id>` so it is stable and re-derivable across sessions (e.g. `onboard-<root-slug>-<date>`, or `segment-investigate-<target-slug>`), since a resuming session must be able to reconstruct it to call `init` again.
@@ -288,7 +295,7 @@ Unchanged from before E20_S08_T03 — every step below is exactly what `segment`
 **Step 1 — Resolve the target.** Deterministic; do not eyeball it.
 
 ```bash
-bash skills/uncharted/scripts/resolve-segment-target.sh --json-only "<path-or-description>"
+bash skills/j-uncharted/scripts/resolve-segment-target.sh --json-only "<path-or-description>"
 ```
 
 It returns one `results[]` record. Read three fields:
@@ -310,7 +317,7 @@ It returns one `results[]` record. Read three fields:
 **Step 2 — Run the engine** on the resolved absolute path:
 
 ```bash
-DOC=$(bash skills/uncharted/scripts/run-engine.sh --mode segment "<resolved target>")
+DOC=$(bash skills/j-uncharted/scripts/run-engine.sh --mode segment "<resolved target>")
 ```
 
 Options, streams, and exit codes are in **Shared Investigative Engine** above — do not restate them here, and do not reimplement enumeration, dependency, or test detection. Two mode-specific readings:
@@ -332,7 +339,7 @@ List `project/board/epics/` and apply the normal scrum-master intake rule (`agen
 
 A new epic is the last option, not the default, and needs a stated reason. Record the epics you weighed and rejected — "none fit" is a claim the user should be able to check.
 
-**Step 5 — Draft the proposal** using `skills/uncharted/assets/SEGMENT_PROPOSAL_TEMPLATE.md`. Its six headings are fixed; fill every one of them. Two things it will not let you skip:
+**Step 5 — Draft the proposal** using `skills/j-uncharted/assets/SEGMENT_PROPOSAL_TEMPLATE.md`. Its six headings are fixed; fill every one of them. Two things it will not let you skip:
 
 - **Every proposed task carries `execution_scope` and a non-empty `scope_rationale`** containing a file-count or line-count claim, assigned against `project/configs/scope-thresholds.json` rather than by feel — `inline` at or under 1 file / 20 lines, `story` when tasks share files across the story (up to 5 files), `task` otherwise. Never self-assign `execution_scope: epic`: it requires `epic_scope_approval: true`, which only a human sets. Propose `story` and say the task looks bigger instead. Field semantics live in `templates/SCRUM_BOARD_SCHEMA.md` — read them there, do not paraphrase them here.
 - **The document's `Open Questions` carry over verbatim**, not re-derived, each with who can answer it and whether it blocks confirmation. A blocking question is resolved *before* the proposal is accepted, because the breakdown depends on its answer.
@@ -371,7 +378,7 @@ Shape, field names, and file naming come from `templates/SCRUM_BOARD_SCHEMA.md`.
 Then prove it mechanically rather than asserting it:
 
 ```bash
-bash skills/uncharted/scripts/validate-proposed-items.sh <every file just written>
+bash skills/j-uncharted/scripts/validate-proposed-items.sh <every file just written>
 ```
 
 It runs `scripts/validate-board.sh` over every file and `scripts/validate-story-format.sh` over every story file, and exits non-zero listing **each** failure — not just the first, because deciding whether to repair or roll back needs the whole list. Exit 2 means a usage error or a missing validator, not a bad board file.
@@ -395,7 +402,7 @@ New in **E20_S08_T03**. Produces a plain-language understanding plus graph nodes
 **Step 3 — Convergence loop.** Run the shared Convergence Loop procedure above. For a single-file target this is one node; for a directory target (after triage) it is one node per surviving candidate. Initialize persistence first:
 
 ```bash
-bash skills/uncharted/scripts/elicitation-state.sh init --id "segment-investigate-$(basename "$RESOLVED_TARGET")-$(date -u +%Y%m%d)" --target "$RESOLVED_TARGET"
+bash skills/j-uncharted/scripts/elicitation-state.sh init --id "segment-investigate-$(basename "$RESOLVED_TARGET")-$(date -u +%Y%m%d)" --target "$RESOLVED_TARGET"
 ```
 
 **Step 4 — On convergence, write the graph and the board item.** Write each converged node/edge to `project/knowledge-graph/graph.json` per the stub schema (`source: "human"`), then present a single `[ARCH]`-tagged board item proposal — epic, story, or task, whichever level fits what was actually investigated (a single flow is usually task-scale; a whole subsystem may warrant a story or, rarely, an epic) — and stop at the same kind of confirmation gate the delivery-shaped path's Step 6 uses (accept / revise / discard / other). **Nothing is written to `project/board/` before that gate is confirmed**, matching the delivery-shaped path's own "nothing written before option 1" guarantee. On acceptance, write the board item and call `elicitation-state.sh complete`.
@@ -416,7 +423,7 @@ Pull an external source into the repo, then investigate it as a segment.
 **Step 1 — Acquire into staging.** Deterministic; do not hand-roll a clone or a copy.
 
 ```bash
-SUMMARY_JSON=$(bash skills/uncharted/scripts/import-source.sh --json-only "<source>")
+SUMMARY_JSON=$(bash skills/j-uncharted/scripts/import-source.sh --json-only "<source>")
 ```
 
 `<source>` is a git URL, a local path **outside** this repo, or `-` (with the snippet piped
@@ -436,7 +443,7 @@ itself on failure).
 destination proposal is presented *alongside* these findings, never before them.
 
 ```bash
-PROVENANCE_JSON=$(bash skills/uncharted/scripts/inspect-provenance.sh \
+PROVENANCE_JSON=$(bash skills/j-uncharted/scripts/inspect-provenance.sh \
   --origin-source "$(echo "$SUMMARY_JSON" | jq -r .source)" \
   --origin-type   "$(echo "$SUMMARY_JSON" | jq -r .source_type)" \
   --origin-ref    "$(echo "$SUMMARY_JSON" | jq -r '.git_ref // ""')" \
@@ -616,7 +623,7 @@ convention to be onboarded. This guarantee is enforced in three independent plac
 stated here:
 
 1. **This prohibition**, read by any agent driving `onboard` mode.
-2. **A structural write-path guard** in `skills/uncharted/scripts/write-backfilled-epics.sh` — its
+2. **A structural write-path guard** in `skills/j-uncharted/scripts/write-backfilled-epics.sh` — its
    `--epics-dir` and `--json-out` destinations are canonicalised and checked against
    `<repo-root>/project/` *before* any file is written, with no flag able to point either one
    outside it. A path that resolves outside `project/` is a hard failure (exit 3), nothing
@@ -631,7 +638,7 @@ New in **E20_S08_T03**. Runs when `onboard` is invoked without `--legacy`.
 **Step 1 — discovery stays scripted.** Run the exact same deterministic discovery chain the legacy pipeline uses — `discover-subsystems.sh` — unchanged. Evidence-gathering is not where this rework touches anything; only what happens with the output differs.
 
 ```bash
-bash skills/uncharted/scripts/discover-subsystems.sh <root>
+bash skills/j-uncharted/scripts/discover-subsystems.sh <root>
 ```
 
 **Step 2 — directory triage.** Feed the discovery output's candidate paths into the shared Directory Triage procedure (see Conversational Elicitation above), and stop at its confirmation gate before anything else happens.
@@ -639,7 +646,7 @@ bash skills/uncharted/scripts/discover-subsystems.sh <root>
 **Step 3 — initialize persistence.**
 
 ```bash
-bash skills/uncharted/scripts/elicitation-state.sh init --id "onboard-$(basename "$(cd "$root" && pwd)")-$(date -u +%Y%m%d)" --target "<root>" --cap 5
+bash skills/j-uncharted/scripts/elicitation-state.sh init --id "onboard-$(basename "$(cd "$root" && pwd)")-$(date -u +%Y%m%d)" --target "<root>" --cap 5
 ```
 
 **Step 4 — convergence loop, once per surviving candidate.** Run the shared Convergence Loop procedure (see Conversational Elicitation above) for each candidate that survived triage — this is where the legacy pipeline's `apply-subsystem-cap.sh` and `write-backfilled-epics.sh` would have silently produced a capped set of `provenance: backfilled` epics; the conversational default asks about each one instead, subject to the same risk-weighted gating and hard turn cap. There is deliberately **no subsystem cap** on the conversational path — the turn cap already bounds cost per candidate, and capping the *candidate count* the way the legacy path does would silently drop subsystems from a human-in-the-loop conversation the same way the legacy path drops them from an unattended one, which defeats the point of asking. A codebase with far more subsystems than is practical to walk through conversationally in one sitting is exactly the multi-session case Multi-Session Persistence exists for — pause, resume across sessions, rather than truncate the candidate list.
@@ -656,12 +663,12 @@ Everything below is `E40_S04`'s original, fully-automated, zero-prompt pipeline
 
 Live as of `E40_S04_T03`. `onboard` does **not** create one epic per discovered subsystem — a
 40-subsystem repository would bury the board on day one. It caps how many become epics, and
-`skills/uncharted/scripts/apply-subsystem-cap.sh` applies that cap to `discover-subsystems.sh`'s
+`skills/j-uncharted/scripts/apply-subsystem-cap.sh` applies that cap to `discover-subsystems.sh`'s
 ranked output:
 
 ```bash
-bash skills/uncharted/scripts/discover-subsystems.sh <root> \
-  | bash skills/uncharted/scripts/apply-subsystem-cap.sh --rapport "$DOC"
+bash skills/j-uncharted/scripts/discover-subsystems.sh <root> \
+  | bash skills/j-uncharted/scripts/apply-subsystem-cap.sh --rapport "$DOC"
 ```
 
 It emits JSON with two explicit arrays — `kept` (the subsystems that become backfilled epics) and
@@ -702,7 +709,7 @@ re-running `onboard` with a higher `--cap`.
 
 #### Generating the backfilled epics
 
-Live as of `E40_S04_T04`. `skills/uncharted/scripts/write-backfilled-epics.sh` is the only thing
+Live as of `E40_S04_T04`. `skills/j-uncharted/scripts/write-backfilled-epics.sh` is the only thing
 that actually writes backfilled epics to the board — it consumes `apply-subsystem-cap.sh`'s
 `kept` array and renders one epic file per entry, following the Epic format in
 `templates/SCRUM_BOARD_SCHEMA.md` exactly (`provenance: backfilled`, `status: Pending`, an empty
@@ -710,9 +717,9 @@ that actually writes backfilled epics to the board — it consumes `apply-subsys
 framed around understanding and integration, never original construction):
 
 ```bash
-bash skills/uncharted/scripts/discover-subsystems.sh <root> \
-  | bash skills/uncharted/scripts/apply-subsystem-cap.sh --rapport "$DOC" \
-  | bash skills/uncharted/scripts/write-backfilled-epics.sh
+bash skills/j-uncharted/scripts/discover-subsystems.sh <root> \
+  | bash skills/j-uncharted/scripts/apply-subsystem-cap.sh --rapport "$DOC" \
+  | bash skills/j-uncharted/scripts/write-backfilled-epics.sh
 ```
 
 | Option | Effect |
@@ -775,7 +782,7 @@ above have been written (or confirmed skipped). Its job is to close the gap the
 describes: a project adopting Jenga should not end up with a populated board sitting underneath a
 `PROJECT_SUMMARY.md` that still reads as if the codebase were empty.
 
-**This is a scrum-master action, not a script.** Nothing under `skills/uncharted/scripts/` writes
+**This is a scrum-master action, not a script.** Nothing under `skills/j-uncharted/scripts/` writes
 `PROJECT_SUMMARY.md`, and the developer agent never touches it either — both `agents/developer.md`
 and `agents/scrum-master.md` already establish `PROJECT_SUMMARY.md` as scrum-master-owned, sole
 writer, no exceptions, and `onboard` does not get to be the exception just because the content
@@ -865,7 +872,7 @@ These hold across every mode:
 - **Confirm before writing to the board.** Proposals are presented for approval first, consistent with the brainstorm-before-commit convention. Since `E20_S08_T03`, this also covers Directory Triage's confirmation gate and each converged node's graph/board write in the conversational elicitation flow — same convention, applied to a new output type (graph nodes), not a new exception to it.
 - **No new rapport type.** Understanding documents use the existing `analysis` type and land in `project/rapports/analysis/`. Conversational elicitation's output (graph nodes + `[ARCH]` board items) is not an understanding document and does not need one — see Conversational Elicitation above for what it produces instead.
 - **Never invent findings.** If the evidence does not support a conclusion, say so under Open Questions (delivery-shaped/legacy paths) or state the uncertainty plainly in the node itself (conversational paths — see Human-Oracle-Availability Limitation above).
-- **Deterministic work belongs in `skills/uncharted/scripts/`**, agent judgement belongs here.
+- **Deterministic work belongs in `skills/j-uncharted/scripts/`**, agent judgement belongs here.
 - **Existing zero-prompt behavior is never silently retired.** `onboard --legacy` and `segment --mode delivery` reproduce exactly what `/uncharted` did before `E20_S08_T03`, with no behavior drift for a caller who keeps using them.
 
 ---

package/skills/{uncharted → j-uncharted}/assets/UNDERSTANDING_DOC_TEMPLATE.md

@@ -4,7 +4,7 @@
   OUTPUT CONTRACT — /uncharted shared investigative engine.
 
   Every mode (`segment`, `import`, `onboard`) emits this exact document shape.
-  It is rendered by `skills/uncharted/scripts/run-engine.sh` and written to
+  It is rendered by `skills/j-uncharted/scripts/run-engine.sh` and written to
   `project/rapports/analysis/` using the existing `analysis` rapport type
   defined in `templates/SCRUM_BOARD_SCHEMA.md`.
 
@@ -34,7 +34,7 @@
 
 **Mode:** {{MODE}}
 **Generated:** {{TIMESTAMP}}
-**Engine:** `skills/uncharted/scripts/run-engine.sh`
+**Engine:** `skills/j-uncharted/scripts/run-engine.sh`
 
 ---
 

package/skills/{uncharted → j-uncharted}/scripts/detect-dependencies.sh

@@ -19,7 +19,7 @@
 # no git state. Its only outputs are JSON on stdout and diagnostics on stderr.
 #
 # ---------------------------------------------------------------------------
-# Output contract (stdout, JSON) — consumed by skills/uncharted/scripts/run-engine.sh
+# Output contract (stdout, JSON) — consumed by skills/j-uncharted/scripts/run-engine.sh
 # ---------------------------------------------------------------------------
 # {
 #   "script": "detect-dependencies.sh",

package/skills/{uncharted → j-uncharted}/scripts/detect-tests.sh

@@ -28,7 +28,7 @@
 # no git state. Its only outputs are JSON on stdout and diagnostics on stderr.
 #
 # ---------------------------------------------------------------------------
-# Output contract (stdout, JSON) — consumed by skills/uncharted/scripts/run-engine.sh
+# Output contract (stdout, JSON) — consumed by skills/j-uncharted/scripts/run-engine.sh
 # ---------------------------------------------------------------------------
 # {
 #   "script": "detect-tests.sh",

package/skills/{uncharted → j-uncharted}/scripts/directory-triage.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/directory-triage.sh
+# skills/j-uncharted/scripts/directory-triage.sh
 #
 # Deterministic front half of the directory-triage step (E20_S08_T03) that
 # sits between discovery and any developer/tester Investigative Mode
@@ -90,7 +90,7 @@
 # does not attempt content-based judgement (reading file contents to guess
 # "this looks like SOAP mock-ups") at all. That pass is agent judgement, per
 # the Skill Implementation Principle in CLAUDE.md, and lives in
-# skills/uncharted/SKILL.md's Directory Triage subsection, not here.
+# skills/j-uncharted/SKILL.md's Directory Triage subsection, not here.
 #
 # ---------------------------------------------------------------------------
 # EXIT CODES
@@ -124,7 +124,7 @@ Classifies candidate directories under <root> into:
                .venv, venv, __pycache__, .next, coverage, target, .git,
                .tox, .mypy_cache, .pytest_cache, .cache, *.egg-info)
   - remaining: everything else — the input to the agent-judgement
-               generalize-list pass documented in skills/uncharted/SKILL.md
+               generalize-list pass documented in skills/j-uncharted/SKILL.md
 
 Options:
   --root DIR       Root the candidates are resolved against (or give it as

package/skills/{uncharted → j-uncharted}/scripts/elicitation-state.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/elicitation-state.sh
+# skills/j-uncharted/scripts/elicitation-state.sh
 #
 # Deterministic persistence + turn-cap counting for `/uncharted`'s
 # conversational convergence loop (E20_S08_T03) — the "propose understanding,
@@ -27,7 +27,7 @@
 # This script performs NO judgement — it does not decide what to ask, what
 # counts as high-impact, or when understanding has actually converged. It
 # only counts turns, tracks status, and persists whatever the agent asks it
-# to persist. All of that judgement lives in skills/uncharted/SKILL.md's
+# to persist. All of that judgement lives in skills/j-uncharted/SKILL.md's
 # Convergence Loop subsection.
 #
 # ---------------------------------------------------------------------------
@@ -89,7 +89,7 @@
 #       Set status "paused" and update "updated_at". The caller (the agent
 #       driving `/uncharted`) is responsible for also writing a scrum-master
 #       SessionEnd handoff with status "elicitation_paused" and this state
-#       file's path, per skills/uncharted/SKILL.md's Multi-Session
+#       file's path, per skills/j-uncharted/SKILL.md's Multi-Session
 #       Persistence subsection — this script only updates the state file
 #       itself, it does not write handoffs.
 #

package/skills/{uncharted → j-uncharted}/scripts/enumerate-target.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# skills/uncharted/scripts/enumerate-target.sh
+# skills/j-uncharted/scripts/enumerate-target.sh
 #
 # Read-only target resolution and structure enumeration for the /uncharted investigative engine.
 #

package/skills/{uncharted → j-uncharted}/scripts/import-source.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/import-source.sh
+# skills/j-uncharted/scripts/import-source.sh
 #
 # Acquisition half of `/uncharted import`. Fetches an external source into a
 # STAGING directory only — it never places anything at a final destination