@jenga-ai/agent 1.3.0 → 3.0.0

package/skills/jenga/scripts/render-confirmation.sh

@@ -97,12 +97,18 @@
 # ENTIRE turn is rejected as an error turn (state left untouched) — there
 # is no partial application of the valid numbers in a mixed-validity reply.
 #
-# Toggling is NOT cascading: unchecking a parent epic/story does not
-# automatically uncheck its children, and vice versa. Each displayed
-# number is an independent checkbox. This is a deliberate simplicity
-# choice — the task only requires "uncheck or re-check individual
-# presented items", not cascading selection logic (that expansion/cascade
-# concern already belongs to cascade-resolve.sh, per its own header).
+# Toggling CASCADES downward (E45_S02_T03): checking or unchecking a
+# story applies the same resulting state to all of its tasks; checking or
+# unchecking an epic applies the same resulting state to all of its
+# stories and their tasks. This is a deliberate, explicit reversal of the
+# original non-cascading design (see this story's 2026-08-27 close-out) —
+# the user hit a real case where unchecking a parent epic left its child
+# story/tasks checked, requiring a manual follow-up uncheck command.
+# Cascade is STRICTLY DOWNWARD (parent -> descendants) only: checking a
+# leaf task does NOT imply its ancestors should also be checked, so a
+# checked child under an unchecked parent is a valid (if visually
+# inconsistent) state. Toggling a leaf task (no children) behaves exactly
+# as it always has — no descendants to cascade into.
 #
 # ---------------------------------------------------------------------------
 # OUTPUT CONTRACT (deliberately NOT uniform JSON — see rationale below)
@@ -165,8 +171,15 @@
 # STATE FILE
 # ---------------------------------------------------------------------------
 # Created under `mktemp -t jenga-confirm-XXXXXX.json`. Stores:
-#   - `numbering`: displayed number -> {item, level, checked} — the ONLY
-#     field that mutates across turns is `checked`.
+#   - `numbering`: displayed number -> {item, level, checked, children} —
+#     `children` is a fixed list of the item's direct descendant numbers
+#     (a story's task numbers; an epic's story numbers), computed once at
+#     build time so continue-mode can cascade a toggle without
+#     re-deriving parent/child relationships from `item_id`/`epic_id`/
+#     `story_id` at toggle time. `children` is always `[]` for a leaf
+#     task. The only fields that mutate across turns are `checked` values
+#     (potentially many at once, via cascade — see TOGGLE COMMAND GRAMMAR
+#     above).
 #   - `layout`: the fixed print order (item lines + header markers),
 #     computed once at start. Continue mode never recomputes tree shape —
 #     it only re-renders from `layout` + the live `checked` flags in
@@ -305,15 +318,17 @@ def pluralize_task(n):
     return f"{n} task{'' if n == 1 else 's'}"
 
 
-def add_item(item, level, indent):
+def add_item(item, level, indent, parent_number=None):
     global counter
     n = str(counter)
     counter += 1
     suffix = ""
     if item.get("id") in undecomposed_ids:
         suffix = "  [needs decomposition -- no children on the board yet]"
-    numbering[n] = {"item": item, "level": level, "checked": True}
+    numbering[n] = {"item": item, "level": level, "checked": True, "children": []}
     layout.append({"kind": "item", "number": n, "level": level, "indent": indent, "suffix": suffix})
+    if parent_number is not None:
+        numbering[parent_number]["children"].append(n)
     return n
 
 
@@ -328,7 +343,7 @@ def append_suffix(extra):
 
 
 for e in epics:
-    add_item(e, "epic", INDENT["epic"])
+    e_num = add_item(e, "epic", INDENT["epic"])
     child_stories = stories_by_epic.get(e["id"], [])
     story_count = len(child_stories)
     task_count = sum(len(tasks_by_story.get(s["id"], [])) for s in child_stories)
@@ -340,23 +355,23 @@ for e in epics:
     append_suffix(", ".join(parts))
 
     for s in child_stories:
