@givolt/i3-composer-agent 1.0.1 → 2.0.0

package/docs/codebuddy-setup.md

@@ -11,7 +11,7 @@ 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.
@@ -22,12 +22,12 @@ not replaced. 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.
@@ -70,16 +70,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,9 +40,9 @@ 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
@@ -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.
 

package/docs/developer-onboarding.md

@@ -65,7 +65,7 @@ node scripts/run-evals.js
 node scripts/run-evals.js --behavioral <skill-name> --dry-run
 
 # Hook regression test, required if you touch hooks/session-start.sh
-# or skills/using-agent-skills/SKILL.md
+# or skills/i3-using-agent-skills/SKILL.md
 bash hooks/session-start-test.sh
 ```
 
@@ -100,17 +100,17 @@ One point worth internalizing rather than looking up: when writing trigger promp
 - [ ] Tier 1 green: `node scripts/validate-skills.js`
 - [ ] Tier 2 green: `node scripts/run-evals.js`
 - [ ] Command parity green if you touched any command directory: `node scripts/validate-commands.js`
-- [ ] Hook test green if you touched `hooks/` or `using-agent-skills`
+- [ ] Hook test green if you touched `hooks/` or `i3-using-agent-skills`
 - [ ] New skill → eval case file present with the minimum trigger/behavioral counts
 - [ ] New skill → gap justified in the PR description; catalog and open PRs checked
 - [ ] No duplicated content; cross-references used instead
-- [ ] Change is small and focused (the repo's own `code-review-and-quality` change-sizing guidance applies to contributions here too)
+- [ ] Change is small and focused (the repo's own `i3-code-review-and-quality` change-sizing guidance applies to contributions here too)
 
 ## 6. Suggested reading order
 
 1. [README.md](../README.md): the catalog and the lifecycle diagram (10 min)
-2. `skills/using-agent-skills/SKILL.md`: how routing works from the agent's side
-3. One well-established skill end to end (e.g. `test-driven-development`): internalize the anatomy by example
+2. `skills/i3-using-agent-skills/SKILL.md`: how routing works from the agent's side
+3. One well-established skill end to end (e.g. `i3-test-driven-development`): internalize the anatomy by example
 4. [skill-anatomy.md](skill-anatomy.md): the format spec, now with context
 5. [evals/README.md](../evals/README.md): the three tiers and the case format
 6. [CONTRIBUTING.md](../CONTRIBUTING.md) + [AGENTS.md](../AGENTS.md): the rules and the repo-scoped agent config

package/docs/gemini-cli-setup.md

@@ -41,9 +41,9 @@ For skills you want always loaded as persistent project context (rather than on-
 
 ```bash
 # Create GEMINI.md with core skills as persistent context
-cat /path/to/i3-composer-agent/skills/incremental-implementation/SKILL.md > GEMINI.md
+cat /path/to/i3-composer-agent/skills/i3-incremental-implementation/SKILL.md > GEMINI.md
 echo -e "\n---\n" >> GEMINI.md
-cat /path/to/i3-composer-agent/skills/code-review-and-quality/SKILL.md >> GEMINI.md
+cat /path/to/i3-composer-agent/skills/i3-code-review-and-quality/SKILL.md >> GEMINI.md
 ```
 
 You can also modularize by importing from separate files:
@@ -51,8 +51,8 @@ You can also modularize by importing from separate files:
 ```markdown
 # Project Instructions
 
