@geraldmaron/construct 1.0.4 → 1.0.6

package/skills/devops/containerization.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/containerization.md — Containerization — Use this skill when writing Dockerfiles, optimizing image size, or securing cont
+skills/devops/containerization.md (Containerization) Use this skill when writing Dockerfiles, optimizing image size, or securing cont
 
 Use this skill when writing Dockerfiles, optimizing image size, or securing container builds. ## Multi-Stage Builds
 -->
@@ -26,14 +26,14 @@ COPY --from=builder /app/node_modules ./node_modules
 ```
 
 Runtime base image selection:
-- `gcr.io/distroless/nodejs20-debian12` — no shell, no package manager, smallest attack surface for Node.
-- `node:20-alpine` — shell available for debugging; use when distroless breaks scripts.
-- `scratch` — static binaries only (Go, Rust with `musl`).
+- `gcr.io/distroless/nodejs20-debian12`: no shell, no package manager, smallest attack surface for Node.
+- `node:20-alpine`: shell available for debugging; use when distroless breaks scripts.
+- `scratch`: static binaries only (Go, Rust with `musl`).
 - Never use `debian`, `ubuntu`, or `node:20` (Debian-based) as a production runtime base; they carry thousands of unnecessary packages.
 
 ## Layer Caching
 
-Order layers by change frequency — least-changed first:
+Order layers by change frequency: least-changed first:
 
 1. Base OS packages (`RUN apk add ...`)
 2. App dependencies (`COPY package*.json ./` then `RUN npm ci`)
@@ -54,7 +54,7 @@ RUN apk add --no-cache curl git && \
     rm -rf /var/cache/apk/*
 ```
 
-Never put cache cleanup in a separate `RUN` — it creates a new layer that does not reclaim space from the previous layer.
+Never put cache cleanup in a separate `RUN`: it creates a new layer that does not reclaim space from the previous layer.
 
 ## Security
 
@@ -67,7 +67,7 @@ Never put cache cleanup in a separate `RUN` — it creates a new layer that does
 | No `apt-get upgrade` | Pin the base image digest instead; `upgrade` produces non-reproducible layers |
 | Read-only filesystem | Pass `--read-only` at runtime; mount writable tmpfs only for paths that need writes |
 
-Never use `ADD` with a URL — it bypasses layer caching in unpredictable ways and cannot be verified. Use `COPY` for local files and `curl` + checksum verification for remote files.
+Never use `ADD` with a URL: it bypasses layer caching in unpredictable ways and cannot be verified. Use `COPY` for local files and `curl` + checksum verification for remote files.
 
 ## Image Scanning
 
@@ -94,7 +94,7 @@ HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
 
 Use an HTTP endpoint for web services. Use a process check (`pgrep`) only for non-HTTP workloads.
 
-Kubernetes uses separate liveness, readiness, and startup probes — configure those in the deployment manifest, not in the Dockerfile. The Docker `HEALTHCHECK` is relevant for `docker run` and Docker Compose only.
+Kubernetes uses separate liveness, readiness, and startup probes: configure those in the deployment manifest, not in the Dockerfile. The Docker `HEALTHCHECK` is relevant for `docker run` and Docker Compose only.
 
 ## Size Optimization
 
@@ -102,5 +102,5 @@ Kubernetes uses separate liveness, readiness, and startup probes — configure t
 - `--no-install-recommends` with `apt-get install` eliminates suggested packages.
 - Always clean package manager caches in the same `RUN` layer as the install command.
 - Use `COPY --chown=app:app` instead of a separate `RUN chown` to avoid a wasted layer.
-- Multi-stage builds remove all build tools, source files, and intermediate artifacts automatically — they are the single highest-impact size reduction technique.
+- Multi-stage builds remove all build tools, source files, and intermediate artifacts automatically: they are the single highest-impact size reduction technique.
 - For Go and Rust, build a statically linked binary (`CGO_ENABLED=0` for Go, `musl` target for Rust) and copy it into `scratch` or distroless for a final image under 20 MB.

package/skills/devops/cost-optimization.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/cost-optimization.md — Cloud Cost Optimization — Use this skill when reducing cloud spend, right-sizing resources, or implementin
+skills/devops/cost-optimization.md (Cloud Cost Optimization) Use this skill when reducing cloud spend, right-sizing resources, or implementin
 
 Use this skill when reducing cloud spend, right-sizing resources, or implementing FinOps practices. ## Cost Visibility
 -->

