@givolt/i3-composer-agent 1.0.1 → 2.1.0

package/.agents/plugins/marketplace.json

@@ -6,7 +6,7 @@
   "plugins": [
     {
       "name": "i3-composer-agent",
-      "version": "1.0.1",
+      "version": "2.1.0",
       "description": "Production-grade engineering skills for AI coding agents covering the development lifecycle from spec to ship.",
       "source": {
         "source": "local",

package/.claude/commands/{build.md → i3-build.md}

@@ -2,12 +2,12 @@
 description: Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass.
 ---
 
-Invoke the i3-composer-agent:incremental-implementation skill alongside i3-composer-agent:test-driven-development.
+Invoke the i3-composer-agent:i3-incremental-implementation skill alongside i3-composer-agent:i3-test-driven-development.
 
 ## Modes
 
-- **`/build`** — implement the *next* pending task, then stop (careful, one slice at a time).
-- **`/build auto`** — generate the plan if needed, get a single approval, then implement *every* task without stopping between them.
+- **`/i3-build`** — implement the *next* pending task, then stop (careful, one slice at a time).
+- **`/i3-build auto`** — generate the plan if needed, get a single approval, then implement *every* task without stopping between them.
 
 `$ARGUMENTS` selects the mode. Treat `auto` (canonical) or `all` as autonomous mode; anything else (or empty) is the default single-task mode. Note: autonomous mode is not faster *per task* — it runs the same test-driven loop — it only removes the human stepping *between* tasks.
 
@@ -24,21 +24,21 @@ Pick the next pending task from the plan. Then:
 7. Commit with a descriptive message
 8. Mark the task complete and stop
 
-## Autonomous: the whole plan (`/build auto`)
+## Autonomous: the whole plan (`/i3-build auto`)
 
 Use this once a spec exists and you want to collapse plan + build into one run. It removes the manual stepping between tasks — **not** the verification. Every task still earns a passing test and its own commit.
 
-1. **Require a spec.** Look only for a spec at a known path: `SPEC.md` at the repo root, `docs/SPEC.md`, or a file under `spec/`. A README or arbitrary doc does **not** count. If none exists, stop and tell the user to run `/spec` first — do not invent requirements.
+1. **Require a spec.** Look only for a spec at a known path: `SPEC.md` at the repo root, `docs/SPEC.md`, or a file under `spec/`. A README or arbitrary doc does **not** count. If none exists, stop and tell the user to run `/i3-spec` first — do not invent requirements.
 2. **Establish a clean baseline.** Run `git status --porcelain`. If there are uncommitted changes outside the expected planning artifacts (`SPEC.md`, `docs/SPEC.md`, `spec/*`, `tasks/plan.md`, `tasks/todo.md`), stop and ask the user to commit, stash, or confirm how to handle them. Autonomous per-task commits must not absorb unrelated local work, or the clean-rollback guarantee breaks.
-3. **Plan if needed.** If there is no `tasks/plan.md`, invoke i3-composer-agent:planning-and-task-breakdown to generate one.
+3. **Plan if needed.** If there is no `tasks/plan.md`, invoke i3-composer-agent:i3-planning-and-task-breakdown to generate one.
 4. **Single checkpoint.** Present the full plan and wait for an unambiguous affirmative (e.g. "approve", "go", "yes"). Treat hedged responses ("looks reasonable", "I guess") as **not** approved. This is the only human gate — after approval, run autonomously. If you generated `tasks/plan.md`, commit it as a single preparatory commit now so it doesn't bleed into the first task's commit.
 5. **Execute every task in dependency order.** Use each task's declared dependencies; if they aren't explicit, execute in the order the plan lists them. For each task, run the full default loop above (RED → GREEN → regression → build → commit → mark complete). Stage only the files that task touched plus its task-status update — never `git add -A` blindly — and make one commit per task so any point is a clean rollback.
 6. **Stop and ask the user** (do not push through) when:
-   - a test can't be made to pass or the build breaks without an obvious fix → follow i3-composer-agent:debugging-and-error-recovery
+   - a test can't be made to pass or the build breaks without an obvious fix → follow i3-composer-agent:i3-debugging-and-error-recovery
    - the spec is ambiguous, or a task needs a decision the spec doesn't cover
-   - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, **or anything you can't undo with `git revert`** → follow i3-composer-agent:doubt-driven-development and get explicit sign-off before continuing
+   - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, **or anything you can't undo with `git revert`** → follow i3-composer-agent:i3-doubt-driven-development and get explicit sign-off before continuing
 
-   After the user resolves a blocker, they re-invoke `/build auto` — it resumes from the next pending task.
+   After the user resolves a blocker, they re-invoke `/i3-build auto` — it resumes from the next pending task.
 7. **Summarize at the end:** tasks completed, tests added, commits made, and anything skipped, flagged, or left for the user.
 
-If any step fails, follow the i3-composer-agent:debugging-and-error-recovery skill.
+If any step fails, follow the i3-composer-agent:i3-debugging-and-error-recovery skill.

package/.claude/commands/{code-simplify.md → i3-code-simplify.md}

@@ -2,7 +2,7 @@
 description: Simplify code for clarity and maintainability — reduce complexity without changing behavior
 ---
 
-Invoke the i3-composer-agent:code-simplification skill.
+Invoke the i3-composer-agent:i3-code-simplification skill.
 
 Simplify recently changed code (or the specified scope) while preserving exact behavior:
 
@@ -19,4 +19,4 @@ Simplify recently changed code (or the specified scope) while preserving exact b
 5. Apply each simplification incrementally — run tests after each change
 6. Verify all tests pass, the build succeeds, and the diff is clean
 
-If tests fail after a simplification, revert that change and reconsider. Use `code-review-and-quality` to review the result.
+If tests fail after a simplification, revert that change and reconsider. Use `i3-code-review-and-quality` to review the result.

package/.claude/commands/{constraints.md → i3-constraints.md}

@@ -2,7 +2,7 @@
 description: Define and enforce this project's quality bar — interview, sane defaults, CONSTRAINTS.md
 ---
 
-Invoke the i3-composer-agent:constraint-driven-development skill.
+Invoke the i3-composer-agent:i3-constraint-driven-development skill.
 
 $ARGUMENTS
 
@@ -27,6 +27,6 @@ Default behaviour with no arguments: set up constraints for this repository.
 7. **Verify.** Run the constraints against the current branch. If anything fails that the user disagrees with, fix the constraint now rather than leaving a gate people will learn to ignore.
 
 Sub-commands:
-- `/constraints check` — run the current constraints against this branch and report
-- `/constraints guard` — inspect the diff for a weakened bar: lowered thresholds, skipped or deleted tests, new suppression comments, unfinished stubs, new exceptions
-- `/constraints ratchet` — record today's measured values as the floor that must not fall
+- `/i3-constraints check` — run the current constraints against this branch and report
+- `/i3-constraints guard` — inspect the diff for a weakened bar: lowered thresholds, skipped or deleted tests, new suppression comments, unfinished stubs, new exceptions
+- `/i3-constraints ratchet` — record today's measured values as the floor that must not fall

package/.claude/commands/{plan.md → i3-plan.md}

@@ -2,7 +2,7 @@
 description: Break work into small verifiable tasks with acceptance criteria and dependency ordering
 ---
 
-Invoke the i3-composer-agent:planning-and-task-breakdown skill.
+Invoke the i3-composer-agent:i3-planning-and-task-breakdown skill.
 
 Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
 

package/.claude/commands/{review.md → i3-review.md}

@@ -2,15 +2,15 @@
 description: Conduct a five-axis code review — correctness, readability, architecture, security, performance
 ---
 
-Invoke the i3-composer-agent:code-review-and-quality skill.
+Invoke the i3-composer-agent:i3-code-review-and-quality skill.
 
 Review the current changes (staged or recent commits) across all five axes:
 
 1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
 2. **Readability** — Clear names? Straightforward logic? Well-organized?
 3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
-4. **Security** — Input validated? Secrets safe? Auth checked? (Use security-and-hardening skill)
-5. **Performance** — No N+1 queries? No unbounded ops? (Use performance-optimization skill)
+4. **Security** — Input validated? Secrets safe? Auth checked? (Use i3-security-and-hardening skill)
+5. **Performance** — No N+1 queries? No unbounded ops? (Use i3-performance-optimization skill)
 
 Categorize findings as Critical, Important, or Suggestion.
 Output a structured review with specific file:line references and fix recommendations.

package/.claude/commands/{ship.md → i3-ship.md}

@@ -2,9 +2,9 @@
 description: Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision
 ---
 
-Invoke the i3-composer-agent:shipping-and-launch skill.
+Invoke the i3-composer-agent:i3-shipping-and-launch skill.
 
-`/ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
+`/i3-ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
 
 ## Phase A — Parallel fan-out
 
@@ -23,7 +23,7 @@ Constraints (from Claude Code's subagent model):
 - Each subagent gets its own context window and returns only its report to this main session.
 - If you need teammates that talk to each other instead of just reporting back, use Claude Code Agent Teams and reference these personas as teammate types (see `references/orchestration-patterns.md`).
 
-**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `.claude/agents/` or `~/.claude/agents/`, those take precedence over this plugin's versions — `/ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Claude Code's scope priority table, so user-level definitions win by design.
+**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `.claude/agents/` or `~/.claude/agents/`, those take precedence over this plugin's versions — `/i3-ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Claude Code's scope priority table, so user-level definitions win by design.
 
 ## Phase B — Merge in main context
 
@@ -69,4 +69,4 @@ Produce a single output:
 2. Personas do not call each other. The main agent merges in Phase B.
 3. The rollback plan is mandatory before any GO decision.
 4. If any persona returns a Critical finding, the default verdict is NO-GO unless the user explicitly accepts the risk.
-5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.
+5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/i3-ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.

package/.claude/commands/{spec.md → i3-spec.md}

@@ -2,7 +2,7 @@
 description: Start spec-driven development — write a structured specification before writing code
 ---
 
-Invoke the i3-composer-agent:spec-driven-development skill.
+Invoke the i3-composer-agent:i3-spec-driven-development skill.
 
 Begin by understanding what the user wants to build. Ask clarifying questions about:
 1. The objective and target users

package/.claude/commands/{test.md → i3-test.md}

@@ -2,7 +2,7 @@
 description: Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern.
 ---
 
-Invoke the i3-composer-agent:test-driven-development skill.
+Invoke the i3-composer-agent:i3-test-driven-development skill.
 
 For new features:
 1. Write tests that describe the expected behavior (they should FAIL)
@@ -16,4 +16,4 @@ For bug fixes (Prove-It pattern):
 4. Confirm the test passes
 5. Run the full test suite for regressions
 
-For browser-related issues, also invoke i3-composer-agent:browser-testing-with-devtools to verify with Chrome DevTools MCP.
+For browser-related issues, also invoke i3-composer-agent:i3-browser-testing-with-devtools to verify with Chrome DevTools MCP.

package/.claude/commands/{webperf.md → i3-webperf.md}

@@ -2,7 +2,7 @@
 description: Run a web performance audit via the web-performance-auditor persona
 ---
 
-`/webperf` targets web applications specifically. Do not use it for utility libraries, CLIs, or server-only code with no browser-facing output.
+`/i3-webperf` targets web applications specifically. Do not use it for utility libraries, CLIs, or server-only code with no browser-facing output.
 
 ## Determine the mode
 

package/.claude-plugin/marketplace.json

@@ -8,7 +8,7 @@
   "plugins": [
     {
       "name": "i3-composer-agent",
-      "version": "1.0.1",
+      "version": "2.1.0",
       "source": "./",
       "description": "Production-grade engineering skills for AI coding agents covering the development lifecycle from spec to ship.",
       "homepage": "https://github.com/49780522/i3-composer-agent",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "i3-composer-agent",
-  "version": "1.0.1",
+  "version": "2.1.0",
   "description": "Production-grade engineering skills for AI coding agents covering the development lifecycle from spec to ship.",
   "author": {
     "name": "Givolt"

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "i3-composer-agent",
-  "version": "1.0.1",
+  "version": "2.1.0",
   "description": "Production-grade engineering skills for AI coding agents covering the development lifecycle from spec to ship.",
   "author": {
     "name": "Givolt"

package/.gemini/commands/{build.toml → i3-build.toml}

@@ -1,12 +1,12 @@
 description = "Implement tasks incrementally — build, test, verify, commit. Add \"auto\" to run the whole plan in one approved pass."
 
 prompt = """
-Invoke the incremental-implementation skill alongside test-driven-development.
+Invoke the i3-incremental-implementation skill alongside i3-test-driven-development.
 
 ## Modes
 
-- `/build` — implement the next pending task, then stop (careful, one slice at a time).
-- `/build auto` — generate the plan if needed, get a single approval, then implement every task without stopping between them.
+- `/i3-build` — implement the next pending task, then stop (careful, one slice at a time).
+- `/i3-build auto` — generate the plan if needed, get a single approval, then implement every task without stopping between them.
 
 The arguments select the mode. Treat `auto` (canonical) or `all` as autonomous mode; anything else (or empty) is the default single-task mode. Note: autonomous mode is not faster per task — it runs the same test-driven loop — it only removes the human stepping between tasks.
 
@@ -23,21 +23,21 @@ Pick the next pending task from the plan. Then:
 7. Commit with a descriptive message
 8. Mark the task complete and stop
 
-## Autonomous: the whole plan (`/build auto`)
+## Autonomous: the whole plan (`/i3-build auto`)
 
 Use this once a spec exists and you want to collapse plan + build into one run. It removes the manual stepping between tasks — not the verification. Every task still earns a passing test and its own commit.
 
-1. Require a spec. Look only for a spec at a known path: SPEC.md at the repo root, docs/SPEC.md, or a file under spec/. A README or arbitrary doc does NOT count. If none exists, stop and tell the user to run /spec first — do not invent requirements.
+1. Require a spec. Look only for a spec at a known path: SPEC.md at the repo root, docs/SPEC.md, or a file under spec/. A README or arbitrary doc does NOT count. If none exists, stop and tell the user to run /i3-spec first — do not invent requirements.
 2. Establish a clean baseline. Run `git status --porcelain`. If there are uncommitted changes outside the expected planning artifacts (SPEC.md, docs/SPEC.md, spec/*, tasks/plan.md, tasks/todo.md), stop and ask the user to commit, stash, or confirm how to handle them. Autonomous per-task commits must not absorb unrelated local work, or the clean-rollback guarantee breaks.
-3. Plan if needed. If there is no tasks/plan.md, invoke the planning-and-task-breakdown skill to generate one.
+3. Plan if needed. If there is no tasks/plan.md, invoke the i3-planning-and-task-breakdown skill to generate one.
 4. Single checkpoint. Present the full plan and wait for an unambiguous affirmative (e.g. "approve", "go", "yes"). Treat hedged responses ("looks reasonable", "I guess") as NOT approved. This is the only human gate — after approval, run autonomously. If you generated tasks/plan.md, commit it as a single preparatory commit now so it doesn't bleed into the first task's commit.
 5. Execute every task in dependency order. Use each task's declared dependencies; if they aren't explicit, execute in the order the plan lists them. For each task, run the full default loop above (RED → GREEN → regression → build → commit → mark complete). Stage only the files that task touched plus its task-status update — never `git add -A` blindly — and make one commit per task so any point is a clean rollback.
 6. Stop and ask the user (do not push through) when:
-   - a test can't be made to pass or the build breaks without an obvious fix → follow the debugging-and-error-recovery skill
+   - a test can't be made to pass or the build breaks without an obvious fix → follow the i3-debugging-and-error-recovery skill
    - the spec is ambiguous, or a task needs a decision the spec doesn't cover
-   - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, or anything you can't undo with `git revert` → follow the doubt-driven-development skill and get explicit sign-off before continuing
-   After the user resolves a blocker, they re-invoke /build auto — it resumes from the next pending task.
+   - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, or anything you can't undo with `git revert` → follow the i3-doubt-driven-development skill and get explicit sign-off before continuing
+   After the user resolves a blocker, they re-invoke /i3-build auto — it resumes from the next pending task.
 7. Summarize at the end: tasks completed, tests added, commits made, and anything skipped, flagged, or left for the user.
 
-If any step fails, follow the debugging-and-error-recovery skill.
+If any step fails, follow the i3-debugging-and-error-recovery skill.
 """

package/.gemini/commands/{code-simplify.toml → i3-code-simplify.toml}

@@ -1,7 +1,7 @@
 description = "Simplify code for clarity and maintainability — reduce complexity without changing behavior"
 
 prompt = """
-Invoke the code-simplification skill.
+Invoke the i3-code-simplification skill.
 
 Simplify recently changed code (or the specified scope) while preserving exact behavior:
 
@@ -18,5 +18,5 @@ Simplify recently changed code (or the specified scope) while preserving exact b
 5. Apply each simplification incrementally — run tests after each change
 6. Verify all tests pass, the build succeeds, and the diff is clean
 
-If tests fail after a simplification, revert that change and reconsider. Use `code-review-and-quality` to review the result.
+If tests fail after a simplification, revert that change and reconsider. Use `i3-code-review-and-quality` to review the result.
 """

package/.gemini/commands/{constraints.toml → i3-constraints.toml}

@@ -1,7 +1,7 @@
 description = "Define and enforce this project's quality bar — interview, sane defaults, CONSTRAINTS.md"
 
 prompt = """
-Invoke the constraint-driven-development skill.
+Invoke the i3-constraint-driven-development skill.
 
 $ARGUMENTS
 
@@ -26,7 +26,7 @@ Default behaviour with no arguments: set up constraints for this repository.
 7. **Verify.** Run the constraints against the current branch. If anything fails that the user disagrees with, fix the constraint now rather than leaving a gate people will learn to ignore.
 
 Sub-commands:
-- `/constraints check` — run the current constraints against this branch and report
-- `/constraints guard` — inspect the diff for a weakened bar: lowered thresholds, skipped or deleted tests, new suppression comments, unfinished stubs, new exceptions
-- `/constraints ratchet` — record today's measured values as the floor that must not fall
+- `/i3-constraints check` — run the current constraints against this branch and report
+- `/i3-constraints guard` — inspect the diff for a weakened bar: lowered thresholds, skipped or deleted tests, new suppression comments, unfinished stubs, new exceptions
+- `/i3-constraints ratchet` — record today's measured values as the floor that must not fall
 """

package/.gemini/commands/{planning.toml → i3-planning.toml}

@@ -1,7 +1,7 @@
 description = "Break work into small verifiable tasks with acceptance criteria and dependency ordering"
 
 prompt = """
-Invoke the planning-and-task-breakdown skill.
+Invoke the i3-planning-and-task-breakdown skill.
 
 Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
 

package/{commands/review.toml → .gemini/commands/i3-review.toml}

@@ -1,15 +1,15 @@
 description = "Conduct a five-axis code review — correctness, readability, architecture, security, performance"
 
 prompt = """
-Invoke the code-review-and-quality skill.
+Invoke the i3-code-review-and-quality skill.
 
 Review the current changes (staged or recent commits) across all five axes:
 
 1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
 2. **Readability** — Clear names? Straightforward logic? Well-organized?
 3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
-4. **Security** — Input validated? Secrets safe? Auth checked? (Use security-and-hardening skill)
-5. **Performance** — No N+1 queries? No unbounded ops? (Use performance-optimization skill)
+4. **Security** — Input validated? Secrets safe? Auth checked? (Use i3-security-and-hardening skill)
+5. **Performance** — No N+1 queries? No unbounded ops? (Use i3-performance-optimization skill)
 
 Categorize findings as Critical, Important, or Suggestion.
 Output a structured review with specific file:line references and fix recommendations.

package/.gemini/commands/{ship.toml → i3-ship.toml}

@@ -1,9 +1,9 @@
 description = "Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision"
 
 prompt = """
-Invoke the shipping-and-launch skill.
+Invoke the i3-shipping-and-launch skill.
 
-`/ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
+`/i3-ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
 
 ## Phase A — Parallel fan-out
 
@@ -22,7 +22,7 @@ Constraints (from Gemini CLI's subagent model):
 - Do not let one persona delegate to another — keep the fan-out flat.
 - For richer multi-agent collaboration where teammates talk to each other instead of just reporting back, see `references/orchestration-patterns.md`.
 
-**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `agents/` (this plugin's agents, at the repo root) or `~/.gemini/agents/` (user-level), those take precedence over this plugin's versions — `/ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Gemini CLI's scope priority table, so user-level definitions win by design.
+**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `agents/` (this plugin's agents, at the repo root) or `~/.gemini/agents/` (user-level), those take precedence over this plugin's versions — `/i3-ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Gemini CLI's scope priority table, so user-level definitions win by design.
 
 ## Phase B — Merge in main context
 
@@ -68,5 +68,5 @@ Produce a single output:
 2. Personas do not call each other. The main agent merges in Phase B.
 3. The rollback plan is mandatory before any GO decision.
 4. If any persona returns a Critical finding, the default verdict is NO-GO unless the user explicitly accepts the risk.
-5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.
+5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/i3-ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.
 """

package/.gemini/commands/{spec.toml → i3-spec.toml}

@@ -1,7 +1,7 @@
 description = "Start spec-driven development — write a structured specification before writing code"
 
 prompt = """
-Invoke the spec-driven-development skill.
+Invoke the i3-spec-driven-development skill.
 
 Begin by understanding what the user wants to build. Ask clarifying questions about:
 1. The objective and target users

package/{commands/test.toml → .gemini/commands/i3-test.toml}

@@ -1,7 +1,7 @@
 description = "Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern."
 
 prompt = """
-Invoke the test-driven-development skill.
+Invoke the i3-test-driven-development skill.
 
 For new features:
 1. Write tests that describe the expected behavior (they should FAIL)
@@ -15,5 +15,5 @@ For bug fixes (Prove-It pattern):
 4. Confirm the test passes
 5. Run the full test suite for regressions
 
-For browser-related issues, also invoke browser-testing-with-devtools to verify with Chrome DevTools MCP.
+For browser-related issues, also invoke i3-browser-testing-with-devtools to verify with Chrome DevTools MCP.
 """

package/.gemini/commands/{webperf.toml → i3-webperf.toml}

@@ -1,7 +1,7 @@
 description = "Run a web performance audit via the web-performance-auditor persona"
 
 prompt = """
-/webperf targets web applications specifically. Do not use it for utility libraries, CLIs, or server-only code with no browser-facing output.
+/i3-webperf targets web applications specifically. Do not use it for utility libraries, CLIs, or server-only code with no browser-facing output.
 
 ## Determine the mode