@givolt/i3-composer-agent 1.0.1 → 2.0.0

package/scripts/validate-reference-links-test.js

@@ -47,7 +47,7 @@ test('passes when a skill reaches the shared checklist two levels up', () => {
   writeFile(root, 'references/definition-of-done.md', '# Definition of Done\n');
   writeFile(
     root,
-    'skills/using-agent-skills/SKILL.md',
+    'skills/i3-using-agent-skills/SKILL.md',
     'See `../../references/definition-of-done.md`.\n'
   );
 
@@ -64,7 +64,7 @@ test('fails when a skill links the shared checklist as if it were colocated', ()
   writeFile(root, 'references/definition-of-done.md', '# Definition of Done\n');
   writeFile(
     root,
-    'skills/using-agent-skills/SKILL.md',
+    'skills/i3-using-agent-skills/SKILL.md',
     'See `references/definition-of-done.md`.\n'
   );
 
@@ -74,7 +74,7 @@ test('fails when a skill links the shared checklist as if it were colocated', ()
   assert.match(result.stdout, /1 skills checked — 1 error\(s\) — FAILED/);
   assert.match(
     result.stdout,
-    /L1: references\/definition-of-done\.md — resolves to skills\/using-agent-skills\/references\/definition-of-done\.md/
+    /L1: references\/definition-of-done\.md — resolves to skills\/i3-using-agent-skills\/references\/definition-of-done\.md/
   );
   assert.match(result.stdout, /use `\.\.\/\.\.\/references\/<file>\.md`/);
 });
@@ -82,7 +82,7 @@ test('fails when a skill links the shared checklist as if it were colocated', ()
 test('checks markdown link syntax, not just backtick mentions', () => {
   const root = makeSandbox();
   writeFile(root, 'references/definition-of-done.md', '# Definition of Done\n');
-  writeFile(root, 'skills/using-agent-skills/SKILL.md', 'See [DoD](references/definition-of-done.md).\n');
+  writeFile(root, 'skills/i3-using-agent-skills/SKILL.md', 'See [DoD](references/definition-of-done.md).\n');
 
   const result = run(root);
 
@@ -193,7 +193,7 @@ test('counts errors from SKILL.md and its reference files together', () => {
 test('fails when a link points at a checklist that no longer exists', () => {
   const root = makeSandbox();
   writeFile(root, 'references/definition-of-done.md', '# Definition of Done\n');
-  writeFile(root, 'skills/shipping-and-launch/SKILL.md', 'See `../../references/renamed.md`.\n');
+  writeFile(root, 'skills/i3-shipping-and-launch/SKILL.md', 'See `../../references/renamed.md`.\n');
 
   const result = run(root);
 
@@ -209,11 +209,11 @@ test('ignores paths that are not references/ links', () => {
   writeFile(root, 'references/definition-of-done.md', '# Definition of Done\n');
   writeFile(
     root,
-    'skills/planning-and-task-breakdown/SKILL.md',
+    'skills/i3-planning-and-task-breakdown/SKILL.md',
     [
       'Save the task list to `tasks/todo.md` and the plan to `tasks/plan.md`.',
       'Record findings in `PERF.md` or `docs/ideas/[idea-name].md`.',
-      'Related: `skills/incremental-implementation/SKILL.md`.',
+      'Related: `skills/i3-incremental-implementation/SKILL.md`.',
       'See `../../references/definition-of-done.md`.',
       '',
     ].join('\n')
@@ -231,7 +231,7 @@ test('reports every unresolvable link, not just the first per skill', () => {
   writeFile(root, 'references/performance-checklist.md', '# Performance\n');
   writeFile(
     root,
-    'skills/code-review-and-quality/SKILL.md',
+    'skills/i3-code-review-and-quality/SKILL.md',
     ['See `references/security-checklist.md`.', 'And `references/performance-checklist.md`.', ''].join('\n')
   );
 
@@ -246,7 +246,7 @@ test('a link inside a fenced block is an example, not a link to resolve', () =>
   writeFile(root, 'references/definition-of-done.md', '# DoD\n');
   writeFile(
     root,
-    'skills/using-agent-skills/SKILL.md',
+    'skills/i3-using-agent-skills/SKILL.md',
     [
       'Shared checklists live two levels up:',
       '',
@@ -271,7 +271,7 @@ test('fence exemption follows CommonMark rather than a bare ``` match', () => {
   const root = makeSandbox();
   writeFile(
     root,
-    'skills/using-agent-skills/SKILL.md',
+    'skills/i3-using-agent-skills/SKILL.md',
     [
       '~~~markdown',
       '[a](references/missing-a.md)',
@@ -296,7 +296,7 @@ test('a real broken link outside any fence is still reported', () => {
   const root = makeSandbox();
   writeFile(
     root,
-    'skills/using-agent-skills/SKILL.md',
+    'skills/i3-using-agent-skills/SKILL.md',
     [
       '```markdown',
       '[shown as an example](references/example-only.md)',

package/scripts/validate-reference-links.js

@@ -9,7 +9,7 @@
  * the skill's own directory, which is two levels below the root. All 18 links
  * across 11 skills resolved to files that do not exist, in the repo and in
  * every plugin-install layout (~/.claude/plugins/cache/..., ~/.codex/...).
- * Agents that followed the guidance — for example using-agent-skills pointing
+ * Agents that followed the guidance — for example i3-using-agent-skills pointing
  * at the Definition of Done — hit a file-not-found and stalled.
  *
  * Nothing else in CI catches this: validate-artifact-paths.js is scoped to

package/skills/{api-and-interface-design → i3-api-and-interface-design}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: api-and-interface-design
+name: i3-api-and-interface-design
 description: 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.
 ---
 
@@ -27,7 +27,7 @@ This means: every public behavior — including undocumented quirks, error messa
 
 - **Be intentional about what you expose.** Every observable behavior is a potential commitment.
 - **Don't leak implementation details.** If users can observe it, they will depend on it.
-- **Plan for deprecation at design time.** See `deprecation-and-migration` for how to safely remove things users depend on.
+- **Plan for deprecation at design time.** See `i3-deprecation-and-migration` for how to safely remove things users depend on.
 - **Tests are not enough.** Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
 
 ### The One-Version Rule

package/skills/{browser-testing-with-devtools → i3-browser-testing-with-devtools}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: browser-testing-with-devtools
+name: i3-browser-testing-with-devtools
 description: 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.
 ---
 

package/skills/{ci-cd-and-automation → i3-ci-cd-and-automation}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: ci-cd-and-automation
+name: i3-ci-cd-and-automation
 description: 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.
 ---
 
@@ -186,7 +186,7 @@ Agent fixes → pushes → CI runs again
 ```
 Lint failure → Agent runs `npm run lint --fix` and commits
 Type error  → Agent reads the error location and fixes the type
-Test failure → Agent follows debugging-and-error-recovery skill
+Test failure → Agent follows i3-debugging-and-error-recovery skill
 Build error → Agent checks config and dependencies
 ```
 

package/skills/{code-review-and-quality → i3-code-review-and-quality}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: code-review-and-quality
+name: i3-code-review-and-quality
 description: 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.
 ---
 
@@ -63,7 +63,7 @@ Does the change fit the system's design?
 
 ### 4. Security
 
-For detailed security guidance, see `security-and-hardening`. Does the change introduce vulnerabilities?
+For detailed security guidance, see `i3-security-and-hardening`. Does the change introduce vulnerabilities?
 
 - Is user input validated and sanitized?
 - Are secrets kept out of code, logs, and version control?
@@ -76,7 +76,7 @@ For detailed security guidance, see `security-and-hardening`. Does the change in
 
 ### 5. Performance
 
-For detailed profiling and optimization, see `performance-optimization`. Does the change introduce performance problems?
+For detailed profiling and optimization, see `i3-performance-optimization`. Does the change introduce performance problems?
 
 - Any N+1 query patterns?
 - Any unbounded loops or unconstrained data fetching?
@@ -161,7 +161,7 @@ Tests reveal intent and coverage:
 - Would the tests catch a regression if the code changed?
 ```
 
-Answer the last question by experiment, not by reading. Invert one condition the change adds (drop a negation, swap `&&` for `||`), run the suite, then restore the file from a copy. A mutation that stays green is a finding: name the test case that is missing. For a project-wide mutation score, see `constraint-driven-development`.
+Answer the last question by experiment, not by reading. Invert one condition the change adds (drop a negation, swap `&&` for `||`), run the suite, then restore the file from a copy. A mutation that stays green is a finding: name the test case that is missing. For a project-wide mutation score, see `i3-constraint-driven-development`.
 
 ### Step 3: Review the Implementation
 
@@ -299,7 +299,7 @@ Part of code review is dependency review:
 4. **Mind the transitive graph.** Most installed packages are ones nobody chose directly. Review the lockfile diff, not just `package.json`; a single direct bump can pull in dozens of indirect changes.
 5. **Keep the lockfile honest.** Commit it, review its diff, and never hand-edit it. The lockfile is the thing that actually pins what ships.
 
-For triaging `npm audit` findings and supply-chain risk (typosquatting, compromised maintainers), follow the `security-and-hardening` skill — this section covers the upgrade *workflow*, that one covers the security verdict.
+For triaging `npm audit` findings and supply-chain risk (typosquatting, compromised maintainers), follow the `i3-security-and-hardening` skill — this section covers the upgrade *workflow*, that one covers the security verdict.
 
 ## The Review Checklist
 

package/skills/{code-simplification → i3-code-simplification}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: code-simplification
+name: i3-code-simplification
 description: 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.
 ---
 

package/skills/{constraint-driven-development → i3-constraint-driven-development}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: constraint-driven-development
+name: i3-constraint-driven-development
 description: 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.
 ---
 
@@ -7,7 +7,7 @@ description: Establishes a project's quality bar as a written contract and stops
 
 ## Overview
 
-Other skills in this pack describe what good looks like. `code-review-and-quality` gives you five axes. `test-driven-development` gives you a cycle. `security-and-hardening` gives you a threat list. All of that lives in prose the agent reads and may or may not follow, and none of it survives the end of the session.
+Other skills in this pack describe what good looks like. `i3-code-review-and-quality` gives you five axes. `i3-test-driven-development` gives you a cycle. `i3-security-and-hardening` gives you a threat list. All of that lives in prose the agent reads and may or may not follow, and none of it survives the end of the session.
 
 This skill produces something different: a written record of **this project's** bar, with numbers, that outlives the conversation and can be checked mechanically.
 
@@ -24,13 +24,13 @@ Apply this skill when:
 - An agent is producing volume nobody is reading line by line
 - CI has checks but nobody can say which ones block a merge and which ones are decoration
 - Coverage, performance, or accessibility numbers get argued about per-PR instead of decided once
-- You're about to run `/build auto` or any autonomous loop, and the only thing standing between it and main is a test suite the agent also wrote
+- You're about to run `/i3-build auto` or any autonomous loop, and the only thing standing between it and main is a test suite the agent also wrote
 
 **When NOT to use:**
 
 - The project already has a `CONSTRAINTS.md` and the user isn't changing it — read it and follow it instead
 - One-off scripts, spikes, throwaway prototypes
-- The user wants a code review right now (`code-review-and-quality`) or a CI pipeline built (`ci-cd-and-automation`)
+- The user wants a code review right now (`i3-code-review-and-quality`) or a CI pipeline built (`i3-ci-cd-and-automation`)
 - Pre-product-market-fit code with a two-week expected lifetime — the floor below is still worth it, the rest isn't
 
 ## Loading Constraints
@@ -56,7 +56,7 @@ Report what you found in two lines, then ask only what's left.
 
 ### Step 2: Four questions, each with a default
 
-Follow the one-question-at-a-time discipline from `interview-me`, with one change: every question here has a default, so "I don't know" is a complete answer that still produces a working config.
+Follow the one-question-at-a-time discipline from `i3-interview-me`, with one change: every question here has a default, so "I don't know" is a complete answer that still produces a working config.
 
 ```
 Q1: Beyond the floor, which of these do you want enforced?
@@ -189,10 +189,10 @@ The single biggest mistake is running everything everywhere. A check that stalls
 
 | Phase | Command | What runs | Budget |
 |-------|---------|-----------|--------|
-| BUILD | `/build` | Types, lint, secrets, the floor | under 5s, changed file only |
-| VERIFY | `/test` | Related tests, coverage on changed lines | under 90s |
-| REVIEW | `/review` | Everything, plus the guards below | minutes |
-| SHIP | `/ship` | Direction checks, no regressions | CI |
+| BUILD | `/i3-build` | Types, lint, secrets, the floor | under 5s, changed file only |
+| VERIFY | `/i3-test` | Related tests, coverage on changed lines | under 90s |
+| REVIEW | `/i3-review` | Everything, plus the guards below | minutes |
+| SHIP | `/i3-ship` | Direction checks, no regressions | CI |
 
 Two rules that keep this tolerable:
 
@@ -303,9 +303,9 @@ The skill was applied correctly when:
 
 ## See Also
 
-- `interview-me` — the one-question-at-a-time discipline this skill's intake borrows
-- `code-review-and-quality` — how to review; this skill decides what the review enforces
-- `ci-cd-and-automation` — building the pipeline these constraints run in
-- `test-driven-development` — the suite that coverage and mutation constraints measure
-- `security-and-hardening` — what the security dimension should contain
-- `performance-optimization` — where the performance numbers come from
+- `i3-interview-me` — the one-question-at-a-time discipline this skill's intake borrows
+- `i3-code-review-and-quality` — how to review; this skill decides what the review enforces
+- `i3-ci-cd-and-automation` — building the pipeline these constraints run in
+- `i3-test-driven-development` — the suite that coverage and mutation constraints measure
+- `i3-security-and-hardening` — what the security dimension should contain
+- `i3-performance-optimization` — where the performance numbers come from

package/skills/{context-engineering → i3-context-engineering}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: context-engineering
+name: i3-context-engineering
 description: 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.
 ---
 

package/skills/{debugging-and-error-recovery → i3-debugging-and-error-recovery}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: debugging-and-error-recovery
+name: i3-debugging-and-error-recovery
 description: 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.
 ---
 
@@ -72,7 +72,7 @@ Cannot reproduce on demand:
     └── Document the conditions observed and revisit when it recurs
 ```
 
-For test failures (npm shown — substitute the repository's own test command, per the test-driven-development skill's Discover the Stack First section):
+For test failures (npm shown — substitute the repository's own test command, per the i3-test-driven-development skill's Discover the Stack First section):
 ```bash
 # Run the specific failing test
 npm test -- --grep "test name"

package/skills/{deprecation-and-migration → i3-deprecation-and-migration}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: deprecation-and-migration
+name: i3-deprecation-and-migration
 description: 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.
 ---
 
@@ -180,7 +180,7 @@ the old one            the app                  a later, separate deploy
 4. **Switch reads.** Point the app at `full_name`, keep writing both. Deploy and bake.
 5. **Contract.** Stop writing `name`, then — in a *separate, later* deploy — drop the column.
 
-Each step is independently deployable and reversible: if step 4 misbehaves, roll the code back and `full_name` is still being populated. Treat each phase as a thin vertical slice — see the `incremental-implementation` skill.
+Each step is independently deployable and reversible: if step 4 misbehaves, roll the code back and `full_name` is still being populated. Treat each phase as a thin vertical slice — see the `i3-incremental-implementation` skill.
 
 **Rules:**
 - **Additive first, destructive last and alone.** Adds (new nullable column, new table, new index) are safe in any deploy; drops and renames get their own deploy *after* no code references the old shape.

package/skills/{documentation-and-adrs → i3-documentation-and-adrs}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: documentation-and-adrs
+name: i3-documentation-and-adrs
 description: 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.
 ---
 

package/skills/{doubt-driven-development → i3-doubt-driven-development}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: doubt-driven-development
+name: i3-doubt-driven-development
 description: 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.
 ---
 
@@ -9,7 +9,7 @@ description: Subjects every non-trivial decision to a fresh-context adversarial
 
 A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to **disprove**, not approve — before any non-trivial output stands.
 
-This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
+This is not `/i3-review`. `/i3-review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
 
 ## When to Use
 
@@ -197,7 +197,7 @@ If 3 cycles is "obviously insufficient" because the artifact is large: the artif
 | "I'm confident, skip the doubt step" | Confidence correlates poorly with correctness on novel problems. Moments of certainty are exactly when blind spots hide. |
 | "Spawning a reviewer is expensive" | Debugging a wrong commit in production is more expensive. The check is bounded; the bug isn't. |
 | "The reviewer will just nitpick" | Only if unscoped. Constrain the prompt to "issues that would make this fail under the contract." |
-| "I'll do doubt at the end with `/review`" | `/review` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |
+| "I'll do doubt at the end with `/i3-review`" | `/i3-review` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |
 | "If I doubt every step I'll never ship" | The skill applies to non-trivial decisions, not every keystroke. Re-read "When NOT to Use." |
 | "Two opinions are always better than one" | Not when the second has less context and produces noise. Reconcile, don't defer. |
 | "The reviewer disagreed so I was wrong" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |
@@ -213,7 +213,7 @@ If 3 cycles is "obviously insufficient" because the artifact is large: the artif
 - Skipping doubt under time pressure on a high-stakes decision
 - Re-spawning fresh-context on an unchanged artifact (you'll get the same findings; you're stalling)
 - **Doubt theater (checkable signal)**: across 2 or more cycles where the reviewer surfaced substantive findings, zero findings were classified as actionable. You are validating, not doubting. Stop and escalate.
-- Doubting only after committing — that's `/review`, not doubt-driven development
+- Doubting only after committing — that's `/i3-review`, not doubt-driven development
 - Hardcoding an external CLI invocation without confirming with the user that the tool exists, is configured, and accepts that exact syntax
 - **Silently skipping cross-model in an interactive doubt cycle.** Even when not recommending it, the offer must be visible. Skipping is fine; silent skipping is not.
 - Falling back silently when an external CLI errors or is missing — surface the failure and let the user redirect
@@ -222,10 +222,10 @@ If 3 cycles is "obviously insufficient" because the artifact is large: the artif
 
 ## Interaction with Other Skills
 
-- **`code-review-and-quality` / `/review`**: complementary. `/review` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.
-- **`source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.
-- **`test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.
-- **`debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.
+- **`i3-code-review-and-quality` / `/i3-review`**: complementary. `/i3-review` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.
+- **`i3-source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.
+- **`i3-test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.
+- **`i3-debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.
 - **Repo orchestration rules** (`../../references/orchestration-patterns.md`): this skill orchestrates from the main session. A persona calling another persona is anti-pattern B — see Loading Constraints above.
 
 ## Verification

package/skills/{frontend-ui-engineering → i3-frontend-ui-engineering}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: frontend-ui-engineering
+name: i3-frontend-ui-engineering
 description: 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.
 ---
 

package/skills/{git-workflow-and-versioning → i3-git-workflow-and-versioning}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: git-workflow-and-versioning
+name: i3-git-workflow-and-versioning
 description: 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.
 ---
 
@@ -110,7 +110,7 @@ git commit -m "refactor validation and add phone number field"
 
 ### 5. Size Your Changes
 
-Target ~100 lines per commit/PR. Changes over ~1000 lines should be split. See the splitting strategies in `code-review-and-quality` for how to break down large changes.
+Target ~100 lines per commit/PR. Changes over ~1000 lines should be split. See the splitting strategies in `i3-code-review-and-quality` for how to break down large changes.
 
 ```
 ~100 lines  → Easy to review, easy to revert
@@ -281,7 +281,7 @@ For anything with consumers, version `MAJOR.MINOR.PATCH` and let the number carr
   PATCH  bug fix, backward-compatible — safe to upgrade
 ```
 
-The number is a promise, so make the code match it. A "patch" that changes behavior consumers relied on is a major change wearing a disguise (Hyrum's Law — see the `api-and-interface-design` skill). When unsure whether a change is breaking, assume it is; a surprise major is far cheaper than a broken consumer.
+The number is a promise, so make the code match it. A "patch" that changes behavior consumers relied on is a major change wearing a disguise (Hyrum's Law — see the `i3-api-and-interface-design` skill). When unsure whether a change is breaking, assume it is; a surprise major is far cheaper than a broken consumer.
 
 ### Tag the release, and let the tag be the source of truth
 
@@ -308,7 +308,7 @@ A changelog is not `git log`. It's the curated, consumer-facing answer to "what
 - `GET /v1/tasks/all` — use the paginated `GET /v1/tasks` (removal in 2.0)
 ```
 
-Write the entry in the same change that makes the change, while the impact is fresh — not reconstructed from commit archaeology at release time. Breaking changes get a migration note and a deprecation window (follow the `deprecation-and-migration` skill); shipping the actual release is the `shipping-and-launch` skill's job — this section is the versioning contract that feeds it.
+Write the entry in the same change that makes the change, while the impact is fresh — not reconstructed from commit archaeology at release time. Breaking changes get a migration note and a deprecation window (follow the `i3-deprecation-and-migration` skill); shipping the actual release is the `i3-shipping-and-launch` skill's job — this section is the versioning contract that feeds it.
 
 ## Common Rationalizations
 

package/skills/{idea-refine → i3-idea-refine}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: idea-refine
+name: i3-idea-refine
 description: 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".
 ---
 
@@ -19,7 +19,7 @@ This skill is primarily an interactive dialogue. Invoke it with an idea, and the
 
 ```bash
 # Optional: Initialize the ideas directory
-bash skills/idea-refine/scripts/idea-refine.sh
+bash skills/i3-idea-refine/scripts/idea-refine.sh
 ```
 
 **Trigger Phrases:**

package/skills/{idea-refine → i3-idea-refine}/scripts/idea-refine.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 set -e
 
-# This script helps initialize the ideas directory for the idea-refine skill.
+# This script helps initialize the ideas directory for the i3-idea-refine skill.
 
 IDEAS_DIR="docs/ideas"
 

package/skills/{incremental-implementation → i3-incremental-implementation}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: incremental-implementation
+name: i3-incremental-implementation
 description: 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.
 ---
 
@@ -38,7 +38,7 @@ For each slice:
 1. **Implement** the smallest complete piece of functionality
 2. **Test** — run the test suite (or write a test if none exists)
 3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)
-4. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance)
+4. **Commit** -- save your progress with a descriptive message (see `i3-git-workflow-and-versioning` for atomic commit guidance)
 5. **Move to the next slice** — carry forward, don't restart
 
 ## Slicing Strategies
@@ -198,7 +198,7 @@ Be explicit about what's in scope and what's NOT in scope for each increment.
 
 ## Increment Checklist
 
-After each increment, verify with the repository's own commands (see the test-driven-development skill's Discover the Stack First section):
+After each increment, verify with the repository's own commands (see the i3-test-driven-development skill's Discover the Stack First section):
 
 - [ ] The change does one thing and does it completely
 - [ ] All existing tests still pass (the repository's test command: `npm test`, `./gradlew test`, `pytest`, ...)

package/skills/{interview-me → i3-interview-me}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: interview-me
+name: i3-interview-me
 description: 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.
 ---
 
@@ -11,7 +11,7 @@ What people ask for and what they actually want are different things. They ask f
 
 The cheapest moment to find this gap is before any plan, spec, or code exists. Once you've started building, switching costs are real, and the user will rationalize the wrong thing into a "good enough" thing. The misfit gets locked in.
 
-This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `idea-refine` generates variations from an idea, `spec-driven-development` writes the requirements down, `doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
+This skill closes the gap before it costs anything. The other Define-phase skills assume you already know roughly what you want: `i3-idea-refine` generates variations from an idea, `i3-spec-driven-development` writes the requirements down, `i3-doubt-driven-development` stress-tests a plan after you've drafted one. Interview-me is the part before all of those, where you ask one question at a time, with your best guess attached, until you can predict what the user is going to say before they say it.
 
 ## When to Use
 
@@ -126,7 +126,7 @@ If they correct you, fold the correction in and restate. Loop until you get an e
 When the user confirms the statement of intent with an explicit "yes":
 
 1. **Deliver the confirmed Statement of Intent.**
-2. **Offer downstream paths** (offer to save it to `docs/intent/[topic].md`, draft a spec with `spec-driven-development`, or move to task planning after the spec).
+2. **Offer downstream paths** (offer to save it to `docs/intent/[topic].md`, draft a spec with `i3-spec-driven-development`, or move to task planning after the spec).
 3. **STOP YOUR TURN IMMEDIATELY.** Do NOT invoke tools or start downstream work in this turn. Hand control back to the user to choose the next step.
 
 ### The 95% Confidence Stop
@@ -149,7 +149,7 @@ If the user wants the intent to persist (a multi-session project, a handoff to a
 
 A short before-and-after.
 
-**Without `interview-me`:**
+**Without `i3-interview-me`:**
 
 ```
 User:  build me a dashboard for our metrics
@@ -158,7 +158,7 @@ Agent: <starts proposing chart libraries and layouts>
 
 The agent has assumed: who it's for, what metrics, what "for our team" means, what success looks like. None of these are stated. Every assumption is a place the user can later say "that's not what I meant."
 
-**With `interview-me`:**
+**With `i3-interview-me`:**
 
 ```
 User: build me a dashboard for our metrics
@@ -187,11 +187,11 @@ Two questions in, the agent has discovered the actual ask isn't "a dashboard." I
 
 ## Interaction with Other Skills
 
-- **`idea-refine`**: downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to `idea-refine` to generate variations against the now-explicit intent.
-- **`spec-driven-development`**: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to `spec-driven-development` to write it down.
-- **`planning-and-task-breakdown`**: two hops downstream of this skill (after the spec).
-- **`doubt-driven-development`**: opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
-- **`source-driven-development`**: orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. They don't compete.
+- **`i3-idea-refine`**: downstream. If the confirmed intent is "I want X but I don't know how to scope it," hand off to `i3-idea-refine` to generate variations against the now-explicit intent.
+- **`i3-spec-driven-development`**: downstream. If the confirmed intent is concrete ("I want X for Y users with Z success criteria"), hand off to `i3-spec-driven-development` to write it down.
+- **`i3-planning-and-task-breakdown`**: two hops downstream of this skill (after the spec).
+- **`i3-doubt-driven-development`**: opposite end of the timeline. Interview-me is pre-decision intent extraction; doubt-driven is post-decision artifact review. Both catch divergence, but at different moments.
+- **`i3-source-driven-development`**: orthogonal. Interview-me clarifies what the user wants; SDD verifies framework facts. They don't compete.
 
 ## Common Rationalizations
 
@@ -222,7 +222,7 @@ Two questions in, the agent has discovered the actual ask isn't "a dashboard." I
 
 ## Verification
 
-After applying interview-me:
+After applying i3-interview-me:
 
 - [ ] An explicit hypothesis with a confidence number was stated in the first turn
 - [ ] Every confidence number below ~70% was accompanied by a one-line reason (what's still unresolved or missing)
@@ -232,4 +232,4 @@ After applying interview-me:
 - [ ] The user confirmed the restate with an explicit yes (not "whatever you think," not "sounds good," not silence)
 - [ ] At the stop point, the agent could predict reactions to the next three questions it would ask
 - [ ] Upon receiving explicit confirmation, stopped the turn immediately without invoking tools or starting downstream work
-- [ ] Any handoff to a downstream skill (`idea-refine`, `spec-driven-development`) was framed in terms of the confirmed intent, not the original underspecified ask
+- [ ] Any handoff to a downstream skill (`i3-idea-refine`, `i3-spec-driven-development`) was framed in terms of the confirmed intent, not the original underspecified ask

package/skills/{observability-and-instrumentation → i3-observability-and-instrumentation}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: observability-and-instrumentation
+name: i3-observability-and-instrumentation
 description: 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.
 ---
 
@@ -18,9 +18,9 @@ Code you can't observe is code you can't operate. Observability is the ability t
 - Reviewing a PR that adds I/O, retries, queues, or cross-service calls
 
 **NOT for:**
-- Diagnosing a failure happening right now — use the `debugging-and-error-recovery` skill (observability is what makes that skill fast next time)
-- Profiling and optimizing measured slowness — use the `performance-optimization` skill
-- Launch-day monitoring checklists and rollback triggers — see the `shipping-and-launch` skill; this skill covers the instrumentation that feeds them
+- Diagnosing a failure happening right now — use the `i3-debugging-and-error-recovery` skill (observability is what makes that skill fast next time)
+- Profiling and optimizing measured slowness — use the `i3-performance-optimization` skill
+- Launch-day monitoring checklists and rollback triggers — see the `i3-shipping-and-launch` skill; this skill covers the instrumentation that feeds them
 
 ## Process
 
@@ -103,7 +103,7 @@ export const runLog = (entryPoint: 'scheduler' | 'replay_endpoint' | 'cli', runI
 
 Both fields have to cross the same boundaries as the correlation ID — queue metadata, HTTP headers — or a worker re-derives the entry point and guesses. A field that merely correlates with an entry point is a hint, not an attribution: anything that can invoke the job can reproduce it.
 
-**Never log secrets, tokens, passwords, or full PII.** This is a hard rule from the `security-and-hardening` skill — telemetry pipelines are a classic data-leak path. Allowlist fields; don't log whole request bodies.
+**Never log secrets, tokens, passwords, or full PII.** This is a hard rule from the `i3-security-and-hardening` skill — telemetry pipelines are a classic data-leak path. Allowlist fields; don't log whole request bodies.
 
 ### 4. Metrics
 

package/skills/{performance-optimization → i3-performance-optimization}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: performance-optimization
+name: i3-performance-optimization
 description: 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.
 ---
 

package/skills/{performance-optimization → i3-performance-optimization}/references/optimization-patterns.md

@@ -1,6 +1,6 @@
 # Optimization Patterns
 
-Worked fixes for the anti-patterns named in Step 3 of the `performance-optimization` skill. The skill states the rule and the signature to look for; this file shows one concrete implementation. Open the section you need after Step 2 has identified the bottleneck — it is not meant to be read top to bottom.
+Worked fixes for the anti-patterns named in Step 3 of the `i3-performance-optimization` skill. The skill states the rule and the signature to look for; this file shows one concrete implementation. Open the section you need after Step 2 has identified the bottleneck — it is not meant to be read top to bottom.
 
 Checklists, measurement commands, TTFB diagnosis, and caching read/write strategies live in `../../../references/performance-checklist.md`.
 

package/skills/{planning-and-task-breakdown → i3-planning-and-task-breakdown}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: planning-and-task-breakdown
+name: i3-planning-and-task-breakdown
 description: 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.
 ---
 
@@ -158,7 +158,7 @@ The same rule applies to an external task list target: never bulk-close or delet
 
 The task list target is where tasks and checkpoints are recorded. It is defined once, here; every other reference in this skill defers to it.
 
-- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/build` command and other downstream tooling expect. Use it unless the project says otherwise.
+- **Default: a checklist-style markdown file at `tasks/todo.md`.** This is the convention the `/i3-build` command and other downstream tooling expect. Use it unless the project says otherwise.
 - **External tracker:** if the project's agent rules (`CLAUDE.md`, `AGENTS.md`, etc.) or the user designate an issue tracker (e.g. GitHub Issues, Jira, Linear, `bd`/beads), create one tracker item per task instead of writing `tasks/todo.md`. Map the Step 4 structure onto the tracker's fields: acceptance criteria and verification steps in the item body, dependencies via the tracker's linking mechanism (`bd dep add`, "blocked by", etc.). Record Step 5 checkpoints as tracker items too, or as a checklist in the plan document if the tracker has no natural equivalent.
 
 When using an external tracker, note it in `tasks/plan.md` (e.g. "Tasks tracked in Linear project FOO") so downstream steps and future sessions know where to look, and keep the plan document's Task List section as an ordered index of tracker item IDs or links rather than a duplicate checklist.