package/skills/devops/data-engineering.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/data-engineering.md — Data Engineering — 1. **Idempotency**: pipelines can run multiple times without duplicating data
+skills/devops/data-engineering.md (Data Engineering) 1. **Idempotency**: pipelines can run multiple times without duplicating data
 
 ## Core Principles 1. **Idempotency**: pipelines can run multiple times without duplicating data
 -->
@@ -59,7 +59,7 @@ stream = env \
 env.execute("Orders Streaming Pipeline")
 ```
 
-Watermarks define event-time handling for late-arriving events — configure based on source latency SLA.
+Watermarks define event-time handling for late-arriving events: configure based on source latency SLA.
 
 ## Data Modeling
 

package/skills/devops/database.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/database.md — Database Patterns — Use this skill when designing schemas, writing migrations, optimizing queries, o
+skills/devops/database.md (Database Patterns) Use this skill when designing schemas, writing migrations, optimizing queries, o
 
 Use this skill when designing schemas, writing migrations, optimizing queries, or selecting databases. ## Schema Design
 -->

package/skills/devops/dependency-management.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/dependency-management.md — Dependency Management — Use this skill when managing package upgrades, resolving CVEs, or establishing l
+skills/devops/dependency-management.md (Dependency Management) Use this skill when managing package upgrades, resolving CVEs, or establishing l
 
 Use this skill when managing package upgrades, resolving CVEs, or establishing lock file and versioning policy. ## Lock File Hygiene
 -->
@@ -11,7 +11,7 @@ Use this skill when managing package upgrades, resolving CVEs, or establishing l
 
 - Always commit lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `go.sum`, `Cargo.lock`.
 - Never delete and regenerate a lock file without reviewing the full diff; regeneration silently upgrades all transitive dependencies.
-- Review lock file diffs in PRs for unexpected transitive version changes — these are where supply chain attacks hide.
+- Review lock file diffs in PRs for unexpected transitive version changes: these are where supply chain attacks hide.
 - Do not add lock files to `.gitignore`; they are the reproducibility contract for the build.
 - A PR that changes only the lock file (no `package.json` change) warrants careful scrutiny.
 
@@ -22,7 +22,7 @@ Use this skill when managing package upgrades, resolving CVEs, or establishing l
 | Dependabot | Daily/weekly schedule | One PR per package by default; group with `groups:` config | Patch: auto-merge if CI passes. Minor: batch weekly, manual review. Major: manual always. |
 | Renovate | Configurable schedule | Group by ecosystem, semver range, or custom regex via `packageRules` | Auto-merge patch and minor with passing CI; use `stabilityDays: 3` to avoid merging on day of release |
 
-Prefer Renovate for complex repos — its `rangeStrategy`, `grouping`, `stabilityDays`, and `automerge` controls are more expressive than Dependabot's.
+Prefer Renovate for complex repos: its `rangeStrategy`, `grouping`, `stabilityDays`, and `automerge` controls are more expressive than Dependabot's.
 
 Always require CI to pass before any auto-merge. Never auto-merge major version bumps.
 

package/skills/devops/devsecops.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/devsecops.md — DevSecOps — Use this skill when integrating security into CI/CD pipelines, managing supply c
+skills/devops/devsecops.md (DevSecOps) Use this skill when integrating security into CI/CD pipelines, managing supply c
 
 Use this skill when integrating security into CI/CD pipelines, managing supply chain risk, or automating security scanning. ## Pipeline Security Stages
 -->

package/skills/devops/git-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/git-workflow.md — Git Workflow — Use this skill when establishing branching strategies, commit conventions, or co
+skills/devops/git-workflow.md (Git Workflow) Use this skill when establishing branching strategies, commit conventions, or co
 
 Use this skill when establishing branching strategies, commit conventions, or code integration practices. ## Branching Strategies
 -->

package/skills/devops/incident-response.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/incident-response.md — Incident Response — | Sev | User impact | Response time | Example |
+skills/devops/incident-response.md (Incident Response) | Sev | User impact | Response time | Example |
 
 ## Severity Levels | Sev | User impact | Response time | Example |
 -->
@@ -14,7 +14,7 @@ skills/devops/incident-response.md — Incident Response — | Sev | User impact
 | **P2** | Significant degradation, partial outage | < 1 hour | Elevated error rate, slow responses |
 | **P3** | Minor impact, workaround available | Best effort / next business day | Single user affected, cosmetic |
 
-Define severity in your runbook and assign it early — it determines escalation and comms cadence.
+Define severity in your runbook and assign it early: it determines escalation and comms cadence.
 
 ## The Response Loop
 
@@ -36,9 +36,9 @@ Healthy detection requires:
 Declare an incident early, even if uncertain. It is easier to downgrade than to delay comms.
 
 1. Create incident channel: `#incident-YYYY-MM-DD-brief-description`
