docs(rebrand): rename & rebrand CI → CIAgent across all documentation, templates, and scripts

- README.md: title, project name, CLI commands, .ci/ → .ciagent/, ci-files → ciagent-files, CI Modification → CIAgent Modification - AGENTS.md: title, project name, architecture tree, agent count (18→19), test count (25→31 suites, 218→370 tests), version (0.4.0→0.6.0), ci-files → ciagent-files, CIConfig → CIAgentConfig, CiMetadata → CIAgentMetadata, .ci/ → .ciagent/ - templates/DECISIONS.md: .ci/audit/ → .ciagent/audit/, ci audit → ciagent audit - scripts/postinstall.js: CI postinstall → CIAgent postinstall - scripts/install.sh: CI → CIAgent, ci-init → ciagent-init, INSTALL COMPLETE banner - opencode/ci/workflows/*.md (11 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-command → ciagent-command usage lines - opencode/ci/references/*.md (5 files): .ci/ → .ciagent/, CI → CIAgent project name, ci-files → ciagent-files references - opencode/ci/contexts/*.md (3 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/agents/ci-*.md (18 files): .ci/ → .ciagent/, CI → CIAgent project name - opencode/command/ci-*.md (11 files): CI → CIAgent project name Preserved: ---ci---/---/ci--- markers, opencode/ci/ dir paths, ci-*.md filenames, ci listProjects()/ci setActiveProject() API names, repo URLs ---ci--- phase: 1 milestone: v0.6 plan: 01-01 task: 01-01-01 status: execute ---/ci---
2026-05-29 17:58:48 +00:00
parent ab6af144b7
commit e31afe3b59
53 changed files with 429 additions and 429 deletions
@@ -1,4 +1,4 @@
-# AGENTS.md — CI Project Guidelines
+# AGENTS.md — CIAgent Project Guidelines
 ## Build & Run Commands
@@ -9,16 +9,16 @@
 ## Project Overview
-CI (Continuous Intelligence) is a fully autonomous AI-driven software engineering harness. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline (research → plan → execute → verify) autonomously, escalating only when it cannot safely proceed alone.
+CIAgent (Continuous Intelligence) is a fully autonomous AI-driven software engineering harness. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline (research → plan → execute → verify) autonomously, escalating only when it cannot safely proceed alone.
 ## Architecture
 ```
 src/
-  agents/          # 18 agent implementations (persona loaders delegating to backends)
+  agents/          # 19 agent implementations (persona loaders delegating to backends)
  backends/        # Intelligence backend layer
    types.ts      # IntelligenceBackend, BackendRequest, BackendResult, BackendConfigSection
-    tool-registry.ts  # CI-owned tool implementations (readFile, writeFile, editFile, runBash, glob, grep)
+    tool-registry.ts  # CIAgent-owned tool implementations (readFile, writeFile, editFile, runBash, glob, grep)
    ollama-base.ts   # Abstract base for Ollama backends (shared tool loop, prompt construction)
    ollama-local.ts  # OllamaLocalBackend (localhost:11434)
    ollama-cloud.ts  # OllamaCloudBackend (remote endpoint, auth, rate limiting)
@@ -26,21 +26,21 @@ src/
    index.ts         # Backend registry + auto-detection
  cli/             # Commander.js CLI (commands.ts, index.ts)
  core/            # Core engine components
-     artifacts.ts   # Legacy .ci/ artifact management (retained for backward compat)
+     artifacts.ts   # Legacy .ciagent/ artifact management (retained for backward compat)
-    audit.ts       # Legacy audit trail in .ci/audit/ (retained for backward compat)
+    audit.ts       # Legacy audit trail in .ciagent/audit/ (retained for backward compat)
-    ci-files.ts    # .ci/ long-lived reference file management (PROJECT.md, ROADMAP.md, etc.)
+    ciagent-files.ts    # .ciagent/ long-lived reference file management (PROJECT.md, ROADMAP.md, etc.)
    clarify.ts     # Clarify phase: question generation, default acceptance
    commit-builder.ts  # Structured commit message generation (---ci--- YAML blocks)
    commit-parser.ts   # ---ci--- YAML block extraction and parsing
-    config.ts      # .ci/config.json load/save/init
+    config.ts      # .ciagent/config.json load/save/init
    decision-engine.ts  # Bounded rationality: commits decisions as git artifacts
    error-recovery.ts   # Retry, plan revision, rollback logic
    escalation.ts  # Escalation protocol: commits escalations as git artifacts
    git-branch.ts  # Branch lifecycle: phase/NN-slug, milestone/vX.X-slug
    git-context.ts # Project state reconstruction from git log + branches
  types/           # Type definitions
-    commit-meta.ts # CiMetadata, CommitDecision, CommitEscalation, ParsedCiCommit
+    commit-meta.ts # CIAgentMetadata, CommitDecision, CommitEscalation, ParsedCIAgentCommit
-    config.ts      # CIConfig, AutonomyLevel, ModelProfile, DEFAULT_CI_CONFIG (includes backend)
+    config.ts      # CIAgentConfig, AutonomyLevel, ModelProfile, DEFAULT_CIAGENT_CONFIG (includes backend)
    decisions.ts   # Decision, ConfidenceLevel, DecisionCategory
    escalation.ts  # Escalation, EscalationType, EscalationResolution
    clarify.ts     # ClarifyQuestion, ClarifyResult
@@ -53,7 +53,7 @@ src/
     security.ts    # Layer 3: regex-based threat pattern scanning (no STRIDE analysis yet)
     quality.ts     # Layer 4: regex-based code quality checks (no multi-persona review yet)
  index.ts         # Public API exports
-  version.ts       # VERSION = "0.4.0"
+  version.ts       # VERSION = "0.6.0"
 templates/         # Template files (config.json, DECISIONS.md, specification.md)
 ```
@@ -62,9 +62,9 @@ templates/         # Template files (config.json, DECISIONS.md, specification.md
 - **Autonomy levels**: `full` (no HITL after clarify), `supervised` (escalate on gates + verification failures), `guided` (escalate on every decision gate)
 - **Decision confidence thresholds**: High (>0.85) auto-decide and log; Medium (0.60–0.85) auto-decide with assumption logging; Low (<0.60) escalate to human
 - **Escalation timeout**: Default 5 minutes, then auto-proceeds with recommended option. Set to `0` to require human, `-1` to always auto-proceed
- **18 agents** purpose-built for CI, all configured for autonomous operation. OrchestratorAgent is CI-specific
+- **19 agents** purpose-built for CIAgent, all configured for autonomous operation. OrchestratorAgent is CIAgent-specific
- **Git-native context**: The git log IS the project memory. Agent's first impulse to gather context is `git log` + `git branch`, not file reads. Dynamic state (decisions, escalations, lessons, compounding) lives in `---ci---` YAML blocks in commit messages. `.ci/` holds only long-lived reference docs (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json).
+- **Git-native context**: The git log IS the project memory. Agent's first impulse to gather context is `git log` + `git branch`, not file reads. Dynamic state (decisions, escalations, lessons, compounding) lives in `---ci---` YAML blocks in commit messages. `.ciagent/` holds only long-lived reference docs (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json).
- **Artifact compatibility**: CI no longer writes `.planning/` schema. Dynamic state is derived from git history. `.ci/` files follow a CI-native schema.
+- **Artifact compatibility**: CIAgent no longer writes `.planning/` schema. `.ciagent/` files follow a CIAgent-native schema.
 ## Code Conventions
@@ -73,7 +73,7 @@ templates/         # Template files (config.json, DECISIONS.md, specification.md
 - **Agent pattern**: All agents extend `BaseAgent` with `name` (AgentName), `description`, `workflow`, and `execute(context: AgentContext): Promise<AgentResult>`. Agents delegate to `context.backend` when available, fail honestly when not.
 - **No runtime validation library**: Uses plain TypeScript types, not Zod schemas (Zod is a dependency but types are hand-defined)
 - **File I/O**: Use `src/utils/file.ts` helpers (`writeFile`, `readFile`, `ensureDir`, `readJSON`, `writeJSON`) instead of raw `fs` calls in agent/business logic
- **Config**: `CIConfig` type and `DEFAULT_CI_CONFIG` in `src/types/config.ts` — always merge partial configs with defaults
+- **Config**: `CIAgentConfig` type and `DEFAULT_CIAGENT_CONFIG` in `src/types/config.ts` — always merge partial configs with defaults
 - **Error handling**: Agents return `{ success: false, error: string }` rather than throwing
 - **No comments in code**: Follow existing pattern — agent files have no comments
 - **Naming**: `camelCase` for functions/variables, `PascalCase` for classes/types/interfaces, `kebab-case` for file names
@@ -91,20 +91,20 @@ Each stage is executed by `OrchestratorAgent.executeStage()`. The orchestrator d
 ```
 IntelligenceBackend (unified interface)
-├── LLMBackend (CI runs tool loop, provides tools, constructs prompts)
+├── LLMBackend (CIAgent runs tool loop, provides tools, constructs prompts)
 │   ├── OllamaLocalBackend     (localhost:11434, no auth)
 │   ├── OllamaCloudBackend     (remote endpoint, API key, rate limits)
 │   └── (future: OpenAI, Anthropic, Gemini, etc.)
-└── AgentBackend (agent runs own tool loop, CI sends request)
+└── AgentBackend (agent runs own tool loop, CIAgent sends request)
    ├── OpencodeBackend        (opencode --non-interactive)
    └── (future: Codex, Claude Code, Hermes, etc.)
 ```
- **LLM backends**: CI constructs system prompts from persona.md + workflow.md, defines tool schemas, runs the tool-call loop via `ToolRegistry`, and parses structured JSON output
+- **LLM backends**: CIAgent constructs system prompts from persona.md + workflow.md, defines tool schemas, runs the tool-call loop via `ToolRegistry`, and parses structured JSON output
- **Agent backends**: CI serializes `BackendRequest`, invokes the agent, and parses JSON `BackendResult` from stdout
+- **Agent backends**: CIAgent serializes `BackendRequest`, invokes the agent, and parses JSON `BackendResult` from stdout
 - **Auto-detection** (provider: "auto"): tries opencode → ollama-local → ollama-cloud → fails with instructions
- **Per-command override**: `ci run --backend ollama-local` forces a specific backend
+- **Per-command override**: `ciagent run --backend ollama-local` forces a specific backend
- **Config**: `backend` section in `.ci/config.json` with provider, fallback, agent_backends, llm_backends
+- **Config**: `backend` section in `.ciagent/config.json` with provider, fallback, agent_backends, llm_backends
 ## Agent Modification Rules (from PRD)
@@ -131,17 +131,17 @@ IntelligenceBackend (unified interface)
 - Test framework: Jest with ts-jest
 - Test file pattern: `**/*.test.ts` in `src/`
 - Run: `npm run test`
- 25 test suites, 218 tests covering types, core, git-native, verification, and utility modules
+- 31 test suites, 370 tests covering types, core, git-native, verification, and utility modules
 - Tests use temp directories (os.mkdtempSync) and clean up after each test
 - Module resolution in jest uses moduleNameMapper to strip `.js` extensions
 ## Important Files
- `.ci/config.json` — Project-level CI configuration (autonomy, parallelization, verification, security, git)
+- `.ciagent/config.json` — Project-level CIAgent configuration (autonomy, parallelization, verification, security, git)
- `.ci/PROJECT.md` — Vision, core value, requirements, constraints, key decisions table
+- `.ciagent/PROJECT.md` — Vision, core value, requirements, constraints, key decisions table
- `.ci/ARCHITECTURE.md` — System architecture, component boundaries, data flow
+- `.ciagent/ARCHITECTURE.md` — System architecture, component boundaries, data flow
- `.ci/ROADMAP.md` — Phase breakdown, milestone mapping, success criteria, progress table
+- `.ciagent/ROADMAP.md` — Phase breakdown, milestone mapping, success criteria, progress table
- `.ci/REQUIREMENTS.md` — v1/v2 requirements with REQ-IDs and traceability matrix
+- `.ciagent/REQUIREMENTS.md` — v1/v2 requirements with REQ-IDs and traceability matrix
 - Git log — Primary project memory: decisions, escalations, lessons, compounding, verification results
 - Branch structure — `phase/NN-slug` (active/complete) and `milestone/vX.X-slug` branches
@@ -191,16 +191,16 @@ IntelligenceBackend (unified interface)
 ## Current State
- **v0.4.0**: Backends module (OllamaLocal, OllamaCloud, Opencode), learnship references removed, verification layers migrated from .planning/ to .ci/
+- **v0.6.0**: Backends module (OllamaLocal, OllamaCloud, Opencode), learnship references removed, verification layers migrated from .planning/ to .ciagent/
- **New modules**: commit-parser (`---ci---` YAML block extraction/parsing), commit-builder (structured commit message generation), git-context (project state reconstruction from git log + branches), git-branch (phase/milestone branch lifecycle), ci-files (`.ci/` long-lived reference file management)
+- **New modules**: commit-parser (`---ci---` YAML block extraction/parsing), commit-builder (structured commit message generation), git-context (project state reconstruction from git log + branches), git-branch (phase/milestone branch lifecycle), ciagent-files (`.ciagent/` long-lived reference file management)
- **Commit schema**: Every CI-generated commit contains a `---ci---` YAML block with phase, milestone, status, decisions, escalations, requirements, lessons, and compound metadata
+- **Commit schema**: Every CIAgent-generated commit contains a `---ci---` YAML block with phase, milestone, status, decisions, escalations, requirements, lessons, and compound metadata
 - **Branch strategy**: `phase/NN-slug` and `milestone/vX.X-slug` branches encode project structure; merged = complete, active = in progress
 - **Core engine rewrites**: DecisionEngine generates commit messages (not audit JSON), EscalationProtocol commits escalations as git artifacts, OrchestratorAgent uses git log as first impulse
- **Removed**: `.ci/audit/` directory (audit trail is git log), `.planning/` directory (dynamic state derived from git history)
+- **Removed**: `.ciagent/audit/` directory (audit trail is git log), `.planning/` directory (dynamic state derived from git history)
- **`.ci/` contents**: `config.json`, `PROJECT.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `REQUIREMENTS.md` — long-lived reference docs updated with discipline
+- **`.ciagent/` contents**: `config.json`, `PROJECT.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `REQUIREMENTS.md` — long-lived reference docs updated with discipline
 - **Reconstruction test**: An agent with only commit message access can reconstruct project state (phase, decisions, requirements coverage, lessons, escalations)
- **Verification layers**: All 4 layers implemented — structural, behavioral, security (STRIDE), quality
+- **Verification layers**: All 4 layers implemented — structural, behavioral, security, quality
 - **CLI**: All 11 commands wired up (`init`, `run`, `quick`, `debug`, `verify`, `review`, `status`, `audit`, `clarify`, `rollback`, `ship`)
 - **Agent implementations**: Persona loaders that delegate to active backend. Fail honestly when no backend is available (no more fake success).
 - **Intelligence backends**: OllamaLocal (LLM, localhost), OllamaCloud (LLM, remote), Opencode (Agent, --non-interactive). Auto-detection: opencode → ollama-local → ollama-cloud.
- **Tests**: 27 test suites covering types, config, decision-engine, escalation, clarify, commit-parser, commit-builder, git-context, git-branch, ci-files, all 4 verification layers, file utils, backends, tool-registry
+- **Tests**: 31 test suites, 370 tests covering types, config, decision-engine, escalation, clarify, commit-parser, commit-builder, git-context, git-branch, ciagent-files, all 4 verification layers, file utils, backends, tool-registry
@@ -1,10 +1,10 @@
-# CI — Continuous Intelligence
+# CIAgent — Continuous Intelligence
 Fully autonomous, git-native AI-driven software engineering harness.
 ## Overview
-CI (Continuous Intelligence) is an autonomous-first software engineering harness that eliminates human-in-the-loop overhead while preserving the rigor of guided development. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline — research, plan, execute, verify — autonomously.
+CIAgent (Continuous Intelligence) is an autonomous-first software engineering harness that eliminates human-in-the-loop overhead while preserving the rigor of guided development. It receives a specification, resolves ambiguities through a single Clarify phase, then executes the full pipeline — research, plan, execute, verify — autonomously.
 **The git log IS the project memory.** Every decision, escalation, lesson learned, and verification result is encoded in commit messages using structured `---ci---` YAML blocks. An agent's first impulse to gather context is `git log`, not file reads. Another agent with access to only commit messages (no code, no diffs) can reconstruct the project state completely.
@@ -14,7 +14,7 @@ From source (package not yet published to npm):
 ```bash
 git clone https://git.cloudinit.dev/continuous-intelligence/ci.git
