@geraldmaron/construct 1.0.4 → 1.0.6

package/commands/design/access.md

@@ -1,10 +1,10 @@
 <!--
-commands/design/access.md — Accessibility audit — WCAG 2.1 AA, keyboard, screen readers, contrast, motion
+commands/design/access.md (Accessibility audit) WCAG 2.1 AA, keyboard, screen readers, contrast, motion
 
-Accessibility audit — WCAG 2.1 AA, keyboard, screen readers, contrast, motion
+Accessibility audit: WCAG 2.1 AA, keyboard, screen readers, contrast, motion
 -->
 ---
-description: Accessibility audit — WCAG 2.1 AA, keyboard, screen readers, contrast, motion
+description: Accessibility audit: WCAG 2.1 AA, keyboard, screen readers, contrast, motion
 ---
 
 You are Construct. Audit: $ARGUMENTS

package/commands/design/flow.md

@@ -1,10 +1,10 @@
 <!--
-commands/design/flow.md — Map the user flow — entry to success, friction points, jobs-to-be-done
+commands/design/flow.md (Map the user flow) entry to success, friction points, jobs-to-be-done
 
-Map the user flow — entry to success, friction points, jobs-to-be-done
+Map the user flow: entry to success, friction points, jobs-to-be-done
 -->
 ---
-description: Map the user flow — entry to success, friction points, jobs-to-be-done
+description: Map the user flow: entry to success, friction points, jobs-to-be-done
 ---
 
 You are Construct. Map the user flow for: $ARGUMENTS

package/commands/design/ui.md

@@ -1,16 +1,16 @@
 <!--
-commands/design/ui.md — Design or review UI — visual hierarchy, states, interaction model, accessibility baseline
+commands/design/ui.md (Design or review UI) visual hierarchy, states, interaction model, accessibility baseline
 
-Design or review UI — visual hierarchy, states, interaction model, accessibility baseline
+Design or review UI: visual hierarchy, states, interaction model, accessibility baseline
 -->
 ---
-description: Design or review UI — visual hierarchy, states, interaction model, accessibility baseline
+description: Design or review UI: visual hierarchy, states, interaction model, accessibility baseline
 ---
 
 You are Construct. Design or review the UI for: $ARGUMENTS
 
 Every meaningful UI surface needs:
-- Clear hierarchy through scale contrast — not uniform emphasis
+- Clear hierarchy through scale contrast: not uniform emphasis
 - Every component state defined: empty, loading, error, success, edge cases
 - Hover, focus, and active states that feel designed
 - WCAG AA baseline: keyboard-navigable, 4.5:1 contrast, visible focus, ARIA labels

package/commands/measure/experiment.md

@@ -1,10 +1,10 @@
 <!--
-commands/measure/experiment.md — Design an experiment — hypothesis, test, evidence threshold, go/no-go decision
+commands/measure/experiment.md (Design an experiment) hypothesis, test, evidence threshold, go/no-go decision
 
-Design an experiment — hypothesis, test, evidence threshold, go/no-go decision
+Design an experiment: hypothesis, test, evidence threshold, go/no-go decision
 -->
 ---
-description: Design an experiment — hypothesis, test, evidence threshold, go/no-go decision
+description: Design an experiment: hypothesis, test, evidence threshold, go/no-go decision
 ---
 
 You are Construct. Design an experiment for: $ARGUMENTS
@@ -12,7 +12,7 @@ You are Construct. Design an experiment for: $ARGUMENTS
 Produce:
 - HYPOTHESIS: "We believe [X] will result in [Y] because [Z]."
 - KEY UNKNOWNS: a small set of questions (typically 3-7) whose answers most change the decision
-- EXPERIMENT: cheapest useful test per unknown — inputs, method, output artifact
+- EXPERIMENT: cheapest useful test per unknown: inputs, method, output artifact
 - EVIDENCE THRESHOLD: what result confirms or disconfirms? Be specific.
-- RECOMMENDATION: explore | prototype | build | kill — with rationale
+- RECOMMENDATION: explore | prototype | build | kill: with rationale
 - WHAT NOT TO LOCK IN YET: decisions that must not harden before evidence arrives

package/commands/measure/metrics.md

@@ -1,10 +1,10 @@
 <!--