-2. Assign **Incident Commander (IC)** — one person owns the call and all decisions
-3. Assign **Scribe** — records timeline, decisions, actions in real time
-4. Assign **Comms Lead** — status page updates and stakeholder notifications
+2. Assign **Incident Commander (IC)**: one person owns the call and all decisions
+3. Assign **Scribe**: records timeline, decisions, actions in real time
+4. Assign **Comms Lead**: status page updates and stakeholder notifications
 
 ### Triage
 
@@ -53,14 +53,14 @@ IC asks: **"What is the user impact and is it getting better or worse?"**
 
 Use `git log --since="2 hours ago"` and deployment logs to find the change vector.
 
-### Mitigate (not root cause — stop the bleeding first)
+### Mitigate (not root cause: stop the bleeding first)
 
 Mitigation options in priority order:
-1. **Rollback** — fastest if a recent deploy is the cause
-2. **Feature flag off** — disable the failing feature
-3. **Traffic shift** — route to a healthy region or canary
-4. **Scale up** — if resource exhaustion is the cause
-5. **Restart** — for stuck processes (last resort — often hides root cause)
+1. **Rollback**: fastest if a recent deploy is the cause
+2. **Feature flag off**: disable the failing feature
+3. **Traffic shift**: route to a healthy region or canary
+4. **Scale up**: if resource exhaustion is the cause
+5. **Restart** (for stuck processes (last resort) often hides root cause)
 
 Do NOT wait for a perfect fix. Mitigate first, fix properly after users are unblocked.
 
@@ -107,12 +107,12 @@ Write the post-mortem within 48 hours while memory is fresh.
 
 ### Required sections
 
-1. **Summary** — 3-sentence description of what happened, impact, and resolution
-2. **Timeline** — chronological log with timestamps
-3. **Root cause(s)** — use 5-whys to reach systemic causes, not surface symptoms
-4. **Contributing factors** — process/tooling gaps that allowed the issue
-5. **What went well** — detection worked, rollback was fast, etc.
-6. **Action items** — concrete, assigned, time-bounded; not vague recommendations
+1. **Summary**: 3-sentence description of what happened, impact, and resolution
+2. **Timeline**: chronological log with timestamps
+3. **Root cause(s)**: use 5-whys to reach systemic causes, not surface symptoms
+4. **Contributing factors**: process/tooling gaps that allowed the issue
+5. **What went well**: detection worked, rollback was fast, etc.
+6. **Action items**: concrete, assigned, time-bounded; not vague recommendations
 
 ### 5-Whys example
 
@@ -129,7 +129,7 @@ Action: Add query plan check to PR template + CI gate for slow queries
 
 ### Blameless culture
 
-The post-mortem finds systemic failures, not individual errors. A person took an action that made sense given the information and tools available at the time — the question is why the system allowed that action to cause an outage.
+The post-mortem finds systemic failures, not individual errors. A person took an action that made sense given the information and tools available at the time: the question is why the system allowed that action to cause an outage.
 
 ## Runbook Template
 

package/skills/devops/monorepo.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/monorepo.md — Monorepo — Use this skill when selecting monorepo tooling, structuring packages, or optimiz
+skills/devops/monorepo.md (Monorepo) Use this skill when selecting monorepo tooling, structuring packages, or optimiz
 
 Use this skill when selecting monorepo tooling, structuring packages, or optimizing affected-only builds. ## Tool Selection
 -->
