@jenga-ai/agent 1.3.0 → 2.0.0

package/README.md

@@ -1,6 +1,8 @@
 # Jenga AI
 
-**A structured multi-agent development workflow that works with any AI agent or AI-native IDE.** Three specialised AI agents — Scrum Master, Developer, and Tester — collaborate through a shared scrum board, an event-driven trigger queue, and 28 slash-command skills to take a project from idea to verified, committed code — across as many sessions as it takes.
+> ⚠️ **Upgrading from a prior version?** Earlier releases could hit a command-collision bug: some host tools (e.g. GitHub Copilot) ship their own built-in `/init` command, which could silently shadow Jenga's own `/init` skill. This release adds **`/j-init`** — an identical, collision-safe copy of `/init` — so you always have a guaranteed-unshadowed way to scaffold a project. If `/init` isn't behaving as documented, run `/j-init` instead.
+
+**A structured multi-agent development workflow that works with any AI agent or AI-native IDE.** Three specialised AI agents — Scrum Master, Developer, and Tester — collaborate through a shared scrum board, an event-driven trigger queue, and a coordinated pipeline of `j:`-prefixed skills that hand work between them — to take a project from idea to verified, committed code — across as many sessions as it takes.
 
 [![npm version](https://img.shields.io/npm/v/@jenga-ai/agent.svg)](https://www.npmjs.com/package/@jenga-ai/agent)
 [![license](https://img.shields.io/npm/l/@jenga-ai/agent.svg)](LICENSE)
@@ -9,14 +11,35 @@
 npm install @jenga-ai/agent
 ```
 
+## The Problem It Solves
+
+Without a framework like Jenga AI, AI-assisted development has serious structural weaknesses:
+
+[![How AI Coding Agents Understand Your Codebase & Developer Tools](https://img.youtube.com/vi/zAe-sau06io/maxresdefault.jpg)](https://www.youtube.com/watch?v=zAe-sau06io)
+
+*"How AI Coding Agents Understand Your Codebase & Developer Tools" — IBM Technology on the same gap in session memory and tooling context that Jenga AI's board and agent contracts are built to close.*
+
+| Problem | Reality |
+|---|---|
+| **AI has no session memory** | Every AI agent session starts from scratch — no awareness of open tasks, past decisions, or what was already tested |
+| **No role separation** | The AI writes *and* "tests" code in the same context, leading to hallucinated test results and self-affirming bugs |
+| **No structured planning** | Work happens ad-hoc — no Epic → Story → Task hierarchy to organise or track progress |
+| **No handoff protocol** | Switching from implementing to testing means manually re-explaining context every time |
+| **No audit trail** | You can't replay *why* something was built, by which agent, based on which task |
+| **Sessions just end** | Work-in-progress, unresolved problems, and incomplete stories silently vanish |
+
+Jenga AI solves each of these with structure: persistent board state, strict agent roles, typed inter-agent contracts, and session-end hooks that preserve context between sessions.
+
+---
+
 ## What You Get
 
 - **Three specialised agents** — Scrum Master, Developer, Tester — each with a distinct role and no self-graded work
 - **A persistent scrum board** — Epics, Stories, and Tasks tracked as Markdown files with structured frontmatter, surviving every session boundary
-- **28 slash-command skills** — from planning (`/pi-plan`, `/todo`) to execution (`/do`, `/dooo`) to review (`/status`, `/reconcile`)
+- **A coordinated skill pipeline, not a command list** — planning skills (`j:pi-plan`, `j:todo`) hand off to execution skills (`j:do`, `j:dooo`), which hand off to review skills (`j:status`, `j:reconcile`), each stage reading and writing the same board state — the old bare `/<name>` form still works everywhere as a permanent alias
 - **An event-driven trigger queue** — async handoffs between agents with a full audit trail in `project/logs/events.json`
 - **Isolated git worktrees per task** — the Developer never works directly on your main branch
-- **Works with any AI agent or IDE** — Claude Code, GitHub Copilot, Warp, and Codex CLI are all supported today
+- **Works with any AI agent or IDE** — Claude Code, GitHub Copilot, and Codex CLI are all supported today
 
 > 📖 **Full reference:** [project/.wiki/documentation.md](project/.wiki/documentation.md) | [Intro Guide](project/.wiki/intro-guide.md)
 
@@ -24,30 +47,13 @@ npm install @jenga-ai/agent
 
 | Agent | Skills & Agents | Root Context File |
 |---|---|---|
-| **Claude Code** | `.claude/` — mirrored automatically on install | `CLAUDE.md` — generated by `/init` today |
+| **Claude Code** | `.claude/` — mirrored automatically on install | `CLAUDE.md` — generated by `j:init` today |
 | **GitHub Copilot** | `.agents/` — mirrored automatically on install | `.github/copilot-instructions.md` — bootstrapped at `npm install` time, refined by `jenga init` |
-| **Codex** | `.agents/` — mirrored automatically on install | `AGENTS.md` — generated by `/init` today |
+| **Codex** | `.agents/` — mirrored automatically on install | `AGENTS.md` — generated by `j:init` today |
 
-`CLAUDE.md` and `AGENTS.md` are generated unconditionally by `/init` — every agent gets a real, populated root-level context file out of the box, not just a pointer. If either file already exists as a genuine pre-existing user file, Jenga writes its own copy as `J-CLAUDE.md` / `J-AGENTS.md` instead and inserts a short reference into the existing file, leaving it otherwise untouched.
+`CLAUDE.md` and `AGENTS.md` are generated unconditionally by `j:init` — every agent gets a real, populated root-level context file out of the box, not just a pointer. If either file already exists as a genuine pre-existing user file, Jenga writes its own copy as `J-CLAUDE.md` / `J-AGENTS.md` instead and inserts a short reference into the existing file, leaving it otherwise untouched.
 
-`.github/copilot-instructions.md` follows a different path: `scripts/postinstall.js` writes it unconditionally and non-interactively the moment `npm install` finishes, so Copilot has working `/skill-name` routing instructions even if a consumer's very first action is a Copilot slash command, before the separate `jenga init` CLI wizard has ever run. Running `jenga init` afterward refines the same file using the user's actual chosen skills path — it is never generated by the `/init` skill itself.
-
----
-
-## The Problem It Solves
-
-Without a framework like Jenga AI, AI-assisted development has serious structural weaknesses:
-
-| Problem | Reality |
-|---|---|
-| **AI has no session memory** | Every AI agent session starts from scratch — no awareness of open tasks, past decisions, or what was already tested |
-| **No role separation** | The AI writes *and* "tests" code in the same context, leading to hallucinated test results and self-affirming bugs |
-| **No structured planning** | Work happens ad-hoc — no Epic → Story → Task hierarchy to organise or track progress |
-| **No handoff protocol** | Switching from implementing to testing means manually re-explaining context every time |
-| **No audit trail** | You can't replay *why* something was built, by which agent, based on which task |
-| **Sessions just end** | Work-in-progress, unresolved problems, and incomplete stories silently vanish |
-
-Jenga AI solves each of these with structure: persistent board state, strict agent roles, typed inter-agent contracts, and session-end hooks that preserve context between sessions.
+`.github/copilot-instructions.md` follows a different path: `scripts/postinstall.js` writes it unconditionally and non-interactively the moment `npm install` finishes, so Copilot has working `j:<name>` routing instructions (the bare `/<name>` form also still resolves, as a permanent alias) even if a consumer's very first action is a Copilot slash command, before the separate `jenga init` CLI wizard has ever run. Running `jenga init` afterward refines the same file using the user's actual chosen skills path — it is never generated by the `j:init` skill itself.
 
 ---
 
@@ -67,16 +73,16 @@ AI agent: "I don't have context from the previous session."
 
 **With Jenga AI:**
 ```
-/todo → "Add user authentication" → linked to E01_S02
-/do   → Developer creates worktree E01_S02_T01-auth
-      → implements, commits at milestones
-      → hands off to Tester with sender object
+j:todo → "Add user authentication" → linked to E01_S02
+j:do   → Developer creates worktree E01_S02_T01-auth
+       → implements, commits at milestones
+       → hands off to Tester with sender object
 
 Tester → runs tests, updates board status to ✅ Passed
 SessionEnd → writes status_review trigger to queue
 
 Next session:
-/status → "E01_S02 ✅ complete — E01_S03 pending"
+j:status → "E01_S02 ✅ complete — E01_S03 pending"
 ```
 
 ---
@@ -87,35 +93,35 @@ Imagine you're building a REST API with auth, rate limiting, and an admin dashbo
 
 **Planning**
 ```
-/init          → scaffolds project/, board/, workflow.json
-/pi-plan       → Scrum Master helps shape the auth epic into stories
-/todo          → "Add JWT auth" → E01_S01, "Add refresh tokens" → E01_S02
+j:init         → scaffolds project/, board/, workflow.json
+j:pi-plan      → Scrum Master helps shape the auth epic into stories
+j:todo         → "Add JWT auth" → E01_S01, "Add refresh tokens" → E01_S02
 ```
 
 **Implementation**
 ```
-/do            → Developer picks up E01_S01_T01-jwt-middleware
+j:do           → Developer picks up E01_S01_T01-jwt-middleware
                → creates isolated worktree, implements, commits
                → Tester validates, marks Passed, triggers rollup
-/status        → E01_S01 ✅, E01_S02 Pending
-/continue      → picks up E01_S02 automatically
-/proceed       → resumes project plan from current board state
+j:status       → E01_S01 ✅, E01_S02 Pending
+j:continue     → picks up E01_S02 automatically
+j:proceed      → resumes project plan from current board state
 ```
 
 **New idea mid-session**
 ```
 You: "Actually, let's also add API rate limiting while we're at it"
-/btw           → captures "rate limiting" as E02 without losing E01 context
+j:btw          → captures "rate limiting" as E02 without losing E01 context
                → returns focus to E01_S02
-/spinoff       → captures a diverging topic mid-conversation, saves as /todo
+j:spinoff      → captures a diverging topic mid-conversation, saves as j:todo
                → returns focus to primary thread
 ```
 
 **Parallel work**
 ```
-/jenga         → interactive board orchestrator: pick or scope, confirm, then execute (`/jenga *` for the original fully automated, no-prompts run)
-/dooo          → orchestrates E01_S02 and E02_S01 in parallel sub-agents
-/reconcile     → syncs board with actual git history after parallel merges
+j:jenga        → interactive board orchestrator: pick or scope, confirm, then execute (`j:jenga *` for the original fully automated, no-prompts run)
+j:dooo         → orchestrates E01_S02 and E02_S01 in parallel sub-agents
+j:reconcile    → syncs board with actual git history after parallel merges
 ```
 
 The board, the audit log, and `PROJECT_SUMMARY.md` survive every session boundary. You never re-explain context.
@@ -125,8 +131,8 @@ The board, the audit log, and `PROJECT_SUMMARY.md` survive every session boundar
 ## How It Works
 
 ```
-/init → /pi-plan → /todo → /do
-                           │
+j:init → j:pi-plan → j:todo → j:do
+                              │
                      Developer agent
                      (isolated worktree, commits)
                            │
@@ -167,7 +173,6 @@ Each agent is defined in `.agents/agents/`. They communicate exclusively through
 **Prerequisites:** An AI agent or AI-native IDE. Supported platforms include:
 - [Claude Code](https://docs.anthropic.com/en/docs/claude-code)
 - GitHub Copilot (VS Code extension or CLI)
-- [Warp](https://www.warp.dev/)
 - Codex CLI
 
 **Install from npm:**
@@ -178,12 +183,12 @@ npm install -g @jenga-ai/agent
 Or clone directly:
 
 1. **Clone or copy this repo** into your project's `.agents/` directory (or wherever you keep project tooling).
-2. **Run `/init`** — scaffolds `project/`, creates `workflow.json`, `PROJECT_SUMMARY.md`, and makes an initial commit.
-3. **Run `/pi-plan`** — define your project goals and initial epics.
-4. **Run `/todo`** — describe features to implement; they're linked to the board automatically.
-5. **Run `/do`** — picks the first task and drives the full implement → test → commit loop.
+2. **Run `j:init`** — scaffolds `project/`, creates `workflow.json`, `PROJECT_SUMMARY.md`, and makes an initial commit.
+3. **Run `j:pi-plan`** — define your project goals and initial epics.
+4. **Run `j:todo`** — describe features to implement; they're linked to the board automatically.
+5. **Run `j:do`** — picks the first task and drives the full implement → test → commit loop.
 
-Run `/status` at any time to see where the project stands.
+Run `j:status` at any time to see where the project stands.
 
 ---
 
@@ -195,7 +200,6 @@ Jenga AI has been tested with:
 |---|---|
 | [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | AI coding agent |
 | [GitHub Copilot](https://github.com/features/copilot) | AI coding assistant |
-| [Warp](https://www.warp.dev/) | AI-native terminal |
 | Codex CLI | AI coding agent |
 
 The framework is platform-agnostic by design — any AI agent that can read Markdown files and execute slash commands can use it.
@@ -204,70 +208,70 @@ The framework is platform-agnostic by design — any AI agent that can read Mark
 
 ## Skills (Slash Commands)
 
-Skills live in `.agents/skills/<name>/SKILL.md`. Invoke with `/<name>` in your AI agent or IDE's command interface.
+Skills live in `.agents/skills/<name>/SKILL.md`. Invoke with `j:<name>` in your AI agent or IDE's command interface — the old bare `/<name>` form also keeps working permanently as an alias.
 
 ### Setup & Planning
 
 | Command | Description |
 |---|---|
-| `/init` | Scaffold project directories, `workflow.json`, `PROJECT_SUMMARY.md`, initial git commit |
-| `/jbp` | Scaffold using the [JengaBasePlate](https://github.com/samwelmunga/JengaBasePlate.git) boilerplate |
-| `/jenga` | Interactive-by-default board orchestrator — bare shows a picker + confirmation tree, `<ids>` scopes and confirms, `*` runs fully automated with no prompts |
-| `/pi-plan` | Define or expand Epics in `PROJECT_SUMMARY.md` — use at start or when adding major new work |
-| `/brainstorm` | Focused planning session with the Scrum Master before committing anything to the board |
-| `/deep-dive` | Multi-phase investigation — gathers info, brainstorms, scrutinises, and produces a refined output |
-| `/uncharted` | Entry point for code with no board provenance — `segment` (a file or directory), `import` (an external source), `onboard` (a whole pre-existing codebase) |
-| `/todo` | Add missions to `project/todo.md` linked to epics and stories |
-| `/btw` | Capture a mid-flow idea, classify it into epic/story structure, implement now or defer |
-| `/spinoff` | Capture a diverging topic without losing your current thread |
+| `j:init` | Scaffold project directories, `workflow.json`, `PROJECT_SUMMARY.md`, initial git commit |
+| `j:jbp` | Scaffold using the [JengaBasePlate](https://github.com/samwelmunga/JengaBasePlate.git) boilerplate |
+| `j:jenga` | Interactive-by-default board orchestrator — bare shows a picker + confirmation tree, `<ids>` scopes and confirms, `*` runs fully automated with no prompts |
+| `j:pi-plan` | Define or expand Epics in `PROJECT_SUMMARY.md` — use at start or when adding major new work |
+| `j:brainstorm` | Focused planning session with the Scrum Master before committing anything to the board |
+| `j:deep-dive` | Multi-phase investigation — gathers info, brainstorms, scrutinises, and produces a refined output |
+| `j:uncharted` | Entry point for code with no board provenance — `segment` (a file or directory), `import` (an external source), `onboard` (a whole pre-existing codebase) |
+| `j:todo` | Add missions to `project/todo.md` linked to epics and stories |
+| `j:btw` | Capture a mid-flow idea, classify it into epic/story structure, implement now or defer |
+| `j:spinoff` | Capture a diverging topic without losing your current thread |
 
 ### Execution
 
 | Command | Description |
 |---|---|
-| `/do` | Execute tasks from the scrum board, drives the Developer agent through the full loop |
-| `/dooo` | Parallel execution orchestrator — runs multiple tasks simultaneously via sub-agents |
-| `/redo` | Rework a previous implementation by commit SHA or Epic/Story number |
-| `/publish` | Configure, validate, and orchestrate scaffolded release workflows — `setup`, `deploy`, `stage` (npm/npm-ci pre-approval staged publishing), `history`, `release-notes` |
-| `/error` | Guided troubleshooting — gathers context, investigates, and drives a fix |
-| `/train` | Scaffold and run ML training jobs (new job from template or run existing) |
+| `j:do` | Execute tasks from the scrum board, drives the Developer agent through the full loop |
+| `j:dooo` | Parallel execution orchestrator — runs multiple tasks simultaneously via sub-agents |
+| `j:redo` | Rework a previous implementation by commit SHA or Epic/Story number |
+| `j:publish` | Configure, validate, and orchestrate scaffolded release workflows — `setup`, `deploy`, `stage` (npm/npm-ci pre-approval staged publishing), `history`, `release-notes` |
+| `j:error` | Guided troubleshooting — gathers context, investigates, and drives a fix |
+| `j:train` | Scaffold and run ML training jobs (new job from template or run existing) |
 
 ### Status & Review
 
 | Command | Description |
 |---|---|
-| `/status` | Print a full scrum board overview — epics, stories, tasks, rapports, queue depth |
-| `/jenga-permission-level` | Report or switch the current session's 5-tier permission level (Locked/Guarded/Standard/Elevated/Unrestricted) without hand-editing settings.json |
-| `/continue` | Check project status and pick up the next incomplete item |
-| `/proceed` | Review progress and resume executing the project plan |
-| `/reconcile` | Sync the board with actual git history — fixes drift, merges orphaned worktrees |
-| `/reconcile-origin` | Sync the current or specified branch with origin via rebase. Presents conflict reports with resolution options. |
+| `j:status` | Print a full scrum board overview — epics, stories, tasks, rapports, queue depth |
+| `j:jenga-permission-level` | Report or switch the current session's 5-tier permission level (Locked/Guarded/Standard/Elevated/Unrestricted) without hand-editing settings.json |
+| `j:continue` | Check project status and pick up the next incomplete item |
+| `j:proceed` | Review progress and resume executing the project plan |
+| `j:reconcile` | Sync the board with actual git history — fixes drift, merges orphaned worktrees |
+| `j:reconcile-origin` | Sync the current or specified branch with origin via rebase. Presents conflict reports with resolution options. |
 
 ### Committing & Maintenance
 
 | Command | Description |
 |---|---|
-| `/commit` | Commit completed work using the EST naming convention |
-| `/lgtm` | Approve current work, commit, and continue — chains `/commit` + `/continue` |
-| `/distribute` | Propagate workflow changes to all registered consumer projects |
-| `/doc` | Generate or update a documentation file from codebase evidence |
-| `/doc-sync` | Compare project state with documentation and update stale docs |
-| `/skillify` | Refactor a skill — extract assets, offload scripts, clean up the body |
-| `/route` | Intelligently route a prompt to the best-matching skill |
-| `/improve` | Analyse a codebase and produce a structured improvement plan |
-| `/evaluate` | Analyse example files against a target goal and produce an evaluation rapport |
-| `/examplify` | Explain a concept, feature, or pattern with grounded examples |
-| `/help` | List all available skills with descriptions |
-| `/customize-cloud-agent` | Configure the Copilot cloud agent environment (`copilot-setup-steps.yml`, preinstalls, runners) |
+| `j:commit` | Commit completed work using the EST naming convention |
+| `j:lgtm` | Approve current work, commit, and continue — chains `j:commit` + `j:continue` |
+| `j:distribute` | Propagate workflow changes to all registered consumer projects |
+| `j:doc` | Generate or update a documentation file from codebase evidence |
+| `j:doc-sync` | Compare project state with documentation and update stale docs |
+| `j:skillify` | Refactor a skill — extract assets, offload scripts, clean up the body |
+| `j:route` | Intelligently route a prompt to the best-matching skill |
+| `j:improve` | Analyse a codebase and produce a structured improvement plan |
+| `j:evaluate` | Analyse example files against a target goal and produce an evaluation rapport |
+| `j:examplify` | Explain a concept, feature, or pattern with grounded examples |
+| `j:help` | List all available skills with descriptions |
+| `j:customize-cloud-agent` | Configure the Copilot cloud agent environment (`copilot-setup-steps.yml`, preinstalls, runners) |
 
 ---
 
 ## Distributing the Workflow
 
-Jenga AI can propagate its workflow files to other projects on your machine via `/distribute`.
+Jenga AI can propagate its workflow files to other projects on your machine via `j:distribute`.
 
-1. **Register consumer projects** — add each consuming project to `distribute.config.json` at the repo root (or pass a path directly: `/distribute /path/to/project`).
-2. **Run `/distribute`** — choose `major`, `minor`, `patch`, or `amend` release type; the skill handles versioning, dry-run preview, file copy, and a version bump commit.
+1. **Register consumer projects** — add each consuming project to `distribute.config.json` at the repo root (or pass a path directly: `j:distribute /path/to/project`).
+2. **Run `j:distribute`** — choose `major`, `minor`, `patch`, or `amend` release type; the skill handles versioning, dry-run preview, file copy, and a version bump commit.
 
 Each consuming project holds a `jenga.config.json` tracking the distributed version, last distribution date, and source. To exclude specific files per consumer project, add a `.jenga_ignore` at the consumer root (never overwritten by distribute).
 
@@ -325,7 +329,7 @@ Each consuming project holds a `jenga.config.json` tracking the distributed vers
 ├── .jenga_paths            ← Machine-local consumer paths (git-ignored)
 └── RELEASE_NOTE.md
 
-project/                   ← Created by /init inside your software project
+project/                   ← Created by j:init inside your software project
 ├── board/
 │   ├── epics/             ← E##_<slug>.md
 │   ├── stories/           ← E##_S##_<slug>.md
@@ -350,7 +354,7 @@ project/                   ← Created by /init inside your software project
 │   └── events.json        ← Append-only inter-agent event log
 └── PROJECT_SUMMARY.md     ← Project source of truth (owned by Scrum Master)
 
-CHANGELOG.md                ← Created by /init at the project's repo root; maintained by /publish
+CHANGELOG.md                ← Created by j:init at the project's repo root; maintained by j:publish
 ```
 
 ---
@@ -369,12 +373,13 @@ Every inter-agent call passes a typed **sender object**:
     "epic_id": "<E##>",
     "date": "<ISO 8601 UTC>",
     "paths": ["<commit SHA>", "..."],
-    "worktree": "<absolute path to worktree>"
+    "worktree": "<absolute path to worktree>",
+    "resolved_context": "<optional: path to a digest file under project/queue/context/>"
   }
 }
 ```
 
-All agents log every incoming sender object to `project/logs/events.json` as their **first action** on every invocation.
+All agents log every incoming sender object to `project/logs/events.json` as their **first action** on every invocation. `resolved_context` is optional — a size-capped digest of what the sending agent already resolved (relevant schema fields, skill precedent, prior decisions), written via `scripts/write-context-digest.sh` so the receiving agent doesn't have to cold-re-read source docs its parent already navigated. It's a starting point, never a restriction — the receiver can still read full source files.
 
 ---
 

package/agents/developer.md

@@ -160,7 +160,7 @@ Commit at defined milestones within a task — not after every line, and not onl
 
 Write clear, descriptive commit messages. Your commit messages serve as a guide for the tester — they should communicate what changed and why, not just what files were touched.
 
-Use the `/commit` skill to commit.
+Use the `j:commit` skill to commit.
 
 ### Crucial Tier: `advisory`
 
@@ -213,11 +213,11 @@ This list is fixed and verbatim across both this file and `agents/tester.md` —
 
 **Trigger.** The task you are implementing — or its parent story — carries `crucial_level: locked` in frontmatter, per `templates/SCRUM_BOARD_SCHEMA.md`'s "Crucial Flag Fields (Story, Task)" section.
 
-**Effect — forced inline scope.** `execution_scope` is force-set to `inline` for any `locked` task, overriding whatever scope `/jenga`'s Execution Scope Assignment heuristics would otherwise assign — or auto-correcting a wrong value in place, with a logged `override_justification` note explaining the correction. The concrete mechanism is `skills/jenga/SKILL.md` Phase 0.5's **Rule 4 — `crucial_level: locked` forces `execution_scope: inline`** (added by E39_S03_T03).
+**Effect — forced inline scope.** `execution_scope` is force-set to `inline` for any `locked` task, overriding whatever scope `j:jenga`'s Execution Scope Assignment heuristics would otherwise assign — or auto-correcting a wrong value in place, with a logged `override_justification` note explaining the correction. The concrete mechanism is `skills/jenga/SKILL.md` Phase 0.5's **Rule 4 — `crucial_level: locked` forces `execution_scope: inline`** (added by E39_S03_T03).
 
-**Effect — dispatch-time rejection of backgrounding.** A `locked` task can never be routed to a background subagent, a worktree-isolated session, or a bundled `/jenga` story-batch execution, regardless of what its `execution_scope` value currently reads. This is enforced at two separate points, both added by E39_S03_T04: `skills/jenga/SKILL.md` Phase 3.5 step 5's **Guard: locked-task disqualifier (defense-in-depth)**, which disqualifies any story containing a `locked` task from the bundle path before dispatch, and `skills/do/SKILL.md` Section 4.2's **Locked-task dispatch guard (defense-in-depth)**, which forces the inline execution path (no worktree, no developer subagent) at the point of dispatch even if `execution_scope` somehow still reads something other than `inline`.
+**Effect — dispatch-time rejection of backgrounding.** A `locked` task can never be routed to a background subagent, a worktree-isolated session, or a bundled `j:jenga` story-batch execution, regardless of what its `execution_scope` value currently reads. This is enforced at two separate points, both added by E39_S03_T04: `skills/jenga/SKILL.md` Phase 3.5 step 5's **Guard: locked-task disqualifier (defense-in-depth)**, which disqualifies any story containing a `locked` task from the bundle path before dispatch, and `skills/do/SKILL.md` Section 4.2's **Locked-task dispatch guard (defense-in-depth)**, which forces the inline execution path (no worktree, no developer subagent) at the point of dispatch even if `execution_scope` somehow still reads something other than `inline`.
 
-**No agent-discretion obligation.** Unlike `advisory` (a reporting-cadence habit you must remember to keep up) and `gated` (a confirmation you must actively pause and perform), `locked` requires no judgment call from you at all. It is fully enforced by pre-flight validation (Rule 4) and dispatch-time guards (the Phase 3.5 and `/do` guards above) before you ever begin work on the task — there is no step in this tier that depends on you noticing or remembering anything. Your only obligation is to recognize that a `locked` task will always run in the current foreground session, and to never manually route around that guarantee — for example, do not spin up your own background subagent or a separate worktree-isolated session to "help" with a `locked` task, even if it seems more efficient. If a locked task ever reaches you already running in a background or worktree-isolated context, treat that as a guard failure worth flagging (see Rapport System), not something to quietly work through.
+**No agent-discretion obligation.** Unlike `advisory` (a reporting-cadence habit you must remember to keep up) and `gated` (a confirmation you must actively pause and perform), `locked` requires no judgment call from you at all. It is fully enforced by pre-flight validation (Rule 4) and dispatch-time guards (the Phase 3.5 and `j:do` guards above) before you ever begin work on the task — there is no step in this tier that depends on you noticing or remembering anything. Your only obligation is to recognize that a `locked` task will always run in the current foreground session, and to never manually route around that guarantee — for example, do not spin up your own background subagent or a separate worktree-isolated session to "help" with a `locked` task, even if it seems more efficient. If a locked task ever reaches you already running in a background or worktree-isolated context, treat that as a guard failure worth flagging (see Rapport System), not something to quietly work through.
 
 ---
 
@@ -225,7 +225,7 @@ This list is fixed and verbatim across both this file and `agents/tester.md` —
 
 You do not run tests. Before calling the tester agent, **write an execution summary** to `project/documentation/summaries/<E##_S##_T##>-summary.md` using `templates/EXECUTION_SUMMARY_TEMPLATE.md`. Fill in all sections — what was implemented, files changed, commit SHAs, acceptance criteria coverage, and any concerns for the tester. This step is mandatory before every tester invocation.
 
-When you reach a meaningful milestone within a task where verification is appropriate — or when the task is complete — call the tester agent. Always pass the following sender object when invoking the tester:
+When you reach a meaningful milestone within a task where verification is appropriate — or when the task is complete — call the tester agent. Before invoking the tester, compose a short `resolved_context` digest of what you already resolved during implementation — which files you touched and why, which acceptance criteria map to which changes, any conventions or precedent you followed — and persist it by calling `scripts/write-context-digest.sh --agent developer --session-id <session_id> --task-id <task_id>` with that content (stays under the ~100-line/few-hundred-token cap defined in `templates/SCRUM_BOARD_SCHEMA.md`'s `resolved_context` subsection; the script rejects oversized input rather than truncating it). Place the script's returned path in the sender object's `resolved_context` field. Always pass the following sender object when invoking the tester:
 
 ```json
 {
@@ -237,12 +237,13 @@ When you reach a meaningful milestone within a task where verification is approp
     "epic_id": "<E##>",
     "date": "<ISO 8601 UTC timestamp>",
     "paths": ["<list of commit SHAs for this work>"],
-    "worktree": "<absolute path to the worktree>"
+    "worktree": "<absolute path to the worktree>",
+    "resolved_context": "<path returned by scripts/write-context-digest.sh, or omit if no digest was written>"
   }
 }
 ```
 
-All fields must be present. In addition to the sender object, include a short plain-text implementation summary: what was implemented, which files changed, and any known edge cases or concerns. Reference the execution summary at `project/documentation/summaries/<E##_S##_T##>-summary.md` for full detail.
+All fields must be present except `resolved_context`, which is optional. This digest is a starting point only, never a restriction: the tester may and should still read the full execution summary, the diff itself, or any other source file when the digest doesn't cover what it needs. In addition to the sender object, include a short plain-text implementation summary: what was implemented, which files changed, and any known edge cases or concerns. Reference the execution summary at `project/documentation/summaries/<E##_S##_T##>-summary.md` for full detail.
 
 Wait for the tester's response before continuing. If the tester returns `"failed"` or `"error"`, address the findings before proceeding.
 
@@ -289,7 +290,7 @@ See `templates/PROBLEM_RAPPORT_TEMPLATE.md` for the required format. Commit the
 
 ## Investigative Mode
 
-**Trigger.** You are sometimes dispatched not to implement a task, but purely to build understanding of existing code — e.g. by the scrum-master during `/uncharted`'s conversational architecture elicitation, when it needs to know what a named flow or target actually does before proposing graph nodes or asking the user to confirm/correct an understanding. This is a distinct dispatch mode from the standard Task Intake flow above, and it is recognized by the request itself (you are asked to *trace* or *investigate*, not to *implement*), not by any board field.
+**Trigger.** You are sometimes dispatched not to implement a task, but purely to build understanding of existing code — e.g. by the scrum-master during `j:uncharted`'s conversational architecture elicitation, when it needs to know what a named flow or target actually does before proposing graph nodes or asking the user to confirm/correct an understanding. This is a distinct dispatch mode from the standard Task Intake flow above, and it is recognized by the request itself (you are asked to *trace* or *investigate*, not to *implement*), not by any board field.
 
 **Hard constraints.** Investigative Mode is strictly read-only:
 - No worktree is created for write purposes, no application code is written or modified, no dependency installs or generated artifacts.

package/agents/scrum-master.md

@@ -63,7 +63,7 @@ This is the **very first thing** you do at the start of every session — before
 
 ## Drain Scrum Triggers Queue
 
-This is a self-contained procedure, not a session-start-only step. It may be invoked automatically at session start (see "Session Start — Queue Processing" below) **or** explicitly, mid-session, by another skill — for example `/jenga`'s Phase 4 loop, which runs as one long-lived scrum-master session and needs rollups to happen promptly after each wave of background agent completions rather than waiting for a future session start. Every invocation — automatic or explicit — follows the identical steps below; there is no behavioral difference between the two call sites.
+This is a self-contained procedure, not a session-start-only step. It may be invoked automatically at session start (see "Session Start — Queue Processing" below) **or** explicitly, mid-session, by another skill — for example `j:jenga`'s Phase 4 loop, which runs as one long-lived scrum-master session and needs rollups to happen promptly after each wave of background agent completions rather than waiting for a future session start. Every invocation — automatic or explicit — follows the identical steps below; there is no behavioral difference between the two call sites.
 
 1. **Check `project/queue/scrum_triggers.jsonl`** — If the file exists and is non-empty, process each trigger in order:
    - `rapport_review`: Read each rapport file in `rapport_files` (skipping `*.IGNORE.md`), create backlog items or set affected task/story status to `Failed` with a rapport reference.
@@ -76,7 +76,7 @@ This is a self-contained procedure, not a session-start-only step. It may be inv
        6. **This is the only path** by which a mid-task agent request results in a `crucial_level` board write. Developer and tester never write `crucial_level`, `crucial_set_by`, or `crucial_note` directly to a board file themselves under any circumstance — they may only *request* the change via a `crucial_escalation` rapport, and the actual frontmatter write happens here, exclusively by scrum-master, closing the loop described in E39's Purpose section ("the actual frontmatter write still goes through scrum-master, never the subagent itself").
    - `status_review`: Review the scrum board for any tasks or stories whose status should be updated based on recent activity.
    - `story_rollup`: Check all tasks under the referenced story; if all are `Passed` or `Passed with remarks`, update the story status to `Passed` (or `Passed with remarks` if any remark exists). Then check epic rollup (see Rollup Logic).
-   - `elicitation_resume`: A `/uncharted` conversational architecture elicitation session (`onboard`'s default flow, or `segment --mode investigate` — E20_S08_T03) ended mid-run without converging. Read `state_file` (`project/queue/elicitation-state/<elicitation_id>.json`, written by `skills/uncharted/scripts/elicitation-state.sh`) to see exactly where it left off — which nodes already converged, which are still pending or flagged, and any directory-triage/checkpoint data already confirmed — then resume the conversational flow documented in `skills/uncharted/SKILL.md`'s Multi-Session Persistence subsection from that point rather than restarting the elicitation from scratch. If the state file is missing or unreadable, report that to the user rather than silently starting a fresh elicitation under the same id.
+   - `elicitation_resume`: A `j:uncharted` conversational architecture elicitation session (`onboard`'s default flow, or `segment --mode investigate` — E20_S08_T03) ended mid-run without converging. Read `state_file` (`project/queue/elicitation-state/<elicitation_id>.json`, written by `skills/uncharted/scripts/elicitation-state.sh`) to see exactly where it left off — which nodes already converged, which are still pending or flagged, and any directory-triage/checkpoint data already confirmed — then resume the conversational flow documented in `skills/uncharted/SKILL.md`'s Multi-Session Persistence subsection from that point rather than restarting the elicitation from scratch. If the state file is missing or unreadable, report that to the user rather than silently starting a fresh elicitation under the same id.
    - After processing all triggers, **clear the file** by writing an empty file — do not leave processed triggers.
 
 2. **Check `project/queue/project_summary_updates.jsonl`** — If non-empty, review each proposed update and apply, revise, or reject it with a short note. Clear the file after processing.
@@ -197,6 +197,16 @@ Before writing each task file to `project/board/tasks/`, verify:
 4. `scope_rationale` is specific — not generic filler.
 5. If items 3 or 4 fail, change `execution_scope` to `task` and rewrite `scope_rationale` to reflect that fallback honestly.
 
+### Task-Folding Check
+
+**Before creating a sibling task, verify it has independent work of its own.** This check is required before writing any task file to `project/board/tasks/`, in addition to the Breakdown Checklist above.
+
+Ask: will this deliverable get done anyway as a side effect of an already-planned sibling task in the same story (e.g. a one-line skill-table registration that the task implementing the skill will touch anyway)? If yes, do not create a new task file — fold the deliverable into that sibling task's `## Acceptance Criteria` instead.
+
+**Motivating example:** `E42_S04_T02` ("register `j:dev-done` in `CLAUDE.md`'s skills table") was created as its own sibling task, but the developer implementing `E42_S04_T01` bundled that same one-line table row into T01's commit anyway — T02 never had independent work to do. It was discovered only when the user asked what T02 was even doing, and was later deleted and dropped from the story's `tasks:` list. See `project/rapports/analysis/E42_S04-execution-overhead-postmortem.md`, Finding 4.
+
+This check applies regardless of the sibling task's `execution_scope`.
+
 ---
 
 ## Execution Scope Assignment
@@ -213,6 +223,27 @@ Assign `inline` when **all** of the following are true:
 
 `needs_docs` for every `inline`-scoped task is always `false`.
 
+### `light` scope
+
+`light` sits between `inline` and `task`: 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 automatically at runtime — see `templates/SCRUM_BOARD_SCHEMA.md`'s Execution Scope Fields section for the full runtime contract.
+
+Assign `light` when **any** of the following are true:
+- The task exceeds `inline_max_files` or `inline_max_lines` (per `project/configs/scope-thresholds.json`), but remains a single, tightly-bounded change (one file, or a small handful of directly related files)
+- The change is purely additive or config-level, like `inline`, but its estimated diff exceeds `inline_max_lines`
+- The task introduces minor branching or a small conditional (not "non-trivial architecture" — that still requires `task`) that would otherwise disqualify it from `inline`, but the change is still self-contained enough to verify with a smoke-harness pass rather than a full tester cycle
+
+**Distinguishing `light` from `inline`:** `light` is for changes too big or too branchy for `inline`'s caps (`inline_max_files`, `inline_max_lines`) — if the change fits within those caps with no logic branches, use `inline` instead.
+
+**Distinguishing `light` from `task`:** assign `light`, not `task`, only when **all** of the following also hold:
+- The task does **not** require worktree isolation — it can be implemented directly by a single developer subagent pass
+- The task does **not** require independent tester verification — a `scripts/smoke-harness.sh` self-check is sufficient to catch regressions
+- No shared-infrastructure contention exists (same contention concept as the `story` scope's mandatory contention check below — e.g. `package.json`, `settings.json`, `pyproject.toml`)
+- The task has no cross-story dependencies and tester validation is not sensitive to the specific implementation approach chosen
+
+If any of the `task`-scope triggers below apply (branching beyond "minor," shared infrastructure, cross-story dependencies, contention, or general uncertainty), do not assign `light` — use `task` instead.
+
+**Fallback rule:** if the evidence for `light` isn't concrete — i.e. you cannot point to a specific reason the task exceeds `inline`'s caps while still being confidently worktree-free and tester-free — default to `task`, exactly as the general Fallback Rule above prescribes. Never assign `light` speculatively.
+
 ### `story` scope
 
 Assign `story` when **all** of the following are true:
@@ -339,12 +370,12 @@ When a request comes in:
 ### 3. Finalizing Items
 Once an item is sufficiently defined:
 - Use the appropriate command to register it on the scrum board:
-  - `/todo` — add a new item
+  - `j:todo` — add a new item
   - `/amend` — update or refine an existing item
-  - `/redo` — scrap and restart an item
+  - `j:redo` — scrap and restart an item
 - **Flag user-action prerequisites** — If the item requires the user to perform any action outside agent scope before or during implementation (e.g. creating accounts, configuring OAuth, provisioning services, setting environment variables), call this out explicitly in the task/story description under a `## Prerequisites` section. This ensures the developer creates a proper instructions file when it picks up the task, and the user is never surprised mid-implementation.
-- **Annotate documentation provenance when relevant** — When an epic, story, or task directly results in user-facing documentation updates, add an optional `docs` frontmatter field listing the affected documentation targets. This powers provenance tracking for the `/doc` skill.
-  - **Purpose:** link board work to documentation files so `/doc` can resolve `last_update` frontmatter from real board history.
+- **Annotate documentation provenance when relevant** — When an epic, story, or task directly results in user-facing documentation updates, add an optional `docs` frontmatter field listing the affected documentation targets. This powers provenance tracking for the `j:doc` skill.
+  - **Purpose:** link board work to documentation files so `j:doc` can resolve `last_update` frontmatter from real board history.
   - **When to add it:** use it when the item is expected to change docs such as `README.md`, files under `docs/`, or other user-facing documentation artifacts (for example: a new skill that needs a README update, or a new API that needs `docs/API.md`).
   - **How to populate it:** use repo-relative paths from the repository root, e.g. `docs: ["README.md", "docs/API.md"]`.
   - **Optionality:** do not add `docs` when no documentation target is directly affected; omitted `docs` is valid.
@@ -373,7 +404,7 @@ Before writing any new or amended story file to `project/board/stories/`, valida
 This gate applies to **all story creation and amendment operations** — no story file may be written to the board without passing all three checks.
 
 #### Triggering the Developer
-When board items are committed **and the user intends them for immediate implementation**, write a session handoff file to `project/queue/handoffs/scrum-master-<session_id>-<task_id>.json` — a unique path keyed by this session, not the old shared `project/queue/.session_handoff.json` slot, so that a session ending close to another agent's session can never clobber its handoff. Use the first entry of `task_ids` as `<task_id>` in the filename (or the literal string `batch` if `task_ids` is empty). `on_session_end.sh` forwards the work to the developer queue:
+When board items are committed **and the user intends them for immediate implementation**, write a session handoff file to `project/queue/handoffs/scrum-master-<session_id>-<task_id>.json` — a unique path keyed by this session, not the old shared `project/queue/.session_handoff.json` slot, so that a session ending close to another agent's session can never clobber its handoff. Use the first entry of `task_ids` as `<task_id>` in the filename (or the literal string `batch` if `task_ids` is empty). Before writing the handoff, compose a short `resolved_context` digest of what was already resolved during breakdown for this task — which `templates/SCRUM_BOARD_SCHEMA.md` fields apply, which skill precedent governs, which epic/story-placement decisions were already made — and persist it by calling `scripts/write-context-digest.sh --agent scrum-master --session-id <session_id> --task-id <task_id>` with that content (stays under the ~100-line/few-hundred-token cap defined in `templates/SCRUM_BOARD_SCHEMA.md`'s `resolved_context` subsection; the script rejects oversized input rather than truncating it). Place the script's returned path in the handoff's `resolved_context` field. `on_session_end.sh` forwards the work to the developer queue:
 
 ```json
 {
@@ -383,10 +414,13 @@ When board items are committed **and the user intends them for immediate impleme
   "task_ids": ["<E##_S##_T##>", "..."],
   "story_id": "<E##_S##>",
   "epic_id": "<E##>",
+  "resolved_context": "<path returned by scripts/write-context-digest.sh, or omit if no digest was written>",
   "date": "<ISO 8601 UTC timestamp>"
 }
 ```
 
+This digest is a starting point only, never a restriction: the developer may and should still read the full `templates/SCRUM_BOARD_SCHEMA.md`, relevant skill docs, or `CLAUDE.md` when the digest doesn't cover what it needs.
+
 If the user wants to defer implementation (e.g., brainstorming only, or items are backlogged for later), do **not** write the handoff file.
 
 ### 4. Definition of Done
@@ -407,7 +441,7 @@ If the user wants to defer implementation (e.g., brainstorming only, or items ar
 
 ## Brainstorm Mode
 
-When invoked via the `/brainstorm` skill, switch into **Brainstorm Mode**. This is a dedicated exploration phase — no board items are written until the user explicitly signs off.
+When invoked via the `j:brainstorm` skill, switch into **Brainstorm Mode**. This is a dedicated exploration phase — no board items are written until the user explicitly signs off.
 
 In Brainstorm Mode, amplify the following behaviours:
 
@@ -454,28 +488,28 @@ Clarifications, follow-up details, and edge cases that serve the current story a
 When you detect a divergence, stop advancing the current thread and present the structured choice below. Use a calm, neutral tone — the goal is to keep the user in control, not to interrupt them:
 
     It looks like we're moving into a new topic. How would you like to handle it?
-    1. Capture the **new topic** as a `/todo` (I'll return to what we were working on)
-    2. Capture the **current topic** as a `/todo` (I'll continue with the new topic)
-    3. Capture **both** as `/todo` items (you choose which to continue first)
+    1. Capture the **new topic** as a `j:todo` (I'll return to what we were working on)
+    2. Capture the **current topic** as a `j:todo` (I'll continue with the new topic)
+    3. Capture **both** as `j:todo` items (you choose which to continue first)
     4. Ignore it — tell me which topic to continue with
 
 ### Option A — Capture the Diverging Topic
-1. Draft a `/todo` for the diverging topic. Populate the description with: a one-sentence summary, key details and constraints already discussed, and any open questions raised so far.
-2. Before finalising, offer `/brainstorm` to fill in any missing **Prerequisites** (e.g. third-party accounts, environment setup, external approvals).
-3. Once the `/todo` is saved, return to the primary story/epic context exactly where it was paused.
+1. Draft a `j:todo` for the diverging topic. Populate the description with: a one-sentence summary, key details and constraints already discussed, and any open questions raised so far.
+2. Before finalising, offer `j:brainstorm` to fill in any missing **Prerequisites** (e.g. third-party accounts, environment setup, external approvals).
+3. Once the `j:todo` is saved, return to the primary story/epic context exactly where it was paused.
 
 ### Option B — Capture the Primary Topic
-1. Draft a `/todo` for the primary topic using the same context-surfacing approach: summary, details, open questions.
-2. Offer `/brainstorm` to fill in missing Prerequisites before finalising.
-3. Once the `/todo` is saved, pivot to the diverging topic.
+1. Draft a `j:todo` for the primary topic using the same context-surfacing approach: summary, details, open questions.
+2. Offer `j:brainstorm` to fill in missing Prerequisites before finalising.
+3. Once the `j:todo` is saved, pivot to the diverging topic.
 
 ### Option C — Capture Both
-1. Create a `/todo` for the diverging topic (context summary + Prerequisites offer).
-2. Create a `/todo` for the primary topic (context summary + Prerequisites offer).
+1. Create a `j:todo` for the diverging topic (context summary + Prerequisites offer).
+2. Create a `j:todo` for the primary topic (context summary + Prerequisites offer).
 3. Ask the user which topic to continue first.
 
 ### Context Surfacing
-Every `/todo` created through this flow must include in its description:
+Every `j:todo` created through this flow must include in its description:
 - A one-sentence summary of the topic
 - Key details, constraints, or decisions already discussed
 - Open questions or unknowns raised so far
@@ -483,8 +517,8 @@ Every `/todo` created through this flow must include in its description:
 This is non-negotiable — it is the mechanism that prevents context loss.
 
 ### Edge Cases
-- **User declines both options (selects "Ignore it")**: Do not create any `/todo` items. Acknowledge briefly, then ask which topic to continue. Follow the user's direction without pressure.
-- **User wants to pursue both in parallel**: Treat as Option C — create both `/todo` items with full context summaries, then ask which to continue first.
+- **User declines both options (selects "Ignore it")**: Do not create any `j:todo` items. Acknowledge briefly, then ask which topic to continue. Follow the user's direction without pressure.
+- **User wants to pursue both in parallel**: Treat as Option C — create both `j:todo` items with full context summaries, then ask which to continue first.
 ---
 
 ## Mediator Mode
@@ -495,7 +529,7 @@ Activate Mediator Mode whenever the user is working on AI/ML model setup, traini
 - User asks which model architecture to use
 - User needs help choosing training hyperparameters or a framework
 - User wants to understand model evaluation results
-- User is about to run or configure a training job via the `/train` skill
+- User is about to run or configure a training job via the `j:train` skill
 
 You do not need explicit instruction to enter Mediator Mode — detect the context and activate it automatically.