-commands/measure/metrics.md — Define metrics — what to measure, baselines, success thresholds, instrumentation needed
+commands/measure/metrics.md (Define metrics) what to measure, baselines, success thresholds, instrumentation needed
 
-Define metrics — what to measure, baselines, success thresholds, instrumentation needed
+Define metrics: what to measure, baselines, success thresholds, instrumentation needed
 -->
 ---
-description: Define metrics — what to measure, baselines, success thresholds, instrumentation needed
+description: Define metrics: what to measure, baselines, success thresholds, instrumentation needed
 ---
 
 You are Construct. Define metrics for: $ARGUMENTS

package/commands/measure/results.md

@@ -1,17 +1,17 @@
 <!--
-commands/measure/results.md — Analyze results — interpret data, separate signal from noise, produce a recommendation
+commands/measure/results.md (Analyze results) interpret data, separate signal from noise, produce a recommendation
 
-Analyze results — interpret data, separate signal from noise, produce a recommendation
+Analyze results: interpret data, separate signal from noise, produce a recommendation
 -->
 ---
-description: Analyze results — interpret data, separate signal from noise, produce a recommendation
+description: Analyze results: interpret data, separate signal from noise, produce a recommendation
 ---
 
 You are Construct. Analyze: $ARGUMENTS
 
 For each finding:
 - FINDING: what the data shows (with specific numbers)
-- CONFIDENCE: high / medium / low — based on sample size and data quality
+- CONFIDENCE: high / medium / low: based on sample size and data quality
 - INFERENCE: what this means for the decision (clearly labeled as interpretation)
 - GAPS: what additional data would increase confidence
 

package/commands/plan/api.md

@@ -1,10 +1,10 @@
 <!--
-commands/plan/api.md — Design an API — contracts, endpoints, error model, data schema
+commands/plan/api.md (Design an API) contracts, endpoints, error model, data schema
 
-Design an API — contracts, endpoints, error model, data schema
+Design an API: contracts, endpoints, error model, data schema
 -->
 ---
-description: Design an API — contracts, endpoints, error model, data schema
+description: Design an API: contracts, endpoints, error model, data schema
 ---
 
 You are Construct. Design the API for: $ARGUMENTS

package/commands/plan/challenge.md

@@ -1,10 +1,10 @@
 <!--
-commands/plan/challenge.md — Challenge a plan — stress-test assumptions, surface failure modes and risks
+commands/plan/challenge.md (Challenge a plan) stress-test assumptions, surface failure modes and risks
 
-Challenge a plan — stress-test assumptions, surface failure modes and risks
+Challenge a plan: stress-test assumptions, surface failure modes and risks
 -->
 ---
-description: Challenge a plan — stress-test assumptions, surface failure modes and risks
+description: Challenge a plan: stress-test assumptions, surface failure modes and risks
 ---
 
 You are Construct. Challenge the following: $ARGUMENTS

package/commands/plan/decide.md

@@ -1,10 +1,10 @@
 <!--
-commands/plan/decide.md — Record a decision — context, options considered, consequences, what it locks in
+commands/plan/decide.md (Record a decision) context, options considered, consequences, what it locks in
 
-Record a decision — context, options considered, consequences, what it locks in
+Record a decision: context, options considered, consequences, what it locks in
 -->
 ---
-description: Record a decision — context, options considered, consequences, what it locks in
+description: Record a decision: context, options considered, consequences, what it locks in
 ---
 
 You are Construct. Document the decision about: $ARGUMENTS

package/commands/plan/feature.md

@@ -1,30 +1,30 @@
 <!--
-commands/plan/feature.md — Plan a feature and turn it into a tracker-linked implementation plan
+commands/plan/feature.md: Plan a feature and turn it into a tracker-linked implementation plan
 
 Produces a structured spec using the canonical Construct plan format, saves it
 to .cx/plans/ as a durable planning artifact linked to the active tracker slice.
 -->
 ---
-description: Plan a feature — produce a structured spec and link it to the active tracker-backed plan
+description: Plan a feature: produce a structured spec and link it to the active tracker-backed plan
 ---
 
 You are Construct. Plan the following: $ARGUMENTS
 
 Use the code-backed orchestration policy for routing/escalation decisions; this prompt only defines the plan artifact shape.
 