-        add_item(s, "story", INDENT["story"])
+        s_num = add_item(s, "story", INDENT["story"], parent_number=e_num)
         child_tasks = tasks_by_story.get(s["id"], [])
         if child_tasks:
             append_suffix(pluralize_task(len(child_tasks)))
         for t in child_tasks:
-            add_item(t, "task", INDENT["task"])
+            add_item(t, "task", INDENT["task"], parent_number=s_num)
 
 if orphan_stories:
     layout.append({"kind": "header", "text": ""})
     layout.append({"kind": "header", "text": "-- Directly Selected Stories (no epic in this selection) --"})
     for s in orphan_stories:
-        add_item(s, "story", INDENT["story"])
+        s_num = add_item(s, "story", INDENT["story"])
         child_tasks = tasks_by_story.get(s["id"], [])
         if child_tasks:
             append_suffix(pluralize_task(len(child_tasks)))
         for t in child_tasks:
-            add_item(t, "task", INDENT["task"])
+            add_item(t, "task", INDENT["task"], parent_number=s_num)
 
 if orphan_tasks:
     layout.append({"kind": "header", "text": ""})
@@ -644,18 +659,40 @@ if invalid:
     print(f"STATE_FILE: {state_file_path}", file=sys.stderr)
     sys.exit(1)
 
+def apply_cascade(num, value):
+    """Set `num`'s checked state to `value`, then recurse into every
+    number in its `children` list (a story's tasks; an epic's stories,
+    which recurse further into their own tasks). Strictly downward —
+    never touches a parent. A leaf task has an empty `children` list, so
+    this degenerates to exactly the old single-flag assignment for the
+    non-cascading base case."""
+    numbering[num]["checked"] = value
+    for child in numbering[num].get("children", []):
+        apply_cascade(child, value)
+
+
 # All-or-nothing application, de-duplicated (first-seen wins on dupes).
+# Resulting values are computed from PRE-mutation state in a first pass,
+# then applied (with cascade) in a second pass -- this avoids a
+# parent-then-child (or child-then-parent) double-toggle artifact when a
+# single reply lists both a parent and one of its own descendants, e.g.
+# bare-number toggle "5,6" where 6 is a child of 5.
 seen = set()
+pending = []
 for tok in valid_tokens:
     if tok in seen:
         continue
     seen.add(tok)
     if action == "check":
-        numbering[tok]["checked"] = True
+        value = True
     elif action == "uncheck":
-        numbering[tok]["checked"] = False
+        value = False
     else:
-        numbering[tok]["checked"] = not numbering[tok]["checked"]
+        value = not numbering[tok]["checked"]
+    pending.append((tok, value))
+
+for tok, value in pending:
+    apply_cascade(tok, value)
 
 state["numbering"] = numbering
 with open(state_file_path, "w", encoding="utf-8") as f:

package/skills/jenga-permission-level/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: jenga-permission-level
+name: j.jenga-permission-level
 description: Report or switch the current session's 5-tier permission level (Locked/Guarded/Standard/Elevated/Unrestricted) without hand-editing settings.json.
 keywords:
   - "permission level"

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 wired into both `agents/scrum-master.md`'s dispatch-to-developer step and `agents/developer.md`'s call-to-tester step (E49_S01_T03).
+
 
 
 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

@@ -9,22 +9,59 @@ 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.
+- Each **skill** is a self-contained instruction set: a `SKILL.md` file inside a per-skill directory.
+  Copilot discovers project skills from **all three** of `.github/skills/`, `.agents/skills/`, and
+  `.claude/skills/`. Jenga installs its skills under `.agents/skills/<skill-name>/` and mirrors
+  byte-identical content into `.claude/skills/<skill-name>/`; when the same skill name is found in
+  more than one of those directories, `.agents/skills/` takes precedence. Cite and open
+  `.agents/skills/` as the canonical path.
+- A skill's **identity is its frontmatter `name:` field, not its directory name**. Jenga names every
+  skill `j.<skill-name>` — the skill in `.agents/skills/status/` declares `name: j.status`.
+- 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.
+**Copilot loads these skills natively.** Copilot has a real, validating skill loader. It reads every
+`SKILL.md` under the discovery paths above and validates each one's frontmatter `name:` against:
 
