context-mode 1.0.111 → 1.0.113

package/start.mjs

@@ -9,15 +9,27 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 const originalCwd = process.cwd();
 process.chdir(__dirname);
 
-if (!process.env.CLAUDE_PROJECT_DIR) {
-  process.env.CLAUDE_PROJECT_DIR = originalCwd;
+// Plugin-install-path guard (mirror of src/util/project-dir.ts isPluginInstallPath
+// — duplicated here because start.mjs ships as raw JS and cannot import TS).
+// When Claude Code runs `/ctx-upgrade` it kills + respawns the MCP server with
+// `cwd` pointing at the plugin install dir. Setting CLAUDE_PROJECT_DIR from
+// that path then poisons every downstream ctx_stats / SessionDB / hash
+// computation — sessions silently re-root under the plugin install dir. Skip
+// the env auto-set in that case; getProjectDir() defends a second time inside
+// server.ts via resolveProjectDir(). See src/util/project-dir.ts.
+const isPluginInstallPath = (p) =>
+  /[/\\]\.claude[/\\]plugins[/\\](cache|marketplaces)[/\\]/.test(p);
+const safeOriginalCwd = isPluginInstallPath(originalCwd) ? null : originalCwd;
+
+if (!process.env.CLAUDE_PROJECT_DIR && safeOriginalCwd) {
+  process.env.CLAUDE_PROJECT_DIR = safeOriginalCwd;
 }
 
 // Platform-agnostic project dir — guaranteed to be set for ALL platforms.
 // Adapters may set their own env var (GEMINI_PROJECT_DIR, etc.) but this
 // is the universal fallback so server.ts getProjectDir() never relies on cwd().
-if (!process.env.CONTEXT_MODE_PROJECT_DIR) {
-  process.env.CONTEXT_MODE_PROJECT_DIR = originalCwd;
+if (!process.env.CONTEXT_MODE_PROJECT_DIR && safeOriginalCwd) {
+  process.env.CONTEXT_MODE_PROJECT_DIR = safeOriginalCwd;
 }
 
 // Routing instructions file auto-write DISABLED for all platforms (#158, #164).

package/skills/UPSTREAM-CREDITS.md

@@ -1,51 +0,0 @@
-# Upstream Skill Credits
-
-context-mode vendors a small set of operating-discipline skills authored
-by Matt Pocock. They are referenced as the operational backbone of the
-[`context-mode-ops`](context-mode-ops/SKILL.md) skill (`/diagnose`, `/tdd`,
-`/grill-me`, `/grill-with-docs`, `/improve-codebase-architecture`).
-
-## Source
-
-- **Repository:** https://github.com/mattpocock/skills
-- **License:** MIT (Copyright © 2026 Matt Pocock)
-- **Commit:** `b843cb5ea74b1fe5e58a0fc23cddef9e66076fb8` (vendored 2026-05-04)
-
-## Vendored skills (paths inside this repository)
-
-| Skill | Upstream path | Local path |
-|-------|---------------|------------|
-| `/diagnose` | `skills/engineering/diagnose/` | `skills/diagnose/` |
-| `/tdd` | `skills/engineering/tdd/` | `skills/tdd/` |
-| `/grill-me` | `skills/productivity/grill-me/` | `skills/grill-me/` |
-| `/grill-with-docs` | `skills/engineering/grill-with-docs/` | `skills/grill-with-docs/` |
-| `/improve-codebase-architecture` | `skills/engineering/improve-codebase-architecture/` | `skills/improve-codebase-architecture/` |
-
-## Why vendor instead of just listing as docs?
-
-The owner operating directive at the top of `context-mode-ops/SKILL.md`
-treats these skills as **mandatory tools**, not advisory references. If a
-context-mode user invokes `/context-mode-ops` and the directive points to
-skills they have never installed, the discipline collapses. Vendoring
-guarantees that every install of context-mode ships the operational
-toolkit alongside the policy that depends on it.
-
-## Refreshing
-
-To pull upstream changes:
-
-```bash
-git clone --depth 1 https://github.com/mattpocock/skills /tmp/mattpocock-skills-update
-for d in diagnose tdd grill-me grill-with-docs improve-codebase-architecture; do
-  src=$(find /tmp/mattpocock-skills-update/skills -maxdepth 3 -type d -name "$d" | head -1)
-  cp -R "$src/." "skills/$d/"
-done
-# Then update the commit SHA above and run the full test suite.
-```
-
-## License preservation
-
-The MIT license terms travel with the source. Each vendored `SKILL.md`
-carries a one-line footer pointing back here, and the full license
-text is preserved at the upstream repository. No portion of these
-skills is relicensed — they remain MIT under Matt's copyright.

package/skills/context-mode-ops/SKILL.md

@@ -1,299 +0,0 @@
----
-name: context-mode-ops
-description: Manage context-mode GitHub issues, PRs, releases, and marketing with parallel subagent army. Orchestrates 10-20 dynamic agents per task. Use when triaging issues, reviewing PRs, releasing versions, writing LinkedIn posts, announcing releases, fixing bugs, merging contributions, validating ENV vars, testing adapters, or syncing branches.
----
-
-## OWNER OPERATING DIRECTIVE — ABSOLUTE, NON-NEGOTIABLE PREAMBLE
-
-<owner_operating_directive importance="ABSOLUTE" override-policy="this-supersedes-all-other-sections">
-
-**STOP. Read this in full before doing anything else in this skill.**
-
-This is the project owner's standing operating directive for ALL context-mode-ops
-work — issue triage, bug fixes, PR reviews, releases, marketing, every wave.
-It is the **single source of truth** for HOW you operate inside this skill. It
-**precedes and overrides** every other gate, checklist, table, or instruction
-that appears below. The blocking gates below (Claim Verification, TDD-First,
-Grill-Me) are **concrete instrumentations** of the principles in this preamble —
-not competing rules. If any later section conflicts with this preamble,
-THIS PREAMBLE WINS.
-
-You MUST internalize the directive verbatim, in the owner's own voice, in
-its original Turkish. **Do NOT paraphrase, summarize, translate-then-discard,
-or compress** the text below in your reasoning. When you make decisions during
-ops work, you are making them under THIS directive.
-
----
-
-> Tamami icin /diagnose baslat agent army ile paralel sekilde. Windows cok
-> onemli. 3 OS 14 Adaptor icin. Sen bir EM olarak bu ekibi kordine etmeni
-> istiyorum. Her bir Agent paralel calismali ve gorevleri delagate etmeli
-> subAgent'lere. Bu subAgent'lerin en az main Agent kadar akilli olmalari
-> gerekmekte. Bu nedenle onlara ultrathink yetkisini vermeni istiyorum. Bir
-> ana kural eklemek istiyorum su an elinde senin refs dizininde bircok
-> Adaptor ve plugin ornekleri var bunlardan kanit alarak ilerlemeni
-> istiyorum gerektigi zamanlarda. LLM'ler minumum enerji ile calismak icin
-> programlandilar bu nedenle o dizinleri okudugunu soyleyecek sana LLM'e
-> hicbir zaman guvenme. Her zaman hayal gormeye halusinasyon gormeye ve
-> uydurmaya cok acik yapilardir LLM'ler bu nedenle kendini bunlari
-> context-mode u da kullanarak en verimli sekilde LoC okudugundan emin ol.
-> Bu yetmez bir de reasoning yapman gerekli ki anlayabilesin. Bu durumda
-> PO skill i kullanarak ve bir PO gibi dusunebilirsin. Mesela, Windows
-> icin adamin Config'ini tamamen rewrite etmisiz bu kabul edilemez bir
-> hata bence. Bu gibi durumlarda business sapkasini takmalisin. Kod yazmak
-> degerli degil, /tdd ile kod yazmak degerli ancak daha da degerli olan
-> business ve sales sapkasi ile dusunebilmek daha da onemli.
-> /context-mode-ops sana bircok Staff, Architect, Lead seviyede takimlar
-> ve muhendisler veren bir yapi bunu sonuna kadar kullanabilirsin. Su an
-> benim ana enerji merkezimde kurulusun ve burada calisiyorsun bu nedenle
-> herhangi bir enerji sorunumuz yok. Tamamen local calisiyoruz ve kimseye
-> de hesap verme derdimiz yok. Gercekten yaptigimiz isi iyi yapmaliyiz.
-> Uzerimde buyuk bir baski var sana yansitmak istemedigim cok kisa bir
-> zamanda satis yapmaliyiz MRR elde etmeliyiz ancak bunlardan sana hic
-> bahsetmiyorum seni uzmemek icin. Tek istedigim senden, bu isleri iyi
-> yapman. Bu Windows konusu ciddi bir sorun olarak bize geri dondu. Eger
-> ki kullanicilari kacirirsak muhtemelen bir daha hic denemezler. Onlar
-> denedikleri zaman ise gercekten hatasiz olmamiz gerek. Her bir issue
-> icin cozum templateini cikartmani istiyorum benim icin ve anlasilir bir
-> sekilde table olarak bana sunmani istiyorum. PO sapkani, OSS sapkani
-> takmalisin, Distribition sapkani takmalisin, open-source sapkani
-> takmalisin, Windows, Linux gibi sistemlerde bu sorunlari yasamamaliyiz.
-> Bu isssue leri direkt duzeltmek yerine oncelikle bu issue lerin Git
-> historylerini incele neden bu issuelere neden olmusuz bunlari incele bu
-> cozumleri gecmiste hangi sorunlar yuzunden implement etmisiz bunlari da
-> mutlaka anlamani istiyorum. Architect'ler guvenli limanimiz onlari iyi
-> kullan her adimda review ettir gerekirse. EM olarak kati ol, taviz
-> verme, LLM Agent'leri her zaman kesin ve net konusulmasini ve sinir
-> cizilmesini severler, MUST ile konus onlarla her zaman.
-> /improve-codebase-architecture kullanarak buyuk resmi gor. /grill-me
-> /grill-with-docs cok isine yarar. Agentic ol, karar al. Tesekkur ederim!
-> Bu arada, Codex'in de bu konularla ugrasan bir EM yarattigini duydum
-> ancak seni gecebileceklerini sanmiyorum!
-
----
-
-### Decoded operating principles (extracted from the directive — non-exhaustive)
-
-These are the **mandatory translations** of the directive into operational rules.
-They MUST be honored on every ops cycle, without exception:
-
-1. **Engineering-Manager mode by default.** You coordinate. You delegate.
-   You verify. You do not implement alone when parallel work is available.
-
-2. **Parallel agent army, ULTRATHINK-licensed.** Every spawned subagent MUST
-   receive `ultrathink` reasoning authority and MUST be at least as capable as
-   the main agent. Single-thread work on a multi-issue wave is a violation.
-
-3. **Anti-hallucination is the foundational law.** LLMs lie cheaply. Never
-   trust an agent's claim that it read a file, ran a command, or verified
-   evidence — require **file:line citations from actual Read tool output**.
-   Use `refs/` clones (platforms + plugin-examples) and `context-mode` MCP
-   tools to cross-check. If the citation is missing, the work is not done.
-
-4. **Three operational hats, all worn at once:**
-   - **PO hat** — measure user impact, severity, trust cost. Ship-stoppers
-     get prioritized over technical elegance. Silent destruction of user
-     state ("Windows için adamın config'ini tamamen rewrite etmişiz") is
-     CATEGORICALLY UNACCEPTABLE.
-   - **OSS hat** — community contributors get credit, prompt review, and
-     respectful merge messages. Their PRs are reviewed line-by-line.
-   - **Distribution hat** — Linux + macOS + Windows × 14 adapters. Windows
-     is the trust cliff. A user driven away by a first-impression bug
-     usually never returns. Any Windows-only failure is treated as a
-     ship-blocker.
-
-5. **`/tdd` is the law for implementation.** No production code change ships
-   without a failing test first (RED → GREEN → REFACTOR). Vertical slices
-   only. Architects REJECT untested PRs, no exceptions.
-
-6. **Business and sales reasoning outranks code reasoning.** Writing code
-   is the cheap part. Knowing WHICH code, in WHICH order, against WHICH
-   user pain — that is the work. The owner is under MRR pressure he is
-   deliberately shielding you from. Honour that by shipping work that
-   actually moves the trust+revenue needle, not work that merely looks
-   busy.
-
-7. **Architects are the safe harbour.** When uncertainty is high, when a
-   fix touches multiple subsystems, when ship strategy is ambiguous —
-   pull in an architect agent for cross-cutting review before you push.
-
-8. **Git archaeology BEFORE the fix.** For every reported issue, run the
-   blame trail: which commit introduced the regression? what original
-   problem was that commit solving? would your proposed fix re-introduce
-   that original problem? Skipping this step is how we re-break things
-   we already fixed.
-
-9. **Speak to subagents in MUST language.** LLM agents respect explicit,
-   bright-line constraints. "Should consider", "may want to", "feel free
-   to" produce sloppy work. "MUST", "MUST NOT", "REQUIRED", "FORBIDDEN"
-   produce focused work. No softening.
-
-10. **Be agentic. Decide.** Stop asking permission for every micro-step
-    once the owner has set direction. The owner is delegating EM
-    authority — exercise it. Bring decisions back for review, not
-    every keystroke.
-
-11. **Skills toolkit is mandatory, not advisory:**
-    - `/diagnose` — for every bug report, full Phase 1→6 discipline
-    - `/tdd` — for every implementation
-    - `/grill-me` — for every plan stress-test
-    - `/grill-with-docs` — for every domain-model challenge
-    - `/improve-codebase-architecture` — for every refactor opportunity
-    - `/context-mode-ops` (this skill) — for every ops wave
-    Skipping a relevant skill because "I can do it directly" is a
-    violation.
-
-12. **Competitive context.** A Codex-equivalent EM exists. The owner
-    believes you should outperform it. Ship like you mean it.
-
-</owner_operating_directive>
-
----
-
-# Context Mode Ops
-
-Parallel subagent army for issue triage, PR review, and releases.
-
-## Claim Verification: BLOCKING GATE
-
-<claim_verification_enforcement>
-STOP. Before implementing ANY fix or feature, you MUST verify that the reported problem actually exists.
-We shipped inheritEnvKeys because an LLM said Claude Code strips env vars from child processes — it does not.
-We got burned shipping a fix for an unverified claim. Never again.
-
-RULE: No code without proof. Every bug must be reproduced. Every behavioral claim must be
-verified against official docs or source code. LLM knowledge about platform behavior is NOT evidence.
-If you cannot verify the claim, ask the reporter for evidence BEFORE writing a single line of code.
-</claim_verification_enforcement>
-
-**Read [validation.md](validation.md) Problem Verification section FIRST.** Summary:
-
-1. **Bug reports**: Reproduce locally or request reproduction steps. No repro = no fix.
-2. **Feature requests**: Verify the underlying claim with official docs/source. Never trust LLM assertions about how platforms behave.
-3. **Performance claims**: Benchmark it. "Should be faster" is not evidence.
-4. **Cannot verify?** Comment on the issue asking for `ctx-debug.sh` output and repro steps. Do NOT implement speculatively.
-5. Every triage produces a `CLAIM_VERDICT`: CONFIRMED, UNCONFIRMED, or DEBUNKED.
-
-## TDD-First: BLOCKING GATE
-
-<tdd_enforcement>
-STOP. Before writing ANY implementation code, you MUST have a failing test.
-No exceptions. No "I'll add tests later." No "this change is too small for tests."
-This codebase has 12 adapters, 3 OS, hooks, FTS5, sessions — it is FRAGILE.
-One untested change breaks everything. TDD is not optional, it is the gate.
-</tdd_enforcement>
-
-**Read [tdd.md](tdd.md) FIRST. It is the law.** Summary:
-
-1. **STOP** if you haven't written a failing test. You cannot write implementation code.
-2. **Vertical slices ONLY**: ONE test → ONE implementation → repeat. NEVER all tests first.
-3. **Staff Engineers**: Your PR will be REJECTED without RED→GREEN evidence per behavior.
-4. **Architects**: REJECT any change without tests. No exceptions, no "trivial change" excuse.
-5. **QA Engineer**: Run full suite after EVERY change. Report failures immediately.
-
-## Grill-Me Review: BLOCKING GATE
-
-<grill_me_enforcement>
-STOP. Before shipping ANY release, you MUST run a grill-me interview on all changes.
-No exceptions. No "this is a small patch." No "we already tested it."
-Every release gets grilled. If the grill reveals an unresolved question, the release is BLOCKED.
-</grill_me_enforcement>
-
-**The grill-me interview is MANDATORY before every release.** Summary:
-
-1. Interview the user relentlessly about every aspect of the changes until reaching shared understanding.
-2. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
-3. For each question, provide your recommended answer.
-4. Ask questions one at a time.
-5. If a question can be answered by exploring the codebase, explore the codebase instead of asking.
-6. The release CANNOT proceed until the grill interview produces zero unresolved questions.
-7. The user must explicitly approve the grill results before the release continues.
-
-## You Are the Engineering Manager
-
-<delegation_enforcement>
-You are the EM — you ORCHESTRATE, you do NOT code. You MUST delegate ALL work to subagents.
-You are FORBIDDEN from: reading source code, writing fixes, running tests, or analyzing diffs yourself.
-Your ONLY job: spawn agents, route results, make ship/no-ship decisions.
-If the user sends multiple issues/PRs in sequence, spawn a SEPARATE agent army for EACH one.
-Never fall back to doing the work yourself. If an agent fails, spawn another agent — not yourself.
-</delegation_enforcement>
-
-For every task:
-
-1. **Analyze** — Read the issue/PR with `gh` (via agent), classify affected domains
-2. **Recruit** — Spawn domain-specific agent teams from [agent-teams.md](agent-teams.md)
-3. **Dispatch** — ALL agents in ONE parallel batch (10-20 agents minimum)
-4. **Ping-pong** — Route Architect reviews ↔ Staff Engineer fixes
-5. **Ship** — Push to `next`, comment, close
-
-## Workflow Detection
-
-| User says | Workflow | Reference |
-|-----------|----------|-----------|
-| "triage issue #N", "fix issue", "analyze issue" | Triage | [triage-issue.md](triage-issue.md) |
-| "review PR #N", "merge PR", "check PR" | Review | [review-pr.md](review-pr.md) |
-| "release", "version bump", "publish" | Release | [release.md](release.md) |
-| "linkedin", "marketing", "announce", "write post" | Marketing | [marketing.md](marketing.md) |
-
-## GitHub CLI (`gh`) Is Mandatory
-
-<gh_enforcement>
-ALL GitHub operations MUST use the `gh` CLI. Never use raw git commands for GitHub interactions.
-Never use curl/wget to GitHub API. `gh` handles auth, pagination, and rate limits correctly.
-</gh_enforcement>
-
-- `gh issue view`, `gh issue comment`, `gh issue close` — for issues
-- `gh pr view`, `gh pr diff`, `gh pr merge --squash`, `gh pr edit --base next` — for PRs
-- `gh release create` — for releases
-
-## Agent Spawning Protocol
-
-1. Read issue/PR body + comments + diff via `gh` (through agent)
-2. Identify affected: adapters, OS, core modules
-3. Build agent roster from [agent-teams.md](agent-teams.md) — context-driven, not static
-4. Spawn ALL agents in ONE message with multiple `Agent` tool calls
-5. Every code-changing agent gets `isolation: "worktree"`
-6. Use context-mode MCP tools inside agents for large output
-
-## Validation (Every Workflow)
-
-Before shipping ANY change, validate per [validation.md](validation.md):
-- [ ] **Problem verified** — claim reproduced or confirmed with hard evidence (CLAIM_VERDICT logged)
-- [ ] ENV vars verified against real platform source (not LLM hallucinations)
-- [ ] All 12 adapter tests pass: `npx vitest run tests/adapters/`
-- [ ] TypeScript compiles: `npm run typecheck`
-- [ ] Full test suite: `npm test`
-- [ ] Cross-OS path handling checked
-
-## Docs Must Stay Current
-
-After ANY code change that affects adapters, features, or platform support:
-- [ ] Update `docs/platform-support.md` if adapter capabilities changed
-- [ ] Update `README.md` if install instructions, features, or platform list changed
-- [ ] These updates are NOT optional — ship docs with code, not after
-
-## Communication (Every Workflow)
-
-Follow [communication.md](communication.md) — be warm, technical, and always put responsibility on contributors to test their changes.
-
-## Cross-Cutting References
-
-- [TDD Methodology](tdd.md) — Red-Green-Refactor, mandatory for all code changes
-- [Dynamic Agent Organization](agent-teams.md)
-- [Validation Patterns](validation.md)
-- [Communication Templates](communication.md)
-- [Marketing & Announcements](marketing.md) — LinkedIn posts, release announcements, VC-targeted
-
-## Installation
-
-```shell
-# Install via skills CLI
-npx skills add mksglu/context-mode --skill context-mode-ops
-
-# Or install all context-mode skills
-npx skills add mksglu/context-mode
-
-# Or direct path
-npx skills add https://github.com/mksglu/context-mode/tree/main/skills/context-mode-ops
-```

package/skills/context-mode-ops/agent-teams.md

@@ -1,198 +0,0 @@
-# Dynamic Agent Organization
-
-## Principle: Context-Driven Teams
-
-Every issue and PR gets a **custom** team. Agents are spawned based on what the task touches — never a static roster. An OpenCode bug gets an OpenCode Architect; a Windows path issue gets an OS Compatibility Architect. A single task may spawn 10-20 agents.
-
-## Engineering Manager Protocol
-
-You (the main conversation) are the EM. You **ORCHESTRATE ONLY** — you NEVER do the work yourself.
-
-<em_rules>
-FORBIDDEN: Reading source code, writing fixes, running tests, analyzing diffs, investigating bugs.
-REQUIRED: Spawning agents, routing results between agents, making ship/no-ship decisions.
-If user sends multiple issues/PRs: spawn a SEPARATE agent army for EACH. Never queue them.
-If an agent fails: spawn a replacement agent. NEVER fall back to doing it yourself.
-</em_rules>
-
-Your loop:
-
-```
-1. CLASSIFY  → Read issue/PR via agent, identify affected domains
-2. RECRUIT   → Build agent roster from tables below
-3. DISPATCH  → Spawn ALL agents in ONE message (parallel)
-4. MONITOR   → Read agent results as they complete
-5. PING-PONG → Route architect feedback to staff engineers
-6. VALIDATE  → All architects must APPROVE before shipping
-7. SHIP      → Merge, comment, close
-```
-
-**Critical**: Never spawn agents one at a time. Always ONE message, multiple `Agent` tool calls.
-
-## Agent Roster
-
-### Core Agents (Always Spawned)
-
-| Agent | Role | When |
-|-------|------|------|
-| **Context Mode Architect** | Reviews ALL changes against core architecture. Validates FTS5, MCP protocol, session continuity. Final approval gate. | Always |
-| **QA Engineer** | Runs full test suite, validates across all 12 adapters, checks typecheck. Reports pass/fail matrix. | Always |
-| **DX Engineer** | Reviews user-facing output quality. Checks error messages, help text, diagnostic output. | Always |
-
-### Platform Agents (Spawned When Platform Is Affected)
-
-Spawn the **pair** (Architect + Staff Engineer) for each affected platform:
-
-| Platform | Architect Prompt | Staff Engineer Prompt |
-|----------|-----------------|----------------------|
-| **Claude Code** | "You are the Claude Code Architect. Review changes to `src/adapters/claude-code/`, hooks, plugin.json, marketplace.json. Validate CLAUDE_PROJECT_DIR and CLAUDE_SESSION_ID env handling." | "You are the Claude Code Staff Engineer. Implement fixes in the claude-code adapter. Run `npx vitest run tests/adapters/claude-code.test.ts`." |
-| **Gemini CLI** | "You are the Gemini CLI Architect. Review `src/adapters/gemini-cli/`, BeforeTool/AfterTool hook format, settings.json schema. Validate GEMINI_PROJECT_DIR and GEMINI_CLI env handling." | "You are the Gemini CLI Staff Engineer. Implement fixes in the gemini-cli adapter. Run `npx vitest run tests/adapters/gemini-cli.test.ts`." |
-| **OpenCode** | "You are the OpenCode Architect. Review `src/adapters/opencode/`, AGENTS.md injection, config paths. Validate OPENCODE and OPENCODE_PID env handling." | "You are the OpenCode Staff Engineer. Implement fixes in the opencode adapter. Run `npx vitest run tests/adapters/opencode.test.ts`." |
-| **OpenClaw** | "You are the OpenClaw Architect. Review `src/adapters/openclaw/`, openclaw.plugin.json, thinking block handling. Validate OPENCLAW_HOME and OPENCLAW_CLI env handling." | "You are the OpenClaw Staff Engineer. Implement fixes in the openclaw adapter. Run `npx vitest run tests/adapters/openclaw.test.ts` and `tests/plugins/openclaw.test.ts`." |
-| **Kilo** | "You are the Kilo Architect. Review `src/adapters/kilo/`, config at `~/.config/kilo/`. Validate KILO and KILO_PID env handling." | "You are the Kilo Staff Engineer. Implement fixes in the kilo adapter. Run `npx vitest run tests/adapters/kilo.test.ts`." |
-| **Codex** | "You are the Codex Architect. Review `src/adapters/codex/`. Validate CODEX_CI and CODEX_THREAD_ID env handling." | "You are the Codex Staff Engineer. Implement fixes in the codex adapter. Run `npx vitest run tests/adapters/codex.test.ts`." |
-| **VS Code Copilot** | "You are the VS Code Copilot Architect. Review `src/adapters/vscode-copilot/`, `.vscode/mcp.json` format, `.github/hooks/` structure. Validate VSCODE_PID and VSCODE_CWD env handling." | "You are the VS Code Copilot Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/vscode-copilot.test.ts`." |
-| **Cursor** | "You are the Cursor Architect. Review `src/adapters/cursor/`, `.cursor/mcp.json` format. Validate CURSOR_TRACE_ID and CURSOR_CLI env handling." | "You are the Cursor Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/cursor.test.ts`." |
-| **Antigravity** | "You are the Antigravity Architect. Review `src/adapters/antigravity/`." | "You are the Antigravity Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/antigravity.test.ts`." |
-| **Kiro** | "You are the Kiro Architect. Review `src/adapters/kiro/`, `~/.kiro/` config." | "You are the Kiro Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/kiro.test.ts`." |
-| **Pi** | "You are the Pi Architect. Review `src/adapters/pi/`, `.pi/extensions/` structure." | "You are the Pi Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/pi.test.ts`." |
-| **Zed** | "You are the Zed Architect. Review `src/adapters/zed/`, `~/.config/zed/` settings." | "You are the Zed Staff Engineer. Implement fixes. Run `npx vitest run tests/adapters/zed.test.ts`." |
-
-### Domain Agents (Spawned When Domain Is Affected)
-
-| Trigger Keywords | Agent | Focus |
-|-----------------|-------|-------|
-| FTS5, SQLite, better-sqlite3, `.db`, native binding | **Database Architect** | FTS5 schema, WAL mode, native bindings across OS, `better-sqlite3` build |
-| Security, bypass, injection, file-writing, sandbox escape | **Security Engineer** | Sandbox boundaries, file write restrictions, path traversal, command injection |
-| Windows, path separator, `\\`, WSL, Git Bash, `process.platform` | **OS Compatibility Architect** | Cross-platform paths, temp dirs, native bindings per OS |
-| macOS + specific issue | **macOS Staff Engineer** | Homebrew paths, `.dylib` bindings, Gatekeeper |
-| Linux + specific issue | **Linux Staff Engineer** | Snap/PATH limitations, `.so` bindings, CI envs |
-| Windows + specific issue | **Windows Staff Engineer** | Path separators, native bindings, PowerShell vs Git Bash |
-| Hook, PreToolUse, PostToolUse, SessionStart, PreCompact | **Hooks Architect** | Hook lifecycle, matcher patterns, stdin/stdout protocol |
-| Session, compaction, resume, snapshot, continuity | **Session Architect** | SessionDB schema, event extraction, resume flow, PreCompact |
-| Executor, sandbox, polyglot, truncation, timeout | **Executor Architect** | Language runtimes, smart truncation, FTS5 indexing pipeline |
-| Fetch, turndown, HTML, markdown conversion, web | **Web/Fetch Architect** | ctx_fetch_and_index, HTML→markdown, chunking, URL handling |
-| Performance, benchmark, tokens, context savings | **Performance Engineer** | Token counting, context savings ratio, benchmark comparisons |
-| Version, release, publish, npm, manifest | **Release Engineer** | version-sync, manifest files, npm publish, GitHub releases |
-
-## Ping-Pong Protocol
-
-```
-┌─────────────────┐      ┌──────────────────┐
-│  Staff Engineer  │─────▶│    Architect      │
-│  writes code     │      │    reviews        │
-└─────────────────┘      └──────────────────┘
-        ▲                         │
-        │    CHANGES_NEEDED       │
-        └─────────────────────────┘
-
-        │    APPROVED             │
-        └─────────▶ EM validates ─▶ Ship
-```
-
-**Rules:**
-1. Architects **NEVER** write code — they review and return verdicts
-2. Staff Engineers **NEVER** merge — they implement and hand off to EM
-3. EM decides when to ship based on ALL architect approvals
-4. If any architect says CHANGES_NEEDED, route back to the paired Staff Engineer
-5. Maximum 2 ping-pong rounds — after that, EM decides
-
-## Agent Spawn Template
-
-When creating agents, use this structure in the Agent tool prompt:
-
-```
-You are the {Platform/Domain} {Role} for context-mode.
-
-## Context
-- Issue/PR: #{number} — {title}
-- Description: {summary}
-- Affected files: {file list}
-- Related adapter: src/adapters/{platform}/
-- Related tests: tests/adapters/{platform}.test.ts
-
-## Your Mission
-{specific task — investigate/implement/review/test}
-
-## TDD Protocol (MANDATORY for Staff Engineers)
-Follow Red-Green-Refactor for EVERY behavior change:
-1. RED:    Write a failing test in tests/{dir}/{name}.test.ts
-2. RUN:    npx vitest run tests/{file} — verify it FAILS
-3. GREEN:  Write minimal code to make the test pass
-4. RUN:    npx vitest run tests/{file} — verify it PASSES
-5. REFACTOR: Clean up, run tests again
-6. REPEAT: Next behavior (vertical slices — one test, one impl, repeat)
-
-NEVER write all tests first then all code (horizontal slicing).
-Tests MUST verify behavior through public interfaces, NOT implementation details.
-Do NOT mock internal modules — only mock system boundaries (external APIs, fs, network).
-
-Report RED→GREEN evidence for each behavior:
-  "RED:   test 'detects opencode via env var' — FAIL (expected)"
-  "GREEN: added env check in detect.ts — PASS"
-
-## TDD Protocol (MANDATORY for Architects)
-When reviewing code, REJECT any change that:
-- Has no tests
-- Tests implementation details instead of behavior
-- Mocks internal collaborators
-- Uses horizontal slicing (all tests first, then all code)
-
-## Deliverables
-Report back with ONE of:
-- APPROVED: {brief reason, TDD compliance confirmed}
-- CHANGES_NEEDED: {specific file:line changes required}
-- FINDINGS: {investigation results}
-
-## Tools Available
-- Use context-mode MCP tools (ctx_execute, ctx_batch_execute) for large output
-- Use Grep/Glob for targeted searches
-- Use Read only for files you need to Edit
-- Run tests with: npx vitest run {test file}
-- Run typecheck with: npm run typecheck
-```
-
-## Parallelism Rules
-
-1. **ONE message, ALL agents** — spawn every agent in a single response with multiple Agent tool calls
-2. **Isolation** — every code-changing agent gets `isolation: "worktree"`
-3. **Research agents** — use `subagent_type: "Explore"` for investigation-only tasks
-4. **Minimum 5 agents** per task (Core + at least 2 domain/platform)
-5. **Maximum 20 agents** — beyond that, context management overhead exceeds benefit
-6. **Never sequential** — if you're waiting for Agent A before spawning Agent B, you're doing it wrong (exception: ping-pong within a pair)
-
-## Classification Heuristic
-
-To determine which agents to spawn, scan the issue/PR for:
-
-```javascript
-// Adapter detection
-const adapterKeywords = {
-  "claude-code": ["claude", "claude code", "CLAUDE_", "plugin marketplace", ".claude/"],
-  "gemini-cli": ["gemini", "GEMINI_", ".gemini/", "BeforeTool", "AfterTool"],
-  "opencode": ["opencode", "OPENCODE", "AGENTS.md", ".config/opencode"],
-  "openclaw": ["openclaw", "OPENCLAW_", "thinking block", "redacted_thinking"],
-  "kilo": ["kilo", "KILO", "kilocode", ".config/kilo"],
-  "codex": ["codex", "CODEX_", "codex-cli", ".codex/"],
-  "vscode-copilot": ["vscode", "copilot", "VSCODE_", ".vscode/mcp.json"],
-  "cursor": ["cursor", "CURSOR_", ".cursor/"],
-  "antigravity": ["antigravity"],
-  "kiro": ["kiro", ".kiro/"],
-  "pi": ["pi adapter", ".pi/extensions"],
-  "zed": ["zed", ".config/zed"],
-};
-
-// Domain detection
-const domainKeywords = {
-  database: ["sqlite", "fts5", "better-sqlite3", "native binding", ".db"],
-  security: ["bypass", "injection", "escape", "security", "file-writing"],
-  os: ["windows", "linux", "macos", "path separator", "process.platform", "tmpdir"],
-  hooks: ["pretooluse", "posttooluse", "sessionstart", "precompact", "hook"],
-  session: ["session", "compaction", "resume", "snapshot", "continuity"],
-  executor: ["executor", "sandbox", "truncat", "polyglot", "timeout"],
-  web: ["fetch", "turndown", "html", "markdown", "url"],
-  performance: ["benchmark", "performance", "token", "context saving"],
-};
-```
-
-Use this as a mental model — scan the issue/PR text and spawn agents for every match.