@givolt/i3-composer-agent 1.0.1 → 2.0.0

package/.agents/plugins/marketplace.json

@@ -6,7 +6,7 @@
   "plugins": [
     {
       "name": "i3-composer-agent",
-      "version": "1.0.1",
+      "version": "2.0.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.0.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.0.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.0.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
 

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # i3 Composer Agent changes
 
+## 2.0.0 — 2026-10-07
+
+Upstream baseline: agent-skills 0.6.12 at commit 1401c8b8030e023baeebb31781a6653fe8e93026.
+
+### Changed
+
+- Commands and Skill IDs use the `i3-` prefix, such as `/i3-spec` and `$i3-spec-driven-development`.
+- Native upgrades back up and retire this package's manifest-owned unprefixed paths. Unowned entries remain in place; failed migrations roll back.
+- Local command references, hooks, routing fixtures and setup documentation follow the renamed identifiers.
+
+### Migration
+
+- Replace `/spec`, `/plan`, `/build` and other lifecycle calls with `/i3-spec`, `/i3-plan`, `/i3-build` and their prefixed equivalents. Plugin calls use `/i3-composer-agent:i3-<command>`.
+- Replace Skill calls such as `$spec-driven-development` with `$i3-spec-driven-development`.
+- Upgrade with `npx @givolt/i3-composer-agent@2.0.0 --codebuddy`, confirm replacement, then reload the host. The installer backs up manifest-owned legacy entries before retiring them.
+- Keep using the pinned 1.0.1 package if a consuming workflow needs the old identifiers. Existing published versions remain available.
+
 ## 1.0.1 — 2026-10-07
 
 Upstream baseline: agent-skills 0.6.12 at commit 1401c8b8030e023baeebb31781a6653fe8e93026.

package/NOTICE.md

@@ -6,7 +6,8 @@ The initial distribution is based on upstream commit `1401c8b` (version 0.6.12).
 
 The original MIT license and copyright notice are preserved in LICENSE.
 Givolt maintains the branding, npm distribution, and installation CLI.
-The original skill IDs, command workflows, and persona definitions are retained.
+Skill IDs and command filenames use an i3- prefix in this distribution.
+The original command workflows and persona definitions are retained.
 
 The tool installation directory presets in `bin/agent-targets.json` are adapted
 from Vercel's [Skills CLI registry](https://github.com/vercel-labs/skills/blob/48dc9e8eb8aa19040e91cb90ba0b642c9cbad57e/src/agents.ts)

package/README.md

@@ -1,4 +1,4 @@
-# i3 Composer Agent v1.0.1
+# i3 Composer Agent v2.0.0
 
 **Based on agent-skills v0.6.12**
 
@@ -9,7 +9,7 @@ Based on [Agent Skills](https://github.com/addyosmani/agent-skills) by Addy Osma
 (MIT). See [NOTICE.md](NOTICE.md) for attribution.
 
 The npm package is `@givolt/i3-composer-agent`; the plugin and marketplace ID is
-`i3-composer-agent`. Skill IDs retain their upstream names.
+`i3-composer-agent`. Commands and Skill IDs use the `i3-` prefix.
 
 ## Install with the wizard
 
@@ -49,6 +49,12 @@ under each tool configuration root. Unrelated settings are left in place.
 `npx -y` accepts npm's package download prompt; the package's own `--yes` flag
 accepts the explicit installation plan.
 
+Earlier native installations migrate their unprefixed Skill and command paths
+when those paths belong to this package's previous installation manifest.
+The migration preserves legacy paths in the backup directory. Unowned entries
+remain in place. Use `/i3-spec` in CodeBuddy or `$i3-spec-driven-development`
+in Codex after upgrading.
+
 ## Prepare the complete plugin
 
 For native plugin registration, including plugin hooks, explicitly prepare a
@@ -78,59 +84,59 @@ codex plugin marketplace add ./i3-composer-agent
 codex plugin add i3-composer-agent@i3-composer-agent
 ```
 
-Start a new session after enabling the plugin. Codex uses the existing Skill
-names, such as `$spec-driven-development`; lifecycle slash-command adaptation
+Start a new session after enabling the plugin. Codex uses the branded Skill
+names, such as `$i3-spec-driven-development`; lifecycle slash-command adaptation
 is maintained separately.
 
 ## Commands
 
 Native CodeBuddy and Claude Code installations use short filenames such as
-`/spec`, `/plan`, `/build` and `/ship`. Hosts supporting Claude-compatible plugin
+`/i3-spec`, `/i3-plan`, `/i3-build` and `/i3-ship`. Hosts supporting Claude-compatible plugin
 commands load the same workflows under the plugin namespace:
 
 | Command | Description |
 | --- | --- |
-| /i3-composer-agent:build | Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass. |
-| /i3-composer-agent:code-simplify | Simplify code for clarity and maintainability — reduce complexity without changing behavior |
-| /i3-composer-agent:constraints | Define and enforce this project's quality bar — interview, sane defaults, CONSTRAINTS.md |
-| /i3-composer-agent:plan | Break work into small verifiable tasks with acceptance criteria and dependency ordering |
-| /i3-composer-agent:review | Conduct a five-axis code review — correctness, readability, architecture, security, performance |
-| /i3-composer-agent:ship | Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision |
-| /i3-composer-agent:spec | Start spec-driven development — write a structured specification before writing code |
-| /i3-composer-agent:test | Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern. |
-| /i3-composer-agent:webperf | Run a web performance audit via the web-performance-auditor persona |
-
-`/i3-composer-agent:build auto` runs the existing approved-plan workflow.
+| /i3-composer-agent:i3-build | Implement tasks incrementally — build, test, verify, commit. Add "auto" to run the whole plan in one approved pass. |
+| /i3-composer-agent:i3-code-simplify | Simplify code for clarity and maintainability — reduce complexity without changing behavior |
+| /i3-composer-agent:i3-constraints | Define and enforce this project's quality bar — interview, sane defaults, CONSTRAINTS.md |
+| /i3-composer-agent:i3-plan | Break work into small verifiable tasks with acceptance criteria and dependency ordering |
+| /i3-composer-agent:i3-review | Conduct a five-axis code review — correctness, readability, architecture, security, performance |
+| /i3-composer-agent:i3-ship | Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision |
+| /i3-composer-agent:i3-spec | Start spec-driven development — write a structured specification before writing code |
+| /i3-composer-agent:i3-test | Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern. |
+| /i3-composer-agent:i3-webperf | Run a web performance audit via the web-performance-auditor persona |
+
+`/i3-composer-agent:i3-build auto` runs the existing approved-plan workflow.
 
 ## Skills
 
 | Skill | Description |
 | --- | --- |
-| [api-and-interface-design](skills/api-and-interface-design/SKILL.md) | Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend. |
-| [browser-testing-with-devtools](skills/browser-testing-with-devtools/SKILL.md) | Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured. |
-| [ci-cd-and-automation](skills/ci-cd-and-automation/SKILL.md) | Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies. |
-| [code-review-and-quality](skills/code-review-and-quality/SKILL.md) | Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline. |
-| [code-simplification](skills/code-simplification/SKILL.md) | Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. |
-| [constraint-driven-development](skills/constraint-driven-development/SKILL.md) | Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read. |
-| [context-engineering](skills/context-engineering/SKILL.md) | Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project. |
-| [debugging-and-error-recovery](skills/debugging-and-error-recovery/SKILL.md) | Guides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing. |
-| [deprecation-and-migration](skills/deprecation-and-migration/SKILL.md) | Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code. |
-| [documentation-and-adrs](skills/documentation-and-adrs/SKILL.md) | Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase. |
-| [doubt-driven-development](skills/doubt-driven-development/SKILL.md) | Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later. |
-| [frontend-ui-engineering](skills/frontend-ui-engineering/SKILL.md) | Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated. |
-| [git-workflow-and-versioning](skills/git-workflow-and-versioning/SKILL.md) | Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog. |
-| [idea-refine](skills/idea-refine/SKILL.md) | Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan". |
-| [incremental-implementation](skills/incremental-implementation/SKILL.md) | Delivers changes incrementally in thin, verifiable slices. Use when implementing any feature or change that touches more than one file, or when picking up the next task from a plan. Use when rolling a change out behind a feature flag, when you're about to write a large amount of code at once, or when a task feels too big to land in one step. |
-| [interview-me](skills/interview-me/SKILL.md) | Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists. |
-| [observability-and-instrumentation](skills/observability-and-instrumentation/SKILL.md) | Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data. |
-| [performance-optimization](skills/performance-optimization/SKILL.md) | Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks. |
-| [planning-and-task-breakdown](skills/planning-and-task-breakdown/SKILL.md) | Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible. |
-| [security-and-hardening](skills/security-and-hardening/SKILL.md) | Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved. |
-| [shipping-and-launch](skills/shipping-and-launch/SKILL.md) | Prepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy. |
-| [source-driven-development](skills/source-driven-development/SKILL.md) | Grounds every implementation decision in official documentation. Use when you want to verify an approach against the official docs before implementing it, or when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. |
-| [spec-driven-development](skills/spec-driven-development/SKILL.md) | Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying. |
-| [test-driven-development](skills/test-driven-development/SKILL.md) | Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. |
-| [using-agent-skills](skills/using-agent-skills/SKILL.md) | Discovers and invokes agent skills. Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked. |
+| [i3-api-and-interface-design](skills/i3-api-and-interface-design/SKILL.md) | Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend. |
+| [i3-browser-testing-with-devtools](skills/i3-browser-testing-with-devtools/SKILL.md) | Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured. |
+| [i3-ci-cd-and-automation](skills/i3-ci-cd-and-automation/SKILL.md) | Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies. |
+| [i3-code-review-and-quality](skills/i3-code-review-and-quality/SKILL.md) | Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch. Use when asked to review a diff or a pull request, even when the diff is pasted inline. |
+| [i3-code-simplification](skills/i3-code-simplification/SKILL.md) | Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity. |
+| [i3-constraint-driven-development](skills/i3-constraint-driven-development/SKILL.md) | Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says "set up constraints" or "define our standards", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read. |
+| [i3-context-engineering](skills/i3-context-engineering/SKILL.md) | Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project. |
+| [i3-debugging-and-error-recovery](skills/i3-debugging-and-error-recovery/SKILL.md) | Guides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing. |
+| [i3-deprecation-and-migration](skills/i3-deprecation-and-migration/SKILL.md) | Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code. |
+| [i3-documentation-and-adrs](skills/i3-documentation-and-adrs/SKILL.md) | Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase. |
+| [i3-doubt-driven-development](skills/i3-doubt-driven-development/SKILL.md) | Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later. |
+| [i3-frontend-ui-engineering](skills/i3-frontend-ui-engineering/SKILL.md) | Builds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated. |
+| [i3-git-workflow-and-versioning](skills/i3-git-workflow-and-versioning/SKILL.md) | Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog. |
+| [i3-idea-refine](skills/i3-idea-refine/SKILL.md) | Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan". |
+| [i3-incremental-implementation](skills/i3-incremental-implementation/SKILL.md) | Delivers changes incrementally in thin, verifiable slices. Use when implementing any feature or change that touches more than one file, or when picking up the next task from a plan. Use when rolling a change out behind a feature flag, when you're about to write a large amount of code at once, or when a task feels too big to land in one step. |
+| [i3-interview-me](skills/i3-interview-me/SKILL.md) | Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists. |
+| [i3-observability-and-instrumentation](skills/i3-observability-and-instrumentation/SKILL.md) | Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data. |
+| [i3-performance-optimization](skills/i3-performance-optimization/SKILL.md) | Optimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks. |
+| [i3-planning-and-task-breakdown](skills/i3-planning-and-task-breakdown/SKILL.md) | Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible. |
+| [i3-security-and-hardening](skills/i3-security-and-hardening/SKILL.md) | Hardens code against vulnerabilities. Use when auditing an input handler for vulnerabilities, when handling user input, authentication, data storage, or external integrations, or when checking a login flow is safe against the OWASP Top Ten. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when auditing dependencies for known vulnerabilities, triaging package-manager audit findings, or assessing supply-chain risk in a new package. Use when personal data or privacy compliance (GDPR, CCPA) is involved. |
+| [i3-shipping-and-launch](skills/i3-shipping-and-launch/SKILL.md) | Prepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy. |
+| [i3-source-driven-development](skills/i3-source-driven-development/SKILL.md) | Grounds every implementation decision in official documentation. Use when you want to verify an approach against the official docs before implementing it, or when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. |
+| [i3-spec-driven-development](skills/i3-spec-driven-development/SKILL.md) | Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when drafting a PRD or requirements document with objectives and scope, or when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying. |
+| [i3-test-driven-development](skills/i3-test-driven-development/SKILL.md) | Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. |
+| [i3-using-agent-skills](skills/i3-using-agent-skills/SKILL.md) | Discovers and invokes agent skills. Use when starting a session, or when you need to decide which skill or workflow applies to the piece of work at hand. This is the meta-skill that governs how all other skills are discovered and invoked. |
 
 ## Bundle options