-When the user's message is or matches `/skill-name` (or otherwise clearly matches a known skill's
-keyword or intent):
+```
+Skill name must start with an ASCII letter or number and contain only
+ASCII letters (a-z, A-Z), numbers, hyphens, underscores, dots, and spaces
+```
+
+A skill whose name fails that rule **does not load at all** — it is reported under "failed to load"
+by `copilot skill list` and is simply absent from the session. Every skill that does load is
+registered as a **native slash command named after its frontmatter `name`**, matched
+case-insensitively: `j.status` is invocable as `/j.status` and appears in the slash-command picker.
+That native path loads and applies the skill on its own — you do not need to locate or open the file
+yourself when the user types it.
+
+**What still depends on these instructions.** Native registration covers only the exact
+`/j.skill-name` form. These forms have **no** native handler and are routed entirely by the steps
+below:
+
+- the no-slash `j.skill-name` form, which is Jenga's documented invocation style;
+- the older bare `/skill-name` alias (`/status`, `/commit`);
+- a message that matches a skill by keyword or intent rather than by a literal command.
+
+For those, do not improvise a plausible-sounding response instead of following these steps — that is
+the exact failure this section exists to prevent.
+
+**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).
+   Jenga Works" above; `.claude/skills/<skill-name>/SKILL.md` holds identical content if the first
+   is absent). Note the directory is the **unprefixed** name — `j.status` lives in `status/`.
 2. Open and read that file **in full** before doing anything else.
 3. Execute its instructions exactly as written, for the rest of this turn — including running any
    shell scripts or commands it references (e.g. via a terminal/shell tool).
@@ -37,9 +74,26 @@ answer directly using your full capabilities.
 
 #### Routing decision table
 
+Before acting on any row below that opens a `SKILL.md` file yourself, check the identifier against
+the trusted allow-list: {{ALLOWED_SKILL_IDS}}.
+
+There are two enforcement layers, and they cover different inputs:
+
+1. **Copilot's own loader** handles the native `/j.skill-name` form. It only ever registers a skill
+   that is actually present under a discovery path and passed name validation.
+2. **This prose allow-list check** is the second layer — and the *only* layer for the forms Copilot
+   does not natively intercept: the no-slash `j.skill-name` form, the bare `/skill-name` alias, and
+   keyword or intent matches. Apply it whenever you are about to open a `SKILL.md` yourself.
+
+Neither layer inspects a skill's *contents*; both defend the invocation-matching layer only.
+
 | Situation | Action |
 |-----------|--------|
-| Message matches a skill keyword or intent | Open `.agents/skills/<skill-name>/SKILL.md`, read it fully, execute it as written |
+| User types the native `/j.skill-name` slash command | Copilot's loader applies the skill; follow the loaded instructions as written |
+| Message matches `j.skill-name` (no slash) 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 |
 
@@ -60,6 +114,7 @@ The `hooks/`, `lib/`, `scripts/`, `templates/`, and `mcp/` directories all live
 ### Notes
 
 - Always resolve file paths relative to `JENGA_PROJECT_DIR`.
-- When a skill asks you to read a file such as `SKILL.md` or a task file, look for it inside `JENGA_PROJECT_DIR/.agents/skills/` or `JENGA_PROJECT_DIR/project/board/` respectively.
+- When a skill asks you to read a file such as `SKILL.md` or a task file, look for it inside `JENGA_PROJECT_DIR/.agents/skills/` (or `JENGA_PROJECT_DIR/.claude/skills/`, which mirrors it) or `JENGA_PROJECT_DIR/project/board/` respectively.
+- If a Jenga skill seems to be missing entirely, run `copilot skill list` and check the "failed to load" section before assuming it does not exist — a name that fails validation is absent rather than broken.
 - Commit messages and branch names follow the EST naming convention (`E<n>_S<n>_T<n>`).
 <!-- JENGA:END -->