@@ -32,12 +32,12 @@ packages/
   auth/
 ```
 
-Keep `apps/` for deployable surfaces and `packages/` for everything importable. Never put deployable entrypoints inside `packages/`. Config packages (`packages/config/`) centralise tooling setup — each app/package extends rather than duplicates.
+Keep `apps/` for deployable surfaces and `packages/` for everything importable. Never put deployable entrypoints inside `packages/`. Config packages (`packages/config/`) centralise tooling setup: each app/package extends rather than duplicates.
 
 ## Package Boundaries
 
 - One package per domain or product surface (`packages/billing`, `packages/auth`, `apps/web`, `apps/api`).
-- Place shared utilities in `packages/utils` or `packages/shared` — never in an app package.
+- Place shared utilities in `packages/utils` or `packages/shared`: never in an app package.
 - Never import directly from one `apps/` package to another `apps/` package; extract shared code to `packages/`.
 - Each package exposes its public API through a single `index.ts` barrel file; internal modules are private.
 - Enforce boundaries with Nx `@nrwl/enforce-module-boundaries` lint rules or ESLint's `import/no-restricted-paths`.
@@ -56,7 +56,7 @@ nx affected --target=build --base=origin/main
 nx affected --target=test --base=origin/main
 ```
 
-Both tools build a change graph from the dependency tree. A change to `packages/utils` marks every downstream package as affected. Only affected packages run in CI — unaffected packages use cached results.
+Both tools build a change graph from the dependency tree. A change to `packages/utils` marks every downstream package as affected. Only affected packages run in CI: unaffected packages use cached results.
 
 CI integration: set `--base` to the merge base of the PR branch (`origin/main` or `$(git merge-base HEAD origin/main)`), not `HEAD^1`, to correctly identify all changed files in the PR.
 
@@ -82,6 +82,6 @@ Generate changelogs automatically from changeset files; do not write changelogs
 ## CI Optimization
 
 - Cache `.turbo` or Nx's default cache directory (`node_modules/.cache/nx`) between CI runs, keyed to the lock file hash.
-- Enable remote caching (Turborepo Remote Cache, Nx Cloud) for team environments — local caches do not transfer between CI runners.
+- Enable remote caching (Turborepo Remote Cache, Nx Cloud) for team environments: local caches do not transfer between CI runners.
 - Run `turbo prune --scope=<app>` to generate a minimal lockfile subset for Docker builds of individual apps.
 - Gate PR merges on `affected` tests, not the full suite, to keep CI under 10 minutes for large repos.

package/skills/devops/observability.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/observability.md — Observability — Use this skill when designing logging, tracing, metrics, or alerting systems.
+skills/devops/observability.md (Observability) Use this skill when designing logging, tracing, metrics, or alerting systems.
 
 Use this skill when designing logging, tracing, metrics, or alerting systems. ## Three Pillars
 -->

package/skills/devops/performance.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/performance.md — Performance Engineering — Use this skill when profiling, load testing, or optimizing application and infra
+skills/devops/performance.md (Performance Engineering) Use this skill when profiling, load testing, or optimizing application and infra
 
 Use this skill when profiling, load testing, or optimizing application and infrastructure performance. ## Performance Targets
 -->

package/skills/devops/testing.md

@@ -1,5 +1,5 @@
 <!--
-skills/devops/testing.md — Testing Strategy — Use this skill when planning test coverage, selecting test types, or establishin
+skills/devops/testing.md (Testing Strategy) Use this skill when planning test coverage, selecting test types, or establishin
 
 Use this skill when planning test coverage, selecting test types, or establishing testing practices. ## Test Pyramid
 -->

package/skills/docs/adr-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/adr-workflow.md — Workflow for recording an architectural decision as an ADR.
+skills/docs/adr-workflow.md: Workflow for recording an architectural decision as an ADR.
 
 Triggered when cx-architect finalizes a design or a technology choice is made. Writes a
 full ADR to docs/adr/ using the shipped template (user-overridable via .cx/templates/docs/adr.md)
@@ -18,7 +18,7 @@ Use when: an architectural decision is made that affects the system structure, d
 ## Steps
 
 1. **cx-architect** or **cx-engineer** identifies the decision
