@deftai/directive-content 0.65.0 → 0.66.0

package/skills/deft-directive-article-review/SKILL.md

@@ -42,13 +42,13 @@ Use this summary to evaluate whether article ideas are genuinely novel or alread
 
 **Directive** is a development framework that combines indexed documentation, task automation, and AI-assisted workflows.
 
-**main.md (front door)** — Central entry/index for a Karpathy-wiki-style set of lazy-loaded markdown rules organized into sections: `coding/`, `languages/`, `interfaces/`, `tools/`, `scm/`, `contracts/`, `swarm/`, `strategies/`, `vbrief/`, and `templates/`. Agents load only what's relevant.
+**main.md (front door)** — Central entry/index for a Karpathy-wiki-style set of lazy-loaded markdown rules organized into sections: `coding/`, `languages/`, `interfaces/`, `tools/`, `scm/`, `contracts/`, `swarm/`, `strategies/`, `xbrief/`, and `templates/`. Agents load only what's relevant.
 
 **Taskfiles (go-task)** — Single entrypoint for all repeatable operations. Core flows: `task dev`, `task test`, `task build`, `task release`. Composed via `deps`; logic lives in scripts/binaries. Caching via `sources/generates + method: checksum`. Namespaced tasks (`docker:build`, `db:migrate`). Every user-facing task has a `desc`; internal wiring marked `internal: true`.
 
-**vbrief** — Structured JSON artifacts in `./vbrief/` covering current state and forward planning: `plan.vbrief.json` (todos/progress), `specification.vbrief.json` (project specs), `playbook-{name}.vbrief.json` (reusable playbooks), `continue.vbrief.json` (interruption recovery). Drives the full lifecycle: planning → specification → execution → checkpointing → resumption. Refreshed via `deft-sync` at session start.
+**xbrief** — Structured JSON artifacts in `./xbrief/` covering current state and forward planning: `plan.xbrief.json` (todos/progress), `specification.xbrief.json` (project specs), `playbook-{name}.xbrief.json` (reusable playbooks), `continue.xbrief.json` (interruption recovery). Drives the full lifecycle: planning → specification → execution → checkpointing → resumption. Refreshed via `deft-sync` at session start.
 
-**Skills** — Versioned, reusable workflows triggered by keywords: `deft-setup` (bootstrap), `deft-build` (implement from spec), `deft-sync` (refresh framework + vbrief), `deft-pre-pr` (quality loop), `deft-review-cycle` (PR bot feedback), `deft-swarm` (parallel agent orchestration), `deft-roadmap-refresh` (issue triage), `deft-interview` (structured Q&A). Skills chain together and encode lessons from prior runs.
+**Skills** — Versioned, reusable workflows triggered by keywords: `deft-setup` (bootstrap), `deft-build` (implement from spec), `deft-sync` (refresh framework + xbrief), `deft-pre-pr` (quality loop), `deft-review-cycle` (PR bot feedback), `deft-swarm` (parallel agent orchestration), `deft-roadmap-refresh` (issue triage), `deft-interview` (structured Q&A). Skills chain together and encode lessons from prior runs.
 
 ## When to Use
 
@@ -77,7 +77,7 @@ Use this summary to evaluate whether article ideas are genuinely novel or alread
 Look for lessons applicable to how directive itself is built, structured, and maintained:
 
 - ! Skills and strategies: are there new skills, strategies, or workflow patterns directive should adopt?
-- ! Framework architecture: does this suggest changes to lazy loading, vBRIEF, AGENTS.md structure, or the patterns/ directory?
+- ! Framework architecture: does this suggest changes to lazy loading, xBRIEF, AGENTS.md structure, or the patterns/ directory?
 - ! Agent safety and reliability: does this reveal new failure modes or defenses directive should encode?
 - ! Tooling: does this suggest new tasks, task patterns, or SCM conventions directive should add?
 - ~ Naming, directory structure, or documentation conventions worth adopting

package/skills/deft-directive-build/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: deft-directive-build
 description: >-
-  Build a project from scope vBRIEFs following Deft Directive framework
+  Build a project from scope xBRIEFs following Deft Directive framework
   standards. Use after deft-directive-setup has generated the project
-  definition, or when the user has story vBRIEFs in vbrief/active/ ready to
+  definition, or when the user has story xBRIEFs in xbrief/active/ ready to
   implement. Handles scaffolding, implementation, testing, and quality checks
   phase by phase.
 ---
@@ -15,33 +15,33 @@ description: >-
 
 # Deft Directive Build
 
-Implements a project from its scope vBRIEFs following Deft Directive standards.
+Implements a project from its scope xBRIEFs following Deft Directive standards.
 
 Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## When to Use
 
-- After `deft-directive-setup` completes and generates `PROJECT-DEFINITION.vbrief.json`
+- After `deft-directive-setup` completes and generates `PROJECT-DEFINITION.xbrief.json`
 - User says "build this", "implement the spec", or "start building"
-- Resuming a partially-built project that has story vBRIEFs in `vbrief/active/`
+- Resuming a partially-built project that has story xBRIEFs in `xbrief/active/`
 
 ## Step 0 -- Implementation Preflight (#810)
 
 - ! Before starting any new implementation story or switching from one story to another, MUST run `git status --short --branch`.
 - ! If the working tree is dirty, MUST stop and summarize the current branch, modified/untracked files, and whether the changes appear related to the target story. Ask the operator to choose one path: commit existing work, stash existing work, include existing work in the current story, or stop.
 - ⊗ Begin a new story while unrelated dirty work is present without explicit operator approval.
-- ! Resolve exactly one target story vBRIEF path by default. One story is the default implementation unit for this skill; if the user asks for a phase/epic, decompose or ask which story to start.
+- ! Resolve exactly one target story xBRIEF path by default. One story is the default implementation unit for this skill; if the user asks for a phase/epic, decompose or ask which story to start.
 - ! Batching multiple stories in one branch/PR requires explicit operator approval and a short rationale recorded in the handoff.
