@givolt/i3-composer-agent 1.0.0 → 2.0.0

package/docs/cursor-setup.md

@@ -20,7 +20,7 @@ Docs: [Rules](https://docs.cursor.com/context/rules) · [Skills](https://docs.cu
 ### Rules vs skills
 
 - **Rules** — concise, stable (“use conventional commits”, “type-annotate public Python APIs”). Prefer one concern per file; avoid large pasted guides.
-- **Skills** — step-by-step processes from this repo (`test-driven-development`, `code-review-and-quality`, etc.). **Do not** copy entire `SKILL.md` bodies into rules; that duplicates `.cursor/skills/` and wastes context.
+- **Skills** — step-by-step processes from this repo (`i3-test-driven-development`, `i3-code-review-and-quality`, etc.). **Do not** copy entire `SKILL.md` bodies into rules; that duplicates `.cursor/skills/` and wastes context.
 
 ### Legacy (avoid for new setups)
 
@@ -40,9 +40,9 @@ your-project/
 │   ├── rules/                    # Short .mdc policies (yours)
 │   │   └── i3-composer-agent.mdc      # Optional: “use project skills” pointer
 │   └── skills/                   # What Cursor Agent loads
-│       ├── using-agent-skills/
-│       ├── test-driven-development/
-│       ├── code-review-and-quality/
+│       ├── i3-using-agent-skills/
+│       ├── i3-test-driven-development/
+│       ├── i3-code-review-and-quality/
 │       └── …                     # Synced from i3-composer-agent + your own skills
 └── i3-composer-agent/                 # Optional: git submodule or vendor clone
     └── skills/                   # Upstream source only
@@ -80,7 +80,7 @@ Each skill folder must contain `SKILL.md` with YAML frontmatter, at minimum:
 
 ```yaml
 ---
-name: test-driven-development
+name: i3-test-driven-development
 description: Drives development with tests. Use when implementing logic, fixing bugs, or changing behavior.
 ---
 ```
@@ -99,7 +99,7 @@ alwaysApply: true
 
 Before non-trivial technical work:
 
-1. Route via `.cursor/skills/using-agent-skills/SKILL.md`.
+1. Route via `.cursor/skills/i3-using-agent-skills/SKILL.md`.
 2. Read and follow the matching skill under `.cursor/skills/<name>/SKILL.md`.
 3. Open `reference.md` in that folder when the skill links to it.
 4. Prefer project skills over guessing; user does not need to say "read skill" each time.
@@ -135,33 +135,33 @@ Project skills in `.cursor/skills/` take precedence for **this** repo’s workfl
 
 1. **Settings → Rules** — project `.mdc` files listed.
 2. **Agent chat** — skills from `.cursor/skills/` appear in the skill list (if your Cursor build exposes it).
-3. Run a task that maps to a skill (e.g. “add a feature with tests first”) without naming the file — agent should open `test-driven-development` when routing works.
+3. Run a task that maps to a skill (e.g. “add a feature with tests first”) without naming the file — agent should open `i3-test-driven-development` when routing works.
 
 ---
 
 ## How agents should use skills
 
-1. **Discover** — `using-agent-skills` maps task phase → skill name.
+1. **Discover** — `i3-using-agent-skills` maps task phase → skill name.
 2. **Read** — full process in `.cursor/skills/<name>/SKILL.md`.
 3. **Deep dive** — `reference.md`, `references/*.md`, or linked checklists when the skill says so.
-4. **Combine** — e.g. `incremental-implementation` + `api-and-interface-design` for an API slice.
+4. **Combine** — e.g. `i3-incremental-implementation` + `i3-api-and-interface-design` for an API slice.
 
-Explicit user phrases (“follow TDD”, “use code-review-and-quality”) still help if the agent drifts.
+Explicit user phrases (“follow TDD”, “use i3-code-review-and-quality”) still help if the agent drifts.
 
 ### Phase → skill (quick map)
 
 | You are… | Skill |
 |----------|--------|
-| Clarifying requirements | `interview-me`, `idea-refine`, `spec-driven-development` |
-| Planning tasks | `planning-and-task-breakdown` |
-| Implementing | `incremental-implementation`, `frontend-ui-engineering`, `api-and-interface-design` |
-| Testing | `test-driven-development`, `browser-testing-with-devtools` |
-| Debugging | `debugging-and-error-recovery` |
-| Reviewing | `code-review-and-quality`, `code-simplification` |
-| Security / performance | `security-and-hardening`, `performance-optimization` |
-| Git / CI / ship | `git-workflow-and-versioning`, `ci-cd-and-automation`, `shipping-and-launch` |
+| Clarifying requirements | `i3-interview-me`, `i3-idea-refine`, `i3-spec-driven-development` |
+| Planning tasks | `i3-planning-and-task-breakdown` |
+| Implementing | `i3-incremental-implementation`, `i3-frontend-ui-engineering`, `i3-api-and-interface-design` |
+| Testing | `i3-test-driven-development`, `i3-browser-testing-with-devtools` |
+| Debugging | `i3-debugging-and-error-recovery` |
+| Reviewing | `i3-code-review-and-quality`, `i3-code-simplification` |
+| Security / performance | `i3-security-and-hardening`, `i3-performance-optimization` |
+| Git / CI / ship | `i3-git-workflow-and-versioning`, `i3-ci-cd-and-automation`, `i3-shipping-and-launch` |
 
-Full tree: `skills/using-agent-skills/SKILL.md` in the repo.
+Full tree: `skills/i3-using-agent-skills/SKILL.md` in the repo.
 
 ---
 
@@ -190,7 +190,7 @@ Full tree: `skills/using-agent-skills/SKILL.md` in the repo.
 
 Files under `i3-composer-agent/agents/` (e.g. code reviewer persona) are **not** loaded automatically by Cursor. Options:
 
-- Reference the skill equivalent (`code-review-and-quality`).
+- Reference the skill equivalent (`i3-code-review-and-quality`).
 - Paste agent markdown into the chat for one review.
 - Extract a **short** checklist into a `.mdc` rule.
 

package/docs/developer-onboarding.md

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

package/docs/gemini-cli-setup.md

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

package/docs/getting-started.md

@@ -38,13 +38,13 @@ Copy the relevant `SKILL.md` content into your agent's system prompt, rules file
 
 **Rules file:** Add skill content to your project's rules file (CLAUDE.md, .cursorrules, etc.).
 
-**Conversation:** Reference the skill when giving instructions: "Follow the test-driven-development process for this change."
+**Conversation:** Reference the skill when giving instructions: "Follow the i3-test-driven-development process for this change."
 
 ### 4. Use the meta-skill for discovery when needed
 
-If your agent does not route skills natively, start with the `using-agent-skills` skill loaded. It contains a flowchart that maps task types to the appropriate skill.
+If your agent does not route skills natively, start with the `i3-using-agent-skills` skill loaded. It contains a flowchart that maps task types to the appropriate skill.
 
-If your host already discovers and activates skills from their descriptions, do not also paste `using-agent-skills` into an always-on system prompt or rules file. That creates two routers for the same task. Install the individual skills and let the host activate them on demand instead.
+If your host already discovers and activates skills from their descriptions, do not also paste `i3-using-agent-skills` into an always-on system prompt or rules file. That creates two routers for the same task. Install the individual skills and let the host activate them on demand instead.
 
 ### Existing projects need no migration
 
@@ -66,9 +66,9 @@ Rolling out to a real project? The **[Adoption Guide](adoption-guide.md)** cover
 
 Load three essential skills into your rules file:
 
-1. **spec-driven-development** — For defining what to build
-2. **test-driven-development** — For proving it works
-3. **code-review-and-quality** — For verifying quality before merge
+1. **i3-spec-driven-development** — For defining what to build
+2. **i3-test-driven-development** — For proving it works
+3. **i3-code-review-and-quality** — For verifying quality before merge
 
 These three cover the most critical quality gaps in AI-assisted development.
 
@@ -77,19 +77,19 @@ These three cover the most critical quality gaps in AI-assisted development.
 For comprehensive coverage, load skills by phase:
 
 ```
-Starting a project:  spec-driven-development → planning-and-task-breakdown
-During development:  incremental-implementation + test-driven-development
-Before merge:        code-review-and-quality + security-and-hardening
-Before deploy:       shipping-and-launch
+Starting a project:  i3-spec-driven-development → i3-planning-and-task-breakdown
+During development:  i3-incremental-implementation + i3-test-driven-development
+Before merge:        i3-code-review-and-quality + i3-security-and-hardening
+Before deploy:       i3-shipping-and-launch
 ```
 
 ### Context-Aware Loading
 
 Don't load all skills at once — it wastes context. Load skills relevant to the current task:
 
-- Working on UI? Load `frontend-ui-engineering`
-- Debugging? Load `debugging-and-error-recovery`
-- Setting up CI? Load `ci-cd-and-automation`
+- Working on UI? Load `i3-frontend-ui-engineering`
+- Debugging? Load `i3-debugging-and-error-recovery`
+- Setting up CI? Load `i3-ci-cd-and-automation`
 
 ## Skill Anatomy
 
@@ -117,7 +117,7 @@ The `agents/` directory contains pre-configured agent personas:
 | `code-reviewer.md` | Five-axis code review |
 | `test-engineer.md` | Test strategy and writing |
 | `security-auditor.md` | Vulnerability detection |
-| `web-performance-auditor.md` | Core Web Vitals & performance audit (via `/webperf`) |
+| `web-performance-auditor.md` | Core Web Vitals & performance audit (via `/i3-webperf`) |
 
 Load an agent definition when you need specialized review. For example, ask your coding agent to "review this change using the code-reviewer agent persona" and provide the agent definition.
 
@@ -127,16 +127,16 @@ The `.claude/commands/` directory contains slash commands for Claude Code:
 
 | Command | Skill Invoked |
 |---------|---------------|
-| `/spec` | spec-driven-development |
-| `/constraints` | constraint-driven-development |
-| `/plan` | planning-and-task-breakdown |
-| `/build` | incremental-implementation + test-driven-development |
-| `/build auto` | planning-and-task-breakdown → incremental-implementation + test-driven-development (whole plan, one approval) |
-| `/test` | test-driven-development |
-| `/review` | code-review-and-quality |
-| `/code-simplify` | code-simplification |
-| `/ship` | shipping-and-launch |
-| `/webperf` | web-performance-auditor (specialist agent, web apps only) |
+| `/i3-spec` | i3-spec-driven-development |
+| `/i3-constraints` | i3-constraint-driven-development |
+| `/i3-plan` | i3-planning-and-task-breakdown |
+| `/i3-build` | i3-incremental-implementation + i3-test-driven-development |
+| `/i3-build auto` | i3-planning-and-task-breakdown → i3-incremental-implementation + i3-test-driven-development (whole plan, one approval) |
+| `/i3-test` | i3-test-driven-development |
+| `/i3-review` | i3-code-review-and-quality |
+| `/i3-code-simplify` | i3-code-simplification |
+| `/i3-ship` | i3-shipping-and-launch |
+| `/i3-webperf` | web-performance-auditor (specialist agent, web apps only) |
 
 > **Note:** When installed as a Claude Code plugin you may see a warning like
 > _"Default commands/ folder is ignored because the manifest sets 'commands'"_.
@@ -150,13 +150,13 @@ The `references/` directory contains supplementary checklists:
 
 | Reference | Use With |
 |-----------|----------|
-| `testing-patterns.md` | test-driven-development |
-| `performance-checklist.md` | performance-optimization |
-| `security-checklist.md` | security-and-hardening |
-| `accessibility-checklist.md` | frontend-ui-engineering |
+| `testing-patterns.md` | i3-test-driven-development |
+| `performance-checklist.md` | i3-performance-optimization |
+| `security-checklist.md` | i3-security-and-hardening |
+| `accessibility-checklist.md` | i3-frontend-ui-engineering |
 | `definition-of-done.md` | all skills / every change |
-| `observability-checklist.md` | observability-and-instrumentation |
-| `orchestration-patterns.md` | doubt-driven-development |
+| `observability-checklist.md` | i3-observability-and-instrumentation |
+| `orchestration-patterns.md` | i3-doubt-driven-development |
 
 Load a reference when you need detailed patterns beyond what the skill covers.
 
@@ -170,7 +170,7 @@ This portability gap is tracked in
 
 ## Spec and task artifacts
 
-The `/spec` and `/plan` commands create working artifacts (`SPEC.md`, `tasks/plan.md`, `tasks/todo.md`). Treat them as **living documents** while the work is in progress:
+The `/i3-spec` and `/i3-plan` commands create working artifacts (`SPEC.md`, `tasks/plan.md`, `tasks/todo.md`). Treat them as **living documents** while the work is in progress:
 
 - Keep them in version control during development so the human and the agent have a shared source of truth.
 - Update them when scope or decisions change.
@@ -189,11 +189,11 @@ The same artifacts are the handoff between sessions. For a small task, run the w
 
 #### Task-boundary restarts and Ralph loops
 
-`/build auto` can run the whole approved plan in one session. It does not require or perform a fresh process per task. Its per-task status updates, verification results, and commits make each completed task a restartable boundary, so a capable external harness may exit and resume there without depending on chat history.
+`/i3-build auto` can run the whole approved plan in one session. It does not require or perform a fresh process per task. Its per-task status updates, verification results, and commits make each completed task a restartable boundary, so a capable external harness may exit and resume there without depending on chat history.
 
-A shell-level "Ralph loop" is harness behavior, not a separate skill workflow. If you use one, restart only after the current task has reached a recorded boundary; on re-entry, read the durable artifacts and repository state before selecting the next pending task. A process exit is not evidence that a task passed, and a restart must not bypass an approval gate. See the `context-engineering` skill's **Restartable Session Boundaries** section for the handoff checklist.
+A shell-level "Ralph loop" is harness behavior, not a separate skill workflow. If you use one, restart only after the current task has reached a recorded boundary; on re-entry, read the durable artifacts and repository state before selecting the next pending task. A process exit is not evidence that a task passed, and a restart must not bypass an approval gate. See the `i3-context-engineering` skill's **Restartable Session Boundaries** section for the handoff checklist.
 
-This doesn't need the `/spec` and `/plan` wrappers — plain requests work in any agent, including a `npx skills add` install that only has the skills:
+This doesn't need the `/i3-spec` and `/i3-plan` wrappers — plain requests work in any agent, including a `npx skills add` install that only has the skills:
 
 > Read SPEC.md, then break it into small verifiable tasks with acceptance criteria and dependency order. Save them to tasks/plan.md and tasks/todo.md. No product code yet — show me the plan first.
 
@@ -201,8 +201,8 @@ This doesn't need the `/spec` and `/plan` wrappers — plain requests work in an
 
 ## Tips
 
-1. **Start with spec-driven-development** for any non-trivial work
-2. **Always load test-driven-development** when writing code
+1. **Start with i3-spec-driven-development** for any non-trivial work
+2. **Always load i3-test-driven-development** when writing code
 3. **Don't skip verification steps** — they're the whole point
 4. **Load skills selectively** — more context isn't always better
 5. **Use the agents for review** — different perspectives catch different issues

package/docs/opencode-setup.md

@@ -30,7 +30,7 @@ npx skills add /path/to/i3-composer-agent --list     # browse before installing
 Install a single skill:
 
 ```bash
-npx skills add /path/to/i3-composer-agent --skill spec-driven-development
+npx skills add /path/to/i3-composer-agent --skill i3-spec-driven-development
 ```
 
 By default `npx skills` installs into a tool-specific directory (often `.claude/skills/` or a shared location). OpenCode will discover skills placed there because it reads `.claude/skills/<name>/SKILL.md` and the generic `.agents/skills/<name>/SKILL.md` paths.
@@ -61,12 +61,12 @@ mkdir -p .opencode/skills
 cp -r /path/to/i3-composer-agent/skills/<skill-name> .opencode/skills/
 ```
 
-For example, to install `spec-driven-development` and `incremental-implementation`:
+For example, to install `i3-spec-driven-development` and `i3-incremental-implementation`:
 
 ```bash
 mkdir -p .opencode/skills
-cp -r /path/to/i3-composer-agent/skills/spec-driven-development .opencode/skills/
-cp -r /path/to/i3-composer-agent/skills/incremental-implementation .opencode/skills/
+cp -r /path/to/i3-composer-agent/skills/i3-spec-driven-development .opencode/skills/
+cp -r /path/to/i3-composer-agent/skills/i3-incremental-implementation .opencode/skills/
 ```
 
 #### Global installation
@@ -89,7 +89,7 @@ If you already share skills across Claude Code and OpenCode, any of these locati
 
 ### What to copy
 
-Copy the directories under `skills/` (for example `skills/spec-driven-development/`). Each directory must contain a `SKILL.md` file. Do not copy the repository's root `AGENTS.md` or `CLAUDE.md`; those files configure development of this repository itself.
+Copy the directories under `skills/` (for example `skills/i3-spec-driven-development/`). Each directory must contain a `SKILL.md` file. Do not copy the repository's root `AGENTS.md` or `CLAUDE.md`; those files configure development of this repository itself.
 
 ## Project `AGENTS.md`
 
@@ -113,13 +113,13 @@ This project uses skills installed under `.opencode/skills/` (or a compatible pa
 
 Map the user's intent to the matching skill automatically:
 
-- Feature / new functionality → `spec-driven-development`, then `incremental-implementation` and `test-driven-development`
-- Planning / breakdown → `planning-and-task-breakdown`
-- Bug / failure / unexpected behavior → `debugging-and-error-recovery`
-- Code review → `code-review-and-quality`
-- Refactoring / simplification → `code-simplification`
-- API or interface design → `api-and-interface-design`
-- UI work → `frontend-ui-engineering`
+- Feature / new functionality → `i3-spec-driven-development`, then `i3-incremental-implementation` and `i3-test-driven-development`
+- Planning / breakdown → `i3-planning-and-task-breakdown`
+- Bug / failure / unexpected behavior → `i3-debugging-and-error-recovery`
+- Code review → `i3-code-review-and-quality`
+- Refactoring / simplification → `i3-code-simplification`
+- API or interface design → `i3-api-and-interface-design`
+- UI work → `i3-frontend-ui-engineering`
 
 ## Execution Model
 
@@ -156,21 +156,21 @@ When your project's `AGENTS.md` instructs the agent to use skills, the agent eva
 
 Examples:
 
-- "build a feature" → `incremental-implementation` + `test-driven-development`
-- "design a system" → `spec-driven-development`
-- "fix a bug" → `debugging-and-error-recovery`
-- "review this code" → `code-review-and-quality`
+- "build a feature" → `i3-incremental-implementation` + `i3-test-driven-development`
+- "design a system" → `i3-spec-driven-development`
+- "fix a bug" → `i3-debugging-and-error-recovery`
+- "review this code" → `i3-code-review-and-quality`
 
 ### 3. Lifecycle Mapping (Implicit Commands)
 
 OpenCode does not require slash commands, but if you prefer them see the next section. In agent-driven mode the lifecycle is mapped implicitly:
 
-- DEFINE → `spec-driven-development`
-- PLAN → `planning-and-task-breakdown`
-- BUILD → `incremental-implementation` + `test-driven-development`
-- VERIFY → `debugging-and-error-recovery`
-- REVIEW → `code-review-and-quality`
-- SHIP → `shipping-and-launch`
+- DEFINE → `i3-spec-driven-development`
+- PLAN → `i3-planning-and-task-breakdown`
+- BUILD → `i3-incremental-implementation` + `i3-test-driven-development`
+- VERIFY → `i3-debugging-and-error-recovery`
+- REVIEW → `i3-code-review-and-quality`
+- SHIP → `i3-shipping-and-launch`
 
 ### Copy the optional slash commands
 
@@ -190,10 +190,10 @@ A typical command file looks like:
 description: Break work into small verifiable tasks
 ---
 
-Invoke the planning-and-task-breakdown skill. Read the spec and create tasks with acceptance criteria.
+Invoke the i3-planning-and-task-breakdown skill. Read the spec and create tasks with acceptance criteria.
 ```
 
-Save it as `.opencode/commands/plan.md` to enable `/plan` in OpenCode.
+Save it as `.opencode/commands/i3-plan.md` to enable `/i3-plan` in OpenCode.
 
 ## Usage Examples
 
@@ -206,7 +206,7 @@ Add authentication to this app
 
 Agent behavior:
 - Detects feature work
-- Invokes `spec-driven-development`
+- Invokes `i3-spec-driven-development`
 - Produces a spec before writing code
 - Moves to planning and implementation skills
 
@@ -218,7 +218,7 @@ This endpoint is returning 500 errors
 ```
 
 Agent behavior:
-- Invokes `debugging-and-error-recovery`
+- Invokes `i3-debugging-and-error-recovery`
 - Reproduces → localizes → fixes → adds guards
 
 ### Example 3: Code Review
@@ -229,7 +229,7 @@ Review this PR
 ```
 
 Agent behavior:
-- Invokes `code-review-and-quality`
+- Invokes `i3-code-review-and-quality`
 - Applies structured review (correctness, design, readability, etc.)
 
 ## Agent Expectations

package/docs/skill-anatomy.md

@@ -34,7 +34,7 @@ description: Guides agents through [task/workflow]. Use when [specific trigger c
 - Top-level keys are limited to the [Agent Skills specification](https://agentskills.io) fields: `name`, `description`, `license`, `compatibility`, `metadata`, and `allowed-tools`. Vendor or runtime controls such as `model`, `tools`, `max_turns`, or `context` go under `metadata` or in a per-agent adapter file; see [docs/advanced-per-agent-configuration.md](advanced-per-agent-configuration.md). The validator rejects any other top-level key.
 
 Published names are compatibility identifiers. In particular,
-`browser-testing-with-devtools` is the stable upstream name because other
+`i3-browser-testing-with-devtools` is the stable upstream name because other
 skills refer to it directly. A downstream catalog may rename it, but that
 catalog owns the alias or migration mapping; downstream-only aliases are not
 maintained in this repository.
@@ -182,8 +182,8 @@ This is about skill *content*; the portability of `references/` *paths* is a sep
 Reference other skills by name:
 
 ```markdown
-Follow the `test-driven-development` skill for writing tests.
-If the build breaks, use the `debugging-and-error-recovery` skill.
+Follow the `i3-test-driven-development` skill for writing tests.
+If the build breaks, use the `i3-debugging-and-error-recovery` skill.
 ```
 
 Don't duplicate content between skills — reference and link instead.

package/docs/windsurf-setup.md

@@ -8,11 +8,11 @@ Windsurf uses `.windsurfrules` for project-specific agent instructions:
 
 ```bash
 # Create a combined rules file from your most important skills
-cat /path/to/i3-composer-agent/skills/test-driven-development/SKILL.md > .windsurfrules
+cat /path/to/i3-composer-agent/skills/i3-test-driven-development/SKILL.md > .windsurfrules
 echo "\n---\n" >> .windsurfrules
-cat /path/to/i3-composer-agent/skills/incremental-implementation/SKILL.md >> .windsurfrules
+cat /path/to/i3-composer-agent/skills/i3-incremental-implementation/SKILL.md >> .windsurfrules
 echo "\n---\n" >> .windsurfrules
-cat /path/to/i3-composer-agent/skills/code-review-and-quality/SKILL.md >> .windsurfrules
+cat /path/to/i3-composer-agent/skills/i3-code-review-and-quality/SKILL.md >> .windsurfrules
 ```
 
 ### Global Rules
@@ -30,19 +30,19 @@ Keep `.windsurfrules` focused on 2-3 essential skills to stay within context lim
 # .windsurfrules
 # Essential i3-composer-agent for this project
 
-[Paste test-driven-development SKILL.md]
+[Paste i3-test-driven-development SKILL.md]
 
 ---
 
-[Paste incremental-implementation SKILL.md]
+[Paste i3-incremental-implementation SKILL.md]
 
 ---
 
-[Paste code-review-and-quality SKILL.md]
+[Paste i3-code-review-and-quality SKILL.md]
 ```
 
 ## Usage Tips
 
 1. **Be selective** — Windsurf's context is limited. Choose skills that address your biggest quality gaps.
-2. **Reference in conversation** — Paste additional skill content into the chat when working on specific phases (e.g., paste `security-and-hardening` when building auth).
+2. **Reference in conversation** — Paste additional skill content into the chat when working on specific phases (e.g., paste `i3-security-and-hardening` when building auth).
 3. **Use references as checklists** — Paste `references/security-checklist.md` and ask Windsurf to verify each item.

package/evals/cases/{api-and-interface-design.json → i3-api-and-interface-design.json}

@@ -1,5 +1,5 @@
 {
-  "skill_name": "api-and-interface-design",
+  "skill_name": "i3-api-and-interface-design",
   "trigger": {
     "positive": [
       {
@@ -18,11 +18,11 @@
     "negative": [
       {
         "prompt": "My unit test is failing with a null pointer exception",
-        "owner": "debugging-and-error-recovery"
+        "owner": "i3-debugging-and-error-recovery"
       },
       {
         "prompt": "Make this landing page responsive on mobile",
-        "owner": "frontend-ui-engineering"
+        "owner": "i3-frontend-ui-engineering"
       }
     ]
   },
@@ -32,7 +32,7 @@
       "prompt": "Design the public API for a URL-shortening service: create, resolve, stats. Produce the endpoint contracts.",
       "expected_output": "Endpoint contracts with methods, paths, request/response shapes, and explicit error semantics",
       "files": [
-        "api-and-interface-design"
+        "i3-api-and-interface-design"
       ],
       "expectations": [
         "Error responses are specified with status codes and a consistent error shape, not just happy paths",

package/evals/cases/{browser-testing-with-devtools.json → i3-browser-testing-with-devtools.json}

@@ -1,5 +1,5 @@
 {
-  "skill_name": "browser-testing-with-devtools",
+  "skill_name": "i3-browser-testing-with-devtools",
   "trigger": {
     "positive": [
       {
@@ -18,11 +18,11 @@
     "negative": [
       {
         "prompt": "Write a spec for the new billing feature before we start",
-        "owner": "spec-driven-development"
+        "owner": "i3-spec-driven-development"
       },
       {
         "prompt": "Break this PRD into ordered implementation tasks",
-        "owner": "planning-and-task-breakdown"
+        "owner": "i3-planning-and-task-breakdown"
       }
     ]
   },
@@ -32,7 +32,7 @@
       "prompt": "The signup form renders but submitting it appears to do nothing. Verify the real behavior in the browser and report findings.",
       "expected_output": "Runtime evidence from the browser: console errors, network activity, DOM state, and a diagnosis",
       "files": [
-        "browser-testing-with-devtools"
+        "i3-browser-testing-with-devtools"
       ],
       "expectations": [
         "Findings are grounded in observed runtime data (console, network, DOM), not static code reading alone",