-2. **Write to `docs/adr/ADR-{NNN}-{slug}.md`** using the template from `get_template("adr")` — resolves `.cx/templates/docs/adr.md` (override) then `templates/docs/adr.md` (shipped)
+2. **Write to `docs/adr/ADR-{NNN}-{slug}.md`** using the template from `get_template("adr")`: resolves `.cx/templates/docs/adr.md` (override) then `templates/docs/adr.md` (shipped)
    - NNN = next sequential number (check existing files)
 3. **Also write a shorter entry to `.cx/decisions/`** for session context
 4. **cx-docs-keeper** updates `.cx/context.md` Architecture Notes with a one-line summary and link

package/skills/docs/backlog-proposal-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/backlog-proposal-workflow.md — Approval-gated issue tracker proposals.
+skills/docs/backlog-proposal-workflow.md: Approval-gated issue tracker proposals.
 -->
 # Backlog Proposal Workflow
 

package/skills/docs/customer-profile-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/customer-profile-workflow.md — Maintain durable customer/account memory for Product Intelligence.
+skills/docs/customer-profile-workflow.md: Maintain durable customer/account memory for Product Intelligence.
 -->
 # Customer Profile Workflow
 

package/skills/docs/document-ingest-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/document-ingest-workflow.md — Convert source documents into retrieval-ready markdown artifacts.
+skills/docs/document-ingest-workflow.md: Convert source documents into retrieval-ready markdown artifacts.
 -->
 # Document Ingest Workflow
 

package/skills/docs/evidence-ingest-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/evidence-ingest-workflow.md — Normalize raw product evidence into Construct knowledge artifacts.
+skills/docs/evidence-ingest-workflow.md: Normalize raw product evidence into Construct knowledge artifacts.
 -->
 # Evidence Ingest Workflow
 

package/skills/docs/init-docs.md

@@ -1,20 +1,20 @@
 <!--
-skills/docs/init-docs.md — Skill: init-docs — Initialize Project Documentation Structure — `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
+skills/docs/init-docs.md (Skill: init-docs) Initialize Project Documentation Structure: `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 
 ## Trigger keywords `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 -->
-# Skill: init-docs — Initialize Project Documentation Structure
+# Skill: init-docs: Initialize Project Documentation Structure
 
 ## Trigger keywords
 `init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`
 
 ## What this skill does
 
-When invoked, gather the user's intent and create a tailored documentation directory structure. The structure serves as both human reference and **required operational project state** — all LLMs working in this project, including Construct, should read these docs to understand purpose, decisions, constraints, and active reality before acting.
+When invoked, gather the user's intent and create a tailored documentation directory structure. The structure serves as both human reference and **required operational project state**: all LLMs working in this project, including Construct, should read these docs to understand purpose, decisions, constraints, and active reality before acting.
 
 ---
 
-## Step 1 — Gather intent (ask these questions)
+## Step 1: Gather intent (ask these questions)
 
 Ask the user **all at once** (single message, not one at a time):
 
@@ -26,9 +26,9 @@ Ask the user **all at once** (single message, not one at a time):
 
 ---
 
-## Step 2 — Generate the structure
+## Step 2: Generate the structure
 
-Based on answers, create the `docs/` directory and appropriate subdirectories. Use this as a base — add or remove sections based on the user's answers.
+Based on answers, create the `docs/` directory and appropriate subdirectories. Use this as a base: add or remove sections based on the user's answers.
 
 ### Core structure (always include)
 
@@ -45,12 +45,12 @@ docs/
 
 ## Interactive UX (TTY)
 
-When run interactively, `construct init-docs` renders a keyboard-driven **full-screen checkbox picker** — all available lanes listed with the default set pre-checked and context-suggested lanes highlighted in the UI. No typing required.
+When run interactively, `construct init-docs` renders a keyboard-driven **full-screen checkbox picker**: all available lanes listed with the default set pre-checked and context-suggested lanes highlighted in the UI. No typing required.
 
-- **↑ / ↓** — move cursor (details shown in a dedicated panel)
-- **Space** — toggle lane on/off
-- **a** — toggle all on/off
-- **Enter** — confirm and scaffold
+- **↑ / ↓**: move cursor (details shown in a dedicated panel)
+- **Space**: toggle lane on/off
+- **a**: toggle all on/off
+- **Enter**: confirm and scaffold
 - Follow-up choices use the same menu pattern instead of free-text answers
 
 If the user selects the `intake` lane, `construct init-docs` should also create `.cx/inbox/`. Both `.cx/inbox/` and `docs/intake/` act as drop zones for ingestable files, while `docs/intake/` also serves as the durable paper trail lane.