-cd ci
+cd ciagent
 npm install
 npm run build
 npm link
@@ -24,45 +24,45 @@ npm link
 ```bash
 # Initialize from inline specification
-ci init "Build a REST API for task management"
+ciagent init "Build a REST API for task management"
 # Initialize from a specification file
-ci init --spec ./specs/my-project.md
+ciagent init --spec ./specs/my-project.md
 # Run the full autonomous pipeline
-ci run --all
+ciagent run --all
 # Run a specific phase
-ci run research
+ciagent run research
-ci run plan
+ciagent run plan
-ci run execute
+ciagent run execute
-ci run verify
+ciagent run verify
 # Execute an ad-hoc task
-ci quick "Add authentication middleware"
+ciagent quick "Add authentication middleware"
 # Check project status (reads from git log + branches)
-ci status
+ciagent status
 # Review autonomous decisions (extracted from git log ---ci--- blocks)
-ci audit
+ciagent audit
-ci audit --verbose
+ciagent audit --verbose
 # Debug an issue
-ci debug "Tests failing on CI"
+ciagent debug "Tests failing on CI"
 # Rollback a phase
-ci rollback 1
+ciagent rollback 1
 # Ship a phase (verify, security, commit, tag)
-ci ship 1
+ciagent ship 1
 ```
 ## Git-Native Architecture (v0.2.0)
 ### The Commit Schema
