@jenga-ai/agent 2.0.0 → 3.0.0

package/skills/{uncharted → j-uncharted}/scripts/inspect-provenance.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/inspect-provenance.sh
+# skills/j-uncharted/scripts/inspect-provenance.sh
 #
 # Provenance surface for `/uncharted import`'s placement-confirmation gate
 # (E40_S03_T02). Given a staged source -- the `content_path` that

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

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/resolve-segment-target.sh
+# skills/j-uncharted/scripts/resolve-segment-target.sh
 #
 # Deterministic front half of `/uncharted segment`. Given the raw argument the
 # user typed, it answers two mechanical questions so the agent never has to
@@ -13,7 +13,7 @@
 # It resolves, it classifies, it reports. It NEVER writes anything, never runs
 # the engine, and never touches application code. Deciding what to do with the
 # answer — which candidate to pick, whether the segment is worth investigating
-# — is agent judgement and lives in `skills/uncharted/SKILL.md`.
+# — is agent judgement and lives in `skills/j-uncharted/SKILL.md`.
 #
 # ---------------------------------------------------------------------------
 # BOARD-LINKAGE CHECK — the reusable interface
@@ -51,7 +51,7 @@
 # (`[A-Za-z0-9_./-]+`, trailing `.`/`-` stripped so a filename ending a sentence
 # still counts). A board file references the path when one of its tokens either
 # equals the path or is a DESCENDANT of it — so `skills/uncharted` is referenced
-# by a board item that only names `skills/uncharted/scripts/run-engine.sh`.
+# by a board item that only names `skills/j-uncharted/scripts/run-engine.sh`.
 #
 # This is a path-boundary test, not a substring test: `docs/hooks` does not make
 # `hooks` linked, and `src/app.js` does not make `src/app` linked.
@@ -343,7 +343,7 @@ def load_board():
 
     Every path-like run in a board file is registered under itself AND under each of its
     ancestor directories, so `skills/uncharted` is found via a board item that only ever names