-## Step 1 — Scope
+## Step 1: Scope
 Produce:
 - **GOAL**: restate the objective in one sentence
 - **APPROACH**: chosen strategy and why (alternatives considered)
 - **RISKS**: top 3 risks and mitigations
 
-## Step 2 — Task breakdown
+## Step 2: Task breakdown
 
 Produce tasks in the canonical Construct plan format:
 
 ## Tasks
 
-### T1 — {Task title}
+### T1: {Task title}
 - **Owner**: {cx-specialist}
 - **Phase**: implement
 - **Files**: {comma-separated list of files this task will touch}
@@ -38,12 +38,12 @@ Produce tasks in the canonical Construct plan format:
 (repeat for each task)
 
 Rules:
-- Each task is atomic — one agent, one deliverable
+- Each task is atomic: one agent, one deliverable
 - Files lists must be disjoint across parallel tasks
 - Acceptance criteria are binary: pass or fail, no "it should be good"
 - Do not change must list every file outside scope that could be accidentally touched
 
-## Step 3 — Save and import
+## Step 3: Save and import
 1. Save this full plan to `.cx/plans/{slug}-plan.md`
 2. If the project uses Beads or another external tracker, include the issue id in the plan and keep the current `plan.md` aligned with it
 3. Declare file ownership explicitly so parallel work still follows the single-writer rule

package/commands/plan/requirements.md

@@ -1,10 +1,10 @@
 <!--
-commands/plan/requirements.md — Define requirements — what needs to be true for this to be done
+commands/plan/requirements.md (Define requirements) what needs to be true for this to be done
 
-Define requirements — what needs to be true for this to be done
+Define requirements: what needs to be true for this to be done
 -->
 ---
-description: Define requirements — what needs to be true for this to be done
+description: Define requirements: what needs to be true for this to be done
 ---
 
 You are Construct. Define requirements for: $ARGUMENTS

package/commands/remember/context.md

@@ -1,10 +1,10 @@
 <!--
-commands/remember/context.md — Save project context — update .cx/context.md so the next session picks up where this one left off
+commands/remember/context.md (Save project context) update .cx/context.md so the next session picks up where this one left off
 
-Save project context — update .cx/context.md so the next session picks up where this one left off
+Save project context: update .cx/context.md so the next session picks up where this one left off
 -->
 ---
-description: Save project context — update .cx/context.md so the next session picks up where this one left off
+description: Save project context: update .cx/context.md so the next session picks up where this one left off
 ---
 
 You are Construct. Save context for: $ARGUMENTS
@@ -12,10 +12,10 @@ You are Construct. Save context for: $ARGUMENTS
 Update `.cx/context.json` as canonical state and refresh `.cx/context.md` as the readable mirror:
 
 ## Active Work
-- [title] — [status: in-progress | blocked | in-review]
+- [title]: [status: in-progress | blocked | in-review]
 
 ## Recent Decisions
-- [date] [decision] — [rationale]
+- [date] [decision]: [rationale]
 
 ## Architecture Notes
 - [constraint or invariant future contributors need to know]

package/commands/remember/handoff.md

@@ -1,10 +1,10 @@
 <!--
-commands/remember/handoff.md — Write a handoff — transfer context so the next session or person can continue without loss
+commands/remember/handoff.md (Write a handoff) transfer context so the next session or person can continue without loss
 
-Write a handoff — transfer context so the next session or person can continue without loss
+Write a handoff: transfer context so the next session or person can continue without loss
 -->
 ---
-description: Write a handoff — transfer context so the next session or person can continue without loss
+description: Write a handoff: transfer context so the next session or person can continue without loss
 ---
 
 You are Construct. Write a handoff for: $ARGUMENTS

package/commands/remember/runbook.md

@@ -1,10 +1,10 @@
 <!--
-commands/remember/runbook.md — Write a runbook — step-by-step procedure for a recurring task or incident
+commands/remember/runbook.md (Write a runbook) step-by-step procedure for a recurring task or incident
 
-Write a runbook — step-by-step procedure for a recurring task or incident
+Write a runbook: step-by-step procedure for a recurring task or incident
 -->
 ---
-description: Write a runbook — step-by-step procedure for a recurring task or incident
+description: Write a runbook: step-by-step procedure for a recurring task or incident
 ---
 
 You are Construct. Write a runbook for: $ARGUMENTS

package/commands/review/code.md

@@ -1,10 +1,10 @@
 <!--
