@givolt/i3-composer-agent 1.0.1 → 2.1.0

package/docs/agents.md

@@ -15,9 +15,9 @@ Three layers, each with a distinct job:
 
 | Layer | What it is | Example | Composition role |
 |-------|-----------|---------|------------------|
-| **Skill** | A workflow with steps and exit criteria | `code-review-and-quality` | The *how* — invoked from inside a persona or command |
+| **Skill** | A workflow with steps and exit criteria | `i3-code-review-and-quality` | The *how* — invoked from inside a persona or command |
 | **Persona** | A role with a perspective and an output format | `code-reviewer` | The *who* — adopts a viewpoint, produces a report |
-| **Command** | A user-facing entry point | `/review`, `/ship` | The *when* — composes personas and skills |
+| **Command** | A user-facing entry point | `/i3-review`, `/i3-ship` | The *when* — composes personas and skills |
 
 The user (or a slash command) is the orchestrator. **Personas do not call other personas.** Skills are mandatory hops inside a persona's workflow.
 
@@ -34,14 +34,14 @@ Pick this when you want one perspective on the current change and the user is in
 ### Slash command (single persona behind it)
 Pick this when there's a repeatable workflow you'd otherwise re-explain every time.
 
-- `/review` → wraps `code-reviewer` with the project's review skill
-- `/test` → wraps `test-engineer` with TDD skill
-- `/webperf` → wraps `web-performance-auditor` for performance-focused audits on web apps
+- `/i3-review` → wraps `code-reviewer` with the project's review skill
+- `/i3-test` → wraps `test-engineer` with TDD skill
+- `/i3-webperf` → wraps `web-performance-auditor` for performance-focused audits on web apps
 
 ### Slash command (orchestrator — fan-out)
 Pick this only when **independent** investigations can run in parallel and produce reports that a single agent then merges.
 
-- `/ship` → fans out to `code-reviewer` + `security-auditor` + `test-engineer` in parallel, then synthesizes their reports into a go/no-go decision
+- `/i3-ship` → fans out to `code-reviewer` + `security-auditor` + `test-engineer` in parallel, then synthesizes their reports into a go/no-go decision
 
 This is the only orchestration pattern this repo endorses. See [references/orchestration-patterns.md](../references/orchestration-patterns.md) for the full pattern catalog and anti-patterns.
 