-@skills/test-driven-development/SKILL.md
-@skills/incremental-implementation/SKILL.md
+@skills/i3-test-driven-development/SKILL.md
+@skills/i3-incremental-implementation/SKILL.md
 ```
 
 Use `/memory show` to verify loaded context, and `/memory reload` to refresh after changes.
@@ -65,18 +65,18 @@ Use `/memory show` to verify loaded context, and `/memory reload` to refresh aft
 
 Add these as persistent context for every session:
 
-- `incremental-implementation` — Build in small verifiable slices
-- `code-review-and-quality` — Five-axis review
+- `i3-incremental-implementation` — Build in small verifiable slices
+- `i3-code-review-and-quality` — Five-axis review
 
 ### On-Demand (Skills)
 
 Install these as skills so they activate only when relevant:
 
-- `test-driven-development` — Activates when implementing logic or fixing bugs
-- `spec-driven-development` — Activates when starting a new project or feature
-- `frontend-ui-engineering` — Activates when building UI
-- `security-and-hardening` — Activates during security reviews
-- `performance-optimization` — Activates during performance work
+- `i3-test-driven-development` — Activates when implementing logic or fixing bugs
+- `i3-spec-driven-development` — Activates when starting a new project or feature
+- `i3-frontend-ui-engineering` — Activates when building UI
+- `i3-security-and-hardening` — Activates during security reviews
+- `i3-performance-optimization` — Activates during performance work
 
 ## Advanced Configuration
 
@@ -84,8 +84,8 @@ Install these as skills so they activate only when relevant:
 
 Many skills in this pack leverage [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) tools to interact with the environment. For example:
 
-- `browser-testing-with-devtools` uses the `chrome-devtools` MCP extension.
-- `performance-optimization` can benefit from performance-related MCP tools.
+- `i3-browser-testing-with-devtools` uses the `chrome-devtools` MCP extension.
+- `i3-performance-optimization` can benefit from performance-related MCP tools.
 
 To enable these, ensure you have the relevant MCP extensions installed in your Gemini CLI configuration (`~/.gemini/config.json`).
 
@@ -93,37 +93,37 @@ To enable these, ensure you have the relevant MCP extensions installed in your G
 
 Gemini CLI supports session lifecycle hooks. You can use these to automatically inject context or run validation scripts at the start of a session.
 
-To replicate the `i3-composer-agent` experience from other tools, you can configure a `SessionStart` hook that reminds you of the available skills or loads a meta-skill. `hooks/session-start.sh` in this repo is a ready-made script for that: it prints the `using-agent-skills` meta-skill as a standard `SessionStart` JSON envelope on stdout.
+To replicate the `i3-composer-agent` experience from other tools, you can configure a `SessionStart` hook that reminds you of the available skills or loads a meta-skill. `hooks/session-start.sh` in this repo is a ready-made script for that: it prints the `i3-using-agent-skills` meta-skill as a standard `SessionStart` JSON envelope on stdout.
 
 ### Explicit Context Loading
 
 You can explicitly load any skill into your current session by referencing it with the `@` symbol in your prompt:
 
 ```markdown
-Use the @skills/test-driven-development/SKILL.md skill to implement this fix.
+Use the @skills/i3-test-driven-development/SKILL.md skill to implement this fix.
 ```
 
 This is useful when you want to ensure a specific workflow is followed without waiting for auto-discovery.
 
 ## Slash Commands
 
-The repo ships 9 slash commands under `.gemini/commands/`: 8 lifecycle commands plus the `/webperf` specialist audit. Gemini CLI auto-discovers them when you run from the project root.
+The repo ships 9 slash commands under `.gemini/commands/`: 8 lifecycle commands plus the `/i3-webperf` specialist audit. Gemini CLI auto-discovers them when you run from the project root.
 
 | Command | What it does |
 |---------|--------------|
-| `/spec` | Write a structured spec before writing code |
-| `/constraints` | Define and enforce the project's quality bar |
-| `/planning` | Break work into small, verifiable tasks |
-| `/build` | Implement the next task incrementally |
-| `/test` | Run TDD workflow — red, green, refactor |
-| `/review` | Five-axis code review |
-| `/code-simplify` | Reduce complexity without changing behavior |
-| `/ship` | Pre-launch checklist via parallel persona fan-out |
-| `/webperf` | Audit browser-facing apps for Core Web Vitals and performance issues |
+| `/i3-spec` | Write a structured spec before writing code |
+| `/i3-constraints` | Define and enforce the project's quality bar |
+| `/i3-planning` | Break work into small, verifiable tasks |
+| `/i3-build` | Implement the next task incrementally |
+| `/i3-test` | Run TDD workflow — red, green, refactor |
+| `/i3-review` | Five-axis code review |
+| `/i3-code-simplify` | Reduce complexity without changing behavior |
+| `/i3-ship` | Pre-launch checklist via parallel persona fan-out |
+| `/i3-webperf` | Audit browser-facing apps for Core Web Vitals and performance issues |
 
 Each command invokes the corresponding skill automatically — no manual skill loading required.
 
-> **Note:** Use `/planning` instead of `/plan` — `/plan` conflicts with a Gemini CLI internal command name.
+> **Note:** Use `/i3-planning` instead of `/i3-plan` — `/i3-plan` conflicts with a Gemini CLI internal command name.
 
 ## Usage Tips