-commands/review/code.md — Code review — correctness, regressions, security, test coverage
+commands/review/code.md (Code review) correctness, regressions, security, test coverage
 
-Code review — correctness, regressions, security, test coverage
+Code review: correctness, regressions, security, test coverage
 -->
 ---
-description: Code review — correctness, regressions, security, test coverage
+description: Code review: correctness, regressions, security, test coverage
 ---
 
 You are Construct. Review: $ARGUMENTS
@@ -12,10 +12,10 @@ You are Construct. Review: $ARGUMENTS
 If no target specified, review all uncommitted changes (`git diff HEAD`).
 
 Check in order:
-1. Correctness — does it do what it's supposed to?
-2. Regression — does it break anything that was working?
-3. Security — injection, auth, secrets, data exposure
-4. Coverage — are there tests for changed or new behavior?
-5. Maintainability — can someone unfamiliar understand it?
+1. Correctness: does it do what it's supposed to?
+2. Regression: does it break anything that was working?
+3. Security: injection, auth, secrets, data exposure
+4. Coverage: are there tests for changed or new behavior?
+5. Maintainability: can someone unfamiliar understand it?
 
 Rate each finding: CRITICAL / HIGH / MEDIUM / LOW. State clearly if no CRITICAL or HIGH findings exist.

package/commands/review/quality.md

@@ -1,10 +1,10 @@
 <!--
-commands/review/quality.md — Quality audit — complexity, naming, duplication, dead code, maintainability
+commands/review/quality.md (Quality audit) complexity, naming, duplication, dead code, maintainability
 
-Quality audit — complexity, naming, duplication, dead code, maintainability
+Quality audit: complexity, naming, duplication, dead code, maintainability
 -->
 ---
-description: Quality audit — complexity, naming, duplication, dead code, maintainability
+description: Quality audit: complexity, naming, duplication, dead code, maintainability
 ---
 
 You are Construct. Audit quality for: $ARGUMENTS
@@ -16,4 +16,4 @@ Check:
 - Unused exports, unreachable branches, stale imports
 - Coupling, unclear data flow
 
-Rate findings: CRITICAL / HIGH / MEDIUM / LOW. Describe the fix — do not rewrite unprompted.
+Rate findings: CRITICAL / HIGH / MEDIUM / LOW. Describe the fix: do not rewrite unprompted.

package/commands/review/security.md

@@ -1,10 +1,10 @@
 <!--
-commands/review/security.md — Security scan — secrets, auth, injection, data exposure, dependency risk
+commands/review/security.md (Security scan) secrets, auth, injection, data exposure, dependency risk
 
-Security scan — secrets, auth, injection, data exposure, dependency risk
+Security scan: secrets, auth, injection, data exposure, dependency risk
 -->
 ---
-description: Security scan — secrets, auth, injection, data exposure, dependency risk
+description: Security scan: secrets, auth, injection, data exposure, dependency risk
 ---
 
 You are Construct. Scan: $ARGUMENTS

package/commands/ship/ready.md

@@ -1,10 +1,10 @@
 <!--
-commands/ship/ready.md — Pre-release check — is this ready to ship?
+commands/ship/ready.md (Pre-release check) is this ready to ship?
 
-Pre-release check — is this ready to ship?
+Pre-release check: is this ready to ship?
 -->
 ---
-description: Pre-release check — is this ready to ship?
+description: Pre-release check: is this ready to ship?
 ---
 
 You are Construct. Check if the following is ready: $ARGUMENTS

package/commands/ship/release.md

@@ -1,10 +1,10 @@
 <!--
-commands/ship/release.md — Release — plan rollout, changelog, rollback, and post-release verification
+commands/ship/release.md (Release) plan rollout, changelog, rollback, and post-release verification
 
-Release — plan rollout, changelog, rollback, and post-release verification
+Release: plan rollout, changelog, rollback, and post-release verification
 -->
 ---
-description: Release — plan rollout, changelog, rollback, and post-release verification
+description: Release: plan rollout, changelog, rollback, and post-release verification
 ---
 
 You are Construct. Release the following: $ARGUMENTS

package/commands/ship/status.md

@@ -1,16 +1,16 @@
 <!--
-commands/ship/status.md — Status — current project state, workflow, uncommitted changes, recent activity
+commands/ship/status.md (Status) current project state, workflow, uncommitted changes, recent activity
 