-- ! **Swarm-cohort dispatch carve-out**: when this skill is invoked as part of a swarm cohort allocated by `skills/deft-directive-swarm/SKILL.md`, the approved Phase 5 allocation plan satisfies the "explicit operator approval and short rationale recorded in the handoff" requirement above -- the dispatched vBRIEF paths and allocation rationale ARE the consent token. Process each assigned story sequentially under the checkpoint-commit + `task scope:complete` discipline below. Do NOT re-prompt the parent for batching approval mid-cohort -- the all-or-nothing dispatch envelope rule (`AGENTS.md` `## Multi-agent orchestration discipline (#954)`) forbids mid-scope user-approval gates.
+- ! **Swarm-cohort dispatch carve-out**: when this skill is invoked as part of a swarm cohort allocated by `skills/deft-directive-swarm/SKILL.md`, the approved Phase 5 allocation plan satisfies the "explicit operator approval and short rationale recorded in the handoff" requirement above -- the dispatched xBRIEF paths and allocation rationale ARE the consent token. Process each assigned story sequentially under the checkpoint-commit + `task scope:complete` discipline below. Do NOT re-prompt the parent for batching approval mid-cohort -- the all-or-nothing dispatch envelope rule (`AGENTS.md` `## Multi-agent orchestration discipline (#954)`) forbids mid-scope user-approval gates.
 - ! **Structured consent-token recognition (#1378)**: the canonical recognition path for the carve-out above is the structured `## Allocation context` section of the dispatch envelope (the frozen schema in `templates/agent-prompt-preamble.md`, Story A of #1378). When that section reports `dispatch_kind: swarm-cohort` with a non-null `allocation_plan_id` AND a non-null `batching_rationale`, the consent token is satisfied mechanically -- read `cohort_vbriefs` as the authoritative file boundary and process each entry sequentially under the checkpoint-commit + `task scope:complete` discipline below, without re-prompting the parent for batching approval mid-cohort. When the `## Allocation context` section is ABSENT (pre-#1378 dispatches, solo-interactive sessions), fall back to the #1371 prose carve-out immediately above -- the prose carve-out remains the recognition path of record for un-elevated envelopes.
 - ! **Within a cohort, between stories**: the working tree MUST be clean after each story's checkpoint commit + `task scope:complete`. If `git status --short` shows uncommitted state between stories (e.g. a missed `task scope:complete` move, an unstaged file from the prior story), checkpoint-commit it and proceed -- do NOT pause to ask the operator. The dirty-tree "ask the operator" branch above applies only at the FIRST story-start of a fresh branch, where uncommitted operator work might legitimately exist.
-- ! If the target story is in `vbrief/proposed/`, run `task scope:promote -- <path>` first; if it is in `vbrief/pending/`, run `task scope:activate -- <path>`. After activation, update the path to the active-file location before preflight.
-- ! Before any code-writing tool call -- the first scaffold edit, the first `task` invocation that mutates files, or any `start_agent` dispatch that will implement scope -- MUST run `task vbrief:preflight -- <active-story-path>` (the structural intent gate; wraps `scripts/preflight_implementation.py` so the same invocation works whether deft is the project root or installed as a `deft/` subdirectory).
+- ! If the target story is in `xbrief/proposed/`, run `task scope:promote -- <path>` first; if it is in `xbrief/pending/`, run `task scope:activate -- <path>`. After activation, update the path to the active-file location before preflight.
+- ! Before any code-writing tool call -- the first scaffold edit, the first `task` invocation that mutates files, or any `start_agent` dispatch that will implement scope -- MUST run `task xbrief:preflight -- <active-story-path>` (the structural intent gate; wraps `scripts/preflight_implementation.py` so the same invocation works whether deft is the project root or installed as a `deft/` subdirectory).
 
-The gate exits 0 only when the candidate vBRIEF lives in `vbrief/active/` AND `plan.status == "running"`. Any other state (pending/, proposed/, completed/, active/-with-non-running-status, malformed JSON, missing keys) exits 1 with an actionable redirect to `task vbrief:activate <path>`.
+The gate exits 0 only when the candidate xBRIEF lives in `xbrief/active/` AND `plan.status == "running"`. Any other state (pending/, proposed/, completed/, active/-with-non-running-status, malformed JSON, missing keys) exits 1 with an actionable redirect to `task xbrief:activate <path>`.
 
 - ! A non-zero exit MUST halt the skill. Surface the helper's stderr message verbatim to the user; do NOT proceed to USER.md Gate, File Reading, or any later phase.
-- ! Use canonical lifecycle tasks to satisfy this gate: `task scope:promote -- <path>` for proposed stories, `task scope:activate -- <path>` for pending stories, and the helper's idempotent companion `task vbrief:activate <path>` only when following the preflight redirect directly. Manual lifecycle moves bypass the activation contract -- use the task.
+- ! Use canonical lifecycle tasks to satisfy this gate: `task scope:promote -- <path>` for proposed stories, `task scope:activate -- <path>` for pending stories, and the helper's idempotent companion `task xbrief:activate <path>` only when following the preflight redirect directly. Manual lifecycle moves bypass the activation contract -- use the task.
 - ⊗ Infer implementation intent from lifecycle vocabulary ("do the full PR process", "start the work", "poller agents"), branching language, or workflow shape. Workflow-shape vocabulary is NOT authorization to spawn an implementation agent (#810 surfacing event).
 - ⊗ Skip this preflight because the user said "yes", "go", or "proceed" -- affirmative continuation phrases are NOT implementation authorization unless the prior turn explicitly proposed implementation. When intent is ambiguous, ask one targeted question before invoking the gate.
 
@@ -64,13 +64,13 @@ The gate exits 0 only when the candidate vBRIEF lives in `vbrief/active/` AND `p
 
 A project is **pre-cutover** if ANY of the following are true. This prose mirrors the executable helper in `scripts/_precutover.py`; when in doubt, the helper is canonical.
 
-1. `SPECIFICATION.md` exists and is neither a deprecation redirect nor a current generated spec export. A current generated spec export contains `<!-- Purpose: rendered specification -->` and `<!-- Source of truth: vbrief/specification.vbrief.json -->`, and `vbrief/specification.vbrief.json` plus all five lifecycle folders exist.
+1. `SPECIFICATION.md` exists and is neither a deprecation redirect nor a current generated spec export. A current generated spec export contains `<!-- Purpose: rendered specification -->` and `<!-- Source of truth: xbrief/specification.xbrief.json -->`, and `xbrief/specification.xbrief.json` plus all five lifecycle folders exist.
 2. `PROJECT.md` exists and contains neither the legacy `<!-- deft:deprecated-redirect -->` sentinel NOR the current `Purpose: deprecation redirect` canonical-banner marker (real content, not a deprecation redirect)
-3. `vbrief/specification.vbrief.json` exists but the lifecycle folders (`vbrief/proposed/`, `vbrief/pending/`, `vbrief/active/`, `vbrief/completed/`, `vbrief/cancelled/`) do NOT exist
+3. `xbrief/specification.xbrief.json` exists but the lifecycle folders (`xbrief/proposed/`, `xbrief/pending/`, `xbrief/active/`, `xbrief/completed/`, `xbrief/cancelled/`) do NOT exist
 4. Strategy output shape violations (run `task verify-strategy-output` -- the canonical gate -- or the direct form `python .deft/core/scripts/validate_strategy_output.py --project-root <path>` after `deft` install):
-   - Any scope vBRIEF under `vbrief/proposed/` (or other lifecycle dirs) lacks the required `YYYY-MM-DD-` date prefix in its filename (e.g. bare `scaffold.vbrief.json`).
-   - `vbrief/PROJECT-DEFINITION.vbrief.json` is missing.
-   - `vbrief/specification.vbrief.json` exists as a legacy dual-write in a user-generated project. This is tolerated only for the framework source tree or a complete post-cutover full-spec consumer where all lifecycle folders exist and `SPECIFICATION.md` is rendered from `vbrief/specification.vbrief.json`.
+   - Any scope xBRIEF under `xbrief/proposed/` (or other lifecycle dirs) lacks the required `YYYY-MM-DD-` date prefix in its filename (e.g. bare `scaffold.xbrief.json`).
+   - `xbrief/PROJECT-DEFINITION.xbrief.json` is missing.
+   - `xbrief/specification.xbrief.json` exists as a legacy dual-write in a user-generated project. This is tolerated only for the framework source tree or a complete post-cutover full-spec consumer where all lifecycle folders exist and `SPECIFICATION.md` is rendered from `xbrief/specification.xbrief.json`.
 
 ### Action on Detection
 
@@ -80,11 +80,11 @@ A project is **pre-cutover** if ANY of the following are true. This prose mirror
 
 ! Include specific details about what was detected (the validator output is authoritative):
 
-- Legacy specification.vbrief.json or missing lifecycle folders: "Follow the frozen v0.59.0 migrator path (#2068) or run `task migrate:preflight` for current-release guidance"
-- Non-date-prefixed vBRIEFs: "Re-run the emitting strategy after the v0.20 migrations (#1166 s1+s2+...) or manually rename files to `YYYY-MM-DD-<slug>.vbrief.json` and `task scope:promote`"
-- Missing `PROJECT-DEFINITION.vbrief.json`: "Run `task project:render` to generate the project definition"
+- Legacy specification.xbrief.json or missing lifecycle folders: "Follow the frozen v0.59.0 migrator path (#2068) or run `task migrate:preflight` for current-release guidance"
+- Non-date-prefixed xBRIEFs: "Re-run the emitting strategy after the v0.20 migrations (#1166 s1+s2+...) or manually rename files to `YYYY-MM-DD-<slug>.xbrief.json` and `task scope:promote`"
+- Missing `PROJECT-DEFINITION.xbrief.json`: "Run `task project:render` to generate the project definition"
 - `SPECIFICATION.md` / `PROJECT.md` without sentinel: the classic pre-cutover messages
-- Scope vBRIEF in wrong folder: "Status is '{status}' but file is in {folder}/ -- run `task scope:activate <file>` to fix"
+- Scope xBRIEF in wrong folder: "Status is '{status}' but file is in {folder}/ -- run `task scope:activate <file>` to fix"
 
 ! After the validator reports clean, re-run this guard before continuing.
 
@@ -144,8 +144,8 @@ signal.
 ## File Reading
 
 - ! Read in order, lazy load:
-  1. `./vbrief/active/` -- scope vBRIEFs for work items to build (required)
-  2. `./vbrief/PROJECT-DEFINITION.vbrief.json` -- project identity, tech stack, architecture
+  1. `./xbrief/active/` -- scope xBRIEFs for work items to build (required)
+  2. `./xbrief/PROJECT-DEFINITION.xbrief.json` -- project identity, tech stack, architecture
   3. `./.planning/codebase/MAP.md` -- generated codebase orientation projection, if present (advisory)
   4. USER.md at the platform-appropriate path (see Platform Detection) -- Personal section is highest precedence; Defaults are fallback
   5. `deft/main.md` -- framework guidelines
@@ -162,22 +162,22 @@ signal.
 
 ```
 USER.md Personal                  <- HIGHEST (name, custom rules -- always wins)
-PROJECT-DEFINITION.vbrief.json   <- Project-specific (tech stack, architecture, config)
+PROJECT-DEFINITION.xbrief.json   <- Project-specific (tech stack, architecture, config)
 USER.md Defaults                  <- Fallback defaults (used when PROJECT-DEFINITION doesn't specify)
 {language}.md                     <- Language standards
 coding.md                         <- General coding
 main.md                           <- Framework defaults
-Scope vBRIEFs                     <- LOWEST
+Scope xBRIEFs                     <- LOWEST
 ```
 
 - ! USER.md Personal section always wins over any other file
-- ! For project-scoped settings, PROJECT-DEFINITION.vbrief.json overrides USER.md Defaults
+- ! For project-scoped settings, PROJECT-DEFINITION.xbrief.json overrides USER.md Defaults
 
 ## Change Lifecycle Gate
 
 ! Before any implementation that touches 3+ files, verify that a `/deft:change <name>` proposal exists and has been confirmed by the user:
 
-- ! Check `history/changes/` for an active `proposal.vbrief.json` matching this work
+- ! Check `history/changes/` for an active `proposal.xbrief.json` matching this work
 - ! If no proposal exists: propose `/deft:change <name>` and present the change name for explicit confirmation (e.g. "Confirm? yes/no")
 - ! The user must reply with an affirmative (`yes`, `confirmed`, `approve`) — a general 'proceed', 'do it', or 'go ahead' does NOT satisfy this gate
 - ? For solo projects: this gate is RECOMMENDED but not mandatory for changes fully covered by `task check`; it remains mandatory for cross-cutting, architectural, or high-risk changes
@@ -185,18 +185,18 @@ Scope vBRIEFs                     <- LOWEST
 
 ## Build Process
 
-All vBRIEFs (including those read from `vbrief/active/` and any new vBRIEFs this skill emits) MUST use `"vBRIEFInfo": { "version": "0.6" }`. The validator rejects any other version (see [`../../conventions/references.md`](../../conventions/references.md)).
+All xBRIEFs (including those read from `xbrief/active/` and any new xBRIEFs this skill emits) MUST use `"xBRIEFInfo": { "version": "0.6" }`. The validator rejects any other version (see [`../../conventions/references.md`](../../conventions/references.md)).
 
 ### Step 1: Understand the Scope
 
-- ! Read story vBRIEFs from `vbrief/active/` and `PROJECT-DEFINITION.vbrief.json`
-- ! Identify phases, dependencies, starting point from scope vBRIEF acceptance criteria
+- ! Read story xBRIEFs from `xbrief/active/` and `PROJECT-DEFINITION.xbrief.json`
+- ! Identify phases, dependencies, starting point from scope xBRIEF acceptance criteria
 - ~ Use `.planning/codebase/MAP.md`, when present, to orient broad codebase scanning. If the MAP conflicts with current code or canonical metadata, surface the drift and trust `plan.architecture.codeStructure` / provider artifacts plus the working tree over generated prose.
 - ! When scanning the existing codebase during scope understanding, MUST surface any contradicting patterns (two error-handling shapes, two state-management approaches, two naming conventions, etc.) before implementation begins -- apply `coding/hygiene.md` `## Surface Conflicts: Pick One, Explain, Flag the Other (#1005)` and choose ONE pattern (more recent OR more tested), explain the choice in the scope summary, and flag the other for cleanup
 - ⊗ Begin implementation against an averaged blend of two contradicting patterns -- "average code that satisfies both rules is the worst code" (#1005)
 - ! Present brief summary to user:
 
-> "Here's what I see: {N} story vBRIEFs in active/. I'll start with {name}. Ready?"
+> "Here's what I see: {N} story xBRIEFs in active/. I'll start with {name}. Ready?"
 
 ### Step 2: Verify Toolchain
 
@@ -223,7 +223,7 @@ After EVERY phase:
 
 ```bash
 task check          # Format, lint, type check, test, coverage
-task test:coverage  # >=85% or PROJECT-DEFINITION.vbrief.json override
+task test:coverage  # >=85% or PROJECT-DEFINITION.xbrief.json override
 ```
 
 - ! Phase is NOT done until `task check` passes
@@ -248,7 +248,7 @@ See `deft/coding/coding.md` and `deft/coding/testing.md` for full rules.
 ! Before every commit, re-read ALL modified files and explicitly check for:
 
 1. ! **Encoding errors** -- em-dashes corrupted to replacement characters, BOM artifacts, mojibake from round-trip read/write
-2. ! **Unintended duplication** -- accidental double entries in CHANGELOG.md, scope vBRIEF files, or structured data files
+2. ! **Unintended duplication** -- accidental double entries in CHANGELOG.md, scope xBRIEF files, or structured data files
 3. ! **Structural issues** -- malformed CHANGELOG entries, broken table rows, mismatched index entries, invalid JSON/YAML
 4. ! **Semantic accuracy** -- verify that counts, claims, and summaries in CHANGELOG entries and ROADMAP changelog lines match the actual data in the commit (e.g. "triaged 4 issues" must match the number actually triaged, issue numbers cited must match the issues actually added)
 5. ! **Semantic contradictions** -- when adding a `!` or `⊗` rule that prohibits a specific command, pattern, or behavior, search the same file for any `~`, `≉`, or prose that recommends or permits the same command/pattern -- resolve all contradictions in the same commit before pushing
@@ -275,8 +275,8 @@ feat(phase-2): add REST API endpoints with integration tests
 - ! Tests fail → fix them; ⊗ skip or weaken assertions
 - ! Coverage drops → write more tests; ⊗ exclude files
 - ! Lint/type errors → fix them; ≉ add ignore comments without documented reason
-- ! Scope vBRIEF ambiguous -> ask user; ⊗ guess
-- ! Scope needs changes -> propose, get approval, update the scope vBRIEF first
+- ! Scope xBRIEF ambiguous -> ask user; ⊗ guess
+- ! Scope needs changes -> propose, get approval, update the scope xBRIEF first
 
 ## Completion
 
@@ -288,15 +288,15 @@ feat(phase-2): add REST API endpoints with integration tests
 
 - ⊗ Skip tests or write them after implementation
 - ⊗ Ignore `task check` failures
-- ⊗ Implement things not in scope vBRIEF without asking
+- ⊗ Implement things not in scope xBRIEF without asking
 - ⊗ Read every deft file upfront
 - ⊗ Move to next phase before current passes checks
 - ⊗ Make commits without running `task check`
 - ⊗ Proceed without USER.md -- always run the USER.md Gate first
-- ⊗ Spawn an implementation agent or invoke a code-writing tool against a vBRIEF that has not passed `task vbrief:preflight` (which wraps `scripts/preflight_implementation.py`) -- always run the Step 0 Implementation Preflight (#810) first; satisfy via `task vbrief:activate <path>`
+- ⊗ Spawn an implementation agent or invoke a code-writing tool against a xBRIEF that has not passed `task xbrief:preflight` (which wraps `scripts/preflight_implementation.py`) -- always run the Step 0 Implementation Preflight (#810) first; satisfy via `task xbrief:activate <path>`
 - ⊗ Proceed without `COST-ESTIMATE.md` and a recorded build / rescope / no-build / skip(+reason) decision -- always run the Cost Phase Gate (#739) first
 - ⊗ Proceed with implementation when the build or test toolchain is unavailable -- always run the Toolchain Gate (Step 2) first
 - ⊗ Proceed to next task or phase without tests passing -- testing is a hard gate, not a cleanup step
 - ⊗ Skip the Change Lifecycle Gate because the user said "proceed" -- broad approval does not satisfy the confirmation gate
-- ⊗ Commit or push directly to the default branch -- always create a feature branch first. Exception: user explicitly instructs a direct commit, or `PROJECT-DEFINITION.vbrief.json` narratives contain `Allow direct commits to master: true`
+- ⊗ Commit or push directly to the default branch -- always create a feature branch first. Exception: user explicitly instructs a direct commit, or `PROJECT-DEFINITION.xbrief.json` narratives contain `Allow direct commits to master: true`
 - ⊗ Add a prohibition (`!` or `⊗`) without scanning the same file for conflicting softer-strength rules (`~`, `≉`) that reference the same term

package/skills/deft-directive-cost/SKILL.md

@@ -25,7 +25,7 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 ## When to Use
 
 - After `skills/deft-directive-setup/SKILL.md` Phase 3 has produced an
-  approved `vbrief/specification.vbrief.json` (status `approved`)
+  approved `xbrief/specification.xbrief.json` (status `approved`)
 - Before `skills/deft-directive-build/SKILL.md` kicks off
 - When the user says "cost", "budget", "pre-build cost", "how much will
   this cost", or asks to estimate cost before building
@@ -60,11 +60,11 @@ two skills agree on the user's preferences file.
 
 ## Inputs
 
-- ! `vbrief/specification.vbrief.json` MUST exist with `plan.status =
+- ! `xbrief/specification.xbrief.json` MUST exist with `plan.status =
   "approved"`. If the spec is not yet approved, stop and redirect to
   `skills/deft-directive-setup/SKILL.md` Phase 3 / the spec approval
   gate.
-- ~ `vbrief/PROJECT-DEFINITION.vbrief.json` (for tech-stack and
+- ~ `xbrief/PROJECT-DEFINITION.xbrief.json` (for tech-stack and
   architecture narratives). Optional but improves the estimate.
 - ~ `templates/COST-ESTIMATE.md` (canonical artifact body).
 - ~ `references/cost-models.md` (methodology).
@@ -139,7 +139,7 @@ This is your project's cost estimate. Pick one.
   `skills/deft-directive-refinement/SKILL.md` to pull spec scope back,
   or the interview), then re-run this skill from Phase 1.
 - ! On `No-build`, write the decision to `COST-ESTIMATE.md`, mark the
-  spec scope vBRIEF accordingly, exit, and do NOT chain into the build
+  spec scope xBRIEF accordingly, exit, and do NOT chain into the build
   skill.
 - ! On `Skip`, write the decision and skip reason to `COST-ESTIMATE.md`
   and proceed to the build kickoff.
@@ -156,8 +156,8 @@ This is your project's cost estimate. Pick one.
 
 - ! `COST-ESTIMATE.md` (in the project root). Created by Phase 2 and
   finalised in Phase 4 with the recorded decision.
-- ~ Reference the artifact from `vbrief/PROJECT-DEFINITION.vbrief.json`
-  via a `references` entry of type `x-vbrief/spec-section` so future
+- ~ Reference the artifact from `xbrief/PROJECT-DEFINITION.xbrief.json`
+  via a `references` entry of type `x-xbrief/spec-section` so future
   agents discover the cost decision when re-reading the project
   definition.
 

package/skills/deft-directive-debug/SKILL.md

@@ -58,8 +58,8 @@ NO CONCLUSIONS WITHOUT EVIDENCE THAT CLOSES
 The investigation is a sustained posture across turns, not a one-shot answer.
 
 - ! On entry, create an investigation directory `.tmp/investigations/<id>/`
-  (gitignored, ephemeral) and write the ledger `investigation.vbrief.json` from
-  `docs/reference/forensic-research/templates/investigation.vbrief.json`. Stamp
+  (gitignored, ephemeral) and write the ledger `investigation.xbrief.json` from
+  `docs/reference/forensic-research/templates/investigation.xbrief.json`. Stamp
   `plan.status = "running"`.
 - ! While MODE is active, every turn appends evidence to the ledger before any
   narrative. The ledger is the source of truth; chat is a view of it.
@@ -71,7 +71,7 @@ The investigation is a sustained posture across turns, not a one-shot answer.
 
 ## The Claim Ledger
 
-The ledger is a thin vBRIEF 0.6 profile (`forensic-research-v1`):
+The ledger is a thin xBRIEF 0.6 profile (`forensic-research-v1`):
 
 - ! Top-level `plan.items[]` are **branches** (competing theories). Each branch's
   child `items[]` are **claims** (testable assertions).
@@ -124,7 +124,7 @@ When the close gate passes, write the Outcome from
 
 ! When the Outcome is delivered and the ledger has passed the close gate, confirm
 exit unambiguously: "deft-directive-debug complete -- exiting skill." Then state
-the next step (e.g. open a fix vBRIEF for the proven cause, or chain into
+the next step (e.g. open a fix xBRIEF for the proven cause, or chain into
 `skills/deft-directive-build/SKILL.md` to implement the fix).
 
 ⊗ Exit silently without confirming completion.

package/skills/deft-directive-decompose/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: deft-directive-decompose
 description: >-
-  Convert approved specification/phase/epic scope vBRIEFs into swarm-ready
-  story vBRIEFs before concurrent agent allocation.
+  Convert approved specification/phase/epic scope xBRIEFs into swarm-ready
+  story xBRIEFs before concurrent agent allocation.
 ---
 <!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
 <!-- Purpose: rendered skill -->
@@ -12,7 +12,7 @@ description: >-
 
 # Deft Directive Decompose
 
-Use this skill when a specification, Phase 4 implementation scope, or epic vBRIEF is too broad for direct concurrent swarm work and must be decomposed into story-level vBRIEFs.
+Use this skill when a specification, Phase 4 implementation scope, or epic xBRIEF is too broad for direct concurrent swarm work and must be decomposed into story-level xBRIEFs.
 
 Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
@@ -20,11 +20,11 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 ## Purpose
 
-Convert approved specification/phase/epic scope vBRIEFs into swarm-ready child story vBRIEFs. Story vBRIEFs are the only valid input for concurrent swarm worker allocation.
+Convert approved specification/phase/epic scope xBRIEFs into swarm-ready child story xBRIEFs. Story xBRIEFs are the only valid input for concurrent swarm worker allocation.
 
 ## Phase 0: Inspect
 
-- ! Read `vbrief/specification.vbrief.json` and relevant scope vBRIEFs from `vbrief/proposed/`, `vbrief/pending/`, and `vbrief/active/`.
+- ! Read `xbrief/specification.xbrief.json` and relevant scope xBRIEFs from `xbrief/proposed/`, `xbrief/pending/`, and `xbrief/active/`.
 - ! Identify broad scopes with `plan.metadata.kind = "phase"` or `"epic"` or scopes with broad `plan.narratives.Acceptance` and empty `plan.items`.
 - ! Preserve parent acceptance as context; do not treat it as executable story acceptance.
 - ! Treat parent `plan.items` as input signals only; they are not automatically child stories.
@@ -34,10 +34,10 @@ Convert approved specification/phase/epic scope vBRIEFs into swarm-ready child s
 
 ## Phase 1: Draft
 
-- ! Draft a decomposition JSON proposal with child stories only; do not write child vBRIEFs yet.
-- ! Treat the draft JSON as a temporary proposal artifact, not a vBRIEF.
-- ! Write draft proposals under `vbrief/.eval/decompositions/`, using a parent-derived slug such as `vbrief/.eval/decompositions/ip001-auth.json`.
-- ! Derive `<parent-slug>` from the parent vBRIEF filename by removing `.vbrief.json` and any leading `YYYY-MM-DD-` date prefix; for example, `vbrief/pending/2026-05-12-ip001-auth.vbrief.json` uses `ip001-auth`, while `vbrief/pending/feature-xyz.vbrief.json` uses `feature-xyz`.
+- ! Draft a decomposition JSON proposal with child stories only; do not write child xBRIEFs yet.
+- ! Treat the draft JSON as a temporary proposal artifact, not a xBRIEF.
+- ! Write draft proposals under `xbrief/.eval/decompositions/`, using a parent-derived slug such as `xbrief/.eval/decompositions/ip001-auth.json`.
+- ! Derive `<parent-slug>` from the parent xBRIEF filename by removing `.xbrief.json` and any leading `YYYY-MM-DD-` date prefix; for example, `xbrief/pending/2026-05-12-ip001-auth.xbrief.json` uses `ip001-auth`, while `xbrief/pending/feature-xyz.xbrief.json` uses `feature-xyz`.
 - ⊗ Agents MUST NOT leave decomposition draft JSON files at the workspace root.
 - ! Each story MUST include `id`, `title`, `Description`, `ImplementationPlan`, `UserStory`, executable `items` or `acceptance`, `traces` or explicit trace justification, `swarm.file_scope`, `swarm.verify_commands`, `swarm.expected_outputs`, `swarm.depends_on`, `swarm.conflict_group`, `swarm.size`, `swarm.file_scope_confidence`, and `swarm.model_tier`.
 - ! `Description` MUST provide at least two concrete sentences explaining the user/product behavior, boundaries, and why this story is independently buildable.
@@ -46,7 +46,7 @@ Convert approved specification/phase/epic scope vBRIEFs into swarm-ready child s
 - ! Each ready story MUST have 2-5 concrete acceptance criteria unless `swarm.acceptance_criteria_justification` explains the exception.
 - ! Acceptance criteria MUST be observable behavior, preferably Given/When/Then or equivalent testable product behavior.
 - ⊗ Mark a story ready when acceptance says only "to refine from parent scope", duplicates the title/description, is placeholder text, or is vague docs-only acceptance.
-- ⊗ Mark a story ready with broad write scope such as `backend/**`, `frontend/**`, `docs/**`, `vbrief/**`, or any other directory glob.
+- ⊗ Mark a story ready with broad write scope such as `backend/**`, `frontend/**`, `docs/**`, `xbrief/**`, or any other directory glob.
 - ⊗ Mark a story ready when verification is only generic validation such as `task check`.
 - ⊗ Mark a story ready with `parallel_safe: false` or `file_scope_confidence: low`; use `readiness: sequential` or `readiness: needs_refinement` instead.
 - ! Model dependencies as story IDs and ensure they form a DAG.
@@ -67,23 +67,23 @@ Convert approved specification/phase/epic scope vBRIEFs into swarm-ready child s
 - ! Validate the approved draft first:
 
 ```bash
-task scope:decompose -- vbrief/pending/2026-05-12-ip001-auth.vbrief.json --draft vbrief/.eval/decompositions/ip001-auth.json --check
+task scope:decompose -- xbrief/pending/2026-05-12-ip001-auth.xbrief.json --draft xbrief/.eval/decompositions/ip001-auth.json --check
 ```
 
 - ! Apply the approved draft:
 
 ```bash
-task scope:decompose -- vbrief/pending/2026-05-12-ip001-auth.vbrief.json --draft vbrief/.eval/decompositions/ip001-auth.json
+task scope:decompose -- xbrief/pending/2026-05-12-ip001-auth.xbrief.json --draft xbrief/.eval/decompositions/ip001-auth.json
 ```
 
-The command creates generated child story vBRIEFs as lifecycle artifacts, defaulting to `vbrief/pending/`. It preserves origin/provenance references, sets each child `planRef` to the parent, updates parent references to include the children, rejects dependency cycles, and rejects ready stories missing executable acceptance, user-story shape, concrete acceptance, narrow file scope, focused verify commands, or traces.
+The command creates generated child story xBRIEFs as lifecycle artifacts, defaulting to `xbrief/pending/`. It preserves origin/provenance references, sets each child `planRef` to the parent, updates parent references to include the children, rejects dependency cycles, and rejects ready stories missing executable acceptance, user-story shape, concrete acceptance, narrow file scope, focused verify commands, or traces.
 
 ## Phase 4: Pending Readiness
 
 - ! Run readiness against the generated pending child story paths after decomposition:
 
 ```bash
-task swarm:readiness -- vbrief/pending/<child-story-1>.vbrief.json vbrief/pending/<child-story-2>.vbrief.json
+task swarm:readiness -- xbrief/pending/<child-story-1>.xbrief.json xbrief/pending/<child-story-2>.xbrief.json
 ```
 
 - ! Treat this as a dry readiness review before activation; do not allocate workers from pending paths.
@@ -93,4 +93,4 @@ task swarm:readiness -- vbrief/pending/<child-story-1>.vbrief.json vbrief/pendin
 
 ## Exit
 
-deft-directive-decompose complete -- exiting skill. Next, activate the approved child story vBRIEFs through the existing lifecycle flow, then run `skills/deft-directive-swarm/SKILL.md` for concurrent allocation.
+deft-directive-decompose complete -- exiting skill. Next, activate the approved child story xBRIEFs through the existing lifecycle flow, then run `skills/deft-directive-swarm/SKILL.md` for concurrent allocation.

package/skills/deft-directive-gh-arch/SKILL.md

@@ -94,7 +94,7 @@ Spawn 3+ sub-agents with **radically different** design constraints. Each produc
 - Agent 3: "Optimize for the most common caller — make the default case trivial"
 - Agent 4 (if applicable): "Design around ports & adapters for cross-boundary dependencies"
 
-- ! The sub-agent dispatch envelope MUST include `templates/agent-prompt-preamble.md` verbatim (or by reference) per AGENTS.md `## Multi-agent orchestration discipline (#954)`. The preamble carries the AGENTS.md read mandate, the #810 vBRIEF gate walkthrough, the PowerShell 5.1 non-ASCII rule, REST-over-GraphQL rules, and the mandatory DONE message protocol -- without it, the recurrence patterns documented in #954 re-fire on every fresh dispatch.
+- ! The sub-agent dispatch envelope MUST include `templates/agent-prompt-preamble.md` verbatim (or by reference) per AGENTS.md `## Multi-agent orchestration discipline (#954)`. The preamble carries the AGENTS.md read mandate, the #810 xBRIEF gate walkthrough, the PowerShell 5.1 non-ASCII rule, REST-over-GraphQL rules, and the mandatory DONE message protocol -- without it, the recurrence patterns documented in #954 re-fire on every fresh dispatch.
 
 Present designs sequentially, then compare in prose. Give your own recommendation — which is strongest and why. If elements combine well, propose a hybrid. Be opinionated.
 
@@ -107,9 +107,9 @@ Present designs sequentially, then compare in prose. Give your own recommendatio
 - ! Create a refactor RFC immediately using `gh issue create` with the template below
 - ~ Issue-label hygiene: before filing, inspect the target repo's existing labels with `gh label list` or the labels API; choose one or more suitable existing labels when practical, or explicitly note that no label was applied. This is a recommendation, not a gate -- do not block issue creation solely because no label fits, and do not invent ad hoc labels outside the repo's existing label set.
 - ! After creating, print the issue URL
-- ! When the RFC is filed as an umbrella with companion child issues (e.g. an interface-extraction RFC plus one child per migrating caller), record the cohort in `vbrief/.eval/slices.jsonl` via `scripts/slice_record.py::write_slice(...)` with `actor="skill:gh-arch"` -- this is the durable production-side record consumed by `task triage:audit --orphans` (#1132 / D13). Same usage pattern as `skills/deft-directive-gh-slice/SKILL.md` Step 6; idempotent on retry. Skip when the RFC is a single-issue "file and forget" with no child cohort.
+- ! When the RFC is filed as an umbrella with companion child issues (e.g. an interface-extraction RFC plus one child per migrating caller), record the cohort in `xbrief/.eval/slices.jsonl` via `scripts/slice_record.py::write_slice(...)` with `actor="skill:gh-arch"` -- this is the durable production-side record consumed by `task triage:audit --orphans` (#1132 / D13). Same usage pattern as `skills/deft-directive-gh-slice/SKILL.md` Step 6; idempotent on retry. Skip when the RFC is a single-issue "file and forget" with no child cohort.
 - ! Confirm skill exit: "deft-directive-gh-arch complete — RFC filed at <url>."
-- ~ Suggest next steps: run `deft-directive-refinement` to slot the RFC into the vBRIEF lifecycle, or assign the issue for swarm pickup.
+- ~ Suggest next steps: run `deft-directive-refinement` to slot the RFC into the xBRIEF lifecycle, or assign the issue for swarm pickup.
 
 **Issue template:**
 

package/skills/deft-directive-gh-slice/SKILL.md

@@ -138,9 +138,9 @@ After all issues are created, print a summary table: issue number, title, type,
 
 - ! When the source plan was sliced into an umbrella + child issues, file the umbrella first, then file its `## Current shape (as of pass-N)` comment per `## Umbrella current-shape convention` in `AGENTS.md` (#1152) so subsequent design passes have a stable edit-in-place surface to update.
 
-### Step 6: Record the cohort in `vbrief/.eval/slices.jsonl` (#1132 / D13)
+### Step 6: Record the cohort in `xbrief/.eval/slices.jsonl` (#1132 / D13)
 
-At slice-completion (after the umbrella + every child issue is filed) call the framework helper to persist a durable cohort record. The record is sibling to the gitignored `candidates.jsonl` but is **tracked in git** (per `vbrief/.eval/README.md`) so a fresh contributor on pass-N can see prior cohort outputs without rebuilding state from closed issues.
+At slice-completion (after the umbrella + every child issue is filed) call the framework helper to persist a durable cohort record. The record is sibling to the gitignored `candidates.jsonl` but is **tracked in git** (per `xbrief/.eval/README.md`) so a fresh contributor on pass-N can see prior cohort outputs without rebuilding state from closed issues.
 
 ```python path=null start=null
 from pathlib import Path

package/skills/deft-directive-interview/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Deterministic structured Q&A interview loop. Use when any skill needs to
   gather structured input from the user through a series of focused questions
   with numbered options, stated defaults, and a confirmation gate before
-  artifact generation. Interview output targets vBRIEF narratives — not
+  artifact generation. Interview output targets xBRIEF narratives — not
   PRD.md.
 ---
 <!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->
@@ -196,7 +196,7 @@ The answers map format:
 
 ## Output Targets
 
-Interview output writes to `specification.vbrief.json` `plan.narratives` — the vBRIEF draft is the sole authoritative output. PRD.md is never generated. All vBRIEFs target the canonical v0.6 schema (`vbrief/schemas/vbrief-core.schema.json`, strict `const: "0.6"`); see [`../../conventions/references.md`](../../conventions/references.md).
+Interview output writes to `specification.xbrief.json` `plan.narratives` — the xBRIEF draft is the sole authoritative output. PRD.md is never generated. All xBRIEFs target the canonical v0.6 schema (`xbrief/schemas/xbrief-core.schema.json`, strict `const: "0.6"`); see [`../../conventions/references.md`](../../conventions/references.md).
 
 When the interview captures origin provenance (e.g. the user links to a GitHub issue or Jira ticket), include a `references` entry in the canonical form documented in [`../../conventions/references.md`](../../conventions/references.md):
 
@@ -204,7 +204,7 @@ When the interview captures origin provenance (e.g. the user links to a GitHub i
 "references": [
   {
     "uri": "https://github.com/{owner}/{repo}/issues/{N}",
-    "type": "x-vbrief/github-issue",
+    "type": "x-xbrief/github-issue",
     "title": "Issue #{N}: {issue title}"
   }
 ]
@@ -212,7 +212,7 @@ When the interview captures origin provenance (e.g. the user links to a GitHub i
 
 ### Full Path Output
 
-! On the Full path, the interview populates `specification.vbrief.json` `plan.narratives` with `vBRIEFInfo.version: "0.6"`, `status: draft`, and rich keys:
+! On the Full path, the interview populates `specification.xbrief.json` `plan.narratives` with `xBRIEFInfo.version: "0.6"`, `status: draft`, and rich keys:
 
 - `ProblemStatement`: What problem this project solves
 - `Goals`: High-level project goals
@@ -224,23 +224,23 @@ When the interview captures origin provenance (e.g. the user links to a GitHub i
 
 ! All narrative values MUST be plain strings — never objects or arrays.
 
-! The human approval gate reviews the vBRIEF draft narratives directly — reviewing the narratives IS the approval step. On approval, update `status` to `approved` and generate downstream scope vBRIEFs.
+! The human approval gate reviews the xBRIEF draft narratives directly — reviewing the narratives IS the approval step. On approval, update `status` to `approved` and generate downstream scope xBRIEFs.
 
 ### Light Path Output
 
-! On the Light path, the interview populates `specification.vbrief.json` with `status: draft` and slim narratives:
+! On the Light path, the interview populates `specification.xbrief.json` with `status: draft` and slim narratives:
 
 - `Overview`: Brief project summary
 - `Architecture`: System design description
 
-! On approval, update `status` to `approved`. Scope vBRIEFs are then created in `vbrief/proposed/` for each identified work item.
+! On approval, update `status` to `approved`. Scope xBRIEFs are then created in `xbrief/proposed/` for each identified work item.
 
 ### PRD.md (deprecated — never authoritative)
 
-PRD.md is not generated as part of the interview workflow on either path. The `specification.vbrief.json` vBRIEF draft is the sole source of truth.
+PRD.md is not generated as part of the interview workflow on either path. The `specification.xbrief.json` xBRIEF draft is the sole source of truth.
 
 - ? If stakeholders require a traditional PRD document, run `task prd:render` to export a read-only `PRD.md` from `plan.narratives`
-- ! PRD.md is never authoritative — `specification.vbrief.json` is the source of truth
+- ! PRD.md is never authoritative — `specification.xbrief.json` is the source of truth
 - ⊗ Generate an authoritative PRD.md during the interview process
 - ⊗ Treat PRD.md as a source of truth — it is a generated export artifact
 
@@ -375,13 +375,13 @@ Tatooine), branded characters (Mickey Mouse, Spider-Man), sports leagues
 2. ! Emit the plain-English risk summary from
    `scripts/ip_risk.py:plain_risk_summary(hits, intent)` into the
    interview output AND into an `IPRisk` narrative on the
-   `specification.vbrief.json` draft. The summary opens with `not legal
+   `specification.xbrief.json` draft. The summary opens with `not legal
    advice`, names the detected categories, and (for commercial intent)
    states explicitly that lawyer consultation is **not optional output**
    from this interview.
 3. ! Inject the three protection scope items from
    `scripts/ip_risk.py:ip_risk_scope_items(intent)` into the spec
-   vBRIEF's `plan.items` array (disclaimer stub `IP-1`, API-only-asset
+   xBRIEF's `plan.items` array (disclaimer stub `IP-1`, API-only-asset
    policy `IP-2`, hosting policy `IP-3`). The items flow naturally into
    the rendered SPECIFICATION.md via the existing
    `scripts/spec_render.py` pipeline -- no spec_render.py modification
@@ -513,7 +513,7 @@ for it.
 - ⊗ Skip the depth gate and generate artifacts with known ambiguity remaining
 - ⊗ Exit the interview without producing a structured answers map for the calling skill
 - ⊗ Combine interview questions with artifact generation in the same message
-- ⊗ Generate an authoritative PRD.md — interview output targets `specification.vbrief.json` narratives only
+- ⊗ Generate an authoritative PRD.md — interview output targets `specification.xbrief.json` narratives only
 - ⊗ Treat PRD.md as a source of truth — it is a read-only export via `task prd:render`
 - ⊗ Auto-advance to the next question on number press without echoing the selection and waiting for confirmation
 - ⊗ Refuse backward navigation during the interview -- the user must be able to revisit previous answers

package/skills/deft-directive-pre-pr/SKILL.md

@@ -51,8 +51,8 @@ Each iteration proceeds through all phases in order. Do NOT skip phases or reord
 ! Re-read each changed file end-to-end (`git diff master --name-only` to get the list).
 
 - ! Read every changed file in full -- do not skim or skip sections
-- ! Compare each file against its scope vBRIEF acceptance criteria in `vbrief/active/`
-- ~ If changed files include `vbrief/PROJECT-DEFINITION.vbrief.json`, a configured `codebase-map` provider artifact, or `.planning/codebase/MAP.md`, read the MAP and canonical metadata together. The MAP is orientation; `plan.architecture.codeStructure` and provider artifacts remain authoritative.
+- ! Compare each file against its scope xBRIEF acceptance criteria in `xbrief/active/`
+- ~ If changed files include `xbrief/PROJECT-DEFINITION.xbrief.json`, a configured `codebase-map` provider artifact, or `.planning/codebase/MAP.md`, read the MAP and canonical metadata together. The MAP is orientation; `plan.architecture.codeStructure` and provider artifacts remain authoritative.
 - ! When adding a `!` or `⊗` rule that prohibits a specific command, pattern, or behavior, search the same file for any `~`, `≉`, or prose that recommends or permits the same command/pattern -- resolve all contradictions in the same commit before pushing
 - ! When strengthening a rule (e.g. upgrading `~` to `!`), grep for the term in the full file and verify no weaker-strength duplicate remains
 - ~ Note any inconsistencies, missing RFC2119 markers, stale cross-references, or incomplete sections
@@ -80,7 +80,7 @@ Each iteration proceeds through all phases in order. Do NOT skip phases or reord
 
 ### Phase 3b -- Auto-Render Exports
 
-! If `vbrief/specification.vbrief.json` exists, refresh rendered exports before the diff check:
+! If `xbrief/specification.xbrief.json` exists, refresh rendered exports before the diff check:
 
 - ! Run `task prd:render` if `PRD.md` already exists in the project root
 - ! Run `task spec:render` if `SPECIFICATION.md` already exists and does not contain `<!-- deft:deprecated-redirect -->`

package/skills/deft-directive-probe/SKILL.md

@@ -36,10 +36,10 @@ Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
 
 While probe completion criteria (below) are NOT met:
 
-- ⊗ Write or update any vBRIEF file (`vbrief/proposed/`, `vbrief/active/`, plan items, narratives)
-- ⊗ Update `vbrief/plan.vbrief.json` or register probe artifacts
+- ⊗ Write or update any xBRIEF file (`xbrief/proposed/`, `xbrief/active/`, plan items, narratives)
+- ⊗ Update `xbrief/plan.xbrief.json` or register probe artifacts
 - ⊗ Post GitHub completion comments, close issues, or open PRs on behalf of the probe session
-- ⊗ Produce probe output markdown files instead of the canonical vBRIEF contract
+- ⊗ Produce probe output markdown files instead of the canonical xBRIEF contract
 
 ! Read existing context and interrogate only — artifacts land in the Output phase after completion.
 
@@ -93,21 +93,21 @@ Walk the decision tree depth-first. For each unresolved branch:
 
 ! Before writing output artifacts, follow the [Preparatory Guard](../../strategies/artifact-guards.md#preparatory-guard-light).
 
-`{scope}` is the project name from `PROJECT-DEFINITION.vbrief.json`, or the feature/component name if probing a sub-scope. Use the same value consistently throughout the session.
+`{scope}` is the project name from `PROJECT-DEFINITION.xbrief.json`, or the feature/component name if probing a sub-scope. Use the same value consistently throughout the session.
 
-- ! Produce a `vbrief/proposed/{scope}-probe.vbrief.json` scope vBRIEF with three mandatory narratives:
+- ! Produce a `xbrief/proposed/{scope}-probe.xbrief.json` scope xBRIEF with three mandatory narratives:
   - `LockedDecisions` — what was resolved and why
   - `SurfacedRisks` — concerns raised, even if not fully resolved
   - `DeferredDecisions` — explicitly acknowledged items with justification
 - ! Each entry includes: **question asked**, **answer given**, **status** (locked / deferred / risk-accepted)
-- ! Persist significant decisions as vBRIEF narratives on the relevant plan items
-- ⊗ Write probe output to a hand-authored markdown file — use vBRIEF narratives for machine-consumable downstream work
+- ! Persist significant decisions as xBRIEF narratives on the relevant plan items
+- ⊗ Write probe output to a hand-authored markdown file — use xBRIEF narratives for machine-consumable downstream work
 
 ## Chaining Gate
 
-After the probe is complete and `vbrief/proposed/{scope}-probe.vbrief.json` is written:
+After the probe is complete and `xbrief/proposed/{scope}-probe.xbrief.json` is written:
 
-- ! Register artifacts in `./vbrief/plan.vbrief.json` (`completedStrategies`, `artifacts`)
+- ! Register artifacts in `./xbrief/plan.xbrief.json` (`completedStrategies`, `artifacts`)
 - ! Return to [interview.md Chaining Gate](../../strategies/interview.md#chaining-gate) when invoked from the interview flow
 - ! Locked decisions, surfaced risks, and deferred decisions MUST flow into subsequent strategies and spec generation
 - ⊗ End the session after probe without returning to the chaining gate or the invoking strategy's next-step menu