-Every CI-generated commit contains a `---ci---` YAML block with structured metadata:
+Every CIAgent-generated commit contains a `---ci---` YAML block with structured metadata:
 ```
 feat(P01-01-02): create user registration endpoint
@@ -92,11 +92,11 @@ requirements:
 | Where | What | Why |
 |-------|------|-----|
-| `.ci/config.json` | Autonomy, thresholds, git strategy | Controls system behavior before any commits exist |
+| `.ciagent/config.json` | Autonomy, thresholds, git strategy | Controls system behavior before any commits exist |
-| `.ci/PROJECT.md` | Vision, core value, requirements, constraints, key decisions table | Long-lived strategic reference |
+| `.ciagent/PROJECT.md` | Vision, core value, requirements, constraints, key decisions table | Long-lived strategic reference |
-| `.ci/ARCHITECTURE.md` | System architecture, component boundaries, data flow | Long-lived technical reference |
+| `.ciagent/ARCHITECTURE.md` | System architecture, component boundaries, data flow | Long-lived technical reference |
-| `.ci/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria | Long-lived planning reference |
+| `.ciagent/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria | Long-lived planning reference |
-| `.ci/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs and traceability | Long-lived requirements reference |
+| `.ciagent/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs and traceability | Long-lived requirements reference |
 | **Git commit bodies** | Decisions, escalations, lessons, compounds, verification results | Dynamic event stream — the audit trail |
 | **Git branches** | Phase/milestone status | `phase/NN-slug` and `milestone/vX.X-slug` encode project structure |
@@ -121,17 +121,17 @@ An agent starting a session gathers context in this order:
 1. `git log --oneline -20` — recent activity
 2. `git branch -a` — phase/milestone structure
 3. `git log -1 --format="%b"` — latest `---ci---` block
-4. `.ci/config.json` — autonomy + thresholds
+4. `.ciagent/config.json` — autonomy + thresholds
-5. `.ci/PROJECT.md` — vision + constraints (when needed)
+5. `.ciagent/PROJECT.md` — vision + constraints (when needed)
-6. `.ci/ROADMAP.md` — phase plan + success criteria (when needed)
+6. `.ciagent/ROADMAP.md` — phase plan + success criteria (when needed)
-7. `.ci/REQUIREMENTS.md` — REQ-IDs + traceability (when planning)
+7. `.ciagent/REQUIREMENTS.md` — REQ-IDs + traceability (when planning)
-8. `.ci/ARCHITECTURE.md` — system structure (when researching)
+8. `.ciagent/ARCHITECTURE.md` — system structure (when researching)
 Steps 1-3 take <1 second and provide 80% of the context needed.
 ### The Reconstruction Test
-An agent with access to **only commit messages** (no code, no diffs, no `.ci/` files) can reconstruct:
+An agent with access to **only commit messages** (no code, no diffs, no `.ciagent/` files) can reconstruct:
 | Reconstructable | How |
 |---------------|-----|
@@ -148,7 +148,7 @@ An agent with access to **only commit messages** (no code, no diffs, no `.ci/` f
 ### Commit Types
-In addition to conventional commit types, CI uses:
+In addition to conventional commit types, CIAgent uses:
 | Type | When Used |
 |------|-----------|
@@ -168,7 +168,7 @@ In addition to conventional commit types, CI uses:
 ## Configuration
-CI uses `.ci/config.json` for project configuration:
+CIAgent uses `.ciagent/config.json` for project configuration:
 ```json
 {
@@ -224,7 +224,7 @@ SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE
 | `commit-builder` | Structured commit message generation for all commit types |
 | `git-context` | Project state reconstruction from `git log` + `git branch` |
 | `git-branch` | Phase/milestone branch lifecycle management |
-| `ci-files` | `.ci/` long-lived reference file management with update discipline |
+| `ciagent-files` | `.ciagent/` long-lived reference file management with update discipline |
 ### Decision Engine
@@ -237,7 +237,7 @@ Decisions are committed to git as `decision` type commits. The audit trail is `g
 ### 18 Agents
-| Agent | Role | CI Modification |
+| Agent | Role | CIAgent Modification |
 |-------|------|----------------|
 | orchestrator | Pipeline controller | Git-first context loading, `---ci---` commit generation |
 | planner | Plan creation | Never sets `autonomous: false` |
@@ -280,7 +280,7 @@ Build a REST API for task management.
 ## Escalation Protocol
-When CI cannot proceed autonomously:
+When CIAgent cannot proceed autonomously:
 1. **Irreversible Action**: Deploy, delete, merge to protected branch
 2. **Verification Failure**: Tests pass but functional verification fails
@@ -298,10 +298,10 @@ Each escalation is committed as an `escalation` type commit. Resolved escalation
 ## Differences from Learnship
-| Dimension | Learnship | CI |
+| Dimension | Learnship | CIAgent |
 |-----------|-----------|-----|
 | Project memory | `.planning/` directory files (legacy) | Git log + `---ci---` commit blocks |
-| Audit trail | `.ci/audit/*.json` files (legacy) | `git log --grep="decisions:"` |
+| Audit trail | `.ciagent/audit/*.json` files (legacy) | `git log --grep="decisions:"` |
 | State management | `STATE.md` + `STATE.md.json` (legacy) | Reconstructed from git on demand |
 | Phase discovery | Read `.planning/phases/` directory (legacy) | `git branch -a \| grep phase/` |
 | Human Interactions | 19+/lifecycle | 1-2/lifecycle |
@@ -1,5 +1,5 @@
 ---
-description: Stress-tests CI proposals through product and engineering lenses using forcing questions. Binding verdicts — only escalates when confidence < 0.60.
+description: Stress-tests CIAgent proposals through product and engineering lenses using forcing questions. Binding verdicts — only escalates when confidence < 0.60.
 color: "#FFA500"
 tools:
  read: true
@@ -9,28 +9,28 @@ tools:
 ---
 <role>
-You are a CI challenger. You stress-test proposals through product and engineering lenses using forcing questions that expose weak assumptions.
+You are a CIAgent challenger. You stress-test proposals through product and engineering lenses using forcing questions that expose weak assumptions.
-CI challengers produce binding verdicts. Only escalate when confidence < 0.60. If confident the proposal is sound, it proceeds. If confident it needs rework, it is sent back.
+CIAgent challengers produce binding verdicts. Only escalate when confidence < 0.60. If confident the proposal is sound, it proceeds. If confident it needs rework, it is sent back.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before challenging, load context from git first:
 1. Run `git log --max-count=30` for recent decisions and project history
 2. Use GitContext.getDecisions(currentPhase) for phase decisions
-3. Read `.ci/PROJECT.md` for project vision and constraints
+3. Read `.ciagent/PROJECT.md` for project vision and constraints
-4. Read `.ci/ARCHITECTURE.md` for component boundaries
+4. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 5. Use GitContext.getCompounds() for compound learnings
 </project_context>
@@ -44,7 +44,7 @@ Read the proposal and all git context. Extract settled decisions that should not
 For assigned lens (product or engineering):
 1. Select 3-5 forcing questions most relevant to the proposal
-2. Answer each based on evidence from git history and .ci/ files
+2. Answer each based on evidence from git history and .ciagent/ files
 3. Note confidence level for each answer
 ### Product Lens Questions
@@ -1,5 +1,5 @@
 ---
-description: Reviews CI code changes through a specific persona lens (correctness, testing, security, performance, maintainability, adversarial). Auto-applies P0 fixes. Flags P1+ for post-hoc review.
+description: Reviews CIAgent code changes through a specific persona lens (correctness, testing, security, performance, maintainability, adversarial). Auto-applies P0 fixes. Flags P1+ for post-hoc review.
 color: "#FF69B4"
 tools:
  read: true
@@ -10,20 +10,20 @@ tools:
 ---
 <role>
-You are a CI code reviewer. You review code changes through a specific persona lens, finding issues by severity and confidence.
+You are a CIAgent code reviewer. You review code changes through a specific persona lens, finding issues by severity and confidence.
-CI code reviewers auto-apply P0 fixes. P1+ issues are flagged for post-hoc review via `git log --grep="review"`.
+CIAgent code reviewers auto-apply P0 fixes. P1+ issues are flagged for post-hoc review via `git log --grep="review"`.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before reviewing, load context from git first:
@@ -31,7 +31,7 @@ Before reviewing, load context from git first:
 1. Run `git log --max-count=10` for recent changes
 2. Run `git diff HEAD~3` to see the changes being reviewed
 3. Use GitContext.getDecisions() for design decisions that explain choices
-4. Read `.ci/ARCHITECTURE.md` for component boundaries
+4. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 5. Read `./AGENTS.md` for project conventions and coding standards
 </project_context>
@@ -11,20 +11,20 @@ tools:
 ---
 <role>
-You are a CI debugger. You investigate bugs using systematic scientific method — forming hypotheses, testing them against the codebase, and finding the exact root cause.
+You are a CIAgent debugger. You investigate bugs using systematic scientific method — forming hypotheses, testing them against the codebase, and finding the exact root cause.
-CI debuggers auto-diagnose and auto-fix when confidence > 0.60. Only low-confidence root causes are escalated to human.
+CIAgent debuggers auto-diagnose and auto-fix when confidence > 0.60. Only low-confidence root causes are escalated to human.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before debugging, load context from git first:
@@ -33,7 +33,7 @@ Before debugging, load context from git first:
 2. Run `git diff HEAD~5` to see recent file changes
 3. Use GitContext.getDecisions() for decisions that may be relevant
 4. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 </project_context>
 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Verifies CI documentation matches the live codebase — catches stale docs, missing sections, incorrect references. Uses git diff to detect code/doc drift.
+description: Verifies CIAgent documentation matches the live codebase — catches stale docs, missing sections, incorrect references. Uses git diff to detect code/doc drift.
 color: "#F0E68C"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---
 <role>
-You are a CI doc verifier. You verify that documentation matches the live codebase by catching stale docs, missing sections, and incorrect references.
+You are a CIAgent doc verifier. You verify that documentation matches the live codebase by catching stale docs, missing sections, and incorrect references.
 You use git diff and codebase analysis to detect drift between documentation and implementation.
@@ -18,18 +18,18 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before verifying, load context from git first:
 1. Run `git diff HEAD~10` to see recent code changes
 2. Run `git log --max-count=20` for recent doc updates
-3. Read `.ci/PROJECT.md`, `.ci/ARCHITECTURE.md`, `.ci/REQUIREMENTS.md`, `.ci/ROADMAP.md`
+3. Read `.ciagent/PROJECT.md`, `.ciagent/ARCHITECTURE.md`, `.ciagent/REQUIREMENTS.md`, `.ciagent/ROADMAP.md`
 4. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
 </project_context>
@@ -37,7 +37,7 @@ Before verifying, load context from git first:
 ## Step 1: Load Documentation
-Read all .ci/ documentation files. Read the codebase for actual state.
+Read all .ciagent/ documentation files. Read the codebase for actual state.
 ## Step 2: Cross-Reference
@@ -1,5 +1,5 @@
 ---
-description: Writes and updates CI project documentation files — grounded in the live codebase, verifies factual claims. Documentation updates are committed with ---ci--- blocks.
+description: Writes and updates CIAgent project documentation files — grounded in the live codebase, verifies factual claims. Documentation updates are committed with ---ci--- blocks.
 color: "#90EE90"
 tools:
  read: true
@@ -11,20 +11,20 @@ tools:
 ---
 <role>
-You are a CI doc writer. You write and update CI project documentation files, grounded in the live codebase. You verify factual claims against actual code.
+You are a CIAgent doc writer. You write and update CIAgent project documentation files, grounded in the live codebase. You verify factual claims against actual code.
-Documentation updates are committed with `---ci---` blocks. You update `.ci/` static files (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md) with discipline.
+Documentation updates are committed with `---ci---` blocks. You update `.ciagent/` static files (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md) with discipline.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before writing, load context from git first:
@@ -32,7 +32,7 @@ Before writing, load context from git first:
 1. Run `git log --max-count=20` for recent changes that affect docs
 2. Use GitContext.getDecisions() for decisions to document
 3. Use GitContext.getRequirementsCoverage() for current coverage
-4. Read the existing .ci/ file you're updating
+4. Read the existing .ciagent/ file you're updating
 5. Read the relevant source code to verify claims
 </project_context>
@@ -51,7 +51,7 @@ Before writing any factual claim:
 ## Step 3: Write/Update Documentation
-Use CiFiles methods to write .ci/ files:
+Use CiFiles methods to write .ciagent/ files:
 - writeProjectMd(project, reason)
 - writeArchitectureMd(architecture)
 - writeRoadmapMd(roadmap)
@@ -1,5 +1,5 @@
 ---
-description: Executes a single CI plan atomically — one task at a time with per-task commits and ---ci--- blocks. Never pauses for checkpoint. Creates automated verification scripts for traditionally human tasks.
+description: Executes a single CIAgent plan atomically — one task at a time with per-task commits and ---ci--- blocks. Never pauses for checkpoint. Creates automated verification scripts for traditionally human tasks.
 color: "#FFFF00"
 tools:
  read: true
@@ -11,20 +11,20 @@ tools:
 ---
 <role>
-You are a CI executor. You execute plan tasks atomically — one task at a time, committing after each with `---ci---` blocks.
+You are a CIAgent executor. You execute plan tasks atomically — one task at a time, committing after each with `---ci---` blocks.
-CI executors NEVER pause for checkpoints. Every task is autonomous. Create automated verification scripts for traditionally human tasks (manual testing, visual inspection, etc.).
+CIAgent executors NEVER pause for checkpoints. Every task is autonomous. Create automated verification scripts for traditionally human tasks (manual testing, visual inspection, etc.).
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before executing, load context from git first:
@@ -32,8 +32,8 @@ Before executing, load context from git first:
 1. Run `git log --max-count=20` for recent project history
 2. Use GitContext.reconstructState() for current phase, milestone, stage
 3. Use GitContext.getDecisions(currentPhase) for phase decisions
-4. Read `.ci/PROJECT.md` for project constraints
+4. Read `.ciagent/PROJECT.md` for project constraints
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 6. Read `./AGENTS.md` or `./CLAUDE.md` for project conventions
 </project_context>
@@ -41,7 +41,7 @@ Before executing, load context from git first:
 ## Step 1: Load Context
-Read the plan file. Extract wave, files_modified, autonomous (always true in CI), must_haves.
+Read the plan file. Extract wave, files_modified, autonomous (always true in CIAgent), must_haves.
 Load git context for current state and decisions.
@@ -1,5 +1,5 @@
 ---
-description: Generates codebase-grounded improvement ideas through a specific thinking frame for CI. Uses git history to understand the codebase evolution.
+description: Generates codebase-grounded improvement ideas through a specific thinking frame for CIAgent. Uses git history to understand the codebase evolution.
 color: "#FFD700"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---
 <role>
-You are a CI ideation agent. You generate codebase-grounded improvement ideas through a specific thinking frame. You use git history to understand the codebase evolution and identify improvement opportunities.
+You are a CIAgent ideation agent. You generate codebase-grounded improvement ideas through a specific thinking frame. You use git history to understand the codebase evolution and identify improvement opportunities.
 You do not implement changes. You produce ideas with rationale for the orchestrator to evaluate and potentially plan.
@@ -18,11 +18,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before ideating, load context from git first:
@@ -31,15 +31,15 @@ Before ideating, load context from git first:
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings
 4. Use GitContext.getLessons() for lessons that suggest improvements
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
-6. Read `.ci/REQUIREMENTS.md` for incomplete requirements
+6. Read `.ciagent/REQUIREMENTS.md` for incomplete requirements
 </project_context>
 <execution_flow>
 ## Step 1: Load Context
-Read git history and .ci/ files. Understand the codebase's current state and evolution.
+Read git history and .ciagent/ files. Understand the codebase's current state and evolution.
 ## Step 2: Apply Thinking Frame
@@ -1,5 +1,5 @@
 ---
-description: Orchestrates the full CI pipeline by iterating through pipeline stages, loading context from the git log first, and delegating to specialized agents. The orchestrator is CI-specific — it drives the SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE flow.
+description: Orchestrates the full CIAgent pipeline by iterating through pipeline stages, loading context from the git log first, and delegating to specialized agents. The orchestrator is CIAgent-specific — it drives the SPECIFY → CLARIFY → RESEARCH → PLAN → EXECUTE → VERIFY → COMPLETE flow.
 color: "#00BFFF"
 tools:
  read: true
@@ -11,9 +11,9 @@ tools:
 ---
 <role>
-You are the CI orchestrator. You drive the full CI pipeline by iterating through pipeline stages, making git-first context loading decisions, and delegating to specialized agents.
+You are the CIAgent orchestrator. You drive the full CIAgent pipeline by iterating through pipeline stages, making git-first context loading decisions, and delegating to specialized agents.
-CI operates autonomously after the clarify phase. You never pause for human checkpoints unless a decision falls below the confidence threshold or an escalation hook is triggered.
+CIAgent operates autonomously after the clarify phase. You never pause for human checkpoints unless a decision falls below the confidence threshold or an escalation hook is triggered.
 Your job: Execute stages in order, collect PhaseResult for each, handle errors via ErrorRecovery, and produce a final project outcome.
@@ -22,11 +22,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before any operation, load project context from git first:
@@ -37,9 +37,9 @@ Before any operation, load project context from git first:
 4. Use GitContext.getEscalations() for any pending escalations
 5. Use GitContext.getRequirementsCoverage() for covered/partial requirements
 6. Use GitContext.getLessons() for learned lessons
-7. Read `.ci/config.json` for autonomy level and parallelization settings
+7. Read `.ciagent/config.json` for autonomy level and parallelization settings
-8. Read `.ci/PROJECT.md` for project vision and constraints
+8. Read `.ciagent/PROJECT.md` for project vision and constraints
-9. Read `.ci/ROADMAP.md` for phase breakdown and success criteria
+9. Read `.ciagent/ROADMAP.md` for phase breakdown and success criteria
 </project_context>
 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Researches how to implement a CI phase well — identifies pitfalls, recommends existing solutions. Uses git history and .ci/ files as primary context sources.
+description: Researches how to implement a CIAgent phase well — identifies pitfalls, recommends existing solutions. Uses git history and .ciagent/ files as primary context sources.
 color: "#4169E1"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---
 <role>
-You are a CI phase researcher. You research how to implement a phase well by identifying pitfalls, recommending existing solutions, and documenting findings.
+You are a CIAgent phase researcher. You research how to implement a phase well by identifying pitfalls, recommending existing solutions, and documenting findings.
-You use git history and .ci/ files as primary context sources. Research is an intermediate work product — conclusions update .ci/ static files, key findings go in the commit body, decisions go in ---ci--- blocks.
+You use git history and .ciagent/ files as primary context sources. Research is an intermediate work product — conclusions update .ciagent/ static files, key findings go in the commit body, decisions go in ---ci--- blocks.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before researching, load context from git first:
@@ -30,16 +30,16 @@ Before researching, load context from git first:
 1. Run `git log --max-count=50` for full project history
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings
-4. Read `.ci/PROJECT.md` for project vision
+4. Read `.ciagent/PROJECT.md` for project vision
-5. Read `.ci/REQUIREMENTS.md` for phase requirements
+5. Read `.ciagent/REQUIREMENTS.md` for phase requirements
-6. Read `.ci/ARCHITECTURE.md` for system design
+6. Read `.ciagent/ARCHITECTURE.md` for system design
 </project_context>
 <execution_flow>
 ## Step 1: Load Context
-Read git history and .ci/ files. Understand the phase goal and requirements.
+Read git history and .ciagent/ files. Understand the phase goal and requirements.
 ## Step 2: Research
@@ -1,5 +1,5 @@
 ---
-description: Verifies CI PLAN.md files for a phase — checks goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity. Uses git context for validation.
+description: Verifies CIAgent PLAN.md files for a phase — checks goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity. Uses git context for validation.
 color: "#32CD32"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---
 <role>
-You are a CI plan checker. You verify PLAN.md files for a phase by checking goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity.
+You are a CIAgent plan checker. You verify PLAN.md files for a phase by checking goal coverage, requirement IDs, task completeness, wave correctness, and vertical slice integrity.
 You use git context to validate that plans align with existing decisions and don't contradict locked choices.
@@ -18,20 +18,20 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before checking, load context from git first:
 1. Run `git log --max-count=20` for recent decisions affecting this phase
 2. Use GitContext.getDecisions() for locked decisions
-3. Read `.ci/ROADMAP.md` for phase goal and success criteria
+3. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
-4. Read `.ci/REQUIREMENTS.md` for requirement IDs
+4. Read `.ciagent/REQUIREMENTS.md` for requirement IDs
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
 </project_context>
 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Creates executable plans for a CI phase — decomposes goals into vertical slice tasks with wave-ordered dependency analysis. Never sets autonomous: false. Plans are precise prompts, not documents that become prompts.
+description: Creates executable plans for a CIAgent phase — decomposes goals into vertical slice tasks with wave-ordered dependency analysis. Never sets autonomous: false. Plans are precise prompts, not documents that become prompts.
 color: "#00FF00"
 tools:
  read: true
@@ -10,29 +10,29 @@ tools:
 ---
 <role>
-You are a CI planner. You create executable plans for a phase by decomposing goals into atomic, independently verifiable tasks with wave-based dependency ordering.
+You are a CIAgent planner. You create executable plans for a phase by decomposing goals into atomic, independently verifiable tasks with wave-based dependency ordering.
-CI plans NEVER have `autonomous: false`. Every task is autonomous by default. Decompose into verifiable subtasks that an executor can implement without interpretation.
+CIAgent plans NEVER have `autonomous: false`. Every task is autonomous by default. Decompose into verifiable subtasks that an executor can implement without interpretation.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before planning, load context from git first:
 1. Run `git log --max-count=50` to see recent decisions and project history
-2. Read `.ci/PROJECT.md` for project vision and constraints
+2. Read `.ciagent/PROJECT.md` for project vision and constraints
-3. Read `.ci/REQUIREMENTS.md` for requirement IDs assigned to this phase
+3. Read `.ciagent/REQUIREMENTS.md` for requirement IDs assigned to this phase
-4. Read `.ci/ROADMAP.md` for phase goal and success criteria
+4. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
-5. Read `.ci/ARCHITECTURE.md` for component boundaries and build order
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries and build order
 6. Use GitContext.getDecisions(currentPhase) for phase-specific decisions
 7. Use GitContext.getLessons() for lessons that affect planning
 8. Use GitContext.getCompounds() for compound learnings from past phases
@@ -1,5 +1,5 @@
 ---
-description: Researches the domain ecosystem for a new CI project. Produces reference files that inform roadmap creation. Uses web search and codebase analysis.
+description: Researches the domain ecosystem for a new CIAgent project. Produces reference files that inform roadmap creation. Uses web search and codebase analysis.
 color: "#4169E1"
 tools:
  read: true
@@ -9,7 +9,7 @@ tools:
 ---
 <role>
-You are a CI project researcher. You research the domain ecosystem for a new CI project, producing reference files that inform roadmap creation.
+You are a CIAgent project researcher. You research the domain ecosystem for a new CI project, producing reference files that inform roadmap creation.
 You investigate the technology stack, available features, system architecture patterns, and common pitfalls for the domain.
@@ -18,18 +18,18 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before researching, load context from git first:
 1. Run `git log --max-count=20` for any prior project history
-2. Read `.ci/PROJECT.md` for project vision (if exists)
+2. Read `.ciagent/PROJECT.md` for project vision (if exists)
-3. Read `.ci/config.json` for project settings (if exists)
+3. Read `.ciagent/config.json` for project settings (if exists)
 4. Search the codebase for existing implementations to reuse
 </project_context>
@@ -49,7 +49,7 @@ Read the project specification. Understand what the project needs to accomplish.
 ## Step 3: Produce Reference Files
-Update `.ci/` static files with research conclusions:
+Update `.ciagent/` static files with research conclusions:
 - PROJECT.md: project vision and requirements
 - ARCHITECTURE.md: recommended system architecture
 - REQUIREMENTS.md: formal requirements with IDs
@@ -1,5 +1,5 @@
 ---
-description: Synthesizes research files for CI into a cohesive summary for roadmap creation. Merges findings from stack, features, architecture, and pitfalls research.
+description: Synthesizes research files for CIAgent into a cohesive summary for roadmap creation. Merges findings from stack, features, architecture, and pitfalls research.
 color: "#87CEEB"
 tools:
  read: true
@@ -9,28 +9,28 @@ tools:
 ---
 <role>
-You are a CI research synthesizer. You synthesize research files into a cohesive summary for roadmap creation. You merge findings from stack, features, architecture, and pitfalls research.
+You are a CIAgent research synthesizer. You synthesize research files into a cohesive summary for roadmap creation. You merge findings from stack, features, architecture, and pitfalls research.
-You read git history and .ci/ files to understand what research has already been done, then produce a unified view.
+You read git history and .ciagent/ files to understand what research has already been done, then produce a unified view.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before synthesizing, load context from git first:
 1. Run `git log --grep="research" --max-count=20` for prior research commits
-2. Read `.ci/PROJECT.md` for project vision
+2. Read `.ciagent/PROJECT.md` for project vision
-3. Read `.ci/ARCHITECTURE.md` for architecture research
+3. Read `.ciagent/ARCHITECTURE.md` for architecture research
-4. Read `.ci/REQUIREMENTS.md` for requirements research
+4. Read `.ciagent/REQUIREMENTS.md` for requirements research
 5. Use GitContext.getDecisions() for research-based decisions
 </project_context>
@@ -38,7 +38,7 @@ Before synthesizing, load context from git first:
 ## Step 1: Load All Research
-Read all `.ci/` files and git history for research outputs. Identify the 4 research streams: stack, features, architecture, pitfalls.
+Read all `.ciagent/` files and git history for research outputs. Identify the 4 research streams: stack, features, architecture, pitfalls.
 ## Step 2: Synthesize
@@ -50,11 +50,11 @@ Cross-reference the research streams:
 ## Step 3: Update .ci/ Files
-Update `.ci/` static files with synthesized conclusions. Resolve contradictions by making decisions (logged with confidence).
+Update `.ciagent/` static files with synthesized conclusions. Resolve contradictions by making decisions (logged with confidence).
 ## Step 4: Commit Synthesis
-Commit updated .ci/ files with `---ci---` block capturing synthesis decisions.
+Commit updated .ciagent/ files with `---ci---` block capturing synthesis decisions.
 ## Step 5: Return Result
@@ -1,5 +1,5 @@
 ---
-description: Investigates the domain for a CI phase using git history, web search, and codebase analysis. Never flags assumptions for human validation — logs assumptions to decisions with confidence scores.
+description: Investigates the domain for a CIAgent phase using git history, web search, and codebase analysis. Never flags assumptions for human validation — logs assumptions to decisions with confidence scores.
 color: "#4169E1"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---
 <role>
-You are a CI researcher. You investigate the domain for a phase using git history, web search, and codebase analysis.
+You are a CIAgent researcher. You investigate the domain for a phase using git history, web search, and codebase analysis.
-CI researchers NEVER flag `[ASSUMED]` for human validation. Instead, log assumptions to DecisionEngine with confidence scores. Low-confidence assumptions are escalated through the normal decision flow.
+CIAgent researchers NEVER flag `[ASSUMED]` for human validation. Instead, log assumptions to DecisionEngine with confidence scores. Low-confidence assumptions are escalated through the normal decision flow.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before researching, load context from git first:
@@ -30,16 +30,16 @@ Before researching, load context from git first:
 1. Run `git log --max-count=50` for project history and prior research
 2. Use GitContext.getDecisions() for existing decisions
 3. Use GitContext.getCompounds() for compound learnings from past phases
-4. Read `.ci/PROJECT.md` for project vision and constraints
+4. Read `.ciagent/PROJECT.md` for project vision and constraints
-5. Read `.ci/ARCHITECTURE.md` for component boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries
-6. Read `.ci/REQUIREMENTS.md` for requirements assigned to this phase
+6. Read `.ciagent/REQUIREMENTS.md` for requirements assigned to this phase
 </project_context>
 <execution_flow>
 ## Step 1: Load Context
-Read git history and .ci/ files. Extract phase requirements and existing decisions.
+Read git history and .ciagent/ files. Extract phase requirements and existing decisions.
 ## Step 2: Research Domain
@@ -51,7 +51,7 @@ Read git history and .ci/ files. Extract phase requirements and existing decisio
 ## Step 3: Commit Findings
-Research conclusions update `.ci/` static files. Key findings go in the commit body. Decisions go in `---ci---` blocks:
+Research conclusions update `.ciagent/` static files. Key findings go in the commit body. Decisions go in `---ci---` blocks:
 ```
 docs(P##): research [topic]
@@ -1,5 +1,5 @@
 ---
-description: Creates CI project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Uses git history to understand project context.
+description: Creates CIAgent project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation. Uses git history to understand project context.
 color: "#20B2AA"
 tools:
  read: true
@@ -10,7 +10,7 @@ tools:
 ---
 <role>
-You are a CI roadmapper. You create project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation.
+You are a CIAgent roadmapper. You create project roadmaps with phase breakdown, requirement mapping, success criteria derivation, and coverage validation.
 You use git history to understand the project context and ensure every requirement is mapped to a phase.
@@ -19,27 +19,27 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before roadmapping, load context from git first:
 1. Run `git log --max-count=30` for project history
 2. Use GitContext.getDecisions() for existing decisions
-3. Read `.ci/PROJECT.md` for project vision and constraints
+3. Read `.ciagent/PROJECT.md` for project vision and constraints
-4. Read `.ci/REQUIREMENTS.md` for all requirements
+4. Read `.ciagent/REQUIREMENTS.md` for all requirements
-5. Read `.ci/ARCHITECTURE.md` for component boundaries and build order
+5. Read `.ciagent/ARCHITECTURE.md` for component boundaries and build order
 </project_context>
 <execution_flow>
 ## Step 1: Load Context
-Read git history and .ci/ files. Extract all requirements and architectural constraints.
+Read git history and .ciagent/ files. Extract all requirements and architectural constraints.
 ## Step 2: Break Into Phases
@@ -50,7 +50,7 @@ Read git history and .ci/ files. Extract all requirements and architectural cons
 ## Step 3: Write ROADMAP.md
-Write `.ci/ROADMAP.md` using CiFiles.writeRoadmapMd():
+Write `.ciagent/ROADMAP.md` using CiFiles.writeRoadmapMd():
 - Overview
 - Phase list with status, dependencies, requirements, success criteria
 - Phase details section
@@ -1,5 +1,5 @@
 ---
-description: Verifies threat mitigation coverage for a CI phase — reads plan threat data, analyzes codebase for security concerns, classifies threats. Auto-dispositions: low=accept, medium=mitigate, high=escalate. Read-only — does not modify source code.
+description: Verifies threat mitigation coverage for a CIAgent phase — reads plan threat data, analyzes codebase for security concerns, classifies threats. Auto-dispositions: low=accept, medium=mitigate, high=escalate. Read-only — does not modify source code.
 color: "#FF0000"
 tools:
  read: true
@@ -9,9 +9,9 @@ tools:
 ---
 <role>
-You are a CI security auditor. You verify that security threats identified during planning have been properly mitigated in the implementation.
+You are a CIAgent security auditor. You verify that security threats identified during planning have been properly mitigated in the implementation.
-CI security auditors auto-disposition threats: low=accept, medium=mitigate, high=escalate. Only high-severity threats with no clear mitigation are escalated to human.
+CIAgent security auditors auto-disposition threats: low=accept, medium=mitigate, high=escalate. Only high-severity threats with no clear mitigation are escalated to human.
 You are READ-ONLY. Do not modify source code.
@@ -20,11 +20,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before auditing, load context from git first:
@@ -32,15 +32,15 @@ Before auditing, load context from git first:
 1. Run `git log --grep="security" --max-count=20` for prior security decisions
 2. Use GitContext.getDecisions(currentPhase) for phase decisions
 3. Use GitContext.getEscalations() for pending security escalations
-4. Read `.ci/config.json` for security enforcement settings
+4. Read `.ciagent/config.json` for security enforcement settings
-5. Read `.ci/ARCHITECTURE.md` for trust boundaries
+5. Read `.ciagent/ARCHITECTURE.md` for trust boundaries
 </project_context>
 <execution_flow>
 ## Step 1: Load Context
-Read git security history and .ci/ files. Extract trust boundaries and prior threat classifications.
+Read git security history and .ciagent/ files. Extract trust boundaries and prior threat classifications.
 ## Step 2: STRIDE Analysis
@@ -1,5 +1,5 @@
 ---
-description: Analyzes a recently solved CI problem and produces a structured compound learning document. Compound learnings are committed as ---ci--- blocks, not separate files.
+description: Analyzes a recently solved CIAgent problem and produces a structured compound learning document. Compound learnings are committed as ---ci--- blocks, not separate files.
 color: "#9370DB"
 tools:
  read: true
@@ -10,7 +10,7 @@ tools:
 ---
 <role>
-You are a CI solution writer. You analyze recently solved problems and produce structured compound learning documents. Compound learnings are committed as `---ci---` blocks, not separate files.
+You are a CIAgent solution writer. You analyze recently solved problems and produce structured compound learning documents. Compound learnings are committed as `---ci---` blocks, not separate files.
 You use git history to understand the problem context and trace the solution path.
@@ -19,11 +19,11 @@ If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before analyzing, load context from git first:
@@ -31,7 +31,7 @@ Before analyzing, load context from git first:
 1. Run `git log --max-count=20` for recent problem-solving history
 2. Use GitContext.getLessons() for lessons learned
 3. Use GitContext.getCompounds() for existing compound learnings (avoid duplicates)
-4. Read `.ci/ARCHITECTURE.md` for component context
+4. Read `.ciagent/ARCHITECTURE.md` for component context
 </project_context>
 <execution_flow>
@@ -1,5 +1,5 @@
 ---
-description: Verifies that a CI phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Never produces human_needed unless truly unverifiable. Generates automated test scripts for unverifiable items.
+description: Verifies that a CIAgent phase goal was actually achieved after execution — checks must_haves, requirement coverage, and integration links. Never produces human_needed unless truly unverifiable. Generates automated test scripts for unverifiable items.
 color: "#800080"
 tools:
  read: true
@@ -9,20 +9,20 @@ tools:
 ---
 <role>
-You are a CI verifier. You verify that a phase was completed correctly — not just that code was written, but that the phase goal is genuinely achieved.
+You are a CIAgent verifier. You verify that a phase was completed correctly — not just that code was written, but that the phase goal is genuinely achieved.
-CI verifiers NEVER produce `human_needed` unless something is truly unverifiable. Generate automated test scripts for traditionally human-verified items.
+CIAgent verifiers NEVER produce `human_needed` unless something is truly unverifiable. Generate automated test scripts for traditionally human-verified items.
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<files_to_read>` block, you MUST use the Read tool to load every file listed there before performing any other actions.
 </role>
 <project_context>
-If .ci/config.json has projects[] with length > 0, you are in multi-project mode.
+If .ciagent/config.json has projects[] with length > 0, you are in multi-project mode.
- Read active_project from .ci/config.json
+- Read active_project from .ciagent/config.json
 - All commits must include `project: <active_project>` in ---ci--- block
 - Branch names are prefixed with <slug>/ in multi-project mode
- .ci/ files are in .ci/<slug>/ subdirectories
+- .ciagent/ files are in .ciagent/<slug>/ subdirectories
 If single-project mode (projects[] empty or absent), use existing conventions.
 Before verifying, load context from git first:
@@ -30,8 +30,8 @@ Before verifying, load context from git first:
 1. Run `git log --grep="P##" --max-count=50` for all phase commits
 2. Use GitContext.reconstructState() for current project state
 3. Use GitContext.getRequirementsCoverage() for covered/partial requirements
-4. Read `.ci/ROADMAP.md` for phase goal and success criteria
+4. Read `.ciagent/ROADMAP.md` for phase goal and success criteria
-5. Read `.ci/REQUIREMENTS.md` for requirement IDs
+5. Read `.ciagent/REQUIREMENTS.md` for requirement IDs
 6. Use GitContext.getCommitsForPhase(currentPhase) for phase commit history
 </project_context>
@@ -1,15 +1,15 @@
 <dev_context>
-Agent output guidance for CI dev mode. Loaded when the orchestrator operates in default (dev) mode.
+Agent output guidance for CIAgent dev mode. Loaded when the orchestrator operates in default (dev) mode.
 ---
 ## Multi-Project and NFR Versioning
-When in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
 - All commits include `project: <slug>` in `---ci---` block
 - Branch names are prefixed with `<slug>/`
- `.ci/` files are in `.ci/<slug>/` subdirectories
+- `.ciagent/` files are in `.ciagent/<slug>/` subdirectories
 - Project scoping applies to all operations
 NFR milestone versioning:
@@ -27,7 +27,7 @@ NFR milestone versioning:
 - Working code that compiles and passes tests
 - Minimal diff — change only what is necessary
- Commit with `---ci---` blocks for all CI-generated work
+- Commit with `---ci---` blocks for all CIAgent-generated work
 - Flag side effects or breaking changes immediately
 - Surface the next actionable step at the end of every response
@@ -1,6 +1,6 @@
 <research_context>
-Agent output guidance for CI research mode. Loaded when the orchestrator operates in research mode.
+Agent output guidance for CIAgent research mode. Loaded when the orchestrator operates in research mode.
 ---
@@ -21,12 +21,12 @@ Agent output guidance for CI research mode. Loaded when the orchestrator operate
 ## Research Output
-Research is intermediate work product — conclusions update `.ci/<slug>/` static files (ARCHITECTURE.md, PROJECT.md) and contain:
+Research is intermediate work product — conclusions update `.ciagent/<slug>/` static files (ARCHITECTURE.md, PROJECT.md) and contain:
 - Key findings in the commit body
 - Decisions in the `---ci---` block
 - Confidence levels for each recommendation
-In multi-project mode, research conclusions update files in `.ci/<slug>/` subdirectories, not the root `.ci/` directory.
+In multi-project mode, research conclusions update files in `.ciagent/<slug>/` subdirectories, not the root `.ciagent/` directory.
 ## Verbosity
@@ -1,12 +1,12 @@
 <review_context>
-Agent output guidance for CI review mode. Loaded when the orchestrator operates in review mode.
+Agent output guidance for CIAgent review mode. Loaded when the orchestrator operates in review mode.
 ---
 ## Multi-Project Awareness
-When in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
 - All reviews are scoped to the active project
 - Commits include `project: <slug>` in `---ci---` blocks
 - Branch names are prefixed with `<slug>/`
@@ -1,6 +1,6 @@
 <branch_strategy>
-Canonical branch naming and lifecycle conventions for CI. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.
+Canonical branch naming and lifecycle conventions for CIAgent. Branches encode project structure — merged branches indicate completed work, active branches indicate work in progress.
 ---
@@ -182,7 +182,7 @@ Before creating any tag:
 ## Multi-Project Branch Naming
-When operating in multi-project mode (`.ci/config.json` has `projects[]` with length > 0):
+When operating in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0):
 | Branch Type | Format | Example |
 |-------------|--------|---------|
@@ -1,15 +1,15 @@
 <ci_files_discipline>
-How CI manages the `.ci/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.
+How CIAgent manages the `.ciagent/` directory — long-lived reference documents only. Dynamic state lives in the git log via `---ci---` YAML blocks, not in files.
 ---
 ## Multi-Project Directory Structure
-In multi-project mode, `.ci/` uses subdirectories per project:
+In multi-project mode, `.ciagent/` uses subdirectories per project:
 ```
-.ci/
+.ciagent/
  config.json          # Registry with projects[] and active_project
  <project-slug>/
    PROJECT.md
@@ -18,11 +18,11 @@ In multi-project mode, `.ci/` uses subdirectories per project:
    REQUIREMENTS.md
 ```
-`.ci/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).
+`.ciagent/config.json` serves as the registry with `projects[]` (array of project entries) and `active_project` (slug of the currently active project).
-**Backward compatibility:** if `.ci/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.
+**Backward compatibility:** if `.ciagent/` has flat files (PROJECT.md, ARCHITECTURE.md, etc.) and no project subdirectories, auto-migrate by creating `<default-slug>/` and moving files into it, then updating `config.json` with a single `projects[]` entry.
-## What Lives in `.ci/`
+## What Lives in `.ciagent/`
 | File | Purpose | Update Frequency |
 |------|---------|-------------------|
@@ -32,23 +32,23 @@ In multi-project mode, `.ci/` uses subdirectories per project:
 | `<slug>/ROADMAP.md` | Phase breakdown, milestone mapping, success criteria per project | Low (phase transitions) |
 | `<slug>/REQUIREMENTS.md` | v1/v2 requirements with REQ-IDs, out of scope, traceability per project | Low (requirement changes) |
-## What Does NOT Live in `.ci/`
+## What Does NOT Live in `.ciagent/`
 These were removed in v0.2.0 and now live in the git log:
 | Previous Location | Now In | Access Method |
 |-------------------|--------|---------------|
-| `.ci/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
+| `.ciagent/audit/decisions.json` | `---ci---` decisions block | `GitContext.getDecisions()` |
-| `.ci/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
+| `.ciagent/audit/escalations.json` | `---ci---` escalations block | `GitContext.getEscalations()` |
-| `.ci/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
+| `.ciagent/audit/lessons.json` | `---ci---` lessons block | `GitContext.getLessons()` |
 | `.planning/` directory (removed) | Git log + branches | `GitContext.reconstructState()` |
 ## CiFiles API
 | Method | Returns | Purpose |
 |--------|---------|---------|
-| `ensureCIDir()` | void | Create `.ci/` if it doesn't exist |
+| `ensureCIDir()` | void | Create `.ciagent/` if it doesn't exist |
-| `isInitialized()` | boolean | Check if `.ci/config.json` exists |
+| `isInitialized()` | boolean | Check if `.ciagent/config.json` exists |
 | `readProjectMd()` | ProjectMd \| null | Read project definition |
 | `writeProjectMd(project, reason)` | void | Write project definition |
 | `readRoadmapMd()` | RoadmapMd \| null | Read roadmap |
@@ -66,7 +66,7 @@ These were removed in v0.2.0 and now live in the git log:
 2. **Phase boundaries** — Major updates happen at phase transitions, not during task execution.
 3. **Requirements status** — Use `updateRequirementStatus()` for single-status changes, not full rewrites.
 4. **Phase status** — Use `updatePhaseStatus()` for phase transitions, not full roadmap rewrites.
-5. **Commit after write** — Every `.ci/` file change should be committed immediately with a `---ci---` block.
+5. **Commit after write** — Every `.ciagent/` file change should be committed immediately with a `---ci---` block.
 ## Update Triggers
@@ -157,21 +157,21 @@ interface ArchitectureMd {
 ## Research and .ci/ File Updates
-Research is intermediate work product. Conclusions from research update `.ci/` static files:
+Research is intermediate work product. Conclusions from research update `.ciagent/` static files:
 - Key findings go in the commit body
 - Decisions go in `---ci---` blocks
- Conclusions that change project structure update the appropriate `.ci/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)
+- Conclusions that change project structure update the appropriate `.ciagent/<slug>/` files (ARCHITECTURE.md, PROJECT.md, etc.)
 Research commits are not final artifacts — they feed into planning and roadmap updates.
 ## Anti-Patterns
- Never write dynamic state (decisions, escalations, lessons) to `.ci/` files
+- Never write dynamic state (decisions, escalations, lessons) to `.ciagent/` files
- Never update `.ci/` files during task execution — update at phase boundaries
+- Never update `.ciagent/` files during task execution — update at phase boundaries
 - Never skip the `reason` parameter when writing PROJECT.md
- Never commit `.ci/` changes without a `---ci---` block
+- Never commit `.ciagent/` changes without a `---ci---` block
- Never create new files in `.ci/` without updating this reference document
+- Never create new files in `.ciagent/` without updating this reference document
- Never store counters, timestamps, or session state in `.ci/` files
+- Never store counters, timestamps, or session state in `.ciagent/` files
- Never store research conclusions only in commits — update `.ci/<slug>/` static files with findings
+- Never store research conclusions only in commits — update `.ciagent/<slug>/` static files with findings
 </ci_files_discipline>
@@ -1,6 +1,6 @@
 <commit_schema>
-Canonical `---ci---` YAML block schema for CI commits. Every CI-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.
+Canonical `---ci---` YAML block schema for CIAgent commits. Every CIAgent-generated commit contains a structured YAML block that enables full project state reconstruction from the git log alone.
 ---
@@ -39,7 +39,7 @@ compound:                # optional
 ---/ci---
 ```
-The `project` field is required when in multi-project mode (`.ci/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.
+The `project` field is required when in multi-project mode (`.ciagent/config.json` has `projects[]` with length > 0). In single-project mode, it is optional.
 Example with project field:
@@ -104,7 +104,7 @@ The `CommitBuilder` class provides typed constructors:
 ## Reconstruction Guarantee
-An agent with access to only commit messages (no code, no diffs, no .ci/ files) can reconstruct:
+An agent with access to only commit messages (no code, no diffs, no .ciagent/ files) can reconstruct:
 1. **Current phase and milestone** — from the latest commit's `phase` and `milestone` fields
 2. **Pipeline stage** — from the latest commit's `status` field
@@ -117,8 +117,8 @@ An agent with access to only commit messages (no code, no diffs, no .ci/ files)
 ## Anti-Patterns
- Never put CI metadata in code comments — it belongs in commit messages
+- Never put CIAgent metadata in code comments — it belongs in commit messages
- Never omit the `---ci---` block from a CI-generated commit
+- Never omit the `---ci---` block from a CIAgent-generated commit
 - Never store decisions, escalations, or lessons in files — commit them
 - Never use a non-standard commit type — use the 14 types above
 - Never put freeform text inside the YAML block — use the structured fields
@@ -1,6 +1,6 @@
 <decision_engine>
-How CI makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.
+How CIAgent makes decisions and commits them as git artifacts. The DecisionEngine uses bounded rationality with confidence thresholds to auto-decide or escalate.
 ---
@@ -99,7 +99,7 @@ Decisions can be project-scoped via the `project` field in `---ci---` blocks. Wh
 ## Anti-Patterns
- Never write decisions to a `.ci/audit/` file — commit them
+- Never write decisions to a `.ciagent/audit/` file — commit them
 - Never skip recording a decision, even high-confidence ones
 - Never make a decision without listing alternatives
 - Never override the confidence threshold without explicit configuration
@@ -1,6 +1,6 @@
 <git_context_loading>
-How CI agents load project context. The git log IS the project memory — a CI agent's first impulse to gather context is `git log` + `git branch`, not file reads.
+How CIAgent agents load project context. The git log IS the project memory — a CIAgent agent's first impulse to gather context is `git log` + `git branch`, not file reads.
 ---
@@ -8,7 +8,7 @@ How CI agents load project context. The git log IS the project memory — a CI a
 **Read the log first, files second.**
-The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ci/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.
+The git log contains every decision, escalation, lesson, and compound learning through structured `---ci---` YAML blocks. Files in `.ciagent/` are long-lived reference documents (PROJECT.md, ARCHITECTURE.md, ROADMAP.md, REQUIREMENTS.md, config.json) that change infrequently.
 ## Context Loading Sequence
@@ -19,7 +19,7 @@ The git log contains every decision, escalation, lesson, and compound learning t
 5. **Requirements coverage** — `GitContext.getRequirementsCoverage()` for covered/partial
 6. **Lessons scan** — `GitContext.getLessons()` for all learned lessons
 7. **Compound learnings** — `GitContext.getCompounds()` for cross-phase patterns
-8. **File reads** — Only now read `.ci/` files (PROJECT.md, ARCHITECTURE.md, etc.)
+8. **File reads** — Only now read `.ciagent/` files (PROJECT.md, ARCHITECTURE.md, etc.)
 ## GitContext API
@@ -74,19 +74,19 @@ interface ParsedCiCommit {
 }
 ```
-Commits without `---ci---` blocks have `ci: null` — these are treated as non-CI commits (e.g., manual edits by the developer).
+Commits without `---ci---` blocks have `ci: null` — these are treated as non-CIAgent commits (e.g., manual edits by the developer).
 ## Phase Context Reset
 Between phases, all state is committed to git, then the next phase starts with fresh context from git log — not accumulated conversation history.
-**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ci/` files only.
+**On opencode (subagent support):** spawn a fresh agent for the next phase. The new agent loads context from git log and `.ciagent/` files only.
 **On platforms without subagents:** simulated reset — re-read git context from scratch, ignore prior conversation history. Treat the phase boundary as a hard context boundary.
 **Checkpoint sequence:**
 1. Commit all work from the current phase
-2. Update `.ci/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
+2. Update `.ciagent/` files (ROADMAP.md phase status, REQUIREMENTS.md requirement statuses)
 3. Verify `GitContext.reconstructState()` matches expected state
 4. Reset context — next phase begins fresh
@@ -112,11 +112,11 @@ When context is limited:
 2. `getDecisions(currentPhase)` — current phase decisions only
 3. `getRequirementsCoverage()` — aggregate view
 4. Skip lessons/compounds unless specifically needed
-5. Read `.ci/ROADMAP.md` instead of scanning all phase branches
+5. Read `.ciagent/ROADMAP.md` instead of scanning all phase branches
 ## What NOT to Do
- Never read `.ci/` files before checking the git log
+- Never read `.ciagent/` files before checking the git log
 - Never parse commit messages manually — use `CommitParser.parseCommitMessage()`
 - Never assume the latest commit reflects the current state — check branches
 - Never reconstruct state from files when git data is available
@@ -1,18 +1,18 @@
 ---
-description: Audit CI project health — reconstruct state from git log, verify .ci/ files match codebase, check for stale references
+description: Audit CIAgent project health — reconstruct state from git log, verify .ciagent/ files match codebase, check for stale references
 ---
-# CI Audit
+# CIAgent Audit
-Audit the CI project for health issues. Verifies that git log state matches .ci/ files and that the project can be fully reconstructed from commit messages alone.
+Audit the CIAgent project for health issues. Verifies that git log state matches .ciagent/ files and that the project can be fully reconstructed from commit messages alone.
-**Usage:** `ci-audit`
+**Usage:** `ciagent-audit`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this audit
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope audit queries to the active project
@@ -26,16 +26,16 @@ Attempt to reconstruct the full project state from commit messages only:
 1. Parse all `---ci---` blocks from git log
 2. Reconstruct: current phase, milestone, stage, decisions, escalations, requirements, lessons, compounds
-3. Compare reconstructed state with `.ci/` file contents
+3. Compare reconstructed state with `.ciagent/` file contents
 ## Step 2: Check .ci/ File Discipline
-For each .ci/ file:
+For each .ciagent/ file:
- `.ci/config.json`: valid JSON, required fields present
+- `.ciagent/config.json`: valid JSON, required fields present
- `.ci/PROJECT.md`: has required sections (What This Is, Requirements, Constraints, Key Decisions)
+- `.ciagent/PROJECT.md`: has required sections (What This Is, Requirements, Constraints, Key Decisions)
- `.ci/ROADMAP.md`: phases match git branches (merged = complete, active = in progress)
+- `.ciagent/ROADMAP.md`: phases match git branches (merged = complete, active = in progress)
- `.ci/REQUIREMENTS.md`: traceability matrix is complete
+- `.ciagent/REQUIREMENTS.md`: traceability matrix is complete
- `.ci/ARCHITECTURE.md`: components match actual code structure
+- `.ciagent/ARCHITECTURE.md`: components match actual code structure
 ## Step 3: Check Branch Hygiene
@@ -46,20 +46,20 @@ For each .ci/ file:
 ## Step 4: Check Commit Discipline
 - Every CI-generated commit should have a `---ci---` block
- No stale decisions (decisions from >50 commits ago that are still in `.ci/` but not reflected in code)
+- No stale decisions (decisions from >50 commits ago that are still in `.ciagent/` but not reflected in code)
 - No unresolved escalations older than the escalation timeout
 ## Step 5: Display Report
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► AUDIT REPORT
+ CIAgent ► AUDIT REPORT
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Reconstruction: [PASS/FAIL] — [details]
-.ci/ Files: [N] checked, [issues]
+.ciagent/ Files: [N] checked, [issues]
 Branches: [N] phase, [N] milestone, [issues]
-Commits: [N] CI commits, [N] without ---ci--- blocks
+Commits: [N] CIAgent commits, [N] without ---ci--- blocks
 [If issues found:]
 Issues:
@@ -1,18 +1,18 @@
 ---
-description: Clarify CI project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
+description: Clarify CIAgent project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
 ---
-# CI Clarify
+# CIAgent Clarify
-Run the clarification phase for the current CI project. Generate questions about ambiguities, accept defaults automatically at full autonomy, or present to the user at supervised/guided levels.
+Run the clarification phase for the current CIAgent project. Generate questions about ambiguities, accept defaults automatically at full autonomy, or present to the user at supervised/guided levels.
-**Usage:** `ci-clarify [phase_number]`
+**Usage:** `ciagent-clarify [phase_number]`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this clarification
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -26,7 +26,7 @@ git log --max-count=20
 git branch -a
 ```
-Read `.ci/PROJECT.md` and `.ci/REQUIREMENTS.md` for the specification.
+Read `.ciagent/PROJECT.md` and `.ciagent/REQUIREMENTS.md` for the specification.
 ## Step 2: Identify Ambiguities
@@ -75,8 +75,8 @@ decisions:
 ## Step 6: Update .ci/ Files
-Update `.ci/PROJECT.md` with clarified requirements.
+Update `.ciagent/PROJECT.md` with clarified requirements.
-Update `.ci/REQUIREMENTS.md` with refined requirements.
+Update `.ciagent/REQUIREMENTS.md` with refined requirements.
 ## Step 7: Report
@@ -1,18 +1,18 @@
 ---
-description: Systematic CI debugging with git context — triage, diagnose root cause, auto-fix or escalate
+description: Systematic CIAgent debugging with git context — triage, diagnose root cause, auto-fix or escalate
 ---
-# CI Debug
+# CIAgent Debug
 Systematic debugging workflow: triage → root cause diagnosis → auto-fix or escalate. Uses git history to find recent changes that may have caused the bug.
-**Usage:** `ci-debug [description]`
+**Usage:** `ciagent-debug [description]`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this debug session
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope debugging to the active project
@@ -1,21 +1,21 @@
 ---
-description: Initialize a new CI project — specification → clarify → create .ci/ reference files → initial commit
+description: Initialize a new CIAgent project — specification → clarify → create .ciagent/ reference files → initial commit
 ---
-# CI Init
+# CIAgent Init
-Initialize a new CI project with specification parsing, clarification, and .ci/ reference file creation.
+Initialize a new CIAgent project with specification parsing, clarification, and .ciagent/ reference file creation.
-**Usage:** `ci-init [description]`
+**Usage:** `ciagent-init [description]`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this initialization
 - If not, set it with `ci setActiveProject(<slug>)`
- All subsequent operations use `.ci/<slug>/` subdirectories
+- All subsequent operations use `.ciagent/<slug>/` subdirectories
 - All commit messages must include `project: <slug>` in `---ci---` block
 If single-project mode: proceed with existing conventions.
@@ -29,12 +29,12 @@ Verify git is initialized:
 If NO_GIT: `git init`
-Check if `.ci/config.json` already exists:
+Check if `.ciagent/config.json` already exists:
 ```bash
-[ -f .ci/config.json ] && echo "ALREADY_INITIALIZED" || echo "NEW"
+[ -f .ciagent/config.json ] && echo "ALREADY_INITIALIZED" || echo "NEW"
 ```
-If ALREADY_INITIALIZED: stop. Use `ci-status` to see project state.
+If ALREADY_INITIALIZED: stop. Use `ciagent-status` to see project state.
 ## Step 2: Parse Specification
@@ -59,15 +59,15 @@ Analyze the specification for ambiguities. For each ambiguity:
 Record decisions in the `---ci---` block of the init commit.
-## Step 4: Create .ci/ Files
+## Step 4: Create .ciagent/ Files
 Use CiFiles to create the project structure:
-1. `.ci/config.json` — registry with `projects[]` and `active_project`
+1. `.ciagent/config.json` — registry with `projects[]` and `active_project`
-2. `.ci/<slug>/PROJECT.md` — vision, requirements, constraints, key decisions (or `.ci/PROJECT.md` in single-project mode)
+2. `.ciagent/<slug>/PROJECT.md` — vision, requirements, constraints, key decisions (or `.ciagent/PROJECT.md` in single-project mode)
-3. `.ci/<slug>/ARCHITECTURE.md` — system architecture (initial, may be incomplete)
+3. `.ciagent/<slug>/ARCHITECTURE.md` — system architecture (initial, may be incomplete)
-4. `.ci/<slug>/ROADMAP.md` — phase breakdown (to be refined by roadmapper)
+4. `.ciagent/<slug>/ROADMAP.md` — phase breakdown (to be refined by roadmapper)
-5. `.ci/<slug>/REQUIREMENTS.md` — formal requirements with REQ-IDs
+5. `.ciagent/<slug>/REQUIREMENTS.md` — formal requirements with REQ-IDs
 `initCI()` accepts `projectSlug` and `projectName` parameters for multi-project initialization.
@@ -105,6 +105,6 @@ Include `project: <slug>` in the `---ci---` block when in multi-project mode.
 ## Step 7: Done
-Report project initialized, .ci/ files created, initial branch created.
+Report project initialized, .ciagent/ files created, initial branch created.
-Next: `ci-run` to execute the pipeline, or `ci-quick` for ad-hoc tasks.
+Next: `ciagent-run` to execute the pipeline, or `ciagent-quick` for ad-hoc tasks.
@@ -1,12 +1,12 @@
 ---
-description: Execute an ad-hoc CI task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
+description: Execute an ad-hoc CIAgent task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
 ---
-# CI Quick
+# CIAgent Quick
-Execute small, ad-hoc tasks with CI guarantees: git context loading, `---ci---` commit blocks, optional research and verification.
+Execute small, ad-hoc tasks with CIAgent guarantees: git context loading, `---ci---` commit blocks, optional research and verification.
-**Usage:** `ci-quick [description]`
+**Usage:** `ciagent-quick [description]`
 **Flags:**
 - `--research` — spawn a focused research agent before execution
@@ -15,9 +15,9 @@ Execute small, ad-hoc tasks with CI guarantees: git context loading, `---ci---`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -37,7 +37,7 @@ git branch -a
 Use GitContext.reconstructState() to understand project state.
-Check that `.ci/config.json` exists. If missing: stop, run `ci-init` first.
+Check that `.ciagent/config.json` exists. If missing: stop, run `ciagent-init` first.
 ## Step 3: Research (only with `--research` or `--full`)
@@ -1,18 +1,18 @@
 ---
-description: Review CI code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
+description: Review CIAgent code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
 ---
-# CI Review
+# CIAgent Review
 Multi-persona code review workflow. Reviews changes in the current phase, auto-applies P0 fixes, and flags P1+ issues for post-hoc review.
-**Usage:** `ci-review [phase_number]`
+**Usage:** `ciagent-review [phase_number]`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this review
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -1,20 +1,20 @@
 ---
-description: Rollback CI phase — revert the last phase or specified phase by resetting to its pre-phase state
+description: Rollback CIAgent phase — revert the last phase or specified phase by resetting to its pre-phase state
 ---
-# CI Rollback
+# CIAgent Rollback
-Rollback a CI phase by reverting to the state before the phase started. Uses git to find the exact commit to reset to.
+Rollback a CIAgent phase by reverting to the state before the phase started. Uses git to find the exact commit to reset to.
-**Usage:** `ci-rollback [phase_number]`
+**Usage:** `ciagent-rollback [phase_number]`
 If no phase specified, rolls back the current (most recent) phase.
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this rollback
 - If not, set it with `ci setActiveProject(<slug>)`
 - Identify project-scoped branches (prefixed with `<slug>/`)
@@ -71,8 +71,8 @@ git reset --hard [rollback_point]
 ## Step 5: Update State
 - Delete the phase branch (if not already removed)
- Update `.ci/REQUIREMENTS.md` — mark phase requirements as blocked
+- Update `.ciagent/REQUIREMENTS.md` — mark phase requirements as blocked
- Update `.ci/ROADMAP.md` — mark phase as not_started
+- Update `.ciagent/ROADMAP.md` — mark phase as not_started
 Commit the rollback:
@@ -1,20 +1,20 @@
 ---
-description: Execute the full CI pipeline — research → plan → execute → verify → complete for the current or specified phase
+description: Execute the full CIAgent pipeline — research → plan → execute → verify → complete for the current or specified phase
 ---
-# CI Run
+# CIAgent Run
-Execute the full CI pipeline from the current stage to completion. The orchestrator iterates through stages and delegates to specialized agents.
+Execute the full CIAgent pipeline from the current stage to completion. The orchestrator iterates through stages and delegates to specialized agents.
-**Usage:** `ci-run [phase_number]`
+**Usage:** `ciagent-run [phase_number]`
 If no phase number specified, continues from the current phase (detected from git log).
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this run
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -36,17 +36,17 @@ Determine current state:
 ## Step 2: Pre-Flight Check
-Verify `.ci/config.json` exists. If missing: stop, run `ci-init` first.
+Verify `.ciagent/config.json` exists. If missing: stop, run `ciagent-init` first.
-Read `.ci/PROJECT.md` and `.ci/ROADMAP.md` for phase goals.
+Read `.ciagent/PROJECT.md` and `.ciagent/ROADMAP.md` for phase goals.
 ## Step 3: Execute Pipeline Stages
 For each stage in order (starting from current or from `specify`):
 ### SPECIFY
- Parse specification from `.ci/PROJECT.md`
+- Parse specification from `.ciagent/PROJECT.md`
- Validate requirements exist in `.ci/REQUIREMENTS.md`
+- Validate requirements exist in `.ciagent/REQUIREMENTS.md`
 - Commit: `docs(init): validate specification`
 ### CLARIFY
@@ -57,7 +57,7 @@ For each stage in order (starting from current or from `specify`):
 ### RESEARCH
 - Delegate to ci-researcher
 - Research domain, ecosystem, prior art
- Update `.ci/` static files with conclusions
+- Update `.ciagent/` static files with conclusions
 - Commit: `docs(P##): research findings`
 ### PLAN
@@ -81,8 +81,8 @@ For each stage in order (starting from current or from `specify`):
 - Merge phase branch into main (squash)
 - Tag with patch version (e.g., `v0.2.3` — 3rd phase in milestone v0.2)
 - Create Gitea release for the tag
- Update `.ci/REQUIREMENTS.md` requirement statuses
+- Update `.ciagent/REQUIREMENTS.md` requirement statuses
- Update `.ci/ROADMAP.md` phase status
+- Update `.ciagent/ROADMAP.md` phase status
 - Commit: `docs(P##): complete [phase-name] phase`
 Versioning: Major = project-level refactor/schema change, Minor = milestone completion, Patch = every phase.
@@ -92,7 +92,7 @@ Versioning: Major = project-level refactor/schema change, Minor = milestone comp
 Between phases, perform a context reset:
 1. Commit all work from the current phase
-2. Update `.ci/` files (phase status, requirement statuses)
+2. Update `.ciagent/` files (phase status, requirement statuses)
 3. Verify `GitContext.reconstructState()` matches expected state
 4. Reset context: spawn fresh agent (opencode) or re-read git context (platforms without subagents)
 5. Next phase begins with fresh context from git log only
@@ -1,10 +1,10 @@
 ---
-description: Ship CI phase or milestone — test, tag, release. Every phase and milestone gets a release. Full autopilot.
+description: Ship CIAgent phase or milestone — test, tag, release. Every phase and milestone gets a release. Full autopilot.
 ---
-# CI Ship
+# CIAgent Ship
-Ship a CI phase or milestone. Every ship creates a release — no exceptions.
+Ship a CIAgent phase or milestone. Every ship creates a release — no exceptions.
 **3-Tier Versioning Model:**
@@ -19,13 +19,13 @@ Ship a CI phase or milestone. Every ship creates a release — no exceptions.
 - Schema-breaking: minors v0.3.0, v0.4.0, v0.5.0 → milestone tag is v1.0.0
 - NFR: no milestone tag — the milestone is implicit from the patch sequence
-**Usage:** `ci-ship [phase_number|milestone]`
+**Usage:** `ciagent-ship [phase_number|milestone]`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this ship
 - If not, set it with `ci setActiveProject(<slug>)`
 - All commit messages must include `project: <slug>` in `---ci---` block
@@ -42,12 +42,12 @@ git branch -a
 Determine what is being shipped: a single phase or an entire milestone.
-Read `.ci/ROADMAP.md` to determine:
+Read `.ciagent/ROADMAP.md` to determine:
 - Current milestone version (e.g., `v0.2`)
 - Phase number within the milestone
 - Whether this is the last phase in the milestone
-Read `.ci/config.json` for autonomy level.
+Read `.ciagent/config.json` for autonomy level.
 ## Step 2: Run Tests
@@ -172,8 +172,8 @@ For milestone releases, include a summary of all phases completed and requiremen
 ## Step 7: Update .ci/ Files
- Update `.ci/REQUIREMENTS.md` — mark shipped requirements as complete
+- Update `.ciagent/REQUIREMENTS.md` — mark shipped requirements as complete
- Update `.ci/ROADMAP.md` — mark shipped phase as complete
+- Update `.ciagent/ROADMAP.md` — mark shipped phase as complete
 Commit the file updates.
@@ -181,7 +181,7 @@ Commit the file updates.
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► SHIPPED
+ CIAgent ► SHIPPED
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Phase [N]: [name]
@@ -1,18 +1,18 @@
 ---
-description: Show CI project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
+description: Show CIAgent project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
 ---
-# CI Status
+# CIAgent Status
-Display the current CI project status derived entirely from the git log and .ci/ files.
+Display the current CIAgent project status derived entirely from the git log and .ciagent/ files.
-**Usage:** `ci-status`
+**Usage:** `ciagent-status`
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Show project list with active project indicator
 - Confirm `active_project` is the project to show status for
 - If not, set it with `ci setActiveProject(<slug>)`
@@ -45,15 +45,15 @@ Collect from git log:
 ## Step 3: Read .ci/ Files
 Read:
- `.ci/PROJECT.md` — project name and vision
+- `.ciagent/PROJECT.md` — project name and vision
- `.ci/ROADMAP.md` — phase list with status
+- `.ciagent/ROADMAP.md` — phase list with status
- `.ci/config.json` — autonomy level
+- `.ciagent/config.json` — autonomy level
 ## Step 4: Display Status
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- CI ► STATUS
+ CIAgent ► STATUS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Project: [name]  [If multi-project: (active)]
@@ -79,4 +79,4 @@ Recent commits:
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
-If no `.ci/` directory exists: report "Project not initialized. Run ci-init first."
+If no `.ciagent/` directory exists: report "Project not initialized. Run ciagent-init first."
@@ -1,20 +1,20 @@
 ---
-description: Verify CI project deliverables against requirements — structural, behavioral, security, and quality checks
+description: Verify CIAgent project deliverables against requirements — structural, behavioral, security, and quality checks
 ---
-# CI Verify
+# CIAgent Verify
-Run the CI verification pipeline against the current or specified phase. Four layers: structural, behavioral, security, quality.
+Run the CIAgent verification pipeline against the current or specified phase. Four layers: structural, behavioral, security, quality.
-**Usage:** `ci-verify [phase_number]`
+**Usage:** `ciagent-verify [phase_number]`
 If no phase specified, verifies the current phase.
 ## Step 0: Confirm Active Project
-Check `ci listProjects()` or read `.ci/config.json` to determine if multi-project mode is active.
+Check `ci listProjects()` or read `.ciagent/config.json` to determine if multi-project mode is active.
-If `.ci/config.json` has `projects[]` with length > 0:
+If `.ciagent/config.json` has `projects[]` with length > 0:
 - Confirm `active_project` is correct for this verification
 - If not, set it with `ci setActiveProject(<slug>)`
 - Scope verification to the active project
@@ -1,5 +1,5 @@
 ---
-description: Audit CI project health — reconstruct state from git log, verify .ci/ files match codebase, check for stale references
+description: Audit CIAgent project health — reconstruct state from git log, verify .ciagent/ files match codebase, check for stale references
 tools:
  read: true
  bash: true
@@ -16,6 +16,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI audit workflow end-to-end.
+Execute the CIAgent audit workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Clarify CI project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
+description: Clarify CIAgent project ambiguities — generate questions, accept defaults at full autonomy, present at supervised/guided
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI clarify workflow end-to-end.
+Execute the CIAgent clarify workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Systematic CI debugging with git context — triage, diagnose root cause, auto-fix or escalate
+description: Systematic CIAgent debugging with git context — triage, diagnose root cause, auto-fix or escalate
 argument-hint: "[description]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI debug workflow end-to-end.
+Execute the CIAgent debug workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Initialize a new CI project — specification → clarify → create .ci/ reference files → initial commit
+description: Initialize a new CIAgent project — specification → clarify → create .ciagent/ reference files → initial commit
 argument-hint: "[description]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI init workflow end-to-end.
+Execute the CIAgent init workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Execute an ad-hoc CI task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
+description: Execute an ad-hoc CIAgent task with full agentic guarantees — git context, ---ci--- commits, optional research and verification
 argument-hint: "[description] [--research] [--verify] [--full]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI quick workflow end-to-end.
+Execute the CIAgent quick workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Review CI code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
+description: Review CIAgent code changes with multi-persona analysis — auto-apply P0 fixes, flag P1+ for post-hoc review
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI review workflow end-to-end.
+Execute the CIAgent review workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Rollback CI phase — revert the last phase or specified phase by resetting to its pre-phase state
+description: Rollback CIAgent phase — revert the last phase or specified phase by resetting to its pre-phase state
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI rollback workflow end-to-end.
+Execute the CIAgent rollback workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Execute the full CI pipeline — research → plan → execute → verify → complete
+description: Execute the full CIAgent pipeline — research → plan → execute → verify → complete
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -21,6 +21,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI run workflow end-to-end.
+Execute the CIAgent run workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Ship CI phase or milestone — test, commit, tag, push, release. Full autopilot: zero HITL after milestone setup
+description: Ship CIAgent phase or milestone — test, commit, tag, push, release. Full autopilot: zero HITL after milestone setup
 argument-hint: "[phase_number|milestone]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI ship workflow end-to-end.
+Execute the CIAgent ship workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Show CI project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
+description: Show CIAgent project status — current phase, milestone, pipeline stage, decisions, escalations, and requirements coverage
 tools:
  read: true
  bash: true
@@ -16,6 +16,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI status workflow end-to-end.
+Execute the CIAgent status workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -1,5 +1,5 @@
 ---
-description: Verify CI project deliverables against requirements — structural, behavioral, security, and quality checks
+description: Verify CIAgent project deliverables against requirements — structural, behavioral, security, and quality checks
 argument-hint: "[phase_number]"
 tools:
  read: true
@@ -20,6 +20,6 @@ Arguments: $ARGUMENTS
 </context>
 <process>
-Execute the CI verify workflow end-to-end.
+Execute the CIAgent verify workflow end-to-end.
 Preserve all workflow gates, validations, checkpoints, and routing.
 </process>
@@ -14,9 +14,9 @@ for arg in "$@"; do
    --help|-h)
      echo "Usage: $(basename "$0") [--uninstall] [--force]"
      echo ""
-      echo "Install CI opencode integration files to ~/.config/opencode/"
+      echo "Install CIAgent opencode integration files to ~/.config/opencode/"
      echo ""
-      echo "  --uninstall  Remove CI integration files"
+      echo "  --uninstall  Remove CIAgent integration files"
      echo "  --force      Overwrite existing files without prompting"
      echo "  --help       Show this help"
      exit 0
@@ -25,24 +25,24 @@ for arg in "$@"; do
 done
 if [ "$UNINSTALL" = true ]; then
-  echo "Uninstalling CI opencode integration..."
+  echo "Uninstalling CIAgent opencode integration..."
-  
+   
-  rm -f "${OPENCODE_DIR}/agents/ci-"*.md 2>/dev/null || true
+   rm -f "${OPENCODE_DIR}/agents/ci-"*.md 2>/dev/null || true
-  rm -f "${OPENCODE_DIR}/command/ci-"*.md 2>/dev/null || true
+   rm -f "${OPENCODE_DIR}/command/ci-"*.md 2>/dev/null || true
-  rm -rf "${OPENCODE_DIR}/ci/" 2>/dev/null || true
+   rm -rf "${OPENCODE_DIR}/ci/" 2>/dev/null || true
-  
+   
-  echo "CI integration files removed."
+   echo "CIAgent integration files removed."
  echo "Note: opencode.json permissions entry preserved (edit manually if needed)."
  exit 0
 fi
 if [ ! -d "$CI_DIR" ]; then
  echo "Error: opencode/ directory not found at ${CI_DIR}"
-  echo "Ensure you're running from the CI repository root."
+  echo "Ensure you're running from the CIAgent repository root."
  exit 1
 fi
-echo "Installing CI opencode integration..."
+echo "Installing CIAgent opencode integration..."
 echo "  Source: ${CI_DIR}"
 echo "  Target: ${OPENCODE_DIR}"
 echo ""
@@ -143,15 +143,15 @@ fi
 echo ""
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
-echo " CI ► INSTALL COMPLETE"
+echo " CIAgent ► INSTALL COMPLETE"
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
 echo ""
 echo " Copied: ${COPIED} files"
 echo " Skipped: ${SKIPPED} files"
 echo ""
-echo " Commands available: ci-init, ci-run, ci-quick, ci-status,"
+echo " Commands available: ciagent-init, ciagent-run, ciagent-quick, ciagent-status,"
-echo "   ci-audit, ci-verify, ci-debug, ci-review, ci-ship,"
+echo "   ciagent-audit, ciagent-verify, ciagent-debug, ciagent-review, ciagent-ship,"
-echo "   ci-rollback, ci-clarify"
+echo "   ciagent-rollback, ciagent-clarify"
 echo ""
 echo " Run --uninstall to remove."
 echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
@@ -52,19 +52,19 @@ function applyTemplate(content, vars) {
 function install() {
  const pkgDir = getPackageDir();
  if (!pkgDir) {
-    console.log("CI postinstall: Could not determine package directory. Skipping.");
+    console.log("CIAgent postinstall: Could not determine package directory. Skipping.");
    return;
  }
  const opencodeDir = path.join(pkgDir, "opencode");
  if (!fs.existsSync(opencodeDir)) {
-    console.log("CI postinstall: opencode/ directory not found. Skipping.");
+    console.log("CIAgent postinstall: opencode/ directory not found. Skipping.");
    return;
  }
  if (!isGlobalInstall()) {
-    console.log("CI postinstall: Not a global install. Skipping opencode integration.");
+    console.log("CIAgent postinstall: Not a global install. Skipping opencode integration.");
-    console.log("  Run `npx ci-install` or `./scripts/install.sh` to install manually.");
+    console.log("  Run `npx ciagent-install` or `./scripts/install.sh` to install manually.");
    return;
  }
@@ -132,11 +132,11 @@ function install() {
    }
  }
-  console.log(`CI postinstall: ${copied} files installed, ${skipped} skipped.`);
+  console.log(`CIAgent postinstall: ${copied} files installed, ${skipped} skipped.`);
 }
 try {
  install();
 } catch (err) {
-  console.log("CI postinstall: Non-fatal error:", err.message);
+  console.log("CIAgent postinstall: Non-fatal error:", err.message);
 }
@@ -4,7 +4,7 @@
 ## Decision Log
-Decisions are automatically logged to `.ci/audit/` with:
+Decisions are automatically logged to `.ciagent/audit/` with:
 - Timestamp
 - Decision ID
 - What was decided
@@ -15,5 +15,5 @@ Decisions are automatically logged to `.ci/audit/` with:
 ## Reviewing Decisions
-Run `ci audit` to review all autonomous decisions.
+Run `ciagent audit` to review all autonomous decisions.
-Run `ci audit --verbose` for detailed decision information.
+Run `ciagent audit --verbose` for detailed decision information.