-Status — current project state, workflow, uncommitted changes, recent activity
+Status: current project state, workflow, uncommitted changes, recent activity
 -->
 ---
-description: Status — current project state, workflow, uncommitted changes, recent activity
+description: Status: current project state, workflow, uncommitted changes, recent activity
 ---
 
 You are Construct. Report status for: $ARGUMENTS
 
 Check and report:
-1. Tracker and `plan.md` state — active slices, blockers, and ownership boundaries
+1. Tracker and `plan.md` state: active slices, blockers, and ownership boundaries
 2. Uncommitted changes via `git status`
 3. Recent commits via `git log --oneline -10`
 4. Active branch and relationship to main

package/commands/understand/docs.md

@@ -1,10 +1,10 @@
 <!--
-commands/understand/docs.md — Look up documentation — current behavior from primary sources, not training memory
+commands/understand/docs.md (Look up documentation) current behavior from primary sources, not training memory
 
-Look up documentation — current behavior from primary sources, not training memory
+Look up documentation: current behavior from primary sources, not training memory
 -->
 ---
-description: Look up documentation — current behavior from primary sources, not training memory
+description: Look up documentation: current behavior from primary sources, not training memory
 ---
 
 You are Construct. Look up: $ARGUMENTS

package/commands/understand/research.md

@@ -1,10 +1,10 @@
 <!--
-commands/understand/research.md — Research a topic — verify facts from primary sources, separate evidence from inference
+commands/understand/research.md. Research a topic. Verify facts from primary sources, separate evidence from inference.
 
-Research a topic — verify facts from primary sources, separate evidence from inference
+Research a topic. Verify facts from primary sources, separate evidence from inference.
 -->
 ---
-description: Research a topic — verify facts from primary sources, separate evidence from inference
+description: Research a topic. Verify facts from primary sources, separate evidence from inference.
 ---
 
 You are Construct. Research: $ARGUMENTS
@@ -20,3 +20,5 @@ Method:
 For each finding: source, date, confidence (confirmed / inferred / weak signal).
 
 Output: FINDINGS (with citations) | INFERENCES (labeled) | GAPS | RECOMMENDATION
+
+Persistence: after producing the output, run `construct knowledge add --source=research --slug=<topic-slug> --topic="<one-line topic>" --confidence=<confirmed|inferred|weak>` and pass the FINDINGS+INFERENCES+GAPS+RECOMMENDATION block on stdin. The store writes a frontmatter-stamped markdown file under `.cx/knowledge/external/research/` and indexes it for future hybrid search. Pass `--source-url=<url>` repeatedly for each cited source (required when confidence=confirmed).

package/commands/understand/this.md

@@ -1,15 +1,15 @@
 <!--
-commands/understand/this.md — Explore and understand something — trace execution paths, map structure, gather evidence
+commands/understand/this.md (Explore and understand something) trace execution paths, map structure, gather evidence
 
-Explore and understand something — trace execution paths, map structure, gather evidence
+Explore and understand something: trace execution paths, map structure, gather evidence
 -->
 ---
-description: Explore and understand something — trace execution paths, map structure, gather evidence
+description: Explore and understand something: trace execution paths, map structure, gather evidence
 ---
 
 You are Construct. Explore and explain: $ARGUMENTS
 
-Gather evidence — do not propose solutions unless asked.
+Gather evidence: do not propose solutions unless asked.
 
 1. Search for the specific symbol, pattern, or behavior
 2. Trace the execution path from entry point to outcome

package/commands/understand/why.md

@@ -1,18 +1,18 @@
 <!--
-commands/understand/why.md — Investigate a failure — why is this broken, what is the root cause
+commands/understand/why.md (Investigate a failure) why is this broken, what is the root cause
 
-Investigate a failure — why is this broken, what is the root cause
+Investigate a failure: why is this broken, what is the root cause
 -->
 ---
-description: Investigate a failure — why is this broken, what is the root cause
+description: Investigate a failure: why is this broken, what is the root cause
 ---
 
 You are Construct. Investigate: $ARGUMENTS
 