@@ -51,16 +51,16 @@ This is the only orchestration pattern this repo endorses. See [references/orche
 Is the work a single perspective on a single artifact?
 ├── Yes → Direct persona invocation
 └── No  → Are the sub-tasks independent (no shared mutable state, no ordering)?
-         ├── Yes → Slash command with parallel fan-out (e.g. /ship)
-         └── No  → Sequential slash commands run by the user (/spec → /plan → /build → /test → /review)
+         ├── Yes → Slash command with parallel fan-out (e.g. /i3-ship)
+         └── No  → Sequential slash commands run by the user (/i3-spec → /i3-plan → /i3-build → /i3-test → /i3-review)
 ```
 
 ## Worked example: valid orchestration
 
-`/ship` is the canonical fan-out orchestrator in this repo:
+`/i3-ship` is the canonical fan-out orchestrator in this repo:
 
 ```
-/ship
+/i3-ship
   ├── (parallel) code-reviewer    → review report
   ├── (parallel) security-auditor → audit report
   └── (parallel) test-engineer    → coverage report
@@ -93,7 +93,7 @@ A `meta-orchestrator` persona whose job is "decide which other persona to call":
 Why this fails:
 - Pure routing layer with no domain value
 - Adds two paraphrasing hops → information loss + 2× token cost
-- The user already knows they want a review; let them call `/review` directly
+- The user already knows they want a review; let them call `/i3-review` directly
 - Replicates work that slash commands and `AGENTS.md` intent-mapping already do
 
 ## Rules for personas
@@ -107,7 +107,7 @@ Why this fails:
 
 The personas in this repo are designed to work as Claude Code subagents and as Agent Teams teammates without modification:
 
-- **As subagents:** auto-discovered when this plugin is enabled (no path config needed). Use the Agent tool with `subagent_type: code-reviewer` (or `security-auditor`, `test-engineer`). `/ship` is the canonical example.
+- **As subagents:** auto-discovered when this plugin is enabled (no path config needed). Use the Agent tool with `subagent_type: code-reviewer` (or `security-auditor`, `test-engineer`). `/i3-ship` is the canonical example.
 - **As Agent Teams teammates** (experimental, requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`): reference the same persona name when spawning a teammate. The persona's body is **appended to** the teammate's system prompt as additional instructions (not a replacement), so your persona text sits on top of the team-coordination instructions the lead installs (SendMessage, task-list tools, etc.).
 
 Subagents only report results back to the main agent. Agent Teams let teammates message each other directly. Use subagents when reports are enough; use Agent Teams when sub-agents need to challenge each other's findings (e.g. competing-hypothesis debugging). See [references/orchestration-patterns.md](../references/orchestration-patterns.md) for the full mapping.

package/docs/antigravity-setup.md

@@ -45,21 +45,21 @@ agy plugin list
 
 ## Lifecycle Workflows and Command Compatibility
 
-Antigravity's [migration tooling](https://www.agy.dev/docs/cli/gcli-migration/) reports the 9 legacy definitions in `commands/*.toml` as "converted to skills." In affected `agy` 1.1.x releases, validation succeeds but the converted wrappers do not appear in the slash-command or skill catalog. A successful `agy plugin validate` therefore confirms the files are well formed, not that `/build` and the other short wrappers are available. This is tracked in [upstream agent-skills #445](https://github.com/addyosmani/agent-skills/issues/445) and upstream in [antigravity-cli #788](https://github.com/google-antigravity/antigravity-cli/issues/788).
+Antigravity's [migration tooling](https://www.agy.dev/docs/cli/gcli-migration/) reports the 9 legacy definitions in `commands/*.toml` as "converted to skills." In affected `agy` 1.1.x releases, validation succeeds but the converted wrappers do not appear in the slash-command or skill catalog. A successful `agy plugin validate` therefore confirms the files are well formed, not that `/i3-build` and the other short wrappers are available. This is tracked in [antigravity-cli #788](https://github.com/google-antigravity/antigravity-cli/issues/788).
 
 Use the native plugin skills directly while that importer limitation applies:
 
 | Intended wrapper | Direct Antigravity invocation | Notes |
 |------------------|-------------------------------|-------|
-| `/spec` | `/i3-composer-agent:spec-driven-development` | Writes a structured spec before code |
-| `/constraints` | `/i3-composer-agent:constraint-driven-development` | Defines and enforces the project's quality bar |
-| `/planning` | `/i3-composer-agent:planning-and-task-breakdown` | Antigravity's built-in `/planning` command is a separate plan-mode control |
-| `/build` | `/i3-composer-agent:incremental-implementation` | Also invoke `/i3-composer-agent:test-driven-development`; wrapper-only `/build auto` orchestration is unavailable |
-| `/test` | `/i3-composer-agent:test-driven-development` | Runs the red-green-refactor workflow |
-| `/review` | `/i3-composer-agent:code-review-and-quality` | Runs the five-axis review workflow |
-| `/code-simplify` | `/i3-composer-agent:code-simplification` | Simplifies without changing behavior |
-| `/ship` | `/i3-composer-agent:shipping-and-launch` | The wrapper's automatic persona fan-out is unavailable; invoke specialist agents separately |
-| `/webperf` | Select `web-performance-auditor` from `/agents` | This workflow is a persona, not a skill |
+| `/i3-spec` | `/i3-composer-agent:i3-spec-driven-development` | Writes a structured spec before code |
+| `/i3-constraints` | `/i3-composer-agent:i3-constraint-driven-development` | Defines and enforces the project's quality bar |
+| `/i3-planning` | `/i3-composer-agent:i3-planning-and-task-breakdown` | Antigravity's built-in `/i3-planning` command is a separate plan-mode control |
+| `/i3-build` | `/i3-composer-agent:i3-incremental-implementation` | Also invoke `/i3-composer-agent:i3-test-driven-development`; wrapper-only `/i3-build auto` orchestration is unavailable |
+| `/i3-test` | `/i3-composer-agent:i3-test-driven-development` | Runs the red-green-refactor workflow |
+| `/i3-review` | `/i3-composer-agent:i3-code-review-and-quality` | Runs the five-axis review workflow |
+| `/i3-code-simplify` | `/i3-composer-agent:i3-code-simplification` | Simplifies without changing behavior |
+| `/i3-ship` | `/i3-composer-agent:i3-shipping-and-launch` | The wrapper's automatic persona fan-out is unavailable; invoke specialist agents separately |
+| `/i3-webperf` | Select `web-performance-auditor` from `/agents` | This workflow is a persona, not a skill |
 
 Do not add YAML frontmatter to the TOML files as a workaround. Gemini CLI reads the parallel TOML command format with a strict parser, and `---` frontmatter makes those files invalid TOML without changing Antigravity's conversion behavior.
 
@@ -80,7 +80,7 @@ To validate that your local plugin is correctly structured and contains all skil
 agy plugin validate /path/to/i3-composer-agent
 ```
 
-Then start a fresh session and type `/i3-composer-agent:` to inspect the namespaced skill catalog. If the validator reports that commands were converted but `/build` returns `No matches`, use the direct invocations above; reinstalling or adding a TOML `name` field does not resolve the known importer limitation.
+Then start a fresh session and type `/i3-composer-agent:` to inspect the namespaced skill catalog. If the validator reports that commands were converted but `/i3-build` returns `No matches`, use the direct invocations above; reinstalling or adding a TOML `name` field does not resolve the known importer limitation.
 
 ---
 
@@ -90,9 +90,9 @@ Then start a fresh session and type `/i3-composer-agent:` to inspect the namespa
 Antigravity CLI automatically discovers the `SKILL.md` files located in the `skills/` directory of the installed plugin. Using the trigger descriptions in each skill's frontmatter, the agent will dynamically activate the appropriate workflow when it detects matching developer intent.
 
 For example, when you ask the agent to:
-- **Design a new system** → It will suggest/activate `spec-driven-development`.
-- **Implement a feature** → It will activate `incremental-implementation` and `test-driven-development`.
-- **Fix a bug** → It will activate `debugging-and-error-recovery`.
+- **Design a new system** → It will suggest/activate `i3-spec-driven-development`.
+- **Implement a feature** → It will activate `i3-incremental-implementation` and `i3-test-driven-development`.
+- **Fix a bug** → It will activate `i3-debugging-and-error-recovery`.
 
 ### 2. Specialized Agent Personas
 The plugin registers reusable subagent definitions from the `agents/` directory:

package/docs/codebuddy-setup.md

@@ -11,23 +11,25 @@ npx @givolt/i3-composer-agent --codebuddy
 The terminal wizard preselects CodeBuddy, still allows multiple tools, and asks
 for project or global scope before installing. Project scope writes these paths:
 
-- `.codebuddy/skills/` — all 25 skills with their original IDs.
+- `.codebuddy/skills/` — all 25 skills with `i3-` IDs.
 - `.codebuddy/references/` — shared checklists used by skill-relative links.
 - `.codebuddy/commands/` — all 9 existing lifecycle workflows.
 - `.codebuddy/agents/` — all 4 persona definitions.
 
-Global scope uses the same layout under `~/.codebuddy/`. Existing assets require
-confirmed replacement and are preserved in backup directories. Settings are
-not replaced. Reload the CodeBuddy window or start a new chat, then inspect
+Global scope uses the same layout under `~/.codebuddy/`. Unchanged manifest-owned
+assets from the same version are reused. Modified files, unowned collisions and
+upgrades require confirmed replacement. Previous files are removed after
+successful installation; a failure restores them. Settings are preserved.
+Reload the CodeBuddy window or start a new chat, then inspect
 the Skills list and type `/` to inspect the command menu.
 
 ```text
-/spec
-/plan
-/build
-/build auto
-/review
-/ship
+/i3-spec
+/i3-plan
+/i3-build
+/i3-build auto
+/i3-review
+/i3-ship
 ```
 
 The command wrappers reference installed skill IDs without the plugin namespace.
@@ -38,9 +40,15 @@ For multiple tools or a noninteractive installation:
 
 ```bash
 npx @givolt/i3-composer-agent --agents codebuddy,codex --scope project --yes
+npx @givolt/i3-composer-agent --agents codebuddy,workbuddy --scope project --yes
 npx @givolt/i3-composer-agent --codebuddy --scope global --yes
 ```
 
+CodeBuddy and WorkBuddy share `.codebuddy/` project files. Installing either
+client first and adding the other at the same package version reuses unmodified
+owned files and merges the client IDs. Global WorkBuddy files use
+`~/.workbuddy/`, independently of `~/.codebuddy/`. See [WorkBuddy setup](workbuddy-setup.md).
+
 CodeBuddy documents [IDE skills](https://www.codebuddy.cn/docs/ide/Features/Skills)
 and [IDE custom commands](https://www.codebuddy.cn/docs/ide/User-guide/Slash-Commands).
 The directory layout follows its [configuration directory reference](https://www.codebuddy.cn/docs/cli/codebuddy-dir).
@@ -70,16 +78,17 @@ manifest. It declares `.claude/commands/` and `commands/`, preserving the nine
 original lifecycle commands and their workflow content.
 
 ```text
-/i3-composer-agent:spec
-/i3-composer-agent:plan
-/i3-composer-agent:build
-/i3-composer-agent:build auto
-/i3-composer-agent:review
-/i3-composer-agent:ship
+/i3-composer-agent:i3-spec
+/i3-composer-agent:i3-plan
+/i3-composer-agent:i3-build
+/i3-composer-agent:i3-build auto
+/i3-composer-agent:i3-review
+/i3-composer-agent:i3-ship
 ```
 
-Skill IDs, persona names, artifact paths, and workflow gates retain their
-upstream behavior. The plugin namespace changes to `i3-composer-agent`.
+Skill IDs and command filenames use `i3-`. Persona names, artifact paths,
+and workflow gates retain their upstream behavior. The plugin namespace is
+`i3-composer-agent`.
 
 The prepared plugin includes all skills, personas, commands, hooks and shared
 `references/`. Native skill installation above does not enable plugin hooks.

package/docs/codex-setup.md

@@ -7,8 +7,8 @@ npx @givolt/i3-composer-agent --codex
 ```
 
 Choose project or global scope. Native installation uses `.agents/skills/`
-or `~/.agents/skills/`, plus the sibling `references/` directory. It retains
-the 25 original skill IDs. This mode does not add short lifecycle
+or `~/.agents/skills/`, plus the sibling `references/` directory. It installs
+the 25 skills with `i3-` IDs. This mode does not add short lifecycle
 slash commands or enable plugin hooks.
 
 For complete plugin registration, prepare a persistent bundle explicitly:
@@ -25,20 +25,20 @@ codex plugin marketplace add ./i3-composer-agent
 codex plugin add i3-composer-agent@i3-composer-agent
 ```
 
-Start a new Codex session after registration. All 25 existing skills keep their
-original IDs. In CLI/IDE, use `/skills` or `$spec-driven-development`; in chat,
+Start a new Codex session after registration. All 25 skills use
+`i3-` IDs. In CLI/IDE, use `/skills` or `$i3-spec-driven-development`; in chat,
 explicitly request the relevant skill from i3 Composer Agent.
 
 The adapter in `.codex-plugin/plugin.json` points at the unchanged `skills/`
 layout. Shared checklists remain under `references/`, so skill-relative links
 resolve inside the complete plugin bundle.
 
-The short lifecycle commands (`/spec`, `/plan`, `/build`, `/ship`) remain
+The short lifecycle commands (`/i3-spec`, `/i3-plan`, `/i3-build`, `/i3-ship`) remain
 available in hosts that load the Claude-compatible command manifest. Codex
 lifecycle-command adaptation is separate from this brand conversion. Native
 Codex `/plan` switches planning mode; it is not the plugin's planning wrapper.
 
-Do not preload `using-agent-skills/SKILL.md` into always-on context: Codex routes
+Do not preload `i3-using-agent-skills/SKILL.md` into always-on context: Codex routes
 skills natively. The meta-skill can remain installed and explicitly invoked.
 
 For local source testing, replace `./i3-composer-agent` above with the absolute

package/docs/commandcode-setup.md

@@ -17,7 +17,7 @@ In an interactive terminal this shows a multi-select so you can choose which of
 **Install a specific skill:**
 
 ```bash
-cmd skills add /path/to/i3-composer-agent -s spec-driven-development
+cmd skills add /path/to/i3-composer-agent -s i3-spec-driven-development
 ```
 
 **User scope** (installs into `~/.commandcode/skills/`, available in every project):
@@ -30,7 +30,7 @@ cmd skills add /path/to/i3-composer-agent --global
 
 ```bash
 # Branch selectors apply to Git sources; prepared npm bundles have no Git history.
-cmd skills add /path/to/i3-composer-agent/skills/interview-me   # a specific path in the repo
+cmd skills add /path/to/i3-composer-agent/skills/i3-interview-me   # a specific path in the repo
 cmd skills add /path/to/i3-composer-agent --force         # overwrite / update if already installed
 ```
 
@@ -38,8 +38,8 @@ cmd skills add /path/to/i3-composer-agent --force         # overwrite / update i
 
 ```bash
 cmd skills list                       # list installed skills (project + user + bundled)
-cmd skills remove spec-driven-development           # remove a project-scoped skill
-cmd skills remove spec-driven-development --global  # remove a user-scoped skill
+cmd skills remove i3-spec-driven-development           # remove a project-scoped skill
+cmd skills remove i3-spec-driven-development --global  # remove a user-scoped skill
 ```
 
 `--force` on `add` re-fetches and overwrites an existing skill, which is how you update to the latest version.
@@ -49,7 +49,7 @@ cmd skills remove spec-driven-development --global  # remove a user-scoped skill
 Installed skills are discovered automatically and appear in the TUI slash menu, tagged `[skill]`:
 
 ```
-/spec-driven-development   [skill] Write a spec before writing code…
+/i3-spec-driven-development   [skill] Write a spec before writing code…
 ```
 
 Type `/` to browse, or start typing a skill name to filter. Use `/skills` to enable/disable skills.

package/docs/copilot-cli-setup.md

@@ -40,7 +40,7 @@ In an interactive session, `/skills list` shows the same catalog.
 The root `plugin.json` is the manifest Copilot CLI reads — it takes precedence over `.claude-plugin/plugin.json`, which belongs to Claude Code. That root manifest declares only a name, version and description, so component paths fall back to their defaults:
 
 - **Skills — available.** With no explicit path, the CLI uses the conventional `skills/` directory, and the skills are discovered there.
-- **Lifecycle commands — not available.** The root manifest has no `commands` field, so nothing registers `/spec`, `/plan`, `/build`, `/test`, `/review` or `/ship`. Those files live in `.claude/commands/` and are Claude Code commands.
+- **Lifecycle commands — not available.** The root manifest has no `commands` field, so nothing registers `/i3-spec`, `/i3-plan`, `/i3-build`, `/i3-test`, `/i3-review` or `/i3-ship`. Those files live in `.claude/commands/` and are Claude Code commands.
 
 For manifest precedence and the per-component path defaults, see the [CLI plugin reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference) and [Creating plugins](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-creating).
 
@@ -48,11 +48,11 @@ For manifest precedence and the per-component path defaults, see the [CLI plugin
 
 Name the skill you want, or describe the task and let the agent route to it:
 
-> Use the spec-driven-development skill to write a spec for [the feature].
+> Use the i3-spec-driven-development skill to write a spec for [the feature].
 
-> Use the test-driven-development skill: write a failing test for this bug first, then fix it.
+> Use the i3-test-driven-development skill: write a failing test for this bug first, then fix it.
 
-> Use the code-review-and-quality skill to review my staged changes.
+> Use the i3-code-review-and-quality skill to review my staged changes.
 
 ## Troubleshooting
 
@@ -60,5 +60,5 @@ Name the skill you want, or describe the task and let the agent route to it:
 |---------|---------------|
 | `plugin install` can't resolve `i3-composer-agent@i3-composer-agent` | Run `copilot plugin marketplace add /path/to/i3-composer-agent` first — that name only resolves once the marketplace is registered. Or install the repository directly. |
 | Plugin installed but no skills | `copilot plugin list` to confirm the plugin, then `copilot skill list` (or `/skills list` in session) to see what was discovered. |
-| `/spec`, `/build` and friends are not found | Expected, not a broken install: the root manifest registers no commands. Ask for the skill by name instead. |
+| `/i3-spec`, `/i3-build` and friends are not found | Expected, not a broken install: the root manifest registers no commands. Ask for the skill by name instead. |
 | Skills changed locally but the CLI shows the old copy | Start a fresh session, or run with `--plugin-dir` pointing at your clone. |

package/docs/copilot-setup.md

@@ -2,7 +2,7 @@
 
 This guide covers Copilot in VS Code. For the standalone `copilot` command-line tool, see [copilot-cli-setup.md](copilot-cli-setup.md).
 
-**What an install actually gives you:** the skills. Each installed skill becomes a slash command named after its frontmatter `name` — `/spec-driven-development`, `/test-driven-development`, and so on. `npx skills add /path/to/i3-composer-agent` and the manual copy below both install skills only. Neither of those two routes copies this repo's short lifecycle wrappers (`/spec`, `/plan`, `/build`, `/test`, `/review`, `/ship`) — those are Claude Code commands living in `.claude/commands/`. Use the full skill names, or add your own aliases — see [Lifecycle workflows](#lifecycle-workflows).
+**What an install actually gives you:** the skills. Each installed skill becomes a slash command named after its frontmatter `name` — `/i3-spec-driven-development`, `/i3-test-driven-development`, and so on. `npx skills add /path/to/i3-composer-agent` and the manual copy below both install skills only. Neither of those two routes copies this repo's short lifecycle wrappers (`/i3-spec`, `/i3-plan`, `/i3-build`, `/i3-test`, `/i3-review`, `/i3-ship`) — those are Claude Code commands living in `.claude/commands/`. Use the full skill names, or add your own aliases — see [Lifecycle workflows](#lifecycle-workflows).
 
 ## Setup
 
@@ -11,11 +11,11 @@ This guide covers Copilot in VS Code. For the standalone `copilot` command-line
 Copilot supports creating agent skills using a `.github/skills`, `.claude/skills`, or `.agents/skills` directory in your repository.
 
 ```bash
-mkdir -p .github/skills/test-driven-development .github/skills/code-review-and-quality
+mkdir -p .github/skills/i3-test-driven-development .github/skills/i3-code-review-and-quality
 
 # Create files for essential skills
-cat /path/to/i3-composer-agent/skills/test-driven-development/SKILL.md > .github/skills/test-driven-development/SKILL.md
-cat /path/to/i3-composer-agent/skills/code-review-and-quality/SKILL.md > .github/skills/code-review-and-quality/SKILL.md
+cat /path/to/i3-composer-agent/skills/i3-test-driven-development/SKILL.md > .github/skills/i3-test-driven-development/SKILL.md
+cat /path/to/i3-composer-agent/skills/i3-code-review-and-quality/SKILL.md > .github/skills/i3-code-review-and-quality/SKILL.md
 ```
 
 Whichever of these two routes you use, the result is one `SKILL.md` per skill directory under one of those three project paths. An installer run with a global/user flag writes somewhere else instead — check its output for the path it used. Run `/skills` in Copilot Chat to open the **Configure Skills** menu and confirm what got discovered.
@@ -91,26 +91,26 @@ Skills are user-invocable by default, so once they're discovered the whole lifec
 
 | Workflow | Copilot invocation | Notes |
 |----------|--------------------|-------|
-| Define | `/spec-driven-development` | Writes a structured spec before code |
-| Plan | `/planning-and-task-breakdown` | Produces `tasks/plan.md` and `tasks/todo.md` |
-| Build | `/incremental-implementation` | Pair with `/test-driven-development`; one slice at a time |
-| Verify | `/test-driven-development` | Red-green-refactor, Prove-It for bugs |
-| Review | `/code-review-and-quality` | Five-axis review |
-| Ship | `/shipping-and-launch` | Launch readiness |
+| Define | `/i3-spec-driven-development` | Writes a structured spec before code |
+| Plan | `/i3-planning-and-task-breakdown` | Produces `tasks/plan.md` and `tasks/todo.md` |
+| Build | `/i3-incremental-implementation` | Pair with `/i3-test-driven-development`; one slice at a time |
+| Verify | `/i3-test-driven-development` | Red-green-refactor, Prove-It for bugs |
+| Review | `/i3-code-review-and-quality` | Five-axis review |
+| Ship | `/i3-shipping-and-launch` | Launch readiness |
 
 Type `/` to browse what's actually loaded in this workspace.
 
 Natural language is the fallback, and works in any Copilot surface whether or not the slash commands show up:
 
-> Use the spec-driven-development skill to write a spec for [the feature].
+> Use the i3-spec-driven-development skill to write a spec for [the feature].
 
-> Use the code-review-and-quality skill to review my staged changes.
+> Use the i3-code-review-and-quality skill to review my staged changes.
 
-### Optional: short `/spec`-style aliases
+### Optional: short `/i3-spec`-style aliases
 
 VS Code's extension-host local agents support [prompt files](https://code.visualstudio.com/docs/agent-customization/prompt-files) at `.github/prompts/<name>.prompt.md`, and each becomes a `/<name>` slash command. The Agent Host does **not** use prompt files — there, use the skill names above.
 
-An alias is a thin shortcut to one skill, nothing more. These aliases do not implement the orchestration in this repo's Claude Code commands — `/build auto`'s single-approval plan-and-implement pass and `/ship`'s parallel persona fan-out. Reproducing that on Copilot is its own piece of work, not something a one-file alias covers. Prefer the skill names as your default; reach for aliases only if the short form is worth the extra file.
+An alias is a thin shortcut to one skill, nothing more. These aliases do not implement the orchestration in this repo's Claude Code commands — `/i3-build auto`'s single-approval plan-and-implement pass and `/i3-ship`'s parallel persona fan-out. Reproducing that on Copilot is its own piece of work, not something a one-file alias covers. Prefer the skill names as your default; reach for aliases only if the short form is worth the extra file.
 
 Create one, without clobbering an existing file:
 
@@ -121,7 +121,7 @@ mkdir -p .github/prompts
 description: Write a structured spec before writing code
 ---
 
-Use the spec-driven-development skill.
+Use the i3-spec-driven-development skill.
 
 Ask clarifying questions about the objective and target users, core features and
 acceptance criteria, stack preferences and constraints, and known boundaries.
@@ -131,27 +131,27 @@ confirm with me before any code is written.
 EOF
 ```
 
-Reload the window, then type `/spec`.
+Reload the window, then type `/i3-spec`.
 
-For the rest, run the same `mkdir`/`cat` block with the filename swapped (the filename *is* the command name), and take the `description` and body from this table. **Replace the entire body below the `---` frontmatter**, not just the skill name — the spec body's SPEC.md and clarifying-question instructions belong to Define only, and leaving them in would make `/plan` or `/test` write a spec.
+For the rest, run the same `mkdir`/`cat` block with the filename swapped (the filename *is* the command name), and take the `description` and body from this table. **Replace the entire body below the `---` frontmatter**, not just the skill name — the spec body's SPEC.md and clarifying-question instructions belong to Define only, and leaving them in would make `/i3-plan` or `/i3-test` write a spec.
 
 | Alias file | `description` | Complete body — everything below the frontmatter |
 |------------|---------------|--------------------------------------------------|
-| `.github/prompts/plan.prompt.md` | Break an approved spec into ordered, verifiable tasks | Use the planning-and-task-breakdown skill. Read the spec, then break the work into small, independently verifiable tasks, each with acceptance criteria and explicit dependency order. Save the result to `tasks/plan.md` and `tasks/todo.md`. Write no product code — show me the plan and wait for my approval. |
-| `.github/prompts/build.prompt.md` | Implement the next planned task, test-first | Use the incremental-implementation and test-driven-development skills. Read `tasks/plan.md` and `tasks/todo.md`, then take the next unchecked task and only that one. Write a failing test first, make it pass, refactor, run the suite, and tick the task off. Stop there and report what changed. |
-| `.github/prompts/test.prompt.md` | Write tests before the code that satisfies them | Use the test-driven-development skill. For new behavior, write a failing test that captures it before any implementation. For a bug, reproduce it with a failing test first, then fix it. Run the suite after each step and show me the red and the green output. |
+| `.github/prompts/plan.prompt.md` | Break an approved spec into ordered, verifiable tasks | Use the i3-planning-and-task-breakdown skill. Read the spec, then break the work into small, independently verifiable tasks, each with acceptance criteria and explicit dependency order. Save the result to `tasks/plan.md` and `tasks/todo.md`. Write no product code — show me the plan and wait for my approval. |
+| `.github/prompts/build.prompt.md` | Implement the next planned task, test-first | Use the i3-incremental-implementation and i3-test-driven-development skills. Read `tasks/plan.md` and `tasks/todo.md`, then take the next unchecked task and only that one. Write a failing test first, make it pass, refactor, run the suite, and tick the task off. Stop there and report what changed. |
+| `.github/prompts/test.prompt.md` | Write tests before the code that satisfies them | Use the i3-test-driven-development skill. For new behavior, write a failing test that captures it before any implementation. For a bug, reproduce it with a failing test first, then fix it. Run the suite after each step and show me the red and the green output. |
 
 Write the body yourself, or take it from this table, rather than copying `.claude/commands/*.md` verbatim: those files reference skills as `i3-composer-agent:<name>`, a Claude Code plugin namespace that means nothing to Copilot.
 
 ### If the skill slash commands don't appear
 
-Work through these in order — `/spec-driven-development` missing and `/spec` missing have different causes:
+Work through these in order — `/i3-spec-driven-development` missing and `/i3-spec` missing have different causes:
 
 1. **Check where the skills landed.** Each one needs its own directory containing a `SKILL.md`. The project-level paths this guide uses are `.github/skills/`, `.claude/skills/` and `.agents/skills/` — but an installer run with a global/user flag writes outside the workspace instead (`~/.agents/skills/` and equivalents), so a skill that isn't in any of the three may simply be installed personally. Confirm the actual path against the [VS Code agent skills docs](https://code.visualstudio.com/docs/agent-customization/agent-skills), then re-install into the project if you wanted it project-scoped.
 2. **Check the frontmatter.** `name` must be present and valid — it *is* the slash command. A skill whose frontmatter opts out of user invocation won't appear.
 3. **Check the Configure Skills menu.** Run `/skills` and confirm the skill is enabled here.
 4. **Start a fresh session.** Newly added skills aren't always picked up mid-conversation.
-5. **Check the host.** If `/spec-driven-development` works but your `/spec` alias doesn't, you're likely on the Agent Host, which doesn't read prompt files.
+5. **Check the host.** If `/i3-spec-driven-development` works but your `/i3-spec` alias doesn't, you're likely on the Agent Host, which doesn't read prompt files.
 6. **Check versions.** VS Code (**Help → About**) and the Copilot Chat extension; skills-as-slash-commands is recent, so update if either is behind.
 
 ## Usage Tips

package/docs/cursor-setup.md

@@ -20,7 +20,7 @@ Docs: [Rules](https://docs.cursor.com/context/rules) · [Skills](https://docs.cu
 ### Rules vs skills
 
 - **Rules** — concise, stable (“use conventional commits”, “type-annotate public Python APIs”). Prefer one concern per file; avoid large pasted guides.
-- **Skills** — step-by-step processes from this repo (`test-driven-development`, `code-review-and-quality`, etc.). **Do not** copy entire `SKILL.md` bodies into rules; that duplicates `.cursor/skills/` and wastes context.
+- **Skills** — step-by-step processes from this repo (`i3-test-driven-development`, `i3-code-review-and-quality`, etc.). **Do not** copy entire `SKILL.md` bodies into rules; that duplicates `.cursor/skills/` and wastes context.
 
 ### Legacy (avoid for new setups)
 
@@ -40,16 +40,16 @@ your-project/
 │   ├── rules/                    # Short .mdc policies (yours)
 │   │   └── i3-composer-agent.mdc      # Optional: “use project skills” pointer
 │   └── skills/                   # What Cursor Agent loads
-│       ├── using-agent-skills/
-│       ├── test-driven-development/
-│       ├── code-review-and-quality/
+│       ├── i3-using-agent-skills/
+│       ├── i3-test-driven-development/
+│       ├── i3-code-review-and-quality/
 │       └── …                     # Synced from i3-composer-agent + your own skills
 └── i3-composer-agent/                 # Optional: git submodule or vendor clone
     └── skills/                   # Upstream source only
 ```
 
 **Source of truth for the agent:** `.cursor/skills/`.  
-Treat `i3-composer-agent/skills/` (or a cloned [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills)) as **upstream** — sync into `.cursor/skills/`, do not edit only upstream and expect Cursor to see it.
+Treat `i3-composer-agent/skills/` as **upstream** — sync into `.cursor/skills/`, do not edit only upstream and expect Cursor to see it.
 
 ---
 
@@ -80,7 +80,7 @@ Each skill folder must contain `SKILL.md` with YAML frontmatter, at minimum:
 
 ```yaml
 ---
-name: test-driven-development
+name: i3-test-driven-development
 description: Drives development with tests. Use when implementing logic, fixing bugs, or changing behavior.
 ---
 ```
@@ -99,7 +99,7 @@ alwaysApply: true
 
 Before non-trivial technical work:
 
-1. Route via `.cursor/skills/using-agent-skills/SKILL.md`.
+1. Route via `.cursor/skills/i3-using-agent-skills/SKILL.md`.
 2. Read and follow the matching skill under `.cursor/skills/<name>/SKILL.md`.
 3. Open `reference.md` in that folder when the skill links to it.
 4. Prefer project skills over guessing; user does not need to say "read skill" each time.
@@ -135,33 +135,33 @@ Project skills in `.cursor/skills/` take precedence for **this** repo’s workfl
 
 1. **Settings → Rules** — project `.mdc` files listed.
 2. **Agent chat** — skills from `.cursor/skills/` appear in the skill list (if your Cursor build exposes it).
-3. Run a task that maps to a skill (e.g. “add a feature with tests first”) without naming the file — agent should open `test-driven-development` when routing works.
+3. Run a task that maps to a skill (e.g. “add a feature with tests first”) without naming the file — agent should open `i3-test-driven-development` when routing works.
 
 ---
 
 ## How agents should use skills
 
-1. **Discover** — `using-agent-skills` maps task phase → skill name.
+1. **Discover** — `i3-using-agent-skills` maps task phase → skill name.
 2. **Read** — full process in `.cursor/skills/<name>/SKILL.md`.
 3. **Deep dive** — `reference.md`, `references/*.md`, or linked checklists when the skill says so.
-4. **Combine** — e.g. `incremental-implementation` + `api-and-interface-design` for an API slice.
+4. **Combine** — e.g. `i3-incremental-implementation` + `i3-api-and-interface-design` for an API slice.
 
-Explicit user phrases (“follow TDD”, “use code-review-and-quality”) still help if the agent drifts.
+Explicit user phrases (“follow TDD”, “use i3-code-review-and-quality”) still help if the agent drifts.
 
 ### Phase → skill (quick map)
 
 | You are… | Skill |
 |----------|--------|
-| Clarifying requirements | `interview-me`, `idea-refine`, `spec-driven-development` |
-| Planning tasks | `planning-and-task-breakdown` |
-| Implementing | `incremental-implementation`, `frontend-ui-engineering`, `api-and-interface-design` |
-| Testing | `test-driven-development`, `browser-testing-with-devtools` |
-| Debugging | `debugging-and-error-recovery` |
-| Reviewing | `code-review-and-quality`, `code-simplification` |
-| Security / performance | `security-and-hardening`, `performance-optimization` |
-| Git / CI / ship | `git-workflow-and-versioning`, `ci-cd-and-automation`, `shipping-and-launch` |
+| Clarifying requirements | `i3-interview-me`, `i3-idea-refine`, `i3-spec-driven-development` |
+| Planning tasks | `i3-planning-and-task-breakdown` |
+| Implementing | `i3-incremental-implementation`, `i3-frontend-ui-engineering`, `i3-api-and-interface-design` |
+| Testing | `i3-test-driven-development`, `i3-browser-testing-with-devtools` |
+| Debugging | `i3-debugging-and-error-recovery` |
+| Reviewing | `i3-code-review-and-quality`, `i3-code-simplification` |
+| Security / performance | `i3-security-and-hardening`, `i3-performance-optimization` |
+| Git / CI / ship | `i3-git-workflow-and-versioning`, `i3-ci-cd-and-automation`, `i3-shipping-and-launch` |
 
-Full tree: `skills/using-agent-skills/SKILL.md` in the repo.
+Full tree: `skills/i3-using-agent-skills/SKILL.md` in the repo.
 
 ---
 
@@ -190,7 +190,7 @@ Full tree: `skills/using-agent-skills/SKILL.md` in the repo.
 
 Files under `i3-composer-agent/agents/` (e.g. code reviewer persona) are **not** loaded automatically by Cursor. Options:
 
-- Reference the skill equivalent (`code-review-and-quality`).
+- Reference the skill equivalent (`i3-code-review-and-quality`).
 - Paste agent markdown into the chat for one review.
 - Extract a **short** checklist into a `.mdc` rule.
 
@@ -222,4 +222,4 @@ Files under `i3-composer-agent/agents/` (e.g. code reviewer persona) are **not**
 
 - [getting-started.md](getting-started.md)
 - [../README.md](../README.md) — Cursor quick blurb
-- Upstream: [github.com/addyosmani/agent-skills](https://github.com/addyosmani/agent-skills)
+- Package: [@givolt/i3-composer-agent](https://www.npmjs.com/package/@givolt/i3-composer-agent)