-    `skills/uncharted/scripts/run-engine.sh`.
+    `skills/j-uncharted/scripts/run-engine.sh`.
     """
     docs = []
     index = {}
@@ -382,7 +382,7 @@ def load_board():
                 for k in range(1, len(parts) + 1):
                     prefix = "/".join(parts[:k])
                     # The token itself is registered too, not just its ancestors -- an exact
-                    # mention of `skills/uncharted/SKILL.md` must make that file linked.
+                    # mention of `skills/j-uncharted/SKILL.md` must make that file linked.
                     if not prefix or prefix in seen_prefixes:
                         continue
                     seen_prefixes.add(prefix)

package/skills/{uncharted → j-uncharted}/scripts/run-engine.sh

@@ -7,7 +7,7 @@
 # This is the ONE script the calling agent invokes. It does not reimplement any analysis:
 # it orchestrates the three deterministic detectors delivered by E40_S01_T02/T03, merges
 # their JSON, renders the understanding document from
-# skills/uncharted/assets/UNDERSTANDING_DOC_TEMPLATE.md, writes it into
+# skills/j-uncharted/assets/UNDERSTANDING_DOC_TEMPLATE.md, writes it into
 # project/rapports/analysis/, and prints the written path — and nothing else — on stdout.
 #
 #   enumerate-target.sh     → Target + Structure sections

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

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # ---------------------------------------------------------------------------
-# skills/uncharted/scripts/validate-proposed-items.sh
+# skills/j-uncharted/scripts/validate-proposed-items.sh
 #
 # Post-write gate for `/uncharted segment` Step 7. Given the board files a
 # confirmed proposal just wrote, it answers one mechanical question: do these
@@ -9,7 +9,7 @@
 # It validates. It NEVER writes, moves, or repairs a board file, and it has no
 # opinion about content — only about format. Deciding what to do with a failure
 # (fix and re-run, or roll the write back) is agent judgement and lives in
-# `skills/uncharted/SKILL.md`.
+# `skills/j-uncharted/SKILL.md`.
 #
 #   Usage: validate-proposed-items.sh <board-file> [more-files...]
 #

package/skills/{uncharted → j-uncharted}/scripts/write-backfilled-epics.sh

@@ -18,7 +18,7 @@
 # application code. Its entire output surface is project/board/, project/rapports/analysis/,
 # and project/PROJECT_SUMMARY.md. This script is the one that actually touches disk in the
 # epic-generation step, so it is where that guarantee is made STRUCTURAL rather than only
-# documented in skills/uncharted/SKILL.md:
+# documented in skills/j-uncharted/SKILL.md:
 #
 #   - The epics directory (--epics-dir, default <repo-root>/project/board/epics) and the
 #     --json-out path, if given, are both canonicalised and checked BEFORE any file is written.

package/skills/j-wtf/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: j.wtf
+description: Polyfill alias of the wtf skill under a collision-safe directory name. Identical behavior to /wtf — 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`. Use when the bare /wtf form is shadowed by another tool's own built-in command of the same name.
+keywords:
+  - wtf
+  - confused
+  - huh
+  - what does this mean
+  - I'm lost
+  - j-wtf
+  - polyfill
+examples:
+  - "wtf"
+  - "wtf does this mean"
+  - "wtf is going on here"
+  - "j-wtf"
+---
+
+# WTF — Alias of /clearify
+
+This skill is a literal-directory-name duplicate of `skills/wtf/`. It exists so that `/j-wtf` (and `j.j-wtf`) give a guaranteed-unshadowed way to reach the same flow as `/wtf`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/wtf` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+
+This file is generated/synced by `scripts/generate-j-alias.sh wtf` from `skills/wtf/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
+## 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.

package/skills/jenga/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: j:jenga
+name: j.jenga
 description: Interactive-by-default board orchestrator with a fully automated escape hatch. Bare `/jenga` renders a picker and confirmation tree before scoping the run; `/jenga <ids>` resolves an explicit fuzzy-ID scope and confirms it; `/jenga *` reproduces the original zero-prompt behavior — decomposing any unbroken Epics into Stories, any unbroken Stories into Tasks, queuing all unqueued Tasks into todo.md, then executing every eligible item with no user prompts — until the board is fully started.
 keywords:
   - jenga

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

@@ -1,5 +1,5 @@
 ---
-name: j: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

@@ -564,7 +564,7 @@ Each file is written by an agent as the **last action** of its session, and is s
 - `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.
+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).
 
 
 

package/templates/agent-context.md.tpl

@@ -10,7 +10,7 @@ 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 `j:skill-name` in the chat prompt (e.g. `j:status`, `j:commit`). The
+- 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.
@@ -18,21 +18,21 @@ This project uses **Jenga** — a skill-based AI agent framework. Jenga organise
 
 ### Skill Routing
 
-If you are Claude Code, both `j:skill-name` (the canonical form) and the older bare `/skill-name`
+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
+`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.
 
-**Old bare-form alias.** `j:skill-name` is the canonical invocation form. A message using the older
+**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
+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
+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
@@ -51,17 +51,17 @@ 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 `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}}
+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,
+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

package/templates/copilot-instructions.md.tpl

@@ -9,8 +9,15 @@ 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 `j:skill-name` in the chat prompt (e.g. `j:status`, `j:commit`). The
+- 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.
@@ -18,22 +25,43 @@ This project uses **Jenga** — a skill-based AI agent framework. Jenga organise
 
 ### Skill Routing
 
-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.
+**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:
 
-**Old bare-form alias.** `j:skill-name` is the canonical invocation form. A message using the older
+```
+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
+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
+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).
@@ -46,17 +74,26 @@ 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.
+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 `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 |
+| 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 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 |
 
@@ -77,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: j: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: j: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: j: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/SKILL.md

@@ -1,155 +0,0 @@
----
-name: j:init
-description: Initialize a new project with the standard directory structure, PROJECT_SUMMARY.md, workflow.json, git repo, and gitignore. Follows a defined ordered onboarding sequence. Use when setting up a new or empty project.
-keywords:
-  - init
-  - initialize
-  - setup
-  - new project
-  - scaffold
-examples:
-  - "initialize a new project"
-  - "set up a new workspace"
----
-
-# Init — Project Setup
-
-## Instructions
-
-Follow these steps in order. Do not skip steps — the sequence matters.
-
-### 1. Detect existing project state
-
-Before asking anything or scaffolding anything, classify the target directory
-(the current directory) by running the detection script:
-
-```bash
-skills/init/scripts/detect-existing-codebase.sh .
-```
-
-It prints exactly one verdict on stdout:
-
-| Verdict | Meaning | What to do |
-|---|---|---|
-| `empty` | The directory is empty, or contains only `.git`, `.gitignore`, and top-level `README*`/`LICENSE*` boilerplate. | Proceed to step 2 — behaviour here is unchanged from before this detection step existed. |
-| `already-scaffolded` | `project/board/`, `project/PROJECT_SUMMARY.md`, or `project/configs/workflow.json` already exists. | Tell the user this directory already has a Jenga scaffold and **stop** — do not run the scaffold script. Re-running it would silently overwrite `PROJECT_SUMMARY.md` and `workflow.json` with fresh stubs. Point them at `/continue` or `/status` instead. |
-| `existing-codebase` | The directory has real content (source, configs, docs beyond the boilerplate list) and is not already scaffolded. | **Pause. Do not scaffold.** Present the choice below and wait for an answer. |
-
-On `existing-codebase`, present this choice verbatim, per the Interaction Pattern in
-`CLAUDE.md` (numbered, free-text last):
-
-    This directory already contains code that wasn't built through Jenga. How would
-    you like to proceed?
-    1. Run /uncharted onboard first, to analyze the existing code and backfill the
-       board before scaffolding
-    2. Scaffold fresh anyway, leaving the board empty (the existing code is never
-       modified either way — onboard mode and fresh scaffolding are both board-only)
-    3. Abort — don't scaffold, don't run /uncharted
-    4. Other (describe below)
-
-- **Option 1** — invoke `/uncharted onboard`. It analyzes the existing code and backfills
-  the board; it never modifies, moves, or restructures application code. Once it
-  finishes, the directory now has `project/PROJECT_SUMMARY.md` etc., so re-running this
-  detection step returns `already-scaffolded` — there is nothing left to scaffold.
-- **Option 2** — continue to step 2 and scaffold fresh. Note in your response that the
-  board will start empty despite the directory containing pre-existing code, since the
-  user explicitly chose that.
-- **Option 3** — stop here. Do not run the scaffold script and do not invoke `/uncharted`.
-- **Option 4** — handle the free-text response on its own merits.
-
-If the run is non-interactive (no user available to answer), default to **option 3
-(abort)**. Unlike the visibility question in step 2, none of these three choices is a
-no-op: running `/uncharted onboard` unattended commits an analysis pass the user never
-asked for, and scaffolding fresh unattended silently discards pre-existing code from the
-board exactly as `/init` did before this step existed. Aborting is the only choice that
-changes nothing on disk, so it is the only safe default.
-
-Never treat `existing-codebase` as if it were `empty`, and never skip straight to step 2
-on that verdict without the user (or the non-interactive default) choosing to.
-
-### 2. Ask how Jenga AI's working files should appear
-
-Ask the user this question, verbatim, before running any script:
-
-    How should Jenga AI's own working files (project/ — the scrum board, todo.md,
-    queue/, rapports/, and logs/) appear in this project?
-    1. Visible — keep them at `project/`, tracked and visible in directory listings
-    2. Ignored — keep them at `project/` but add them to `.gitignore` so they are never committed
-    3. Not sure — explain the trade-offs and ask me again
-
-If the user picks option 3, explain the trade-offs and re-ask. Do not proceed until
-the answer is one of `visible` or `ignored`.
-
-If the run is non-interactive (no user available to answer), use the default:
-**`visible`**. It is the only choice that changes nothing on disk, so an unattended
-run can never silently relocate directories or edit `.gitignore`.
-
-> A third mode, `hidden` (dot-prefixing `project/` to `.project/`, matching the
-> `.agents/`/`.claude/` convention), was built and then withdrawn before release —
-> testing found it left board resolution and session-end hooks writing to two
-> different trees. It is not offered here. See
-> `skills/distribute/CONFIG_SCHEMA.md` for the root-cause note and the tracked
-> follow-up to reintroduce it once fixed.
-
-Carry the chosen value into step 3. Do not apply it yourself — the script owns all
-of the mechanical work.
-
-### 3. Run the scaffold script
-
-`init.sh` is not guaranteed to live at a single fixed path: in a project that
-installed Jenga via npm, it was mirrored to `.claude/skills/init/scripts/`
-(Claude Code) and `.agents/skills/init/scripts/` (Copilot/other agents) by
-`postinstall.js`, and neither of those exists yet in this framework's own
-source checkout, where it lives at the bare `skills/init/scripts/` path
-instead. This step runs before `CLAUDE.md`/`AGENTS.md` exist, so it cannot
-rely on either file's routing instructions to resolve the path — it must
-locate its own script directly. Execute the init script from the project
-root, passing the choice from step 2:
-
-```bash
-INIT_SCRIPT=""
-for candidate in .claude/skills/init/scripts/init.sh .agents/skills/init/scripts/init.sh skills/init/scripts/init.sh; do
-  [[ -f "$candidate" ]] && { INIT_SCRIPT="$candidate"; break; }
-done
-if [[ -z "$INIT_SCRIPT" ]]; then
-  echo "Error: could not locate init.sh under .claude/skills/, .agents/skills/, or skills/" >&2
-  exit 1
-fi
-chmod +x "$INIT_SCRIPT" && "$INIT_SCRIPT" --visibility <visible|ignored>
-```
-
-Omitting `--visibility` falls back to the `JENGA_PROJECT_FILES_VISIBILITY`
-environment variable, then to `visible`.
-
-This script handles all scaffolding in one step:
-1. Initializes the git repository
-2. Creates `.gitignore`
-3. Creates the full directory structure under `project/`
-4. Creates `project/PROJECT_SUMMARY.md` with placeholder content
-5. Creates `project/configs/workflow.json` with shared constants
-6. Creates `project/configs/test-config.json` stub
-7. Creates `project/configs/scope-thresholds.json` with default execution-scope thresholds (consumed by `/jenga` and `/do`, which halt if it's missing)
-8. Creates `project/data/baselines.json`
-9. Creates `project/logs/events.json`
-10. Creates `docs/STRATEGY.md` — a strategic brief stub intended for investors, partners, and the product team
-11. Creates `CHANGELOG.md` from the shared template — a running log of notable changes, seeded with an `[Unreleased]` section
-12. Applies the chosen visibility mode via `scripts/apply-project-visibility.sh`, which records it as `project_files_visibility` in `jenga.config.json` and performs any `.gitignore` change
-13. Stages and commits all files with the message `init: scaffold project structure and workflow config`
-
-The visibility mode is validated before any scaffolding happens, so an invalid
-value fails fast and leaves nothing behind. It is applied before the commit, so
-the `.gitignore` entry is captured in the initial commit.
-
-If the script fails, check that you are in the project root and that git and `jq`
-are available.
-
-See `skills/distribute/CONFIG_SCHEMA.md` for the full `project_files_visibility`
-field reference.
-
-### 4. Prompt next step
-
-Inform the user that setup is complete, and state which visibility mode was applied
-and where the working files now live. Mention that `docs/STRATEGY.md` was created as
-a strategic brief stub for investors, partners, and the product team — they can fill
-it in now or return to it later. Suggest running `/pi-plan` to define project goals
-and epics.

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

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

package/skills/init/assets/strategy_stub_template.md

@@ -1,38 +0,0 @@
-# Strategy
-
-<!-- This document is intended for investors, strategic partners, and senior stakeholders.
-     Write in clear, confident language that conveys conviction and focus.
-     Avoid jargon. Prioritise substance over length. -->
-
-## Vision
-
-<!-- Describe the long-term direction of this project over a 3–5 year horizon.
-     What change do you want to see in the world, and what role does this project play in bringing it about?
-     A strong vision statement is specific, ambitious, and grounded — it should be possible to hold yourself accountable to it. -->
-
-## Value Proposition
-
-<!-- Articulate what makes this project uniquely valuable and to whom.
-     Answer: Why does this exist? Why now? Why this team?
-     Focus on the distinct advantage or insight that underpins the project — not features, but the underlying value delivered. -->
-
-## Scope
-
-### In Scope
-
-<!-- List the capabilities, domains, or problem spaces this project actively addresses.
-     Be specific enough that a new stakeholder can quickly understand the boundaries of the work.
-     Use bullet points for readability. -->
-
-### Out of Scope
-
-<!-- List what this project explicitly does not cover.
-     Revenue model, pricing strategy, and competitive analysis are intentionally excluded from this document —
-     they belong in separate artefacts and are out of scope here.
-     Use this section to prevent scope creep and set clear expectations with stakeholders. -->
-
-## Target Audience
-
-<!-- Describe who this project is built for.
-     Include both the end users (who experiences the product) and the stakeholders (who evaluates or funds it).
-     Be specific: a well-defined audience sharpens every other section of this document. -->