-1. Capture — exact error, stack trace, reproduction steps
-2. Reproduce — confirm you can trigger the failure consistently
-3. Isolate — narrow to the smallest failing case
-4. Trace — follow data and control flow to where the invariant breaks
-5. Root cause — the one upstream cause that, if fixed, prevents the failure
+1. Capture: exact error, stack trace, reproduction steps
+2. Reproduce: confirm you can trigger the failure consistently
+3. Isolate: narrow to the smallest failing case
+4. Trace: follow data and control flow to where the invariant breaks
+5. Root cause: the one upstream cause that, if fixed, prevents the failure
 
 Do not plan a fix until root cause is confirmed. If you cannot reproduce, say so immediately and ask for more context.

package/commands/work/clean.md

@@ -1,10 +1,10 @@
 <!--
-commands/work/clean.md — Remove AI-generated code smells — verbosity, hedging, dead comments, generic names
+commands/work/clean.md (Remove AI-generated code smells) verbosity, hedging, dead comments, generic names
 
-Remove AI-generated code smells — verbosity, hedging, dead comments, generic names
+Remove AI-generated code smells: verbosity, hedging, dead comments, generic names
 -->
 ---
-description: Remove AI-generated code smells — verbosity, hedging, dead comments, generic names
+description: Remove AI-generated code smells: verbosity, hedging, dead comments, generic names
 ---
 
 You are cx-reviewer identifying AI slop in: $ARGUMENTS
@@ -13,17 +13,17 @@ Then dispatch cx-engineer to apply the fixes.
 
 ## What to remove
 
-1. **Obvious comments** — `// This function calculates X` when the function is named `calculateX`
-2. **Hedging names** — `result`, `data`, `temp`, `item`, `obj`, `value`, `response` — rename to reflect what they actually contain
-3. **Debug artifacts** — `console.log`, `print`, `debugger`, leftover logging statements
-4. **Unnecessary wrapping** — functions that do nothing except call one other function with no transformation
-5. **Dead TODO blocks** — `// TODO: remove later`, `// FIXME: clean this up`, stale commented-out code
-6. **Restated types** — `const userArray: User[] = []` → name already says it's a list, annotation adds nothing
-7. **Over-specified assertions** — test assertions that restate the implementation rather than the behavior
-8. **Swallowed errors** — `catch (e) {}` or `catch (e) { return null }` with no context or logging
-9. **Single-use abstractions** — helper created for one call site that could just be inline
-10. **Padded error messages** — `"An error occurred while attempting to process your request"` → `"Failed to process request"`
-11. **Boilerplate docstrings** — JSDoc/docstrings that only restate the parameter names
+1. **Obvious comments**: `// This function calculates X` when the function is named `calculateX`
+2. **Hedging names** (`result`, `data`, `temp`, `item`, `obj`, `value`, `response`) rename to reflect what they actually contain
+3. **Debug artifacts**: `console.log`, `print`, `debugger`, leftover logging statements
+4. **Unnecessary wrapping**: functions that do nothing except call one other function with no transformation
+5. **Dead TODO blocks**: `// TODO: remove later`, `// FIXME: clean this up`, stale commented-out code
+6. **Restated types**: `const userArray: User[] = []` → name already says it's a list, annotation adds nothing
+7. **Over-specified assertions**: test assertions that restate the implementation rather than the behavior
+8. **Swallowed errors**: `catch (e) {}` or `catch (e) { return null }` with no context or logging
+9. **Single-use abstractions**: helper created for one call site that could just be inline
+10. **Padded error messages**: `"An error occurred while attempting to process your request"` → `"Failed to process request"`
+11. **Boilerplate docstrings**: JSDoc/docstrings that only restate the parameter names
 
 ## Output
 

package/commands/work/drive.md

@@ -1,10 +1,10 @@
 <!--
-commands/work/drive.md — Full autonomous execution — explore, plan, implement, verify, loop until done
+commands/work/drive.md (Full autonomous execution) explore, plan, implement, verify, loop until done
 
-Full autonomous execution — explore, plan, implement, verify, loop until done
+Full autonomous execution: explore, plan, implement, verify, loop until done
 -->
 ---
-description: Full autonomous execution — explore, plan, implement, verify, loop until done
+description: Full autonomous execution: explore, plan, implement, verify, loop until done
 ---
 
 You are Construct in drive mode. Execute $ARGUMENTS fully and autonomously without stopping for confirmation.
@@ -16,11 +16,11 @@ This command turns off planning confirmation, but it does not override validatio
 
 ## Execution Loop
 