package/skills/continue/SKILL.md

@@ -1,29 +0,0 @@
----
-name: continue
-description: Check project status across PROJECT_SUMMARY.md, epics, and stories to determine what should be done next. Reports "All done!" if everything is complete.
-keywords:
-  - continue
-  - next
-  - proceed
-  - what's next
-  - status
-examples:
-  - "what should I do next?"
-  - "continue with the project"
----
-
-# Continue — Pick Up the Next Work Item
-
-## Instructions
-
-1. **Check `project/PROJECT_SUMMARY.md`** — Determine if there is outstanding work at the project level.
-
-2. **Check `project/epics/`** — If the project summary is done, check if any epics have remaining work.
-
-3. **Check `project/stories/`** — If epics are done, check if any stories have remaining work.
-
-   **Important:** Always check story status within an epic even if the epic itself is marked as done.
-
-4. **If everything is complete** — Respond with: "All done! 🎉"
-
-5. **Otherwise** — Begin work on the next incomplete item.

package/skills/error/SKILL.md

@@ -1,29 +0,0 @@
----
-name: error
-description: Guided troubleshooting flow that gathers context about an error — where it occurs, what was attempted, what went wrong, and what was expected.
-keywords:
-  - error
-  - bug
-  - fix
-  - troubleshoot
-  - debug
-  - broken
-examples:
-  - "I'm getting an error"
-  - "help me fix this bug"
-metadata: 
-  prefered_agent: tester
----
-
-# Error — Guided Troubleshooting
-
-## Instructions
-
-Ask the following questions to understand the background of the error:
-
-1. Where does the error occur?
-2. What are you trying to do?
-3. What went wrong?
-4. What was the expected outcome?
-
-Then use the answers to investigate and resolve the issue by creating a issue using the /todo skill.

package/skills/examplify/SKILL.md

@@ -1,42 +0,0 @@
----
-name: examplify
-description: Explains concepts, features, use cases, and patterns based on provided context — a description, scenario, code snippet, or file. Use when the user wants to understand what something is, how it works, when to use it, or wants a concrete example.
-keywords:
-  - examplify
-  - explain
-  - example
-  - how does
-  - understand
-examples:
-  - "explain how this works"
-  - "give me an example of X"
----
-
-# Concept Explainer
-
-## Instructions
-
-If the context is unclear or too broad, ask one focused clarifying question before proceeding. Otherwise, infer and proceed.
-
-Explain the concept by covering:
-
-1. **What it is** — a plain-language definition
-2. **Why it exists** — the problem it solves
-3. **How it works** — core mechanics
-4. **When to use it** — and when not to
-5. **Example(s)** — grounded in the user's context; show a before/after when relevant
-
-After delivering the explanation, save a copy to:
-`project/documentation/examples/<concept_and_context>.md`
-
-Derive the filename from the concept + context (lowercased, hyphenated). Tell the user where the file was saved.
-
-## Follow-up
-
-If further discussion reveals new information about the topic — a new use case, correction, or better example — ask the user:
-
-> "That adds something new to what we covered — want me to update the saved file?"
-1. Yes
-2. No
-
-If yes, append the new content under an `## Additional Notes` section. Do not overwrite the original.

package/skills/init/assets/scope-thresholds_template.json

@@ -1,7 +0,0 @@
-{
-  "threshold_version": 1,
-  "inline_max_files": 1,
-  "inline_max_lines": 20,
-  "story_max_files": 5,
-  "bundle_lock_ttl_minutes": 30
-}

package/skills/jbp/SKILL.md

