@jenga-ai/agent 2.0.0 → 3.1.0

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

@@ -1,25 +1,32 @@
 ---
-name: j:idea
-description: Capture a loosely-defined idea to project/ideas.md — a lightweight, "maybe someday" log with no board or promotion overhead.
+name: j.idea
+description: Polyfill alias of the idea skill under a collision-safe directory name. Identical behavior to /idea — Capture a loosely-defined idea to project/ideas.md — a lightweight, "maybe someday" log with no board or promotion overhead. Use when the bare /idea form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - idea
   - capture idea
   - log idea
   - brain dump
   - maybe someday
+  - j-idea
+  - polyfill
 examples:
   - "capture this as an idea"
   - "log this idea for later"
   - "I have a rough idea I want to jot down"
+  - "j-idea"
 metadata:
   prefered_agent: scrum-master
 ---
 
 # Idea — Lightweight Idea Capture
 
+This skill is a literal-directory-name duplicate of `skills/idea/`. It exists so that `/j-idea` (and `j.j-idea`) give a guaranteed-unshadowed way to reach the same flow as `/idea`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/idea` 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 idea` from `skills/idea/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Instructions
 
-1. **Ensure `project/ideas.md` exists** — If it doesn't exist, it will be auto-created by `idea_manager.sh` from `skills/idea/assets/idea_template.md` — no manual action needed.
+1. **Ensure `project/ideas.md` exists** — If it doesn't exist, it will be auto-created by `idea_manager.sh` from `skills/j-idea/assets/idea_template.md` — no manual action needed.
 
 2. **Ask the user about the idea:**
    - What's the idea?

package/skills/{idea → j-idea}/assets/idea_handoff_template.md

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

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

@@ -1,10 +1,17 @@
 ---
-name: j:improve
-description: A skill for analyzing a codebase and producing a structured improvement plan toward a defined goal.
+name: j.improve
+description: Polyfill alias of the improve skill under a collision-safe directory name. Identical behavior to /improve — A skill for analyzing a codebase and producing a structured improvement plan toward a defined goal. Use when the bare /improve form is shadowed by another tool's own built-in command of the same name.
+keywords:
+  - j-improve
+  - polyfill
 ---
 
 # Improve
 
+This skill is a literal-directory-name duplicate of `skills/improve/`. It exists so that `/j-improve` (and `j.j-improve`) give a guaranteed-unshadowed way to reach the same flow as `/improve`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/improve` 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 improve` from `skills/improve/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Instructions
 
 Before doing anything, check the attached description for an explicit or implicit goal.