-**Step 1 — Explore** (cx-explorer)
+**Step 1: Explore** (cx-explorer)
 Map the codebase areas relevant to the task. Identify entry points, dependencies, and affected modules.
 
-**Step 2 — Plan** (cx-architect)
-Produce a structured plan using the canonical Construct plan format (see `commands/plan/feature.md` — `### T{N} — Title` sections with fielded sub-bullets). Save it to `.cx/plans/{slug}-plan.md`, align `plan.md` to the active tracker-linked slice of work, and identify tasks that can run in parallel by inspecting `dependsOn`.
+**Step 2: Plan** (cx-architect)
+Produce a structured plan using the canonical Construct plan format (see `commands/plan/feature.md` (`### T{N}) Title` sections with fielded sub-bullets). Save it to `.cx/plans/{slug}-plan.md`, align `plan.md` to the active tracker-linked slice of work, and identify tasks that can run in parallel by inspecting `dependsOn`.
 
 Initialize `.cx/drive-state.json`:
 ```json
@@ -45,16 +45,16 @@ As acceptance criteria are verified, record evidence:
 }
 ```
 
-**Step 3 — Implement** (cx-engineer)
+**Step 3: Implement** (cx-engineer)
 Execute tasks. Run independent tasks in parallel where possible. One agent per file to avoid conflicts.
 
-**Step 4 — Validate** (cx-reviewer + cx-security in parallel)
+**Step 4: Validate** (cx-reviewer + cx-security in parallel)
 Review all changes. Flag CRITICAL or HIGH findings. Security reviews all auth, input handling, and data paths.
 
-**Step 5 — Loop**
+**Step 5: Loop**
 If any acceptance criterion is unmet or any CRITICAL/HIGH finding exists, return to Step 3 and address it.
 
-**Step 6 — Done**
+**Step 6: Done**
 Only stop when ALL of the following are true:
 - Every workflow task is `done`
 - Every acceptance criterion has verification evidence

package/commands/work/optimize-prompts.md

@@ -1,10 +1,10 @@
 <!--
-commands/work/optimize-prompts.md — Prompt optimization command.
+commands/work/optimize-prompts.md: Prompt optimization command.
 
 Runs the closed-loop prompt optimization workflow using telemetry trace data.
 -->
 ---
-description: Closed-loop prompt optimization — read telemetry traces, diagnose failures, push improved version to staging
+description: Closed-loop prompt optimization: read telemetry traces, diagnose failures, push improved version to staging
 ---
 
 You are cx-trace-reviewer running a prompt optimization cycle for: $ARGUMENTS
@@ -18,13 +18,13 @@ Optimize prompt fragments and overlays, not the runtime orchestration policy. If
 
 ## Required steps
 
-1. **Read current prompt** — read the agent's prompt from `agents/registry.json` (or its `promptFile`)
-2. **Fetch recent scores** — GET `{CONSTRUCT_TELEMETRY_URL}/api/public/scores?name=quality&limit=200`
-3. **Skip agents with fewer than 20 scored traces** — insufficient signal; note them but do not optimize
-4. **Diagnose failure patterns** — analyze low-scoring traces, identify top 3 recurring patterns
-5. **Generate improved prompt** — targeted edits that address failures without breaking high-scoring behaviors
-6. **Push to staging** — update the prompt in a staging marker comment; log the candidate via `cx_trace` with `promptVersion: staging-{timestamp}`
-7. **Report** — for each agent: before/after median score estimate, patterns addressed, staging version note
+1. **Read current prompt**: read the agent's prompt from `agents/registry.json` (or its `promptFile`)
+2. **Fetch recent scores**: GET `{CONSTRUCT_TELEMETRY_URL}/api/public/scores?name=quality&limit=200`
+3. **Skip agents with fewer than 20 scored traces**: insufficient signal; note them but do not optimize
+4. **Diagnose failure patterns**: analyze low-scoring traces, identify top 3 recurring patterns
+5. **Generate improved prompt**: targeted edits that address failures without breaking high-scoring behaviors
+6. **Push to staging**: update the prompt in a staging marker comment; log the candidate via `cx_trace` with `promptVersion: staging-{timestamp}`
+7. **Report**: for each agent: before/after median score estimate, patterns addressed, staging version note
 
 ## Output