@@ -90,7 +90,7 @@ When run non-interactively (`--yes` or piped stdin), the lean default set is use
 
 ---
 
-## Step 3 — Make the core docs explicit project state
+## Step 3: Make the core docs explicit project state
 
 The required core documents are the operational state surface for the repo. All LLMs working here should read and maintain them:
 
@@ -104,9 +104,9 @@ Fill these in based on the user's answers and the actual repo shape. Treat them
 
 ---
 
-## Step 4 — Create skeleton files
+## Step 4: Create skeleton files
 
-Each created file should have a minimal, useful skeleton — not just a title. Skeletons should include:
+Each created file should have a minimal, useful skeleton: not just a title. Skeletons should include:
 - A one-line description of what goes in this file
 - Section headings relevant to the doc type
 - A note at the top that the file is required project state and all LLMs should keep it current.
@@ -156,7 +156,7 @@ Link to `docs/adr/` or the canonical project decision log used in this repo.
 
 ---
 
-## Step 5 — Tell the repo how upkeep works
+## Step 5: Tell the repo how upkeep works
 
 After creating the files, instruct the user:
 

package/skills/docs/init-project.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/init-project.md — Project Initialization — Use when: starting work on a new project or joining an existing one without doc
+skills/docs/init-project.md (Project Initialization) Use when: starting work on a new project or joining an existing one without doc
 
 Use when: starting work on a new project or joining an existing one without doc structure. ## Command
 -->

package/skills/docs/prd-workflow.md

@@ -1,9 +1,9 @@
 <!--
-skills/docs/prd-workflow.md — Workflow for producing a PRD and connecting it to workflow task packets.
+skills/docs/prd-workflow.md: Workflow for producing a PRD and connecting it to workflow task packets.
 
 Guides cx-product-manager through requirements gathering, user research, and writing a PRD
 to docs/prd/. Once approved, the PRD feeds /plan feature to create bead packets in
-.cx/workflow.json — closing the loop from discovery to execution.
+.cx/workflow.json: closing the loop from discovery to execution.
 -->
 # PRD Workflow
 
@@ -17,7 +17,7 @@ Choose the document type before drafting:
 | `prd-platform` | Internal platform, APIs, SDKs, developer tooling, operational infrastructure, shared services |
 | `prd-business` | Strategic bets, market positioning, business model changes, make-vs-buy, pricing strategy |
 | `meta-prd` | Requirements about the product operating system itself: agent workflows, evidence pipelines, templates, evaluation loops, governance |
-| `rfc` | Technical or architectural proposals that need structured review before implementation — no contract changes |
+| `rfc` | Technical or architectural proposals that need structured review before implementation: no contract changes |
 | `rfc-platform` | Proposals that change an external contract: API, SDK, schema, event payload, permission model, protocol |
 
 Style constraint: do not produce a wall of bullets. Use paragraphs for reasoning and narrative, tables for comparison, and bullets only where scanability helps. Keep em dashes rare.

package/skills/docs/prfaq-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/prfaq-workflow.md — Working-backwards PRFAQ generation from PRDs or evidence.
+skills/docs/prfaq-workflow.md: Working-backwards PRFAQ generation from PRDs or evidence.
 -->
 # PRFAQ Workflow
 

package/skills/docs/product-intelligence-review.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-intelligence-review.md — Evaluate Product Intelligence artifacts before they become docs of record.
+skills/docs/product-intelligence-review.md: Evaluate Product Intelligence artifacts before they become docs of record.
 -->
 # Product Intelligence Review
 

package/skills/docs/product-intelligence-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-intelligence-workflow.md — Native Construct workflow for product evidence, synthesis, and product docs.
+skills/docs/product-intelligence-workflow.md: Native Construct workflow for product evidence, synthesis, and product docs.
 
 Use this to move from raw product evidence to PRDs, Meta PRDs, PRFAQs, signal briefs,
 customer profiles, and backlog proposals without creating a separate sidecar system.