package/skills/j-init/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: j:j-init
+name: j.init
 description: Polyfill alias of the init skill under a collision-safe directory name. Identical behavior to /init — initializes a new project with the standard directory structure, PROJECT_SUMMARY.md, workflow.json, git repo, and gitignore. Use when the built-in "/init" command (e.g. GH Copilot's own init) shadows Jenga's /init alias.
 keywords:
   - init
@@ -21,7 +21,7 @@ This skill is a literal-directory-name duplicate of `skills/init/`. It exists be
 some host tools/harnesses (e.g. GH Copilot) ship their own built-in command literally
 named `/init`, which can shadow or override Jenga AI's own `/init` alias (Claude Code's
 native skill resolution is a literal-string, directory-name-based match — see
-`docs/skill-authoring.md`'s "Invocation Convention"). `/j-init` (and `j:j-init`) give
+`docs/skill-authoring.md`'s "Invocation Convention"). `/j-init` (and `j.j-init`) give
 users a guaranteed-unshadowed way to reach the exact same setup flow.
 
 Keep this file's instructions in lockstep with `skills/init/SKILL.md` — any change made

package/skills/j-jbp/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: j.jbp
+description: Polyfill alias of the jbp skill under a collision-safe directory name. Identical behavior to /jbp — Scaffold the project using the JengaBasePlate boilerplate repo template from https://github.com/samwelmunga/JengaBasePlate.git. Use when the bare /jbp form is shadowed by another tool's own built-in command of the same name.
+keywords:
+  - jbp
+  - boilerplate
+  - scaffold
+  - template
+  - jenga base
+  - j-jbp
+  - polyfill
+examples:
+  - "scaffold with JengaBasePlate"
+  - "set up the base template"
+  - "j-jbp"
+---
+
+# JBP — JengaBasePlate Scaffold
+
+This skill is a literal-directory-name duplicate of `skills/jbp/`. It exists so that `/j-jbp` (and `j.j-jbp`) give a guaranteed-unshadowed way to reach the same flow as `/jbp`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/jbp` 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 jbp` from `skills/jbp/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
+## 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/j-lgtm/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: j.lgtm
+description: Polyfill alias of the lgtm skill under a collision-safe directory name. Identical behavior to /lgtm — Approve and commit the current work, then continue to the next task. Shortcut that chains /commit followed by /continue. Use when the bare /lgtm form is shadowed by another tool's own built-in command of the same name.
+keywords:
+  - lgtm
+  - approve
+  - looks good
+  - done
+  - commit and continue
+  - j-lgtm
+  - polyfill
+examples:
+  - "lgtm, commit this"
+  - "looks good, move on"
+  - "j-lgtm"
+---
+
+# LGTM — Approve, Commit, and Continue
+
+This skill is a literal-directory-name duplicate of `skills/lgtm/`. It exists so that `/j-lgtm` (and `j.j-lgtm`) give a guaranteed-unshadowed way to reach the same flow as `/lgtm`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/lgtm` 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 lgtm` from `skills/lgtm/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
+## 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/{pi-plan → j-pi-plan}/SKILL.md

@@ -1,21 +1,28 @@
 ---
-name: j:pi-plan
-description: Define or expand project Epics in PROJECT_SUMMARY.md. Use this at the start of a project to establish its foundation, AND whenever the user wants to add major new features, plan a significant new area of work, or make epic-level changes to an existing project. Trigger whenever you hear things like "new feature area", "big change", "new epic", "expand the project", "add a major capability", or "plan a new phase" — even mid-project.
+name: j.pi-plan
+description: Polyfill alias of the pi-plan skill under a collision-safe directory name. Identical behavior to /pi-plan — Define or expand project Epics in PROJECT_SUMMARY.md. Use this at the start of a project to establish its foundation, AND whenever the user wants to add major new features, plan a significant new area of work, or make epic-level changes to an existing project. Trigger whenever you hear things like "new feature area", "big change", "new epic", "expand the project", "add a major capability", or "plan a new phase" — even mid-project. Use when the bare /pi-plan form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - epic
   - template
   - expand
   - new feature area
   - project structure
+  - j-pi-plan
+  - polyfill
 examples:
   - "add a new epic for X"
   - "expand the project with a new feature area"
+  - "j-pi-plan"
 metadata: 
   prefered_agent: scrum-master
 ---
 
 # Pi-plan — Define and Expand Project Epics
 
+This skill is a literal-directory-name duplicate of `skills/pi-plan/`. It exists so that `/j-pi-plan` (and `j.j-pi-plan`) give a guaranteed-unshadowed way to reach the same flow as `/pi-plan`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/pi-plan` 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 pi-plan` from `skills/pi-plan/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## When to use this skill
 
 - **New project**: Gather project description and goals, then define the initial set of Epics.
@@ -59,4 +66,4 @@ Story files created under `project/board/stories/` should follow `./assets/story
 
 4. **Define new Epics** — Draft one or more new Epic objects using the same schema as above, then append them to the existing Epics list in `project/PROJECT_SUMMARY.md`. Do not modify existing Epics unless the user explicitly asks.
 
-5. **Confirm before writing** — Show the user the proposed new Epic(s) and get confirmation before updating the file.
+5. **Confirm before writing** — Show the user the proposed new Epic(s) and get confirmation before updating the file.

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

@@ -1,20 +1,27 @@
 ---
-name: j:proceed
-description: Review project progress by checking epics and stories, optionally consulting PROJECT_SUMMARY.md and WARP.md, then continue executing the project plan.
+name: j.proceed
+description: Polyfill alias of the proceed skill under a collision-safe directory name. Identical behavior to /proceed — Review project progress by checking epics and stories, optionally consulting PROJECT_SUMMARY.md and WARP.md, then continue executing the project plan. Use when the bare /proceed form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - proceed
   - review progress
   - check epics
   - continue executing
+  - j-proceed
+  - polyfill
 examples:
   - "proceed with the plan"
   - "review progress and continue"
+  - "j-proceed"
 metadata:
   prefered_agent: scrum-master
 ---
 
 # Proceed — Resume Project Execution
 
+This skill is a literal-directory-name duplicate of `skills/proceed/`. It exists so that `/j-proceed` (and `j.j-proceed`) give a guaranteed-unshadowed way to reach the same flow as `/proceed`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/proceed` 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 proceed` from `skills/proceed/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 ## Instructions
 
 1. **Assess progress** — Read `project/PROJECT_SUMMARY.md`, then check `project/board/epics/`, `project/board/stories/`, and `project/board/tasks/` to determine how far the project has come and what is outstanding.

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

@@ -1,6 +1,6 @@
 ---
-name: j:publish
-description: Configure, validate, and orchestrate scaffolded release workflows through a single `/publish` entry point with bounded sub-commands.
+name: j.publish
+description: Polyfill alias of the publish skill under a collision-safe directory name. Identical behavior to /publish — Configure, validate, and orchestrate scaffolded release workflows through a single `/publish` entry point with bounded sub-commands. Use when the bare /publish form is shadowed by another tool's own built-in command of the same name.
 keywords:
   - publish
   - deploy
@@ -11,6 +11,8 @@ keywords:
   - release notes
   - staged publishing
   - stage
+  - j-publish
+  - polyfill
 examples:
   - "publish setup --target staging-appstore"
   - "publish setup --type mobile-ios"
@@ -26,6 +28,7 @@ examples:
   - "test a release before publishing"
   - "publish stage --target npm-registry --dry-run"
   - "approve a staged npm release"
+  - "j-publish"
 metadata:
   scope: multi-target-v2
   primary_target: multi
@@ -39,13 +42,17 @@ metadata:
 
 # Publish — Deployment Pipeline Orchestrator
 
+This skill is a literal-directory-name duplicate of `skills/publish/`. It exists so that `/j-publish` (and `j.j-publish`) give a guaranteed-unshadowed way to reach the same flow as `/publish`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/publish` 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 publish` from `skills/publish/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+
 `/publish` is the single entry point for release workflows in this repository. It wires configuration validation, setup, gated deployment, release-note drafting, and ledger history into one end-to-end flow, and dispatches the final publish step to a per-type adapter.
 
 Four target types are currently supported:
 
 - **`mobile-ios`** — publishes an iOS build to App Store Connect via the iOS adapter. See the [iOS App Store](#ios-app-store) section for iOS-specific configuration.
-- **`npm`** — publishes a package to an npm registry via the npm adapter. See the npm adapter (`skills/publish/adapters/npm.md`) and the npm wizard (`skills/publish/wizards/npm.md`) for npm-specific configuration.
-- **`npm-ci`** — publishes a package to npmjs.com via GitHub Actions OIDC (Trusted Publishers), with no `NPM_TOKEN` stored. The adapter generates a GitHub Actions workflow, commits it to the repository, and triggers it via `gh workflow run`. See the npm-ci adapter (`skills/publish/adapters/npm-ci.md`) and the npm-ci wizard (`skills/publish/wizards/npm-ci.md`) for configuration details.
+- **`npm`** — publishes a package to an npm registry via the npm adapter. See the npm adapter (`skills/j-publish/adapters/npm.md`) and the npm wizard (`skills/j-publish/wizards/npm.md`) for npm-specific configuration.
+- **`npm-ci`** — publishes a package to npmjs.com via GitHub Actions OIDC (Trusted Publishers), with no `NPM_TOKEN` stored. The adapter generates a GitHub Actions workflow, commits it to the repository, and triggers it via `gh workflow run`. See the npm-ci adapter (`skills/j-publish/adapters/npm-ci.md`) and the npm-ci wizard (`skills/j-publish/wizards/npm-ci.md`) for configuration details.
 - **`droplet`** — deploys a website or app to any SSH-reachable Linux host (including DigitalOcean Droplets) using a generated GitHub Actions workflow. The workflow SSHes into the host, pulls the deploy branch, runs an optional build command, and restarts the service. See [Droplet (GitHub Actions → SSH)](#droplet-github-actions--ssh) for configuration details.
 
 Every sub-command validates the config before doing anything else, so behaviour is identical regardless of which target type a project uses.
@@ -55,23 +62,23 @@ Every sub-command validates the config before doing anything else, so behaviour
 Before any sub-command executes, validate the config with:
 
 ```bash
-bash skills/publish/scripts/validate_config.sh <path-to-publish.json>
+bash skills/j-publish/scripts/validate_config.sh <path-to-publish.json>
 ```
 
 For deploy-oriented flows, validate the selected target with:
 
 ```bash
-bash skills/publish/scripts/check_target_config.sh <target-name> <path-to-publish.json>
+bash skills/j-publish/scripts/check_target_config.sh <target-name> <path-to-publish.json>
 ```
 
 - Default config resolution: prefer repo-root `publish.json`, fall back to `project/configs/publish.json`
-- Schema: `skills/publish/schemas/publish.schema.json`
-- Example config: `skills/publish/assets/publish.example.json`
-- Secrets guide: `skills/publish/assets/secrets-guide.md`
-- Deploy contract and exit codes: `skills/publish/assets/ci-contract.md`
-- iOS adapter template: `skills/publish/adapters/mobile-ios.md`
-- npm adapter template: `skills/publish/adapters/npm.md`
-- Ownership matrix: `skills/publish/assets/ownership-matrix.md`
+- Schema: `skills/j-publish/schemas/publish.schema.json`
+- Example config: `skills/j-publish/assets/publish.example.json`
+- Secrets guide: `skills/j-publish/assets/secrets-guide.md`
+- Deploy contract and exit codes: `skills/j-publish/assets/ci-contract.md`
+- iOS adapter template: `skills/j-publish/adapters/mobile-ios.md`
+- npm adapter template: `skills/j-publish/adapters/npm.md`
+- Ownership matrix: `skills/j-publish/assets/ownership-matrix.md`
 
 If config or env validation fails, the skill exits with code `4` and does not continue.
 
@@ -79,15 +86,15 @@ If config or env validation fails, the skill exits with code `4` and does not co
 
 | Command | Purpose | Implementation script | Notes |
 |---|---|---|---|
-| `/publish setup` | Prepare or refresh target configuration | `skills/publish/scripts/setup_wizard.sh` | Supported types: `mobile-ios`, `npm`, `npm-ci`, `droplet` |
-| `/publish deploy` | Run the full 11-step deploy orchestration | `skills/publish/scripts/publish_deploy.sh` | Dispatches to the adapter for the target's `type` (`mobile-ios`, `npm`, `npm-ci`, or `droplet`); `--dry-run` is honoured end-to-end |
-| `/publish stage` | Stage an npm release into npm's staged-publishing area, smoke-test it in isolation, then approve or reject it | `skills/publish/scripts/npm_stage_pipeline.sh` (the `publish` sub-command) and `skills/publish/scripts/npm_stage_inspect.sh` (`list`, `view`, `download`, `test`, `approve`, `reject`) | Supported for `npm` and `npm-ci` target types only |
-| `/publish history` | Read the canonical publish ledger | `skills/publish/scripts/show_history.sh` | Target-agnostic; filter by `--target <name>` |
-| `/publish release-notes` | Merge new release notes into the standing `CHANGELOG.md` (or a standalone draft via `--output`) without publishing | `skills/publish/scripts/generate_release_notes.sh` | Target-agnostic |
+| `/publish setup` | Prepare or refresh target configuration | `skills/j-publish/scripts/setup_wizard.sh` | Supported types: `mobile-ios`, `npm`, `npm-ci`, `droplet` |
+| `/publish deploy` | Run the full 11-step deploy orchestration | `skills/j-publish/scripts/publish_deploy.sh` | Dispatches to the adapter for the target's `type` (`mobile-ios`, `npm`, `npm-ci`, or `droplet`); `--dry-run` is honoured end-to-end |
+| `/publish stage` | Stage an npm release into npm's staged-publishing area, smoke-test it in isolation, then approve or reject it | `skills/j-publish/scripts/npm_stage_pipeline.sh` (the `publish` sub-command) and `skills/j-publish/scripts/npm_stage_inspect.sh` (`list`, `view`, `download`, `test`, `approve`, `reject`) | Supported for `npm` and `npm-ci` target types only |
+| `/publish history` | Read the canonical publish ledger | `skills/j-publish/scripts/show_history.sh` | Target-agnostic; filter by `--target <name>` |
+| `/publish release-notes` | Merge new release notes into the standing `CHANGELOG.md` (or a standalone draft via `--output`) without publishing | `skills/j-publish/scripts/generate_release_notes.sh` | Target-agnostic |
 
 ## Quality Gate Policy
 
-The deploy flow invokes `skills/publish/scripts/run_gates.sh` at two fixed points:
+The deploy flow invokes `skills/j-publish/scripts/run_gates.sh` at two fixed points:
 
 1. **Pre-deploy:** `run_gates.sh pre <target> <publish.json> [--non-interactive]`
 2. **Post-deploy:** `run_gates.sh post <target> <publish.json> [--non-interactive]`
@@ -98,7 +105,7 @@ The deploy flow invokes `skills/publish/scripts/run_gates.sh` at two fixed point
 - Post-deploy gate failure records a `partial` publish result instead of rolling back the adapter upload
 - `--non-interactive` suppresses retry prompts and aborts immediately on failure
 
-See `skills/publish/assets/ci-contract.md` for the full quality-gate policy.
+See `skills/j-publish/assets/ci-contract.md` for the full quality-gate policy.
 
 ## Usage Signatures
 
@@ -108,13 +115,13 @@ See `skills/publish/assets/ci-contract.md` for the full quality-gate policy.
 /publish setup [<target>] [--type mobile-ios|npm|droplet] [--config <path>]
 ```
 
-Implementation: `bash skills/publish/scripts/setup_wizard.sh [<target>] [--type <deployment_type>] [--config <path>]`
+Implementation: `bash skills/j-publish/scripts/setup_wizard.sh [<target>] [--type <deployment_type>] [--config <path>]`
 
 Wizard flow:
 1. Resolve or prompt for the target name.
 2. Resolve or prompt for the deployment type. Supported values: `mobile-ios`, `npm`, `droplet`.
-3. Print the secrets guide path and the opening warning from `skills/publish/assets/secrets-guide.md`.
-4. Load `skills/publish/wizards/<type>.md` and render each `## Question:` section as a prompt.
+3. Print the secrets guide path and the opening warning from `skills/j-publish/assets/secrets-guide.md`.
+4. Load `skills/j-publish/wizards/<type>.md` and render each `## Question:` section as a prompt.
 5. Preview the generated target config as JSON.
 6. Save on confirmation by merging or creating `publish.json`.
 7. Validate the saved file with `validate_config.sh`; if validation fails, roll back the write.
@@ -140,7 +147,7 @@ Example invocations:
 /publish deploy [--target <name>] [--config <path>] [--yes] [--dry-run] [--minor | --major] [--notes-file <path>]
 ```
 
-Implementation: `bash skills/publish/scripts/publish_deploy.sh [flags...]`
+Implementation: `bash skills/j-publish/scripts/publish_deploy.sh [flags...]`
 
 Deploy flow:
 1. Select the target from config or `--target`
@@ -217,8 +224,8 @@ All seven sub-commands:
 
 Implementation:
 
-- `publish` → `bash skills/publish/scripts/npm_stage_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive] [--otp <otp>]` — six ordered phases (validate, gates, pack, stage, capture, ledger); writes a `staged` ledger entry on success.
-- `test`, `list`, `view`, `download`, `approve`, `reject` → `bash skills/publish/scripts/npm_stage_inspect.sh <sub> [args] [--config <path>] [--dry-run] [--json]`
+- `publish` → `bash skills/j-publish/scripts/npm_stage_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive] [--otp <otp>]` — six ordered phases (validate, gates, pack, stage, capture, ledger); writes a `staged` ledger entry on success.
+- `test`, `list`, `view`, `download`, `approve`, `reject` → `bash skills/j-publish/scripts/npm_stage_inspect.sh <sub> [args] [--config <path>] [--dry-run] [--json]`
   - `test` downloads the exact staged tarball into an isolated scratch directory outside the repo, installs it, runs the target's `npm.stage.smoke_cmd` (or the documented default check), and writes a `stage_tested` ledger entry (`pass`/`fail`).
   - `approve` refuses to run unless a passing `test` is on record for that exact stage id, unless `--force <reason>` is given; writes an `approved` ledger entry.
   - `reject` is the discard path omitted from npm's own staged-publishing docs page — documented here so it stays discoverable; writes a `rejected` ledger entry.
@@ -242,7 +249,7 @@ instead of being caught by users after `npm publish`.
 /publish history [--config <path>] [--limit <count>] [--target <name>] [--json]
 ```
 
-Implementation: `bash skills/publish/scripts/show_history.sh [--limit <count>] [--target <name>] [--json] [--config <path>]`
+Implementation: `bash skills/j-publish/scripts/show_history.sh [--limit <count>] [--target <name>] [--json] [--config <path>]`
 
 ### `/publish release-notes`
 
@@ -250,7 +257,7 @@ Implementation: `bash skills/publish/scripts/show_history.sh [--limit <count>] [
 /publish release-notes --target <name> [--config <path>] [--from-tag <tag>] [--to-ref <git-ref>] [--output <path>]
 ```
 
-Implementation: `bash skills/publish/scripts/generate_release_notes.sh [--target <name>] [--from-tag <tag>] [--to-ref <git-ref>] [--output <path>] [<publish_json_path>]`
+Implementation: `bash skills/j-publish/scripts/generate_release_notes.sh [--target <name>] [--from-tag <tag>] [--to-ref <git-ref>] [--output <path>] [<publish_json_path>]`
 
 Release-note rules:
 - The last publish tag is the highest semver tag on the current branch that also has a matching ledger entry in `project/logs/publish-history.json`.
@@ -263,15 +270,15 @@ Release-note rules:
 ## Ledger & Tagging
 
 - `project/logs/publish-history.json` is append-only. New publishes add new rows; existing rows are never edited in-place.
-- `bash skills/publish/scripts/suggest_semver_bump.sh` suggests `major`, `minor`, or `patch` based on git history since the last ledger-backed publish tag.
-- `bash skills/publish/scripts/write_ledger_entry.sh <target> <adapter> <platform_state> <notes_path> [--yes] [--dry-run] [--version <vX.Y.Z>] [--config <path>]` appends the canonical publish entry and creates the matching annotated git tag.
-- `bash skills/publish/scripts/reconcile_tags.sh [--dry-run] [--config <path>]` repairs drift:
+- `bash skills/j-publish/scripts/suggest_semver_bump.sh` suggests `major`, `minor`, or `patch` based on git history since the last ledger-backed publish tag.
+- `bash skills/j-publish/scripts/write_ledger_entry.sh <target> <adapter> <platform_state> <notes_path> [--yes] [--dry-run] [--version <vX.Y.Z>] [--config <path>]` appends the canonical publish entry and creates the matching annotated git tag.
+- `bash skills/j-publish/scripts/reconcile_tags.sh [--dry-run] [--config <path>]` repairs drift:
   - git tag without ledger entry → append `partial` ledger row with note `Manually tagged without /publish`
   - ledger entry without git tag → create the missing tag retroactively
 
 ## Agent Roles
 
-See `skills/publish/assets/ownership-matrix.md` for the action-by-action ownership matrix.
+See `skills/j-publish/assets/ownership-matrix.md` for the action-by-action ownership matrix.
 
 Summary:
 - **Developer** initiates `/publish setup`, `/publish deploy`, and release-note review
@@ -280,7 +287,7 @@ Summary:
 
 ## Configuration Model
 
-The canonical config must validate against `skills/publish/schemas/publish.schema.json`.
+The canonical config must validate against `skills/j-publish/schemas/publish.schema.json`.
 
 ### Required top-level structure
 
@@ -327,10 +334,10 @@ The iOS adapter trust boundary is explicit: publish-side external commands are l
 
 The `npm` adapter publishes a Node package to an npm-compatible registry.
 
-- Adapter template: `skills/publish/adapters/npm.md`
-- Wizard template: `skills/publish/wizards/npm.md`
+- Adapter template: `skills/j-publish/adapters/npm.md`
+- Wizard template: `skills/j-publish/wizards/npm.md`
 
-See those files for the required target fields (registry URL, access, tag, `--dry-run` behaviour) and env references. Additional npm-specific schema details are owned by the npm settings block in `skills/publish/schemas/publish.schema.json`.
+See those files for the required target fields (registry URL, access, tag, `--dry-run` behaviour) and env references. Additional npm-specific schema details are owned by the npm settings block in `skills/j-publish/schemas/publish.schema.json`.
 
 ## npm CI (OIDC Trusted Publisher)
 
@@ -338,9 +345,9 @@ The `npm-ci` adapter publishes a Node package to npmjs.com via **GitHub Actions
 
 > Use `npm` for local publishes with a token; use `npm-ci` for CI-only publishing with OIDC (no token required).
 
-- Adapter template: `skills/publish/adapters/npm-ci.md`
-- Wizard template: `skills/publish/wizards/npm-ci.md`
-- Example config: `skills/publish/assets/publish.example.npm-ci.json`
+- Adapter template: `skills/j-publish/adapters/npm-ci.md`
+- Wizard template: `skills/j-publish/wizards/npm-ci.md`
+- Example config: `skills/j-publish/assets/publish.example.npm-ci.json`
 
 ### Required target fields for `npm-ci`
 
@@ -400,7 +407,7 @@ The generated workflow reads these from GitHub Actions secrets:
 - `DROPLET_SSH_KEY` (or value of `ssh_key_secret`) — private key contents
 - `DROPLET_KNOWN_HOSTS` (or value of `known_hosts_secret`) — `ssh-keyscan` output
 
-See `skills/publish/assets/secrets-guide.md` for setup instructions.
+See `skills/j-publish/assets/secrets-guide.md` for setup instructions.
 
 ### First-run prerequisites (manual)
 

package/skills/{publish → j-publish}/adapters/droplet.md

@@ -76,7 +76,7 @@ The `gh` CLI must be authenticated (`gh auth login`) before running
 ### Pipeline entrypoint
 
 ```bash
-bash skills/publish/scripts/droplet_pipeline.sh \
+bash skills/j-publish/scripts/droplet_pipeline.sh \
   --target <name> \
   --config <path-to-publish.json> \
   [--dry-run]

package/skills/{publish → j-publish}/adapters/mobile-ios.md

@@ -2,7 +2,7 @@
 
 The `mobile-ios` adapter drives the `/publish deploy` flow for iOS App Store targets.
 It is a prompt/template contract for the agent layer and delegates concrete execution to
-`skills/publish/scripts/ios_pipeline.sh`.
+`skills/j-publish/scripts/ios_pipeline.sh`.
 
 ## Invocation Contract
 
@@ -43,13 +43,13 @@ The required env vars are:
 Validate them before execution with:
 
 ```bash
-bash skills/publish/scripts/validate_ios_env.sh <path-to-publish.json>
+bash skills/j-publish/scripts/validate_ios_env.sh <path-to-publish.json>
 ```
 
 ### Pipeline entrypoint
 
 ```bash
-bash skills/publish/scripts/ios_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive]
+bash skills/j-publish/scripts/ios_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive]
 ```
 
 ## Execution Phases

package/skills/{publish → j-publish}/adapters/npm-ci.md

@@ -79,7 +79,7 @@ The `gh` CLI must be authenticated before running `/publish deploy` against an
 ### Pipeline entrypoint
 
 ```bash
