@givolt/i3-composer-agent 1.0.1 → 2.0.0

package/rebrand/templates/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 {{SKILL_COUNT}} skills with their original IDs.
+- `.codebuddy/skills/` — all {{SKILL_COUNT}} skills with `i3-` IDs.
 - `.codebuddy/references/` — shared checklists used by skill-relative links.
 - `.codebuddy/commands/` — all {{COMMAND_COUNT}} existing lifecycle workflows.
 - `.codebuddy/agents/` — all {{PERSONA_COUNT}} 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/rebrand/templates/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 {{SKILL_COUNT}} original skill IDs. This mode does not add short lifecycle
+or `~/.agents/skills/`, plus the sibling `references/` directory. It installs
+the {{SKILL_COUNT}} 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 {{SKILL_COUNT}} 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 {{SKILL_COUNT}} 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/rebrand/tests/pipeline.test.cjs

@@ -8,6 +8,8 @@ const path = require('node:path');
 const { spawnSync } = require('node:child_process');
 const root = path.resolve(__dirname, '../..');
 const baselineVersion = require('../upstream.json').upstreamVersion;
+const upstream = require('../upstream.json');
+const { runtimePath, rewriteReferences } = require('../identifiers.cjs');
 
 function run(directory, executable, args) {
   return spawnSync(executable, args, { cwd: directory, encoding: 'utf8' });
@@ -24,6 +26,19 @@ function fixture(t, branch = 'release/test-candidate') {
   for (const name of ['skills', 'references', 'agents', 'commands', '.claude', '.gemini', '.claude-plugin', '.codex-plugin', '.agents', 'hooks', 'docs', 'scripts', 'evals', 'rebrand', 'LICENSE', 'plugin.json', 'README.md']) {
     fs.cpSync(path.join(root, name), path.join(directory, name), { recursive: true, filter: file => !file.includes(`${path.sep}results${path.sep}`) });
   }
+  function restore(folder) {
+    for (const entry of fs.readdirSync(folder, { withFileTypes: true })) {
+      if (entry.name === 'rebrand') continue;
+      const file = path.join(folder, entry.name);
+      if (entry.isDirectory()) restore(file);
+      else if (/\.(?:md|js|cjs|sh|toml|json|yml|patch|diff)$/.test(entry.name)) fs.writeFileSync(file, rewriteReferences(fs.readFileSync(file, 'utf8'), true));
+    }
+  }
+  restore(directory);
+  for (const source of [...upstream.skills.map(id => `skills/${id}`), ...upstream.skills.map(id => `evals/cases/${id}.json`), ...upstream.skills.map(id => `evals/fixtures/${id}`), ...upstream.runtimeFiles.filter(file => /commands\/[^/]+\.(md|toml)$/.test(file))]) {
+    const branded = runtimePath(source);
+    if (fs.existsSync(path.join(directory, branded))) fs.renameSync(path.join(directory, branded), path.join(directory, source));
+  }
   // Model an upstream source checkout, including when this suite runs in a packed branded bundle.
   for (const name of ['plugin.json', '.claude-plugin/plugin.json', '.codex-plugin/plugin.json']) {
     const file = path.join(directory, name);
@@ -57,9 +72,62 @@ test('a source checkout generates a complete, repeatable branded distribution',
   const brand = JSON.parse(fs.readFileSync(path.join(directory, 'rebrand/brand.json'), 'utf8'));
   assert.equal(pkg.version, brand.releaseVersion);
   assert.equal(fs.existsSync(path.join(directory, 'bin/i3-composer-agent.cjs')), true);
-  assert.equal(node(directory, 'scripts/validate-brand.cjs').status, 0);
+  const validation = node(directory, 'scripts/validate-brand.cjs');
+  assert.equal(validation.status, 0, validation.stdout + validation.stderr);
+  const complete = run(directory, 'npm', ['run', 'validate']);
+  assert.equal(complete.status, 0, complete.stdout + complete.stderr);
+  const routing = node(directory, 'scripts/run-evals.js', ['--min-rank1', '95']);
+  assert.equal(routing.status, 0, routing.stdout + routing.stderr);
+  const check = node(directory, 'rebrand/apply.cjs', ['--check']);
+  assert.equal(check.status, 0, check.stdout + check.stderr);
+});
+
+test('branded commands and skills use i3 identifiers with working local references', t => {
+  const directory = fixture(t);
+  record(directory);
+  apply(directory);
+  const skill = 'i3-spec-driven-development';
+  const file = path.join(directory, 'skills', skill, 'SKILL.md');
+  assert.ok(fs.existsSync(file), 'branded Skill directory must use i3-');
+  assert.match(fs.readFileSync(file, 'utf8'), /^name: i3-spec-driven-development$/m);
+  assert.equal(fs.existsSync(path.join(directory, 'skills/spec-driven-development')), false);
+  const command = fs.readFileSync(path.join(directory, '.claude/commands/i3-spec.md'), 'utf8');
+  assert.match(command, /i3-composer-agent:i3-spec-driven-development/);
+  assert.equal(fs.existsSync(path.join(directory, '.claude/commands/spec.md')), false);
+  const helper = 'skills/i3-idea-refine/scripts/idea-refine.sh';
+  assert.ok(fs.statSync(path.join(directory, helper)).mode & 0o111, 'helper execution permissions must survive renaming');
+  assert.ok(fs.readFileSync(path.join(directory, 'skills/i3-idea-refine/SKILL.md'), 'utf8').includes(helper), 'helper reference must resolve to its retained filename');
+  for (const commands of ['commands', '.gemini/commands']) {
+    assert.ok(fs.existsSync(path.join(directory, commands, 'i3-planning.toml')));
+  }
+  const hook = fs.readFileSync(path.join(directory, 'hooks/session-start.sh'), 'utf8');
+  assert.match(hook, /i3-using-agent-skills\/SKILL\.md/);
+  assert.equal(node(directory, 'scripts/validate-commands.js').status, 0);
+  const readme = fs.readFileSync(path.join(directory, 'README.md'), 'utf8');
+  assert.match(readme, /\/i3-spec/);
+  assert.match(readme, /skills\/i3-spec-driven-development\/SKILL\.md/);
   const check = node(directory, 'rebrand/apply.cjs', ['--check']);
   assert.equal(check.status, 0, check.stdout + check.stderr);
+  apply(directory);
+  assert.equal(fs.existsSync(path.join(directory, 'skills/i3-i3-spec-driven-development')), false);
+});
+
+test('generated native installer preserves references and migrates legacy identifiers safely', t => {
+  const directory = fixture(t);
+  record(directory);
+  apply(directory);
+  const result = run(directory, process.execPath, ['--test', 'tests/installer.test.cjs']);
+  assert.equal(result.status, 0, result.stdout + result.stderr);
+});
+
+test('identifier rewriting preserves upstream URLs and avoids repeated prefixes', () => {
+  const content = 'Use spec-driven-development and /spec. https://github.com/addyosmani/agent-skills/blob/main/skills/spec-driven-development/SKILL.md';
+  const expected = 'Use i3-spec-driven-development and /i3-spec. https://github.com/addyosmani/agent-skills/blob/main/skills/spec-driven-development/SKILL.md';
+  assert.equal(rewriteReferences(content), expected);
+  assert.equal(rewriteReferences(expected), expected);
+  assert.equal(rewriteReferences(expected, true), content);
+  assert.equal(rewriteReferences('Save specs/auth/spec.md; use .claude/commands/spec.md.'), 'Save specs/auth/spec.md; use .claude/commands/i3-spec.md.');
+  assert.equal(rewriteReferences('skills/idea-refine/scripts/idea-refine.sh'), 'skills/i3-idea-refine/scripts/idea-refine.sh');
 });
 
 test('brand fixes advance independently while preserving upstream provenance', t => {
@@ -132,9 +200,9 @@ test('missing files and altered skill identifiers fail preservation validation',
   const directory = fixture(t);
   record(directory);
   apply(directory);
-  const file = path.join(directory, 'skills/using-agent-skills/SKILL.md');
+  const file = path.join(directory, 'skills/i3-using-agent-skills/SKILL.md');
   const original = fs.readFileSync(file, 'utf8');
-  fs.writeFileSync(file, original.replace('name: using-agent-skills', 'name: renamed-meta-skill'));
+  fs.writeFileSync(file, original.replace('name: i3-using-agent-skills', 'name: renamed-meta-skill'));
   assert.notEqual(node(directory, 'scripts/validate-brand.cjs').status, 0);
   fs.writeFileSync(file, original);
   fs.rmSync(file);

package/references/accessibility-checklist.md

@@ -1,6 +1,6 @@
 # Accessibility Checklist
 
-Quick reference for WCAG 2.1 AA compliance. Use alongside the `frontend-ui-engineering` skill.
+Quick reference for WCAG 2.1 AA compliance. Use alongside the `i3-frontend-ui-engineering` skill.
 
 ## Table of Contents
 

package/references/definition-of-done.md

@@ -1,6 +1,6 @@
 # Definition of Done
 
-A standing, project-wide bar that every change must clear before it counts as done. Unlike acceptance criteria, which vary per task and answer "did we build the right thing?", the Definition of Done is the same every time and answers "is this finished to our standard?". Use it as the final gate in `planning-and-task-breakdown`, `incremental-implementation`, and `shipping-and-launch`.
+A standing, project-wide bar that every change must clear before it counts as done. Unlike acceptance criteria, which vary per task and answer "did we build the right thing?", the Definition of Done is the same every time and answers "is this finished to our standard?". Use it as the final gate in `i3-planning-and-task-breakdown`, `i3-incremental-implementation`, and `i3-shipping-and-launch`.
 
 ## Definition of Done vs. Acceptance Criteria
 
@@ -32,7 +32,7 @@ Apply this to every change before declaring it done.
 - [ ] Changes are scoped to the task; no unrelated refactors snuck in
 - [ ] Linting and formatting pass
 
-The depth behind these items lives in `code-review-and-quality` (the five-axis review) and `code-simplification` (reducing complexity without changing behavior).
+The depth behind these items lives in `i3-code-review-and-quality` (the five-axis review) and `i3-code-simplification` (reducing complexity without changing behavior).
 
 ### Integration
 - [ ] Change works with the rest of the system, not just in isolation
@@ -41,20 +41,20 @@ The depth behind these items lives in `code-review-and-quality` (the five-axis r
 
 ### Documentation
 - [ ] Public interfaces, APIs, and user-facing behavior are documented
-- [ ] Architectural decisions worth preserving are recorded (see `documentation-and-adrs`)
+- [ ] Architectural decisions worth preserving are recorded (see `i3-documentation-and-adrs`)
 - [ ] Documentation describes the current state in timeless language, not the change history
 
 ### Ship-readiness
-- [ ] Security implications reviewed for any untrusted input, auth, or data handling (see `security-and-hardening`)
-- [ ] Observability in place for new critical paths (logs, metrics, traces) (see `observability-and-instrumentation`)
-- [ ] Rollback path exists for anything risky (see `shipping-and-launch`)
+- [ ] Security implications reviewed for any untrusted input, auth, or data handling (see `i3-security-and-hardening`)
+- [ ] Observability in place for new critical paths (logs, metrics, traces) (see `i3-observability-and-instrumentation`)
+- [ ] Rollback path exists for anything risky (see `i3-shipping-and-launch`)
 - [ ] The human has reviewed and approved before merge or deploy
 
 ## How to Apply
 
 - **Per task**: confirm the Correctness and Quality sections before checking the task off.
 - **Per feature**: confirm Integration and Documentation before considering the feature complete.
-- **Per release**: the full checklist is the floor; `shipping-and-launch` adds the deploy-specific gates on top.
+- **Per release**: the full checklist is the floor; `i3-shipping-and-launch` adds the deploy-specific gates on top.
 
 Tailor the list to the project once, then reuse it unchanged. A Definition of Done that is renegotiated every sprint is not a Definition of Done.
 

package/references/observability-checklist.md

@@ -1,6 +1,6 @@
 # Observability Checklist
 
-Quick reference for instrumenting production code. Use alongside the `observability-and-instrumentation` skill.
+Quick reference for instrumenting production code. Use alongside the `i3-observability-and-instrumentation` skill.
 
 ## Table of Contents
 
@@ -28,7 +28,7 @@ Telemetry without a question is noise. Before instrumenting anything:
 - [ ] Correlation ID is propagated on every outbound call and async boundary (HTTP headers, queue metadata)
 - [ ] Any log stream written by more than one entry point (scheduler, replay endpoint, manual run) carries an entry-point field, set where the run starts and propagated alongside the correlation ID
 - [ ] Log levels are consistent: `error` = invariant broken, someone may act; `warn` = degraded but handled; `info` = significant business event; `debug` = off in production
-- [ ] No secrets, tokens, passwords, or unredacted PII in any log line (hard rule from `security-and-hardening`)
+- [ ] No secrets, tokens, passwords, or unredacted PII in any log line (hard rule from `i3-security-and-hardening`)
 - [ ] Fields are allowlisted — no whole request/response bodies, no auth headers
 - [ ] External service calls logged with metadata only: endpoint, status, latency, attempt count, sanitized identifiers
 - [ ] Actual log output spot-checked: structured fields, not `[object Object]`
@@ -89,4 +89,4 @@ Before a feature ships to production, all of the following are true:
 - [ ] A request can be traced across every service it touches
 - [ ] On-call knows where the runbooks are
 
-For launch-day monitoring sequence and rollback triggers, see the `shipping-and-launch` skill.
+For launch-day monitoring sequence and rollback triggers, see the `i3-shipping-and-launch` skill.

package/references/orchestration-patterns.md

@@ -32,12 +32,12 @@ user → code-reviewer → report → user
 A slash command that wraps one persona with the project's skills. Saves the user from re-explaining the workflow every time.
 
 ```
-/review → code-reviewer (with code-review-and-quality skill) → report
+/i3-review → code-reviewer (with i3-code-review-and-quality skill) → report
 ```
 
 **Use when:** the same single-persona invocation happens repeatedly with the same setup.
 
-**Examples in this repo:** `/review`, `/test`, `/code-simplify`.
+**Examples in this repo:** `/i3-review`, `/i3-test`, `/i3-code-simplify`.
 
 **Cost:** same as direct invocation. The slash command is just a saved prompt.
 
@@ -51,7 +51,7 @@ Multiple personas operate on the same input concurrently, each producing an inde
 
 ```
                     ┌─→ code-reviewer    ─┐
-/ship → fan out  ───┼─→ security-auditor ─┤→ merge → go/no-go + rollback
+/i3-ship → fan out  ───┼─→ security-auditor ─┤→ merge → go/no-go + rollback
                     └─→ test-engineer    ─┘
 ```
 
@@ -61,7 +61,7 @@ Multiple personas operate on the same input concurrently, each producing an inde
 - The merge step is small enough to stay in the main context
 - Wall-clock latency matters
 
-**Examples in this repo:** `/ship`.
+**Examples in this repo:** `/i3-ship`.
 
 **Cost:** N parallel sub-agent contexts + one merge turn. Higher than direct invocation, but faster wall-clock and produces better reports because each sub-agent stays focused on its single perspective.
 
@@ -80,7 +80,7 @@ If any answer is "no," fall back to direct invocation or a single-persona comman
 The user runs slash commands in a defined order, carrying context (or commit history) between them. There is no orchestrator agent — the user IS the orchestrator.
 
 ```
-user runs:  /spec  →  /plan  →  /build  →  /test  →  /review  →  /ship
+user runs:  /i3-spec  →  /i3-plan  →  /i3-build  →  /i3-test  →  /i3-review  →  /i3-ship
 ```
 
 **Use when:** the workflow has dependencies (each step needs the previous step's output) and human judgment between steps adds value.
@@ -134,7 +134,7 @@ Claude Code has two parallelism primitives. Pattern 3 (parallel fan-out with mer
 | Status | Stable | Experimental — requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` |
 | Cost | Lower | Higher — each teammate is a separate Claude instance |
 
-**The personas in this repo work in both modes.** When spawned as subagents (e.g. by `/ship`), they report findings to the main session. When spawned as teammates (`Spawn a teammate using the security-auditor agent type…`), they can challenge each other's findings directly. The persona definition is the same; only the spawning context changes.
+**The personas in this repo work in both modes.** When spawned as subagents (e.g. by `/i3-ship`), they report findings to the main session. When spawned as teammates (`Spawn a teammate using the security-auditor agent type…`), they can challenge each other's findings directly. The persona definition is the same; only the spawning context changes.
 
 One subtlety: the `skills` and `mcpServers` frontmatter fields in a persona are honored when it runs as a subagent but **ignored when it runs as a teammate** — teammates load skills and MCP servers from your project and user settings, the same as a regular session. If a persona depends on a specific skill or MCP server being loaded, configure it at the session level so it's available in both modes.
 
@@ -167,13 +167,13 @@ The fields that DO work in plugin agents are: `name`, `description`, `tools`, `d
 
 ### Spawning multiple subagents in parallel
 
-In Claude Code, parallel fan-out (Pattern 3) requires issuing **multiple Agent tool calls in a single assistant turn**. Sequential turns serialize execution. `/ship` calls this out explicitly. Any new orchestrator command should do the same.
+In Claude Code, parallel fan-out (Pattern 3) requires issuing **multiple Agent tool calls in a single assistant turn**. Sequential turns serialize execution. `/i3-ship` calls this out explicitly. Any new orchestrator command should do the same.
 
 ---
 
 ## Worked example: Agent Teams for competing-hypothesis debugging
 
-This example shows when to reach for **Agent Teams** instead of `/ship`'s subagent fan-out. The two patterns look similar from a distance — both spawn the same three personas — but the value comes from a different place.
+This example shows when to reach for **Agent Teams** instead of `/i3-ship`'s subagent fan-out. The two patterns look similar from a distance — both spawn the same three personas — but the value comes from a different place.
 
 ### The scenario
 
@@ -186,19 +186,19 @@ Plausible root causes (mutually exclusive, all fit the symptoms):
 3. A missing index on a query that scales with cart size
 4. A flaky third-party API where the SDK retries silently before timing out
 
-A single agent will pick the first plausible theory and stop investigating. A `/ship`-style subagent fan-out would have each persona report independently — but their reports never meet, so nothing rules out the wrong theories.
+A single agent will pick the first plausible theory and stop investigating. A `/i3-ship`-style subagent fan-out would have each persona report independently — but their reports never meet, so nothing rules out the wrong theories.
 
 This is exactly the case the Agent Teams docs describe: *"With multiple independent investigators actively trying to disprove each other, the theory that survives is much more likely to be the actual root cause."*
 
-### Why this is *not* a `/ship` job
+### Why this is *not* a `/i3-ship` job
 
-| | `/ship` (subagents) | Agent Teams |
+| | `/i3-ship` (subagents) | Agent Teams |
 |--|--------------------|-------------|
 | Sub-agents see | The same diff, different lenses | A shared task list, each other's messages |
 | Output | Three independent reports → one merge | Adversarial debate → consensus root cause |
 | Right when | You want a verdict on a known artifact | You want to *find* the artifact among hypotheses |
 
-`/ship` is a verdict; Agent Teams is an investigation.
+`/i3-ship` is a verdict; Agent Teams is an investigation.
 
 ### Setup (one-time, per-environment)
 
@@ -262,7 +262,7 @@ Always cleanup through the lead, not a teammate (per the docs: teammates lack fu
 
 ### Cost expectation
 
-Three Sonnet teammates running for ~10–15 minutes of investigation costs noticeably more than the same three personas spawned as subagents by `/ship`. The justification is *quality of conclusion* — for production debugging where the wrong fix is expensive, the extra tokens are a bargain. For a routine PR review, stick with `/ship`.
+Three Sonnet teammates running for ~10–15 minutes of investigation costs noticeably more than the same three personas spawned as subagents by `/i3-ship`. The justification is *quality of conclusion* — for production debugging where the wrong fix is expensive, the extra tokens are a bargain. For a routine PR review, stick with `/i3-ship`.
 
 ### Anti-pattern in this scenario
 
@@ -270,7 +270,7 @@ Do **not** rebuild this as a `/debug` slash command that fans out subagents. Sub
 
 ### When *not* to use Agent Teams
 
-- Production-bound verdict on a known diff → use `/ship` (subagents).
+- Production-bound verdict on a known diff → use `/i3-ship` (subagents).
 - One specialist perspective on one artifact → direct persona invocation.
 - Sequential lifecycle (spec → plan → build) → user-driven slash commands (Pattern 4).
 - Read-heavy research with a small digest → built-in `Explore` subagent.
@@ -292,7 +292,7 @@ A persona whose job is to decide which other persona to call.
 **Why it fails:**
 - Pure routing layer with no domain value
 - Adds two paraphrasing hops → information loss + roughly 2× token cost
-- The user already knew they wanted a review; they could have called `/review` directly
+- The user already knew they wanted a review; they could have called `/i3-review` directly
 - Replicates the work that slash commands and intent mapping in `AGENTS.md` already do
 
 **What to do instead:** add or refine slash commands. Document intent → command mapping in `AGENTS.md`.
@@ -315,7 +315,7 @@ A `code-reviewer` that internally invokes `security-auditor` when it sees auth c
 
 ### C. Sequential orchestrator that paraphrases
 
-An agent that calls `/spec`, then `/plan`, then `/build`, etc. on the user's behalf.
+An agent that calls `/i3-spec`, then `/i3-plan`, then `/i3-build`, etc. on the user's behalf.
 
 **Why it fails:**
 - Loses the human checkpoints that catch wrong-direction work
@@ -329,7 +329,7 @@ An agent that calls `/spec`, then `/plan`, then `/build`, etc. on the user's beh
 
 ### D. Deep persona trees
 
-`/ship` calls a `pre-ship-coordinator` that calls a `quality-coordinator` that calls `code-reviewer`.
+`/i3-ship` calls a `pre-ship-coordinator` that calls a `quality-coordinator` that calls `code-reviewer`.
 
 **Why it fails:**
 - Each layer adds latency and tokens with no decision value

package/references/performance-checklist.md

@@ -1,6 +1,6 @@
 # Performance Checklist
 
-Quick reference checklist for web application performance. Use alongside the `performance-optimization` skill.
+Quick reference checklist for web application performance. Use alongside the `i3-performance-optimization` skill.
 
 ## Table of Contents
 
@@ -132,7 +132,7 @@ When TTFB is slow (> 800ms), check each component in DevTools Network waterfall:
 
 ## Caching Strategies
 
-The decision material (which layer, which invalidation strategy, what never to cache) lives in the `performance-optimization` skill. This section covers the read/write patterns and the checklist.
+The decision material (which layer, which invalidation strategy, what never to cache) lives in the `i3-performance-optimization` skill. This section covers the read/write patterns and the checklist.
 
 ### Read and write patterns
 

package/references/security-checklist.md

@@ -1,6 +1,6 @@
 # Security Checklist
 
-Quick reference for web application security. Use alongside the `security-and-hardening` skill.
+Quick reference for web application security. Use alongside the `i3-security-and-hardening` skill.
 
 ## Table of Contents
 

package/references/testing-patterns.md

@@ -1,6 +1,6 @@
 # Testing Patterns Reference (JavaScript/TypeScript)
 
-Quick reference of JavaScript/TypeScript testing patterns — Jest, React Testing Library, Supertest, and Playwright — illustrating the universal principles from the `test-driven-development` skill. The principles (Arrange-Act-Assert, naming, mock discipline, anti-patterns) apply in any ecosystem; the syntax and tooling shown here are JS/TS-specific. In another stack, follow the same principles with the repository's own test framework and commands.
+Quick reference of JavaScript/TypeScript testing patterns — Jest, React Testing Library, Supertest, and Playwright — illustrating the universal principles from the `i3-test-driven-development` skill. The principles (Arrange-Act-Assert, naming, mock discipline, anti-patterns) apply in any ecosystem; the syntax and tooling shown here are JS/TS-specific. In another stack, follow the same principles with the repository's own test framework and commands.
 
 ## Table of Contents
 

package/scripts/floor-guard-reference-test.js

@@ -2,7 +2,7 @@
 
 'use strict';
 
-// Contract test for skills/constraint-driven-development/references/floor-guard.md.
+// Contract test for skills/i3-constraint-driven-development/references/floor-guard.md.
 // The fenced `js` block is extracted unchanged and run, with real git, against small
 // fixtures: each is a fresh repository with one source file, one test file and a
 // CONSTRAINTS.md carrying a floor bullet, a coverage minimum, a bundle maximum and an
@@ -16,7 +16,7 @@ const { spawnSync } = require('node:child_process');
 const { after, before, test } = require('node:test');
 
 const REFERENCE = path.join(
-  __dirname, '..', 'skills', 'constraint-driven-development', 'references', 'floor-guard.md',
+  __dirname, '..', 'skills', 'i3-constraint-driven-development', 'references', 'floor-guard.md',
 );
 const CONSTRAINTS = [
   '# Constraints',

package/scripts/lib/skill-lint.js

@@ -85,6 +85,8 @@ const REQUIRED_SECTIONS = [
 // cannot bypass the validator by editing their own skill file.
 // Every entry must have a documented reason.
 const SECTION_EXEMPT_SKILLS = {
+  'i3-using-agent-skills': 'Branded alias of the reviewed upstream meta-skill.',
+  'i3-idea-refine': 'Branded alias of the reviewed upstream legacy structure.',
   'using-agent-skills': 'Meta-skill — orchestrates other skills; When-to-Use and Verification are not applicable to a routing document.',
   'idea-refine':        'Legacy structure predating skill-anatomy.md — uses How-It-Works/Usage/Anti-patterns instead of standard headings. Tracked for conformance in https://github.com/addyosmani/agent-skills/issues',
 };

package/scripts/run-evals-test.js

@@ -608,13 +608,13 @@ test('accepted grading omits run key when no metadata is provided', () => {
 });
 
 test('materializes a git baseline and applies a working-tree patch', () => {
-  const workspace = materializeWorkspace({ files: ['git-workflow-and-versioning'] });
+  const workspace = materializeWorkspace({ files: ['i3-git-workflow-and-versioning'] });
   try {
     const status = spawnSync('git', ['status', '--short'], { cwd: workspace, encoding: 'utf8' });
     const commits = spawnSync('git', ['rev-list', '--count', 'HEAD'], { cwd: workspace, encoding: 'utf8' });
 
     assert.equal(status.status, 0, status.stdout + status.stderr);
-    assert.match(status.stdout, / M git-workflow-and-versioning\/app\.js/);
+    assert.match(status.stdout, / M i3-git-workflow-and-versioning\/app\.js/);
     assert.equal(commits.stdout.trim(), '1');
     assert.equal(fs.existsSync(path.join(workspace, '.eval')), false);
   } finally {

package/scripts/validate-artifact-paths-test.js

@@ -45,8 +45,8 @@ test('passes when producers and consumers use the canonical artifact paths', ()
   writeFile(root, '.claude/commands/spec.md', 'Save the spec as `SPEC.md` in the project root.\n');
   writeFile(root, '.claude/commands/plan.md', 'Save the plan to `tasks/plan.md` and task list to `tasks/todo.md`.\n');
   writeFile(root, '.claude/commands/build.md', 'Look for a spec at `SPEC.md`, `docs/SPEC.md`, or under `spec/`. Require `tasks/plan.md`.\n');
-  writeFile(root, 'skills/spec-driven-development/SKILL.md', 'Save the plan to `tasks/plan.md` and the task list to `tasks/todo.md`.\n');
-  writeFile(root, 'skills/planning-and-task-breakdown/SKILL.md', 'Save to `tasks/plan.md` and `tasks/todo.md`.\n');
+  writeFile(root, 'skills/i3-spec-driven-development/SKILL.md', 'Save the plan to `tasks/plan.md` and the task list to `tasks/todo.md`.\n');
+  writeFile(root, 'skills/i3-planning-and-task-breakdown/SKILL.md', 'Save to `tasks/plan.md` and `tasks/todo.md`.\n');
 
   const result = run(root);
 
@@ -94,7 +94,7 @@ test('ignores non-artifact markdown references (no false positives)', () => {
   const root = makeSandbox();
   writeFile(
     root,
-    'skills/spec-driven-development/SKILL.md',
+    'skills/i3-spec-driven-development/SKILL.md',
     'See `SKILL.md` and `references/testing-patterns.md`. Save the plan to `tasks/plan.md`.\n',
   );
 

package/scripts/validate-artifact-paths.js

@@ -60,8 +60,8 @@ const GUARDED_FILES = [
   'commands/planning.toml',
   'commands/build.toml',
   // Skills the commands invoke
-  'skills/spec-driven-development/SKILL.md',
-  'skills/planning-and-task-breakdown/SKILL.md',
+  'skills/i3-spec-driven-development/SKILL.md',
+  'skills/i3-planning-and-task-breakdown/SKILL.md',
   // Docs that tell users where the artifacts live
   'docs/getting-started.md',
   'docs/adoption-guide.md',
@@ -74,6 +74,8 @@ const GUARDED_FILES = [
 // drifted spec.md are both caught, then compared against the allowlist.
 const ARTIFACT_RE = /(?:[A-Za-z0-9._[\]-]+\/)*(?:spec|plan|todo)\.md/gi;
 
+GUARDED_FILES.push(...GUARDED_FILES.filter(relative => /(?:^|\/)commands\//.test(relative)).map(relative => relative.replace(/(commands\/)([^/]+)(\.md|\.toml)$/, '$1i3-$2$3')));
+
 function findViolations(relPath) {
   const abs = path.join(ROOT, relPath);
   if (!fs.existsSync(abs)) return null; // skipped

package/scripts/validate-brand.cjs

@@ -9,7 +9,7 @@ const brand = require('../rebrand/brand.json');
 const pkg = require('../package.json');
 const upstream = require('../rebrand/upstream.json');
 const { validateCatalog } = require('../rebrand/catalog.cjs');
-validateCatalog(root, upstream);
+validateCatalog(root, upstream, { branded: true });
 function json(relative) { return JSON.parse(fs.readFileSync(path.join(root, relative), 'utf8')); }
 assert.equal(pkg.name, brand.npmName);
 assert.equal(pkg.version, brand.releaseVersion);
@@ -31,13 +31,13 @@ for (const relative of ['.claude-plugin/marketplace.json', '.agents/plugins/mark
 assert.ok(json('.codex-plugin/plugin.json').interface.shortDescription.length <= 30);
 const skills = fs.readdirSync(path.join(root, 'skills')).filter(name => fs.existsSync(path.join(root, 'skills', name, 'SKILL.md')));
 assert.equal(skills.length, upstream.skills.length, 'brand conversion must preserve the reviewed upstream skills');
-assert.ok(skills.includes('using-agent-skills'), 'meta-skill ID must remain stable');
+assert.ok(skills.includes('i3-using-agent-skills'), 'meta-skill ID must use the branded prefix');
 const commands = fs.readdirSync(path.join(root, '.claude/commands')).filter(name => name.endsWith('.md'));
 assert.equal(commands.length, upstream.commands.length, 'brand conversion must preserve the reviewed upstream commands');
 for (const command of commands) {
   const body = fs.readFileSync(path.join(root, '.claude/commands', command), 'utf8');
   assert.ok(!body.includes('agent-skills:'), `${command}: stale plugin namespace`);
-  for (const match of body.matchAll(/i3-composer-agent:([a-z-]+)/g)) assert.ok(skills.includes(match[1]), `${command}: unknown skill ${match[1]}`);
+  for (const match of body.matchAll(/(?<!\/)i3-composer-agent:([a-z0-9-]+)/g)) assert.ok(skills.includes(match[1]), `${command}: unknown skill ${match[1]}`);
 }
 for (const relative of pkg.i3ComposerAgent.pluginFiles) assert.ok(fs.existsSync(path.join(root, relative)), `bundle is missing ${relative}`);
 assert.match(fs.readFileSync(path.join(root, 'LICENSE'), 'utf8'), /Copyright \(c\) 2025 Addy Osmani/);

package/scripts/validate-commands.js

@@ -46,6 +46,7 @@ const DIRS = {
 // Key = Claude stem, value = TOML stem.
 const NAME_MAP = {
   plan: 'planning',
+  'i3-plan': 'i3-planning',
 };
 const NAME_MAP_REVERSE = Object.fromEntries(
   Object.entries(NAME_MAP).map(([k, v]) => [v, k])