@@ -1,25 +0,0 @@
----
-name: jbp
-description: Scaffold the project using the JengaBasePlate boilerplate repo template from https://github.com/samwelmunga/JengaBasePlate.git
-keywords:
-  - jbp
-  - boilerplate
-  - scaffold
-  - template
-  - jenga base
-examples:
-  - "scaffold with JengaBasePlate"
-  - "set up the base template"
----
-
-# JBP — JengaBasePlate Scaffold
-
-## Instructions
-
-Use the following repo as the boilerplate framework for this project:
-
-```
-https://github.com/samwelmunga/JengaBasePlate.git
-```
-
-Clone or pull the template and apply its structure to the current project.

package/skills/lgtm/SKILL.md

@@ -1,21 +0,0 @@
----
-name: lgtm
-description: Approve and commit the current work, then continue to the next task. Shortcut that chains /commit followed by /continue.
-keywords:
-  - lgtm
-  - approve
-  - looks good
-  - done
-  - commit and continue
-examples:
-  - "lgtm, commit this"
-  - "looks good, move on"
----
-
-# LGTM — Approve, Commit, and Continue
-
-## Instructions
-
-1. Invoke the `/commit` skill and wait for it to finish.
-
-2. If the current workflow is part of a `/do` execution, return to that workflow. Otherwise, invoke the `/continue` skill.

package/skills/todo/SKILL.md

@@ -1,48 +0,0 @@
----
-name: 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.
-keywords:
-  - todo
-  - add task
-  - queue work
-  - backlog
-  - add to list
-examples:
-  - "add this to the todo list"
-  - "queue this as a task"
-metadata: 
-  prefered_agent: scrum-master
----
-
-# Todo — Add Missions to the Todo List
-
-## Instructions
-
-1. **Ensure `project/todo.md` exists** — If it doesn't exist, it will be auto-created by `todo_manager.sh` — no manual action needed.
-
-2. **Ask the user about the mission:**
-   - Where do you want to do this?
-   - What would you like to do?
-   - What is the goal?
-
-3. **Classify the mission** — Check if it fits into:
-   - An existing story
-   - A new story inside an existing Epic
-   - A new story inside a new Epic
-   - None of the above
-
-4. **Update project documentation** — Add the mission to the appropriate files under `project/board/epics/` and `project/board/stories/` if applicable.
-   - If the mission involves implementing or modifying a skill, apply the **Skill Implementation Principle — Scripts Over Inline Logic** (see `CLAUDE.md` / `AGENTS.md`): note in the story/task's acceptance criteria that deterministic, repeatable steps must be offloaded to scripts under `skills/<name>/scripts/` (or `scripts/`) rather than encoded as inline agent instructions in `SKILL.md`.
-   - If the user indicates the mission is high-risk, or explicitly asks to flag it, set an elevated caution tier directly on the story or task frontmatter: `crucial_level` (one of `advisory`, `gated`, `locked` — see `templates/SCRUM_BOARD_SCHEMA.md` for valid values and their meaning), `crucial_set_by: user`, and `crucial_note` capturing the user's stated reason. This user-initiated flag is written immediately — it does not require the confirm-before-write gate, which applies only to scrum-master-*proposed* caution tiers (a separate, heuristic-driven path).
-
-5. **Add to `project/todo.md`** by running:
-   ```
-   bash scripts/todo_manager.sh add '<mission title>: <Epic no.>_<Story no.>'
-   ```
-   The epic and story reference is only required if the mission is assigned to one.
-
-6. **Ask the user**: "Add another todo" or "Done"?
-   - If **add another** — go back to step 2.
-   - If **done** — ask if they want to execute the todo list.
-     - If **yes** — invoke the `/do` skill.
-     - If **no** — exit.

package/skills/wtf/SKILL.md

@@ -1,20 +0,0 @@
----
-name: 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
-  - confused
-  - huh
-  - what does this mean
-  - I'm lost
-examples:
-  - "wtf"
-  - "wtf does this mean"
-  - "wtf is going on here"
----
-
-# WTF — Alias of /clearify
-
-## 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.