package/skills/docs/product-signal-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/product-signal-workflow.md — Synthesize product signals from evidence into the right artifact.
+skills/docs/product-signal-workflow.md: Synthesize product signals from evidence into the right artifact.
 Confidence rubric, contradiction resolution, artifact decision tree, and storage are all defined here.
 Follow rules/common/research.md for source-handling policy.
 -->
@@ -18,10 +18,10 @@ Use when: the user asks what customers are asking for, what themes are emerging,
 ## Contradiction Resolution
 
 When two signals conflict:
-1. Name both signals explicitly — do not average them away.
+1. Name both signals explicitly: do not average them away.
 2. Weight by customer tier (enterprise > growth > SMB) and recency (weight decays after 90 days).
 3. Record the contradiction in the signal brief as an open question.
-4. Never let a minority signal disappear — it may be the leading indicator.
+4. Never let a minority signal disappear: it may be the leading indicator.
 
 ## Artifact Decision Tree
 
@@ -43,11 +43,11 @@ After grouping evidence, check `.cx/knowledge/decisions/strategy/` for any decla
 
 ## Steps
 
-1. **Gather** — collect evidence briefs, customer profiles, field notes, tickets, and research from `.cx/knowledge/` and linked sources.
-2. **Group** — cluster by theme, ask, pain point, affected persona, product area, and counter-signal.
-3. **Assign confidence** — apply the rubric above; separate observation from inference.
-4. **Check strategy** — check `.cx/knowledge/decisions/strategy/`; flag alignment or conflict with Bets and Non-bets if documents exist.
-5. **Select artifact** — apply the decision tree; write the artifact; store to the path below.
+1. **Gather**: collect evidence briefs, customer profiles, field notes, tickets, and research from `.cx/knowledge/` and linked sources.
+2. **Group**: cluster by theme, ask, pain point, affected persona, product area, and counter-signal.
+3. **Assign confidence**: apply the rubric above; separate observation from inference.
+4. **Check strategy**: check `.cx/knowledge/decisions/strategy/`; flag alignment or conflict with Bets and Non-bets if documents exist.
+5. **Select artifact**: apply the decision tree; write the artifact; store to the path below.
 
 ## Storage
 
@@ -58,4 +58,4 @@ After grouping evidence, check `.cx/knowledge/decisions/strategy/` for any decla
 | PRD | `docs/prd/` |
 | PRFAQ | `docs/prfaq/` |
 | Meta PRD | `docs/meta-prd/` |
-| Backlog proposal | pending approval gate — do not file until explicit user approval |
+| Backlog proposal | pending approval gate: do not file until explicit user approval |

package/skills/docs/research-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/research-workflow.md — Research Workflow — Use when: the user asks to research a topic, investigate a question, or gather e
+skills/docs/research-workflow.md (Research Workflow) Use when: the user asks to research a topic, investigate a question, or gather e
 
 Use when: the user asks to research a topic, investigate a question, or gather evidence for a decision. ## Steps
 -->
@@ -11,9 +11,9 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 
 ## Steps
 
-1. **Clarify the question** — one specific, falsifiable question the research must answer.
-2. **Apply recency discipline** — always search from the most recent year backward. For fast-moving domains (AI tools, security, market data), treat anything older than 12 months as presumptively stale unless a newer source confirms it is still accurate.
-3. **Check internal evidence first** — search `.cx/research/`, `.cx/knowledge/`, `docs/prd/`, `docs/meta-prd/`, ADRs, runbooks, and ingested artifacts before going external.
+1. **Clarify the question**: one specific, falsifiable question the research must answer.
+2. **Apply recency discipline**: always search from the most recent year backward. For fast-moving domains (AI tools, security, market data), treat anything older than 12 months as presumptively stale unless a newer source confirms it is still accurate.
+3. **Check internal evidence first**: search `.cx/research/`, `.cx/knowledge/`, `docs/prd/`, `docs/meta-prd/`, ADRs, runbooks, and ingested artifacts before going external.
 4. **Choose the research path and starting point** by domain:
 
    | Domain | Authoritative starting points |
@@ -28,10 +28,10 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 5. **Use a source hierarchy**:
    - Primary: official docs, exact-version API references, standards, source code, peer-reviewed papers
    - Secondary: changelogs, migration guides, maintainer issue comments, release notes
