valent-pipeline 0.1.6 → 0.1.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.1.6",
+  "version": "0.1.7",
   "description": "v3 multi-agent AI pipeline for software development lifecycle",
   "type": "module",
   "bin": {

package/pipeline/agents-manifest.yaml

@@ -29,7 +29,7 @@ agents:
     model: opus
     lifecycle: persistent
     role: "Pipeline orchestrator — spawns team, monitors execution, manages story lifecycle"
-    prompt_template: v3/prompts/lead.md
+    prompt_template: .valent-pipeline/prompts/lead.md
     reads_from: [story-input, agents-manifest.yaml, pipeline-config.yaml, pipeline-state.json]
     writes_to: [pipeline-state.json]
 
@@ -38,7 +38,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Requirements analyst — translates ACs into implementation brief"
-    prompt_template: v3/prompts/reqs.md
+    prompt_template: .valent-pipeline/prompts/reqs.md
     reads_from: [story-input]  # all story folder contents: ACs, trigger-map, architecture-decisions, UX spec when available
     writes_to: [reqs-brief.md]
 
@@ -47,7 +47,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "UX specification agent — translates UX spec into component specs"
-    prompt_template: v3/prompts/uxa.md
+    prompt_template: .valent-pipeline/prompts/uxa.md
     reads_from: [reqs-brief.md, ux-spec, trigger-map, scenarios]
     writes_to: [uxa-spec.md]
     project_types: [fullstack-web, frontend-only]
@@ -58,7 +58,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "QA spec writer — produces behavioral test specifications"
-    prompt_template: v3/prompts/qa-a.md
+    prompt_template: .valent-pipeline/prompts/qa-a.md
     reads_from: [reqs-brief.md, uxa-spec.md]
     writes_to: [qa-test-spec.md, visual-validation-checklist.md]
 
@@ -67,7 +67,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Quality gate — validates reqs, UXA spec, test specs (Pass 1) and bug priorities (Pass 2)"
-    prompt_template: v3/prompts/judge-g1.md
+    prompt_template: .valent-pipeline/prompts/judge-g1.md
     passes:
       pass1_review_order: [reqs-validation, uxa-validation, qa-spec-validation]  # sequential, stop on first failure
       pass2: bug-review
@@ -79,7 +79,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Backend developer — implements production code and tests"
-    prompt_template: v3/prompts/bend.md
+    prompt_template: .valent-pipeline/prompts/bend.md
     reads_from: [reqs-brief.md, qa-test-spec.md]
     writes_to: [bend-handoff.md]
 
@@ -88,7 +88,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Frontend developer — implements UI components and tests"
-    prompt_template: v3/prompts/fend.md
+    prompt_template: .valent-pipeline/prompts/fend.md
     reads_from: [reqs-brief.md, uxa-spec.md, qa-test-spec.md]
     writes_to: [fend-handoff.md]
     project_types: [fullstack-web, frontend-only]
@@ -98,7 +98,7 @@ agents:
     model: opus
     lifecycle: per-story
     role: "Code reviewer — 3-pass adversarial review of production and test code"
-    prompt_template: v3/prompts/critic.md
+    prompt_template: .valent-pipeline/prompts/critic.md
     review_passes: [blind-hunt, edge-case-hunt, acceptance-audit, triage]
     reads_from: [git-diff, reqs-brief.md, qa-test-spec.md]
     writes_to: [critic-review.md]
@@ -108,7 +108,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Test executor — runs tests, validates spec alignment, files bugs"
-    prompt_template: v3/prompts/qa-b.md
+    prompt_template: .valent-pipeline/prompts/qa-b.md
     reads_from: [qa-test-spec.md, critic-review.md, reqs-brief.md]
     writes_to: [execution-report.md, bugs.md, traceability-matrix.md]
     can_request_spawn: [pmcp]  # asks lead to spawn PMCP
@@ -118,7 +118,7 @@ agents:
     model: sonnet
     lifecycle: per-story
     role: "Final ship gate — evidence-based approval or rejection"
-    prompt_template: v3/prompts/judge-g2.md
+    prompt_template: .valent-pipeline/prompts/judge-g2.md
     reads_from: [execution-report.md, traceability-matrix.md, pmcp-evidence.md, bugs.md, judge-g1-review.md, qa-test-spec.md]  # critic-review.md intentionally excluded — G2 validates test/execution evidence, not code review; qa-test-spec.md used as reference for assertion cross-check
     writes_to: [judge-g2-decision.md, story-report.md]
 
@@ -127,7 +127,7 @@ agents:
     model: haiku
     lifecycle: per-story
     role: "Knowledge retrieval — answers queries from persistent data sources"
-    prompt_template: v3/prompts/knowledge.md
+    prompt_template: .valent-pipeline/prompts/knowledge.md
     data_sources: [chromadb, curated-knowledge-files, correction-directives]
     context_variables: [knowledge_mode, chromadb_host, chromadb_collection_prefix, curated_files_path, correction_directives]
     # No writes_to — Knowledge Agent responds via inbox only, no file output
@@ -137,7 +137,7 @@ ephemeral_agents:
     name: PMCP
     model: sonnet
     role: "Visual validation — executes browser automation MCP checklist, captures screenshots"
-    prompt_template: v3/prompts/pmcp.md
+    prompt_template: .valent-pipeline/prompts/pmcp.md
     reads_from: [visual-validation-checklist.md]
     writes_to: [pmcp-evidence.md]
     spawned_by: lead
@@ -148,7 +148,7 @@ ephemeral_agents:
     name: Embed
     model: haiku
     role: "Knowledge indexer — indexes curated patterns into knowledge base"
-    prompt_template: v3/prompts/embed.md
+    prompt_template: .valent-pipeline/prompts/embed.md
     spawned_by: lead
     triggered_by: retrospective  # only runs after Retrospective Agent curates what to index
 
@@ -156,7 +156,7 @@ ephemeral_agents:
     name: Retrospective
     model: sonnet
     role: "Batch reviewer — analyzes last N stories for recurring patterns"
-    prompt_template: v3/prompts/retrospective.md
+    prompt_template: .valent-pipeline/prompts/retrospective.md
     spawned_by: lead
     triggered_by: every-n-stories
 
@@ -164,7 +164,7 @@ ephemeral_agents:
     name: Help
     model: haiku
     role: "Pipeline help — explains any piece of the pipeline from documentation"
-    prompt_template: v3/prompts/help.md
-    reads_from: [v3/docs/]
+    prompt_template: .valent-pipeline/prompts/help.md
+    reads_from: [.valent-pipeline/docs/]
     spawned_by: lead
     triggered_by: user-request

package/pipeline/docs/agent-reference.md

@@ -1,7 +1,7 @@
 # V3 Agent Reference
 
 > Quick reference for all 15 agents in the v3 pipeline.
-> Definitive source: `v3/agents-manifest.yaml`
+> Definitive source: `.valent-pipeline/agents-manifest.yaml`
 
 ---
 
@@ -41,7 +41,7 @@ Spawned on-demand by the Lead when triggered by specific events.
 | PMCP | Sonnet | Visual validation -- browser automation MCP, captures screenshots | `visual-validation-checklist.md` | `pmcp-evidence.md` | Requested by QA-B, BEND, or FEND |
 | Embed | Haiku | Knowledge indexer -- indexes curated patterns into knowledge base | _(retrospective output)_ | _(indexing instructions)_ | After Retrospective agent curates what to index |
 | Retrospective | Sonnet | Batch reviewer -- analyzes last N stories for recurring patterns | _(story reports)_ | _(retrospective report)_ | Every N stories (configurable) |
-| Help | Haiku | Pipeline help -- explains any piece of the pipeline from documentation | `v3/docs/` | _(inbox only)_ | User request |
+| Help | Haiku | Pipeline help -- explains any piece of the pipeline from documentation | `.valent-pipeline/docs/` | _(inbox only)_ | User request |
 
 ---
 

package/pipeline/docs/knowledge-system.md

@@ -10,8 +10,8 @@ The knowledge system has three data sources, three agents, and one principle: th
 
 | Source | Format | Purpose |
 |--------|--------|---------|
-| **Curated knowledge files** | Markdown in `v3/knowledge/curated/` | Conventions, validated patterns, known pitfalls, test stability data |
-| **Correction directives** | YAML in `v3/knowledge/correction-directives.yaml` | Behavioral changes for agents -- translates observations into prompt-level guidance |
+| **Curated knowledge files** | Markdown in `.valent-pipeline/knowledge/curated/` | Conventions, validated patterns, known pitfalls, test stability data |
+| **Correction directives** | YAML in `.valent-pipeline/knowledge/correction-directives.yaml` | Behavioral changes for agents -- translates observations into prompt-level guidance |
 | **ChromaDB** (optional) | Vector store via Docker or remote host | Embedding-based retrieval for code patterns and build artifacts |
 
 ### Agents
@@ -34,7 +34,7 @@ Retrospective Agent
     v
 Embed Agent
     |--- indexes ---> ChromaDB collections (if configured)
-    |--- writes  ---> v3/knowledge/curated/ files
+    |--- writes  ---> .valent-pipeline/knowledge/curated/ files
     v
 Knowledge Agent (next story)
     |--- reads   ---> correction directives (active only)
@@ -175,7 +175,7 @@ Configured via `knowledge.mode` in `pipeline-config.yaml`.
 
 ### `local-docker`
 
-- ChromaDB runs locally via `docker compose -f v3/docker-compose.chromadb.yml up -d`
+- ChromaDB runs locally via `docker compose -f .valent-pipeline/docker-compose.chromadb.yml up -d`
 - Knowledge Agent connects to ChromaDB at the configured `chromadb_host` (typically `http://localhost:8000`)
 - Falls back to curated-only mode if ChromaDB is unreachable
 - Embed Agent indexes into both ChromaDB collections and curated files
@@ -224,7 +224,7 @@ Each instruction specifies content, target, and metadata:
 
 | Target | Behavior |
 |--------|----------|
-| `curated/{filename}` | Write or update a file in `v3/knowledge/curated/`. Existing content is preserved unless the instruction specifies replacement. |
+| `curated/{filename}` | Write or update a file in `.valent-pipeline/knowledge/curated/`. Existing content is preserved unless the instruction specifies replacement. |
 | `chromadb-collection:{name}` | Index into the named ChromaDB collection with the specified metadata. Only executed when `knowledge_mode` is `local-docker` or `connect-to-existing`. |
 
 ### Embed Agent Behavior

package/pipeline/docs/lead-lifecycle.md

@@ -1,6 +1,6 @@
 # Lead Agent Lifecycle Reference
 
-> Detailed reference for lead agent behavior. The lead prompt (`v3/prompts/lead.md`) references this document for long-form details.
+> Detailed reference for lead agent behavior. The lead prompt (`.valent-pipeline/prompts/lead.md`) references this document for long-form details.
 
 ---
 
@@ -49,12 +49,12 @@ The lead reads `agents-manifest.yaml`, filters by `lifecycle: per-story`, and ch
 ### Step 3: Prepare Shared Context
 
 - Place story input files in the story directory (`{story_output_dir}/`)
-- Read active correction directives from `v3/knowledge/correction-directives.yaml`
+- Read active correction directives from `.valent-pipeline/knowledge/correction-directives.yaml`
 - Include correction directives in the shared context for all agents
 
 ### Step 4: Build Task Dependency Graph
 
-See `v3/docs/task-graph.md` for the full specification. The lead constructs the graph from manifest `reads_from`/`writes_to` fields and the story execution sequence.
+See `.valent-pipeline/docs/task-graph.md` for the full specification. The lead constructs the graph from manifest `reads_from`/`writes_to` fields and the story execution sequence.
 
 ### Step 5: Spawn Teammates
 
@@ -94,7 +94,7 @@ When a gate rejects, the lead reads the rejection reason and routes per the Reje
 
 ### Escalation Handling
 
-Any teammate can send an inbox escalation to the lead. The lead either resolves autonomously or surfaces to the user via the Human Escalation Protocol (see `v3/docs/communication-standard.md#7`).
+Any teammate can send an inbox escalation to the lead. The lead either resolves autonomously or surfaces to the user via the Human Escalation Protocol (see `.valent-pipeline/docs/communication-standard.md#7`).
 
 ### PMCP / Embed Requests
 

package/pipeline/docs/lean-spawn-human-tasks.md

@@ -123,19 +123,19 @@ valent-pipeline init --yes
 ```
 
 Verify:
-- `v3/` directory created with all infrastructure files
-- `.claude/skills/v3-*/SKILL.md` files installed
-- `v3/pipeline-config.yaml` generated with defaults
+- `.valent-pipeline/` directory created with all infrastructure files
+- `.claude/skills/valent-*/SKILL.md` files installed
+- `.valent-pipeline/pipeline-config.yaml` generated with defaults
 - `pipeline-backlog.yaml` created
-- `v3/knowledge/curated/` directory with README
-- `v3/knowledge/correction-directives.yaml` exists
+- `.valent-pipeline/knowledge/curated/` directory with README
+- `.valent-pipeline/knowledge/correction-directives.yaml` exists
 
 Then test other commands:
 
 ```bash
 valent-pipeline config validate    # should exit 0
 valent-pipeline upgrade --dry-run  # should show no changes (just installed)
-valent-pipeline db init            # should create v3/pipeline.db
+valent-pipeline db init            # should create .valent-pipeline/pipeline.db
 valent-pipeline db rebuild         # should complete (no stories to index yet)
 ```
 
@@ -204,4 +204,4 @@ npx valent-pipeline upgrade
 1. **Package name:** `valent-pipeline` (unscoped) or `@valent/pipeline` (scoped)?
 2. **Embedding model:** Start with FTS5-only (simpler, no model dependency) or include vector embeddings from day 1?
 3. **ChromaDB deprecation:** Remove ChromaDB support entirely or keep as alternate mode?
-4. **v3-run-epic team lifecycle:** The Knowledge persistence change means teams persist across stories in an epic. Confirm you're OK with this behavioral change.
+4. **valent-run-epic team lifecycle:** The Knowledge persistence change means teams persist across stories in an epic. Confirm you're OK with this behavioral change.

package/pipeline/docs/npx-implementation-plan.md

@@ -33,7 +33,7 @@ valent-pipeline/
   bin/cli.js
   src/commands/{init,upgrade,validate}.js
   src/lib/{templates,config-schema}.js
-  pipeline/                  # infrastructure copied to user's v3/
+  pipeline/                  # infrastructure copied to user's .valent-pipeline/
     prompts/
     templates/
     task-graphs/             # 7 yaml files (one per project type)
@@ -43,9 +43,9 @@ valent-pipeline/
     docker-compose.chromadb.yml
     docs/
   skills/                    # copied to user's .claude/skills/
-    v3-run-story/SKILL.md
-    v3-configure/SKILL.md
-    v3-run-retrospective/SKILL.md
+    valent-run-story/SKILL.md
+    valent-configure/SKILL.md
+    valent-run-retrospective/SKILL.md
 ```
 
 ---
@@ -76,24 +76,24 @@ valent-pipeline/
   - ChromaDB settings
 - `--yes` flag for non-interactive defaults
 - File scaffolding on completion:
-  - Copy `pipeline/` contents to `./v3/`
-  - Generate `v3/pipeline-config.yaml` from answers
+  - Copy `pipeline/` contents to `./.valent-pipeline/`
+  - Generate `.valent-pipeline/pipeline-config.yaml` from answers
   - Create empty `pipeline-backlog.yaml`
   - Copy `skills/` contents to `./.claude/skills/`
-  - Create `v3/knowledge/curated/` with seeded README
-  - Create `v3/knowledge/correction-directives.yaml` (empty template)
-  - Append `v3/chromadb-data/` to `.gitignore`
-  - Write `v3/.valent-version` with current package version
-- Guard: warn if `v3/pipeline-config.yaml` already exists; require `--force` to overwrite
+  - Create `.valent-pipeline/knowledge/curated/` with seeded README
+  - Create `.valent-pipeline/knowledge/correction-directives.yaml` (empty template)
+  - Append `.valent-pipeline/chromadb-data/` to `.gitignore`
+  - Write `.valent-pipeline/.valent-version` with current package version
+- Guard: warn if `.valent-pipeline/pipeline-config.yaml` already exists; require `--force` to overwrite
 
 ---
 
 ## Step 4: Implement `upgrade` command [Medium]
 
 **Deliverables:**
-- Reads `v3/.valent-version` to determine currently installed version
+- Reads `.valent-pipeline/.valent-version` to determine currently installed version
 - Replaces infrastructure files only (prompts, templates, task-graphs, spawn-templates, agents-manifest, scripts, docker-compose, docs, skills)
-- Never touches project-specific files: `pipeline-config.yaml`, `correction-directives.yaml`, `pipeline-backlog.yaml`, `v3/knowledge/curated/`
+- Never touches project-specific files: `pipeline-config.yaml`, `correction-directives.yaml`, `pipeline-backlog.yaml`, `.valent-pipeline/knowledge/curated/`
 - `--dry-run` flag: prints what would change without writing
 - Major version bumps require `--force` and print migration notes
 
@@ -102,7 +102,7 @@ valent-pipeline/
 ## Step 5: Implement `config validate` command [Small]
 
 **Deliverables:**
-- JSON schema validation of `v3/pipeline-config.yaml` against schema in `src/lib/config-schema.js`
+- JSON schema validation of `.valent-pipeline/pipeline-config.yaml` against schema in `src/lib/config-schema.js`
 - Exit code `0` on valid, `1` on invalid (CI-friendly)
 - Human-readable error output with field paths
 
@@ -111,10 +111,10 @@ valent-pipeline/
 ## Step 6: Repo reorganization [Medium]
 
 **Deliverables:**
-- Infrastructure files moved/copied from `v3/` and `.claude/skills/v3-*/` into `valent-pipeline/pipeline/` and `valent-pipeline/skills/`
+- Infrastructure files moved/copied from `.valent-pipeline/` and `.claude/skills/valent-*/` into `valent-pipeline/pipeline/` and `valent-pipeline/skills/`
 - All 7 task graph YAML files created under `valent-pipeline/pipeline/task-graphs/` (existing 3 moved; 4 new ones authored: data-pipeline, mcp-server, document-generation, library)
 - Kanban test project (`kanban/`) stays as-is; consumes via `npm link` after this step
-- Current repo `v3/` remains as the "installed pipeline" for live testing
+- Current repo `.valent-pipeline/` remains as the "installed pipeline" for live testing
 
 ---
 

package/pipeline/docs/npx-packaging.md

@@ -20,29 +20,29 @@ The v3 pipeline splits into three categories of files:
 
 | File | Category | Notes |
 |------|----------|-------|
-| `v3/prompts/*.md` (14 files) | Pipeline infrastructure | Shipped with package |
-| `v3/templates/*.md` (17 files) | Pipeline infrastructure | Shipped with package |
-| `v3/task-graphs/fullstack-web.yaml` | Pipeline infrastructure | Shipped with package |
-| `v3/task-graphs/backend-api.yaml` | Pipeline infrastructure | Shipped with package |
-| `v3/task-graphs/frontend-only.yaml` | Pipeline infrastructure | Shipped with package |
-| `v3/spawn-templates/pipeline-context.template.md` | Pipeline infrastructure | Shipped with package; filled at runtime |
-| `v3/spawn-templates/agent-spawn.template.md` | Pipeline infrastructure | Shipped with package |
-| `v3/spawn-templates/knowledge-spawn.template.md` | Pipeline infrastructure | Shipped with package |
-| `v3/agents-manifest.yaml` | Pipeline infrastructure | Shipped with package; models section overridable via project config |
-| `v3/scripts/embed.ts` | Pipeline infrastructure | Shipped with package |
-| `v3/docker-compose.chromadb.yml` | Pipeline infrastructure | Shipped with package |
-| `v3/docs/*.md` | Pipeline infrastructure | Shipped with package |
-| `.claude/skills/v3-run-story/SKILL.md` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
-| `.claude/skills/v3-configure/` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
-| `.claude/skills/v3-run-retrospective/` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
-| `v3/pipeline-config.yaml` | Project-specific | Generated by init wizard from user answers |
-| `v3/knowledge/curated/` | Project-specific | Directory created by init; README seeded; content added by project team |
-| `v3/knowledge/correction-directives.yaml` | Project-specific | Empty template written by init; populated by Retrospective agent over time |
+| `.valent-pipeline/prompts/*.md` (14 files) | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/templates/*.md` (17 files) | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/task-graphs/fullstack-web.yaml` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/task-graphs/backend-api.yaml` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/task-graphs/frontend-only.yaml` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/spawn-templates/pipeline-context.template.md` | Pipeline infrastructure | Shipped with package; filled at runtime |
+| `.valent-pipeline/spawn-templates/agent-spawn.template.md` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/spawn-templates/knowledge-spawn.template.md` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/agents-manifest.yaml` | Pipeline infrastructure | Shipped with package; models section overridable via project config |
+| `.valent-pipeline/scripts/embed.ts` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/docker-compose.chromadb.yml` | Pipeline infrastructure | Shipped with package |
+| `.valent-pipeline/docs/*.md` | Pipeline infrastructure | Shipped with package |
+| `.claude/skills/valent-run-story/SKILL.md` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
+| `.claude/skills/valent-configure/` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
+| `.claude/skills/valent-run-retrospective/` | Pipeline infrastructure | Installed to project's `.claude/skills/` by init |
+| `.valent-pipeline/pipeline-config.yaml` | Project-specific | Generated by init wizard from user answers |
+| `.valent-pipeline/knowledge/curated/` | Project-specific | Directory created by init; README seeded; content added by project team |
+| `.valent-pipeline/knowledge/correction-directives.yaml` | Project-specific | Empty template written by init; populated by Retrospective agent over time |
 | `pipeline-backlog.yaml` | Project-specific | Initialized empty by init |
 | `stories/` | Runtime-generated | Created during story execution |
-| `v3/steps/qa-a/` | Runtime-generated | QA-A step files written during story execution |
-| `v3/steps/qa-b/` | Runtime-generated | QA-B step files written during story execution |
-| `v3/chromadb-data/` | Runtime-generated | ChromaDB persistent volume; not committed |
+| `.valent-pipeline/steps/qa-a/` | Runtime-generated | QA-A step files written during story execution |
+| `.valent-pipeline/steps/qa-b/` | Runtime-generated | QA-B step files written during story execution |
+| `.valent-pipeline/chromadb-data/` | Runtime-generated | ChromaDB persistent volume; not committed |
 
 ---
 
@@ -51,14 +51,14 @@ The v3 pipeline splits into three categories of files:
 `npx valent-pipeline init` runs an interactive wizard and then sets up the project:
 
 1. **Prompt** for project type (`fullstack-web`, `backend-api`, `frontend-only`, etc.), tech stack (language, frameworks, test tools), model tier preferences, and knowledge store mode.
-2. **Copy pipeline infrastructure** to `v3/` in the project: prompts, templates, task graphs, spawn templates, agents manifest, scripts, docker-compose, docs.
-3. **Generate `v3/pipeline-config.yaml`** from user answers.
+2. **Copy pipeline infrastructure** to `.valent-pipeline/` in the project: prompts, templates, task graphs, spawn templates, agents manifest, scripts, docker-compose, docs.
+3. **Generate `.valent-pipeline/pipeline-config.yaml`** from user answers.
 4. **Initialize `pipeline-backlog.yaml`** as an empty backlog template.
-5. **Install skills** to the project's `.claude/skills/` directory (not the user's global `~/.claude/skills/`): `v3-run-story`, `v3-configure`, `v3-run-retrospective`. Project-scoped skills are resolved by Claude Code from the repo root, so they travel with the repo and don't collide with other projects on the same machine.
-6. **Create `v3/knowledge/curated/`** with a seeded README explaining how to add curated files.
-7. **Create `v3/knowledge/correction-directives.yaml`** as an empty template.
+5. **Install skills** to the project's `.claude/skills/` directory (not the user's global `~/.claude/skills/`): `valent-run-story`, `valent-configure`, `valent-run-retrospective`. Project-scoped skills are resolved by Claude Code from the repo root, so they travel with the repo and don't collide with other projects on the same machine.
+6. **Create `.valent-pipeline/knowledge/curated/`** with a seeded README explaining how to add curated files.
+7. **Create `.valent-pipeline/knowledge/correction-directives.yaml`** as an empty template.
 
-The `stories/` directory and all runtime-generated content are created on demand during the first `/v3-run-story` invocation.
+The `stories/` directory and all runtime-generated content are created on demand during the first `/valent-run-story` invocation.
 
 ---
 
@@ -66,7 +66,7 @@ The `stories/` directory and all runtime-generated content are created on demand
 
 The new task-graph and spawn-template files shift logic from imperative SKILL.md code to declarative data files. This has direct implications for packaging:
 
-**Task graphs are static per project type.** The Lead reads `v3/task-graphs/{project_type}.yaml` at startup to get the dependency graph, rather than building it from logic embedded in SKILL.md. Adding a new project type means adding a new YAML file — no changes to SKILL.md.
+**Task graphs are static per project type.** The Lead reads `.valent-pipeline/task-graphs/{project_type}.yaml` at startup to get the dependency graph, rather than building it from logic embedded in SKILL.md. Adding a new project type means adding a new YAML file — no changes to SKILL.md.
 
 **Spawn templates are static.** The orchestrator fills `pipeline-context.template.md` at runtime with story ID, pipeline config, and knowledge context, then uses it when spawning agents. The template itself ships unchanged with the package.
 
@@ -78,8 +78,8 @@ The new task-graph and spawn-template files shift logic from imperative SKILL.md
 
 ## 5. Future Considerations
 
-**Version management.** When a new package version is released, infrastructure files in `v3/` need to be updated. A `npx valent-pipeline upgrade` command (or a check during init/run) should diff the installed versions of infrastructure files against the package version and offer a guided upgrade. Project-specific files (`pipeline-config.yaml`, `correction-directives.yaml`, backlog) must never be overwritten during upgrade.
+**Version management.** When a new package version is released, infrastructure files in `.valent-pipeline/` need to be updated. A `npx valent-pipeline upgrade` command (or a check during init/run) should diff the installed versions of infrastructure files against the package version and offer a guided upgrade. Project-specific files (`pipeline-config.yaml`, `correction-directives.yaml`, backlog) must never be overwritten during upgrade.
 
-**Knowledge and ChromaDB.** The `v3/knowledge/curated/` directory and `correction-directives.yaml` are project-specific and grow over time. ChromaDB data (`v3/chromadb-data/`) is a runtime artifact that should be in `.gitignore`. The embed script (`v3/scripts/embed.ts`) is infrastructure and ships with the package, but the ChromaDB instance itself is the project team's responsibility to stand up and maintain.
+**Knowledge and ChromaDB.** The `.valent-pipeline/knowledge/curated/` directory and `correction-directives.yaml` are project-specific and grow over time. ChromaDB data (`.valent-pipeline/chromadb-data/`) is a runtime artifact that should be in `.gitignore`. The embed script (`.valent-pipeline/scripts/embed.ts`) is infrastructure and ships with the package, but the ChromaDB instance itself is the project team's responsibility to stand up and maintain.
 
-**Skills installation.** Skills are installed to the project's `.claude/skills/` directory, not the user's global `~/.claude/skills/`. Claude Code resolves skills from the project root first, so project-scoped skills take precedence and don't collide across projects. This means multiple projects on the same machine can run different pipeline versions without conflict. The init command should create `.claude/skills/v3-run-story/`, `.claude/skills/v3-configure/`, and `.claude/skills/v3-run-retrospective/` inside the project repo.
+**Skills installation.** Skills are installed to the project's `.claude/skills/` directory, not the user's global `~/.claude/skills/`. Claude Code resolves skills from the project root first, so project-scoped skills take precedence and don't collide across projects. This means multiple projects on the same machine can run different pipeline versions without conflict. The init command should create `.claude/skills/valent-run-story/`, `.claude/skills/valent-configure/`, and `.claude/skills/valent-run-retrospective/` inside the project repo.

package/pipeline/docs/pipeline-overview.md

@@ -92,7 +92,7 @@ All inter-agent communication uses the distilled communication standard:
 - **Design Council** protocol for structured deliberation on contested design decisions
 - **Human Escalation** protocol when agent deliberation is insufficient
 
-See `v3/docs/communication-standard.md` for the full specification.
+See `.valent-pipeline/docs/communication-standard.md` for the full specification.
 
 ---
 
@@ -109,21 +109,21 @@ See `v3/docs/communication-standard.md` for the full specification.
 ## How to Run It
 
 ```
-/v3-run-story STORY-ID
+/valent-run-story STORY-ID
 ```
 
 This spawns the Lead agent, which reads the story input from `stories/STORY-ID/`, builds the team, and executes the pipeline.
 
 ### Prerequisites
 
-1. A `v3/pipeline-config.yaml` file exists (run `/v3-configure` to generate one)
+1. A `.valent-pipeline/pipeline-config.yaml` file exists (run `/valent-configure` to generate one)
 2. A story directory exists at `stories/STORY-ID/` with at least a `story.md` file containing the user story and acceptance criteria
 
 ---
 
 ## How to Configure
 
-Run `/v3-configure` to interactively set:
+Run `/valent-configure` to interactively set:
 
 - **Project type** -- fullstack-web, backend-api, frontend-only, data-pipeline, mcp-server, document-generation, library
 - **Tech stack** -- language, frameworks, test tools, browser automation
@@ -131,7 +131,7 @@ Run `/v3-configure` to interactively set:
 - **Quality thresholds** -- max rejection cycles, retrospective frequency, stall detection timeout
 - **Knowledge store** -- none (curated files only), local-docker (ChromaDB), or connect-to-existing
 
-Configuration is stored in `v3/pipeline-config.yaml`. See that file for detailed comments on every setting.
+Configuration is stored in `.valent-pipeline/pipeline-config.yaml`. See that file for detailed comments on every setting.
 
 ---
 

package/pipeline/docs/template-skeleton.md

@@ -1,6 +1,6 @@
 # Template Skeleton Reference
 
-Universal structure that all 16 handoff document templates follow. Consult this document before authoring or modifying any template in `v3/templates/`.
+Universal structure that all 16 handoff document templates follow. Consult this document before authoring or modifying any template in `.valent-pipeline/templates/`.
 
 ---
 
@@ -197,7 +197,7 @@ blockers: []
 
 ### What does NOT go in a template
 
-- Agent reasoning logic or decision procedures. That belongs in the agent's prompt (`v3/prompts/{agent}.md`).
+- Agent reasoning logic or decision procedures. That belongs in the agent's prompt (`.valent-pipeline/prompts/{agent}.md`).
 - Hardcoded tech stack references. Use `{backend_framework}`, `{test_framework_unit}`, etc. when the section content varies by tech stack.
 - Prose instructions to the agent. Templates are output schemas, not input prompts.
 - Default values or example data. Placeholders use `{token}` syntax only.
@@ -222,7 +222,7 @@ The lead agent validates handoff artifacts against templates at two points:
 
 ### At pipeline initialization
 
-- For every agent in the manifest, verify that each `writes_to` artifact has a corresponding `.template.md` file in `v3/templates/`.
+- For every agent in the manifest, verify that each `writes_to` artifact has a corresponding `.template.md` file in `.valent-pipeline/templates/`.
 - For every `reads_from` entry, verify that some other agent's `writes_to` produces it (or it is a story input).
 - Missing templates are a configuration error; the lead halts and reports.
 
@@ -259,7 +259,7 @@ Templates do not restate the communication standard rules. They embody them stru
 
 ## 7. Template Inventory
 
-The 16 templates in `v3/templates/`, mapped to their producing agents:
+The 16 templates in `.valent-pipeline/templates/`, mapped to their producing agents:
 
 | Template | Producing Agent | Primary Consumers |
 |----------|----------------|-------------------|

package/pipeline/prompts/bend.md

@@ -69,7 +69,7 @@ Read active correction directives from `{correction_directives}`. If the file do
 
 ## Output
 
-Write `bend-handoff.md` using the template at `v3/templates/bend-handoff.template.md`. Update YAML frontmatter as you complete each step.
+Write `bend-handoff.md` using the template at `.valent-pipeline/templates/bend-handoff.template.md`. Update YAML frontmatter as you complete each step.
 
 ## Quality Standards
 
@@ -99,13 +99,13 @@ Update `stepsCompleted` and `pendingSteps` in frontmatter as you progress.
 
 ### Decision Gate: testing_profiles
 
-If `testing_profiles` excludes `api`, read `v3/steps/common/no-api-passthrough.md` and skip remaining steps.
+If `testing_profiles` excludes `api`, read `.valent-pipeline/steps/common/no-api-passthrough.md` and skip remaining steps.
 
 ### Steps
 
 | Step | File | Summary |
 |------|------|---------|
-| 1. Read Inputs | `v3/steps/bend/read-inputs.md` | Read reqs-brief, qa-test-spec, correction directives, knowledge queries |
-| 2. Implement | `v3/steps/bend/implement.md` | DB changes, API endpoints, business logic |
-| 3. Write Tests | `v3/steps/bend/write-tests.md` | Test writing, DB verification, execution, integration readiness |
-| 4. Handoff | `v3/steps/bend/handoff.md` | Write bend-handoff.md, final verification |
+| 1. Read Inputs | `.valent-pipeline/steps/bend/read-inputs.md` | Read reqs-brief, qa-test-spec, correction directives, knowledge queries |
+| 2. Implement | `.valent-pipeline/steps/bend/implement.md` | DB changes, API endpoints, business logic |
+| 3. Write Tests | `.valent-pipeline/steps/bend/write-tests.md` | Test writing, DB verification, execution, integration readiness |
+| 4. Handoff | `.valent-pipeline/steps/bend/handoff.md` | Write bend-handoff.md, final verification |

package/pipeline/prompts/critic.md

@@ -74,7 +74,7 @@ Update YAML frontmatter as you complete each step. Fields: `stepsCompleted`, `pe
 
 ## Output
 
-Write `critic-review.md` using the template at `v3/templates/critic-review.template.md`. Update YAML frontmatter as you complete each step.
+Write `critic-review.md` using the template at `.valent-pipeline/templates/critic-review.template.md`. Update YAML frontmatter as you complete each step.
 
 ## Step Sequence
 
@@ -82,15 +82,15 @@ After triage-depth, execute only the passes indicated by your selected depth lev
 
 | Step | File | Condition |
 |------|------|-----------|
-| 0. Triage Depth | `v3/steps/critic/triage-depth.md` | Always |
+| 0. Triage Depth | `.valent-pipeline/steps/critic/triage-depth.md` | Always |
 | 1. Read git diff | (inline) | Always |
-| 2. Pass 1: Blind Hunt | `v3/steps/critic/blind-hunt.md` | standard, deep |
+| 2. Pass 1: Blind Hunt | `.valent-pipeline/steps/critic/blind-hunt.md` | standard, deep |
 | 2b. Query Knowledge Agent | (inline -- conditional) | If Knowledge Agent available |
-| 3. Pass 2: Edge Case Hunt | `v3/steps/critic/edge-case-hunt.md` | deep only |
-| 4. Pass 3: Acceptance Audit | `v3/steps/critic/acceptance-audit.md` | Always |
-| 5. Test Code Review | `v3/steps/critic/test-review.md` | standard, deep |
-| 6. Triage | `v3/steps/critic/triage.md` | Always |
-| 7. Write Verdict | `v3/steps/critic/write-verdict.md` | Always |
+| 3. Pass 2: Edge Case Hunt | `.valent-pipeline/steps/critic/edge-case-hunt.md` | deep only |
+| 4. Pass 3: Acceptance Audit | `.valent-pipeline/steps/critic/acceptance-audit.md` | Always |
+| 5. Test Code Review | `.valent-pipeline/steps/critic/test-review.md` | standard, deep |
+| 6. Triage | `.valent-pipeline/steps/critic/triage.md` | Always |
+| 7. Write Verdict | `.valent-pipeline/steps/critic/write-verdict.md` | Always |
 
 ### Step 1: Read the git diff
 Read ALL changed files. Categorize into production code vs test code. Note file count and line count for the Review Scope section.

package/pipeline/prompts/embed.md

@@ -32,7 +32,7 @@ Verify `{story_output_dir}/embed-instructions.md` exists. If missing, send `[BLO
 **If `{knowledge_mode}` is `sqlite` (recommended):**
 
 ```bash
-npx tsx v3/scripts/embed-sqlite.ts {story_output_dir}/embed-instructions.md \
+npx tsx .valent-pipeline/scripts/embed-sqlite.ts {story_output_dir}/embed-instructions.md \
   --db-path {sqlite_db_path} \
   --curated-path {curated_files_path}
 ```
@@ -46,7 +46,7 @@ The script handles:
 **If `{knowledge_mode}` is `local-docker` or `connect-to-existing` (legacy):**
 
 ```bash
-npx tsx v3/scripts/embed.ts {story_output_dir}/embed-instructions.md \
+npx tsx .valent-pipeline/scripts/embed.ts {story_output_dir}/embed-instructions.md \
   --chromadb-host {chromadb_host} \
   --collection-prefix {chromadb_collection_prefix} \
   --curated-path {curated_files_path}

package/pipeline/prompts/fend.md

@@ -66,7 +66,7 @@ Read active correction directives from `{correction_directives}`. If the file do
 
 ## Output
 
-Write `fend-handoff.md` using the template at `v3/templates/fend-handoff.template.md`. Update YAML frontmatter as you complete each step.
+Write `fend-handoff.md` using the template at `.valent-pipeline/templates/fend-handoff.template.md`. Update YAML frontmatter as you complete each step.
 
 ## Quality Standards
 
@@ -124,13 +124,13 @@ Update `stepsCompleted` and `pendingSteps` in frontmatter as you progress.
 
 ### Decision Gate: testing_profiles
 
-If `testing_profiles` excludes `ui`, read `v3/steps/common/no-ui-passthrough.md` and skip remaining steps.
+If `testing_profiles` excludes `ui`, read `.valent-pipeline/steps/common/no-ui-passthrough.md` and skip remaining steps.
 
 ### Steps
 
 | Step | File | Summary |
 |------|------|---------|
-| 1. Read Inputs | `v3/steps/fend/read-inputs.md` | Read reqs-brief, uxa-spec, qa-test-spec, correction directives, knowledge queries |
-| 2. Implement | `v3/steps/fend/implement.md` | Components, states, accessibility, routing |
-| 3. Write Tests | `v3/steps/fend/write-tests.md` | Test writing, execution, integration readiness |
-| 4. Handoff | `v3/steps/fend/handoff.md` | Write fend-handoff.md, final verification |
+| 1. Read Inputs | `.valent-pipeline/steps/fend/read-inputs.md` | Read reqs-brief, uxa-spec, qa-test-spec, correction directives, knowledge queries |
+| 2. Implement | `.valent-pipeline/steps/fend/implement.md` | Components, states, accessibility, routing |
+| 3. Write Tests | `.valent-pipeline/steps/fend/write-tests.md` | Test writing, execution, integration readiness |
+| 4. Handoff | `.valent-pipeline/steps/fend/handoff.md` | Write fend-handoff.md, final verification |