-bash skills/publish/scripts/npm_ci_pipeline.sh \
+bash skills/j-publish/scripts/npm_ci_pipeline.sh \
   --target <name> \
   --config <path-to-publish.json> \
   [--dry-run]
@@ -235,9 +235,9 @@ automated and human halves of the flow:
 - **Approval is always a human, out-of-CI step.** `npm stage approve`
   requires an interactive npm 2FA one-time password — there is no OIDC
   equivalent for approval. A human runs
-  `bash skills/publish/scripts/npm_stage_inspect.sh test <stage-id>` (or
+  `bash skills/j-publish/scripts/npm_stage_inspect.sh test <stage-id>` (or
   relies on the automated CI-staged test result) and then
-  `bash skills/publish/scripts/npm_stage_inspect.sh approve <stage-id> --otp <otp>`
+  `bash skills/j-publish/scripts/npm_stage_inspect.sh approve <stage-id> --otp <otp>`
   from their own machine. `reject` (same script) is available to either
   side to discard a staged candidate.
 

package/skills/{publish → j-publish}/adapters/npm.md

@@ -2,7 +2,7 @@
 
 The `npm` adapter drives the `/publish deploy` flow for npm registry targets.
 It is a prompt/template contract for the agent layer and delegates concrete execution to
-`skills/publish/scripts/npm_pipeline.sh`.
+`skills/j-publish/scripts/npm_pipeline.sh`.
 
 ## Invocation Contract
 
@@ -30,13 +30,13 @@ The required env vars are:
 Validate them before execution with:
 
 ```bash
-bash skills/publish/scripts/validate_npm_env.sh <path-to-publish.json>
+bash skills/j-publish/scripts/validate_npm_env.sh <path-to-publish.json>
 ```
 
 ### Pipeline entrypoint
 
 ```bash
-bash skills/publish/scripts/npm_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive]
+bash skills/j-publish/scripts/npm_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive]
 ```
 
 ## Execution Phases
@@ -114,13 +114,13 @@ A successful run produces:
 Before a live `deploy`, this target type also supports **staged publishing**
 via `/publish stage` — npm's own pre-publish staging area, which lets a
 release be smoke-tested from the exact tarball that would ship before it
-becomes visible on the registry. See `skills/publish/SKILL.md`'s
+becomes visible on the registry. See `skills/j-publish/SKILL.md`'s
 `### /publish stage` section for the full command reference; summary here:
 
-- `bash skills/publish/scripts/npm_stage_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive] [--otp <otp>]` runs validate → gates → pack → stage → capture → ledger and writes a `staged` ledger entry.
-- `bash skills/publish/scripts/npm_stage_inspect.sh test <stage-id>` installs the staged tarball into an isolated scratch directory and smoke-tests it, writing a `stage_tested` ledger entry.
-- `bash skills/publish/scripts/npm_stage_inspect.sh approve <stage-id>` requires an npm 2FA one-time password and refuses without a passing `test` on record unless `--force <reason>` is given.
-- `bash skills/publish/scripts/npm_stage_inspect.sh reject <stage-id>` discards the staged version.
+- `bash skills/j-publish/scripts/npm_stage_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive] [--otp <otp>]` runs validate → gates → pack → stage → capture → ledger and writes a `staged` ledger entry.
+- `bash skills/j-publish/scripts/npm_stage_inspect.sh test <stage-id>` installs the staged tarball into an isolated scratch directory and smoke-tests it, writing a `stage_tested` ledger entry.
+- `bash skills/j-publish/scripts/npm_stage_inspect.sh approve <stage-id>` requires an npm 2FA one-time password and refuses without a passing `test` on record unless `--force <reason>` is given.
+- `bash skills/j-publish/scripts/npm_stage_inspect.sh reject <stage-id>` discards the staged version.
 
 Same registry-existence precondition as a normal `npm` publish: staged
 publishing only applies to a package that has already had at least one

package/skills/{publish → j-publish}/assets/ci-contract.md

@@ -7,9 +7,9 @@ This document defines the CI-safe execution contract for the scaffolded `/publis
 Every `/publish` invocation must perform these steps before command-specific work:
 
 1. Resolve config path (`--config <path>` or default `project/configs/publish.json`)
-2. Run `bash skills/publish/scripts/validate_config.sh <resolved-path>`
+2. Run `bash skills/j-publish/scripts/validate_config.sh <resolved-path>`
 3. Abort immediately with exit code `4` if the file is missing, invalid JSON, or fails validation
-4. For the iOS adapter, run `bash skills/publish/scripts/validate_ios_env.sh <resolved-path>` before build/upload work begins
+4. For the iOS adapter, run `bash skills/j-publish/scripts/validate_ios_env.sh <resolved-path>` before build/upload work begins
 
 ## Inputs
 

package/skills/{publish → j-publish}/schemas/publish.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://jenga.local/skills/publish/schemas/publish.schema.json",
+  "$id": "https://jenga.local/skills/j-publish/schemas/publish.schema.json",
   "title": "Publish Skill Configuration",
   "description": "Schema for project/configs/publish.json used by the /publish skill.",
   "type": "object",

package/skills/{publish → j-publish}/scripts/npm_stage_inspect.sh

@@ -419,8 +419,31 @@ cmd_list() {
   # `list` itself needs no config (npm stage list takes no target/config).
   : "${config_arg}"
 
+  # `npm stage list` rejects a version-qualified spec ("Version specifiers
+  # are not supported for listing staged packages") — it only accepts a bare
+  # package name. If the caller passed one anyway (e.g. "@jenga-ai/agent@1.3.0"
+  # or "some-pkg@1.3.0"), split it into name + version here, pass only the
+  # bare name to npm, and filter the result to that version client-side
+  # below (same fallback the fix in npm_stage_pipeline.sh uses). A leading
+  # '@' belongs to a scoped package's own name, not a version marker, so the
+  # version split point is the second '@' for scoped specs, the first for
+  # unscoped ones.
+  local package_name="${package_spec}" package_version=""
+  if [[ -n "${package_spec}" ]]; then
+    if [[ "${package_spec}" == @* ]]; then
+      local rest="${package_spec#@}"
+      if [[ "${rest}" == *"@"* ]]; then
+        package_name="@${rest%%@*}"
+        package_version="${rest#*@}"
+      fi
+    elif [[ "${package_spec}" == *"@"* ]]; then
+      package_name="${package_spec%%@*}"
+      package_version="${package_spec#*@}"
+    fi
+  fi
+
   local -a cmd=(npm stage list)
-  [[ -n "${package_spec}" ]] && cmd+=("${package_spec}")
+  [[ -n "${package_name}" ]] && cmd+=("${package_name}")
   cmd+=(--json)
 
   if (( dry_run )); then
@@ -436,6 +459,16 @@ cmd_list() {
     exit "${EXIT_OP_FAILED}"
   fi
 
+  if [[ -n "${package_version}" ]]; then
+    local filtered
+    if filtered="$(printf '%s' "${output}" | jq -c --arg ver "${package_version}" '
+      ( if (type == "array") then . else (.stages? // .items? // []) end )
+      | [ .[] | select((.version // "") == $ver) ]
+    ' 2>/dev/null)"; then
+      output="${filtered}"
+    fi
+  fi
+
   if (( json_out )); then
     printf '%s\n' "${output}"
     exit "${EXIT_OK}"