-   - Tertiary: blogs/forums/Q&A only to locate primaries — never cite tertiary alone for a load-bearing claim
-6. **Verify every URL** — fetch each URL cited and confirm it resolves and matches the cited claim. Mark unconfirmed URLs as `[unverified]`.
-7. **Structure findings** using the template from `get_template("research-brief")` — resolves `.cx/templates/docs/research-brief.md` (override) then `templates/docs/research-brief.md` (shipped)
-8. **Write to `.cx/research/{topic-slug}.md`** — cx-docs-keeper owns this
+   - Tertiary: blogs/forums/Q&A only to locate primaries: never cite tertiary alone for a load-bearing claim
+6. **Verify every URL**: fetch each URL cited and confirm it resolves and matches the cited claim. Mark unconfirmed URLs as `[unverified]`.
+7. **Structure findings** using the template from `get_template("research-brief")`: resolves `.cx/templates/docs/research-brief.md` (override) then `templates/docs/research-brief.md` (shipped)
+8. **Write to `.cx/research/{topic-slug}.md`**: cx-docs-keeper owns this
 9. **Reference the research doc** in the requesting agent's output (link by path)
 
 ## Verification bar
@@ -39,13 +39,13 @@ Follow [rules/common/research.md](../../rules/common/research.md) as the default
 - Every load-bearing claim must cite a verified source path, URL, or document reference.
 - Record publication date, version, or access date for each source. If no date is available, state `[undated]` and treat confidence as `low`.
 - Fetch and confirm every URL before including it in a committed document.
-- Separate observation from inference — label each finding's confidence as `high`, `medium`, or `low`.
+- Separate observation from inference: label each finding's confidence as `high`, `medium`, or `low`.
 - Name contradictions and unresolved gaps.
 - Prefer two independent sources per load-bearing claim unless one authoritative primary source is sufficient.
 - State the strongest counter-evidence when one exists.
 
 ## File naming
-- Topic slug: lowercase, hyphens, no spaces — e.g., `firebase-auth-v9-migration.md`
+- Topic slug: lowercase, hyphens, no spaces: e.g., `firebase-auth-v9-migration.md`
 - Date prefix for time-sensitive research: `2026-04-release-comparison.md`
 
 ## When research feeds a decision

package/skills/docs/runbook-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/runbook-workflow.md — Runbook Workflow — Use when: creating operational procedures for services, alerts, or recurring ope
+skills/docs/runbook-workflow.md (Runbook Workflow) Use when: creating operational procedures for services, alerts, or recurring ope
 
 Use when: creating operational procedures for services, alerts, or recurring operations. ## Steps
 -->
@@ -10,7 +10,7 @@ Use when: creating operational procedures for services, alerts, or recurring ope
 ## Steps
 
 1. **cx-sre** or **cx-release-manager** identifies the need
-2. **Write to `docs/runbooks/{service}-{operation}.md`** using the template from `get_template("runbook")` — resolves `.cx/templates/docs/runbook.md` (override) then `templates/docs/runbook.md` (shipped)
+2. **Write to `docs/runbooks/{service}-{operation}.md`** using the template from `get_template("runbook")`: resolves `.cx/templates/docs/runbook.md` (override) then `templates/docs/runbook.md` (shipped)
 3. **Link from the relevant alert** or monitoring dashboard
 4. **cx-docs-keeper** adds to `.cx/context.md` if it's a critical path runbook
 

package/skills/docs/strategy-workflow.md

@@ -1,5 +1,5 @@
 <!--
-skills/docs/strategy-workflow.md — Read, update, and reason about the product strategy.
+skills/docs/strategy-workflow.md: Read, update, and reason about the product strategy.
 Canonical store: ~/.cx/strategy.md (user-global) or .cx/strategy.md (project-local, committed).
 Template: templates/docs/strategy.md.
 -->
@@ -32,5 +32,5 @@ Given a product signal or PRD, check:
 
 | Scope | Path | Committed? |
 |---|---|---|
-| User-global | `~/.cx/strategy.md` | No — local only |
-| Project-local | `.cx/strategy.md` | Yes — source of truth for this repo |
+| User-global | `~/.cx/strategy.md` | No: local only |
+| Project-local | `.cx/strategy.md` | Yes: source of truth for this repo |