@jenga-ai/agent 1.3.0 → 2.0.0

package/skills/todo/scripts/add_trivial_task.sh

@@ -0,0 +1,216 @@
+#!/usr/bin/env bash
+# skills/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
+# in its parent story's tasks: frontmatter list and in project/todo.md.
+#
+# This script performs only the MECHANICAL half of --trivial: templating the
+# task file, assigning the next task number, and wiring it into the board.
+# 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
+# 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.
+#
+# Usage:
+#   add_trivial_task.sh --story <E##_S##> --title "<title>" \
+#     --description "<description>" --criteria "<c1>|<c2>|..." \
+#     --computed-tier <inline|task|story> --est-files <N> --est-lines <M> \
+#     [--prerequisites "<text>"]
+#
+# Requires an ALREADY-EXISTING parent story file (--trivial does not create
+# stories or epics — resolve/create those first via the normal /todo flow).
+#
+# On success, prints the new task ID (e.g. E32_S14_T05) to stdout and exits 0.
+
+set -euo pipefail
+
+REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../../.." && pwd)"
+cd "$REPO_ROOT"
+
+TASKS_DIR="project/board/tasks"
+STORIES_DIR="project/board/stories"
+UPDATE_STORY_SCRIPT="skills/todo/scripts/update_story_tasks.py"
+
+story_id=""
+title=""
+description=""
+criteria=""
+computed_tier=""
+est_files=""
+est_lines=""
+prerequisites="None."
+
+usage() {
+  cat >&2 <<EOF
+Usage: $0 --story <E##_S##> --title "<title>" --description "<description>" \\
+       --criteria "<c1>|<c2>|..." --computed-tier <inline|task|story> \\
+       --est-files <N> --est-lines <M> [--prerequisites "<text>"]
+EOF
+  exit 1
+}
+
+while [ $# -gt 0 ]; do
+  case "$1" in
+    --story) story_id="$2"; shift 2 ;;
+    --title) title="$2"; shift 2 ;;
+    --description) description="$2"; shift 2 ;;
+    --criteria) criteria="$2"; shift 2 ;;
+    --computed-tier) computed_tier="$2"; shift 2 ;;
+    --est-files) est_files="$2"; shift 2 ;;
+    --est-lines) est_lines="$2"; shift 2 ;;
+    --prerequisites) prerequisites="$2"; shift 2 ;;
+    -h|--help) usage ;;
+    *) echo "Error: unknown argument '$1'" >&2; usage ;;
+  esac
+done
+
+for req_name in story_id title description criteria computed_tier est_files est_lines; do
+  if [ -z "${!req_name}" ]; then
+    echo "Error: --${req_name//_/-} is required" >&2
+    exit 1
+  fi
+done
+
+if ! [[ "$story_id" =~ ^E[0-9]+_S[0-9]+$ ]]; then
+  echo "Error: --story must look like E##_S## (got '$story_id')" >&2
+  exit 1
+fi
+
+case "$computed_tier" in
+  inline|task|story) ;;
+  *) echo "Error: --computed-tier must be one of: inline, task, story (got '$computed_tier')" >&2; exit 1 ;;
+esac
+
+case "$est_files" in
+  ''|*[!0-9]*) echo "Error: --est-files must be a non-negative integer (got '$est_files')" >&2; exit 1 ;;
+esac
+case "$est_lines" in
+  ''|*[!0-9]*) echo "Error: --est-lines must be a non-negative integer (got '$est_lines')" >&2; exit 1 ;;
+esac
+
+epic_id="${story_id%%_S*}"
+
+# Locate the parent story file. --trivial requires it to already exist.
+story_file=""
+for f in "${STORIES_DIR}/${story_id}_"*.md; do
+  if [ -f "$f" ]; then
+    story_file="$f"
+    break
+  fi
+done
+if [ -z "$story_file" ]; then
+  echo "Error: no story file found for $story_id under $STORIES_DIR/. --trivial requires an already-resolved story — create it via the normal /todo flow first." >&2
+  exit 1
+fi
+
+if [ ! -f "$UPDATE_STORY_SCRIPT" ]; then
+  echo "Error: $UPDATE_STORY_SCRIPT not found." >&2
+  exit 1
+fi
+
+# Determine the next task number for this story by scanning existing task files.
+max_num=0
+shopt -s nullglob
+for f in "${TASKS_DIR}/${story_id}_T"*.md; do
+  base="$(basename "$f")"
+  num="$(printf '%s' "$base" | sed -nE "s/^${story_id}_T([0-9]+)_.*/\1/p")"
+  if [ -n "$num" ]; then
+    num=$((10#$num))
+    if [ "$num" -gt "$max_num" ]; then
+      max_num=$num
+    fi
+  fi
+done
+shopt -u nullglob
+next_num=$((max_num + 1))
+next_num_padded="$(printf '%02d' "$next_num")"
+task_id="${story_id}_T${next_num_padded}"
+
+shopt -s nullglob
+existing_matches=("${TASKS_DIR}/${task_id}_"*.md)
+shopt -u nullglob
+if [ "${#existing_matches[@]}" -gt 0 ]; then
+  echo "Error: a task file for $task_id already exists (ID collision). Aborting." >&2
+  exit 1
+fi
+
+# Slugify the title for the filename.
+slug="$(printf '%s' "$title" | tr '[:upper:]' '[:lower:]' | sed -E 's/[^a-z0-9]+/-/g; s/^-+//; s/-+$//')"
+slug="${slug:0:60}"
+slug="${slug%-}"
+if [ -z "$slug" ]; then
+  slug="trivial-task"
+fi
+
+today="$(date -u +%Y-%m-%d)"
+
+scope_rationale="forced inline via --trivial; computed scope would have been '${computed_tier}' — estimated ${est_files} files, ~${est_lines} lines"
+override_justification="/todo --trivial invoked by user on ${today}; execution_scope forced to 'inline', overriding the heuristic's computed '${computed_tier}' tier (see scope_rationale)."
+
+# Build the Acceptance Criteria block from the pipe-separated --criteria value.
+criteria_block=""
+IFS='|' read -ra crit_arr <<< "$criteria"
+for c in "${crit_arr[@]}"; do
+  c_trimmed="$(printf '%s' "$c" | sed -E 's/^[[:space:]]+//; s/[[:space:]]+$//')"
+  if [ -n "$c_trimmed" ]; then
+    criteria_block+="- [ ] ${c_trimmed}"$'\n'
+  fi
+done
+if [ -z "$criteria_block" ]; then
+  echo "Error: --criteria produced no usable acceptance criteria" >&2
+  exit 1
+fi
+
+task_file="${TASKS_DIR}/${task_id}_${slug}.md"
+
+cat > "$task_file" <<EOF
+---
+id: ${task_id}
+story_id: ${story_id}
+epic_id: ${epic_id}
+title: ${title}
+status: Pending
+date_created: ${today}
+date_started:
+date_completed:
+dates_previously_completed:
+reopened_on:
+reopened_reason:
+assigned_to: developer
+docs: []
+execution_scope: inline
+needs_docs: false
+scope_rationale: "${scope_rationale}"
+jenga_assigned: false
+override_justification: "${override_justification}"
+---
+
+# Task: ${title}
+
+## Description
+${description}
+
+## Prerequisites
+${prerequisites}
+
+## Acceptance Criteria
+${criteria_block}
+EOF
+
+echo "Wrote task file: ${task_file}"
+
+# Register the new task under its parent story's tasks: frontmatter list.
+if ! scripts/with-lock.sh "$story_file" -- python3 "$UPDATE_STORY_SCRIPT" "$story_file" "$task_id"; then
+  echo "Error: failed to register ${task_id} in ${story_file}'s tasks: list (lock timeout or write failure)." >&2
+  exit 1
+fi
+
+# Register the todo entry using the FULL task ID, so /do routes straight into
+# its Inline Execution Path without a redundant breakdown pass.
+bash scripts/todo_manager.sh add "${title}: ${task_id}"
+
+echo "${task_id}"

package/skills/todo/scripts/update_story_tasks.py

@@ -0,0 +1,87 @@
+#!/usr/bin/env python3
+"""
+skills/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
+task_id is a no-op, exit 0).
+
+This is a pure text/frontmatter edit and does no board-wide validation beyond
+"frontmatter block exists" — it is intended to be invoked already wrapped in
+scripts/with-lock.sh, keyed to the story file, per templates/SCRUM_BOARD_SCHEMA.md's
+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>
+
+Exit codes:
+    0   success (task_id inserted, or already present)
+    1   usage error
+    2   story file has no parseable frontmatter block
+"""
+import sys
+
+
+def main() -> int:
+    if len(sys.argv) != 3:
+        print("Usage: update_story_tasks.py <story-file> <task-id>", file=sys.stderr)
+        return 1
+
+    path, task_id = sys.argv[1], sys.argv[2]
+
+    with open(path, "r", encoding="utf-8") as f:
+        content = f.read()
+
+    parts = content.split("---", 2)
+    if len(parts) < 3:
+        print(f"Error: {path} has no valid '---' frontmatter block", file=sys.stderr)
+        return 2
+
+    _, frontmatter, rest = parts
+    lines = frontmatter.split("\n")
+    task_line = f"  - {task_id}"
+
+    if any(line.strip() == task_line.strip() for line in lines):
+        print(f"No-op: {task_id} already present in {path}'s tasks: list")
+        return 0
+
+    idx = None
+    inline_empty_idx = None
+    for i, line in enumerate(lines):
+        stripped = line.strip()
+        if stripped == "tasks:":
+            idx = i
+            break
+        if stripped == "tasks: []":
+            inline_empty_idx = i
+            break
+
+    if inline_empty_idx is not None:
+        lines[inline_empty_idx] = "tasks:"
+        lines.insert(inline_empty_idx + 1, task_line)
+    elif idx is not None:
+        j = idx + 1
+        while j < len(lines) and lines[j].strip().startswith("- "):
+            j += 1
+        lines.insert(j, task_line)
+    else:
+        # No tasks: key found at all — append one at the end of the frontmatter,
+        # trimming any single trailing blank line first so formatting stays tidy.
+        if lines and lines[-1].strip() == "":
+            lines.pop()
+        lines.append("tasks:")
+        lines.append(task_line)
+        lines.append("")
+
+    new_frontmatter = "\n".join(lines)
+    new_content = "---" + new_frontmatter + "---" + rest
+
+    with open(path, "w", encoding="utf-8") as f:
+        f.write(new_content)
+
+    print(f"Updated {path}: added {task_id} to tasks:")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/uncharted/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: uncharted
+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.
 metadata:
   prefered_agent: scrum-master

package/skills/wtf/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: wtf
+name: j:wtf
 description: Alias of /clearify — clarifies ambiguous, dense, or under-specified prompts and conversation on request. This folder exists only so the `/wtf` slash command resolves to a skill; behaviour is identical to `/clearify`.
 keywords:
   - wtf

package/templates/SCRUM_BOARD_SCHEMA.md

@@ -67,9 +67,28 @@ All status fields must use one of the following exact strings:
 | `Blocked`            | Cannot proceed; human intervention required                |
 | `Backlog`            | Epic-level only; queued but not yet prioritized for work    |
 | `Done`               | Epic-level only; all child stories/tasks closed out          |
+| `Merged`             | Set after a successful `/self-sync` run's file diff shows the ticket's recorded files were touched |
+| `Publicized`         | Set after a successful `/mirror-public` run's file diff shows the ticket's recorded files were touched |
+| `Privatized`         | Set at ticket-close time via a static `.publicignore` blocklist membership check (no run dependency) |
+| `Deployed to Stage`  | Set when the public `jenga-npm` repo's CI tags a `vX.Y.Z-stage` tag that resolves back (via the `Source-Commit:` trailer) to this ticket's commit |
+| `Deployed to Prod`   | Set when the public `jenga-npm` repo's CI tags a `vX.Y.Z` (prod) tag that resolves back to this ticket's commit |
 
 Only the **tester agent** may write status values to story and task files. Only the **scrum master** may write status values to epic files and may update story status as part of rollup.
 
+All five statuses above are **script-set, never agent-judged** — no agent decides when a ticket becomes `Merged`, `Publicized`, `Privatized`, `Deployed to Stage`, or `Deployed to Prod`; a deterministic script observation sets them, per the mechanisms described below.
+
+### Static vs. Reactive Status Setting
+
+`Privatized` is set **statically**: at ticket-close time, a script checks whether the ticket's recorded files match the `.publicignore` blocklist. This check has no dependency on any particular run having occurred — it is a pure membership test.
+
+The other four — `Merged`, `Publicized`, `Deployed to Stage`, `Deployed to Prod` — are set **reactively**: a script observes the outcome of a specific run (a `/self-sync` or `/mirror-public` file diff, or a public-repo CI tag event) and sets the status only when that run's evidence confirms the ticket was affected. Absent a qualifying run, the status is not set.
+
+### Publicized / Privatized / Deployed Lifecycle Relationship
+
+`Publicized` and `Privatized` are **mutually exclusive** — a ticket is one or the other, never both. A ticket's files either pass the `.publicignore` blocklist check (making it eligible for `Publicized`) or match it (making it `Privatized`); it cannot satisfy both conditions at once.
+
+Only **`Publicized`** tickets are eligible to progress further down the deploy lifecycle, from `Deployed to Stage` to `Deployed to Prod`. A `Privatized` ticket's files never reach the public `jenga-npm` repo, so it can never acquire a CI tag there and therefore can never reach either deploy status.
+
 ---
 
 ## File Formats
@@ -161,7 +180,7 @@ reopened_on:                 # comma-separated list, e.g. 2026-02-01, 2026-04-10
 reopened_reason:             # comma-separated list, e.g. "Scope expanded", "Bug found post-release"
 assigned_to: developer | tester | scrum-master
 docs: []                     # optional list of repo-relative documentation paths, e.g. ["README.md", "docs/API.md"]
-execution_scope: task          # task | story | epic | inline; omit for legacy tasks (defaults to task)
+execution_scope: task          # task | story | epic | inline | light; omit for legacy tasks (defaults to task)
 needs_docs: true               # boolean; omit for legacy tasks (defaults to true)
 scope_rationale: ""            # required when execution_scope is set; must contain a numeric/file-count claim
 jenga_assigned: true           # boolean; true = machine-assigned, false = human override
@@ -315,13 +334,14 @@ level.
 These six fields control the execution footprint of a task within the `/jenga` and `/do` workflows. They are **optional** — omitting all six is valid and equivalent to `execution_scope: task` / `needs_docs: true`.
 
 **`execution_scope`**
-- Valid values: `task` | `story` | `epic` | `inline`
+- Valid values: `task` | `story` | `epic` | `inline` | `light`
 - When required: optional; omit for legacy tasks (runtime default: `task`)
 - Description: defines how broadly this task's implementation touches the codebase.
   - `task` — standard single-task scope (default)
   - `story` — task may touch files across multiple tasks in the same story
   - `epic` — task may touch files across stories; requires `epic_scope_approval: true` on the parent epic
   - `inline` — trivial change (e.g. config tweak, comment, schema doc); no execution plan or summary document is needed
+  - `light` — sits between `inline` and `task` in scope: a single developer subagent pass with no worktree, self-verified via `scripts/smoke-harness.sh` in lieu of a separate tester invocation; if the smoke harness fails, execution falls back to `task` scope
 
 **`needs_docs`**
 - Valid values: `true` | `false`
@@ -528,6 +548,7 @@ Each file is written by an agent as the **last action** of its session, and is s
 | `worktree`    | developer, tester    | Absolute path                            |
 | `paths`       | developer, tester    | Commit SHAs                              |
 | `rapport_file`| tester only          | Path to rapport if status is failed/error |
+| `resolved_context` | all, optional   | Digest of context the sending agent already resolved; see below |
 | `date`        | all                  | ISO 8601 UTC                             |
 
 **Status values per agent:**
@@ -535,6 +556,16 @@ Each file is written by an agent as the **last action** of its session, and is s
 - `developer`: `implementation_complete`
 - `tester`: `passed`, `passed_with_remarks`, `failed`, `error`
 
+**`resolved_context` — digest, not a dump (E49).** An optional field a sending agent populates with a short digest of conclusions it already reached while navigating source documents (e.g. which schema fields apply, which skill precedent governs, which decisions are already made) — so the receiving subagent doesn't have to cold-re-read the same files from scratch. It must stay under a size cap of roughly 100 lines (a few hundred tokens), mirroring `scope_rationale`'s "must contain a measurable claim" discipline: a `resolved_context` value that is a raw file dump or exceeds the cap is not valid. The digest is a starting point only — it never restricts the receiving agent from reading full source files when the digest is insufficient or needs verification. The digest body itself lives in a per-task file at `project/queue/context/<agent>-<session_id>-<task_id>.json`, following the same unique-path, single-use, session-scoped convention as `handoffs/` above (not a shared, clobber-prone slot); this handoff's `resolved_context` field holds a reference to (or the inline content of) that file.
+
+**`project/queue/context/` — physical digest files (E49_S01_T02).** The directory itself is kept via `.gitkeep`; individual digest files (`*.json`) are git-ignored for the same reason `handoffs/*.json` is — a committed one can no longer be told apart from a live pending digest by inspection alone. Three scripts implement the convention end to end:
+
+- `scripts/write-context-digest.sh` — the sending agent's write path. Takes `--agent`, `--session-id`, `--task-id`, and digest content (`--content`, `--content-file`, or stdin); enforces the ~100-line cap above by **rejecting** (not truncating) an oversized digest, since a silently-truncated digest could cut off mid-thought and mislead the receiver — the sender is the only party that actually knows what's safe to cut. Writes atomically (tmp file in the same directory, then `mv`) and prints the resulting absolute path to stdout for the caller to place in the handoff's `resolved_context` field.
+- `scripts/consume-context-digest.sh <path>` — the receiving agent's read path. Atomically claims the file (rename to a `.claimed.$$` sibling, same TOCTOU-safe pattern `on_session_end.sh` section 4 uses for `handoffs/`), prints its content (full JSON envelope, or just the `digest` field with `--raw`), and deletes it — single-use, like `handoffs/`.
+- `scripts/sweep-stale-context-digests.sh` — an age-based backstop (default 24h, overridable), invoked from `hooks/on_session_end.sh` on every session end regardless of agent, for a digest whose intended receiver never calls the consume script (abandoned dispatch, or a receiver that read the raw file directly and forgot to clean up). Age-based rather than routed-and-deleted-immediately like `handoffs/`, because a digest's consumer is a later session that may not have started yet when some unrelated session's `SessionEnd` hook fires.
+
+Populating `resolved_context` when dispatching (scrum-master → developer, developer → tester) is sibling task E49_S01_T03 — not yet wired into `agents/scrum-master.md` or `agents/developer.md` as of this writing. The physical convention above is usable standalone in the meantime.
+
 
 
 Located at `project/configs/workflow.json`. Scaffolded by `/init` and owned by the scrum master.

package/templates/agent-context.md.tpl

@@ -10,20 +10,30 @@ This project uses **Jenga** — a skill-based AI agent framework. Jenga organise
 ### How Jenga Works
 
 - Each **skill** is a self-contained instruction set stored under `{{SKILL_DISCOVERY_PATH}}<skill-name>/`.
-- Skills are invoked by typing `/skill-name` in the chat prompt.
+- Skills are invoked by typing `j:skill-name` in the chat prompt (e.g. `j:status`, `j:commit`). The
+  older bare `/skill-name` form (e.g. `/status`, `/commit`) is a **permanent alias** — it keeps
+  resolving indefinitely, with no deprecation warning and no removal planned — so treat a message in
+  either form as the exact same invocation.
 - The active project directory is available via the `JENGA_PROJECT_DIR` environment variable. **Use `JENGA_PROJECT_DIR` — not `CLAUDE_PROJECT_DIR` or any other agent-specific variable** — as the canonical path to the project folder.
 
 ### Skill Routing
 
-If you are Claude Code, `/skill-name` is a native harness-level mechanism: the harness itself
-intercepts the literal command and loads the skill for you, independent of anything written here. If
-you are any other agent (Codex, or a generic `AGENTS.md` consumer) with no equivalent native
-interception, you depend entirely on the instructions below to know what "invoking a skill" concretely
-means. Do not improvise a plausible-sounding response instead of following these steps — that is the
-exact failure this section exists to prevent.
+If you are Claude Code, both `j:skill-name` (the canonical form) and the older bare `/skill-name`
+(a permanent alias) are native harness-level mechanisms: the harness itself intercepts the literal
+command and loads the skill for you, independent of anything written here. If you are any other agent
+(Codex, or a generic `AGENTS.md` consumer) with no equivalent native interception, you depend entirely
+on the instructions below to know what "invoking a skill" concretely means — for either the
+`j:skill-name` form or the older bare `/skill-name` form, both of which route to the same skill. Do not
+improvise a plausible-sounding response instead of following these steps — that is the exact failure
+this section exists to prevent.
 
-When the user's message is or matches `/skill-name` (or otherwise clearly matches a known skill's
-keyword or intent):
+**Old bare-form alias.** `j:skill-name` is the canonical invocation form. A message using the older
+bare `/skill-name` form is not deprecated and must not be treated as an error, a warning case, or a
+migration prompt — route it to the identical skill as its `j:skill-name` equivalent. Both forms remain
+equally valid indefinitely.
+
+When the user's message is or matches `j:skill-name`, or matches the older bare `/skill-name` alias (or
+otherwise clearly matches a known skill's keyword or intent):
 
 1. Locate the target file at `{{SKILL_DISCOVERY_PATH}}<skill-name>/SKILL.md` (the discovery path from
    "How Jenga Works" above).
@@ -41,10 +51,23 @@ answer directly using your full capabilities.
 
 | Situation | Action |
 |-----------|--------|
+| Message matches `j:skill-name` | Open `{{SKILL_DISCOVERY_PATH}}<skill-name>/SKILL.md`, read it fully, execute it as written |
+| Message matches the older bare `/skill-name` alias | Treat identically to `j:skill-name` — same skill, same file, no warning, no migration prompt |
 | Message matches a skill keyword or intent | Open `{{SKILL_DISCOVERY_PATH}}<skill-name>/SKILL.md`, read it fully, execute it as written |
 | Message is a general coding or project question | Answer directly |
 | Ambiguous — could be skill or free-form | Prefer the skill; open and execute its `SKILL.md` rather than describing it |
 
+### Skill Identifier Allow-List
+
+The trusted `j:`-prefixed skill identifiers for this project are: {{ALLOWED_SKILL_IDS}}
+
+Before treating a `j:<name>` invocation (or its bare `/<name>` alias) as a genuine Jenga skill,
+confirm `<name>` appears in this list. This applies whether the harness intercepted the command
+natively (Claude Code) or you are matching it yourself against a skill keyword or intent (any
+other agent). If `<name>` does **not** appear in this list, do not guess at intent and do not
+execute anything — tell the user the identifier is unrecognized and is not a known Jenga skill,
+rather than treating it as one anyway.
+
 ### Available Skills
 
 {{SKILL_LIST}}

package/templates/copilot-instructions.md.tpl

@@ -10,18 +10,27 @@ This project uses **Jenga** — a skill-based AI agent framework. Jenga organise
 ### How Jenga Works
 
 - Each **skill** is a self-contained instruction set stored under `.agents/skills/<skill-name>/` (the non-Claude discovery path; Claude Code reads the same content from `.claude/skills/`).
-- Skills are invoked by typing `/skill-name` in the chat prompt.
+- Skills are invoked by typing `j:skill-name` in the chat prompt (e.g. `j:status`, `j:commit`). The
+  older bare `/skill-name` form (e.g. `/status`, `/commit`) is a **permanent alias** — it keeps
+  resolving indefinitely, with no deprecation warning and no removal planned — so treat a message in
+  either form as the exact same invocation.
 - The active project directory is available via the `JENGA_PROJECT_DIR` environment variable. **Use `JENGA_PROJECT_DIR` — not `CLAUDE_PROJECT_DIR` or any other agent-specific variable** — as the canonical path to the project folder.
 
 ### Skill Routing
 
-Unlike Claude Code, GitHub Copilot has **no native slash-command interception** — typing `/skill-name`
-does not automatically load or run anything on its own. Copilot depends entirely on the instructions
-below to know what "invoking a skill" concretely means. Do not improvise a plausible-sounding response
-instead of following these steps — that is the exact failure this section exists to prevent.
+Unlike Claude Code, GitHub Copilot has **no native slash-command interception** — typing `j:skill-name`
+(or the older bare `/skill-name` alias) does not automatically load or run anything on its own. Copilot
+depends entirely on the instructions below to know what "invoking a skill" concretely means. Do not
+improvise a plausible-sounding response instead of following these steps — that is the exact failure
+this section exists to prevent.
 
-When the user's message is or matches `/skill-name` (or otherwise clearly matches a known skill's
-keyword or intent):
+**Old bare-form alias.** `j:skill-name` is the canonical invocation form. A message using the older
+bare `/skill-name` form is not deprecated and must not be treated as an error, a warning case, or a
+migration prompt — route it to the identical skill as its `j:skill-name` equivalent. Both forms remain
+equally valid indefinitely.
+
+When the user's message is or matches `j:skill-name`, or matches the older bare `/skill-name` alias (or
+otherwise clearly matches a known skill's keyword or intent):
 
 1. Locate the target file at `.agents/skills/<skill-name>/SKILL.md` (the discovery path from "How
    Jenga Works" above).
@@ -37,9 +46,17 @@ answer directly using your full capabilities.
 
 #### Routing decision table
 
+Before acting on any row below that opens a `SKILL.md` file, first check the identifier against
+the trusted allow-list: {{ALLOWED_SKILL_IDS}}. Since Copilot/Codex has no native interception for
+`j:skill-name`, this prose-level check is the entire enforcement mechanism — there is no runtime
+guard behind it.
+
 | Situation | Action |
 |-----------|--------|
-| Message matches a skill keyword or intent | Open `.agents/skills/<skill-name>/SKILL.md`, read it fully, execute it as written |
+| Message matches `j:skill-name` and `skill-name` is in the allow-list | Open `.agents/skills/<skill-name>/SKILL.md`, read it fully, execute it as written |
+| Message matches the older bare `/skill-name` alias and `skill-name` is in the allow-list | Treat identically to `j:skill-name` — same skill, same file, no warning, no migration prompt |
+| Message matches a skill keyword or intent and the matched skill is in the allow-list | Open `.agents/skills/<skill-name>/SKILL.md`, read it fully, execute it as written |
+| Message matches `j:skill-name` or `/skill-name`, but `skill-name` is **not** in the allow-list | Do not open or execute anything — tell the user the identifier is unrecognized and is not a known Jenga skill |
 | Message is a general coding or project question | Answer directly |
 | Ambiguous — could be skill or free-form | Prefer the skill; open and execute its `SKILL.md` rather than describing it |