@geraldmaron/construct 1.0.3 → 1.0.5

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

@@ -8,8 +8,8 @@ Use when: product evidence should create or update Jira, Linear, GitHub Issues,
 ## Steps
 
 1. Load source evidence, evidence brief, PRD, or signal brief.
-2. Search existing tracker context if an MCP is configured; otherwise search local docs and product-intel artifacts.
-3. Create `.cx/product-intel/backlog-proposals/{date}-{slug}.md` with `get_template("backlog-proposal")`.
+2. Search existing tracker context if an MCP is configured; otherwise search local docs and knowledge artifacts.
+3. Create `.cx/knowledge/internal/backlog-proposals/{date}-{slug}.md` with `get_template("backlog-proposal")`.
 4. Include duplicate/conflict analysis and exact proposed writes.
 5. Return `NEEDS_MAIN_INPUT` for approval before any external write.
 6. After approval, apply changes and update the proposal's application log.

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

@@ -7,7 +7,7 @@ Use when: customer evidence should update durable product memory.
 
 ## Steps
 
-1. Load the existing customer profile from `.cx/product-intel/customer-profiles/` if present.
+1. Load the existing customer profile from `.cx/knowledge/internal/customer-profiles/` if present.
 2. Read the new source evidence.
 3. Add new facts, asks, pain points, contacts, product areas, and evidence links.
 4. Preserve historical entries. Do not delete or rewrite prior history without explicit approval.

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

@@ -1,5 +1,5 @@
 <!--
-skills/docs/evidence-ingest-workflow.md — Normalize raw product evidence into Construct product-intel artifacts.
+skills/docs/evidence-ingest-workflow.md — Normalize raw product evidence into Construct knowledge artifacts.
 -->
 # Evidence Ingest Workflow
 
@@ -11,9 +11,9 @@ Follow [rules/common/research.md](../../rules/common/research.md) for source met
 
 1. Identify the source type and date.
 2. Extract source metadata: customer, actor, product area, channel, linked issue, and confidence.
-3. Save raw or lightly normalized source material under `.cx/product-intel/sources/`.
-4. If customer-specific, update or create `.cx/product-intel/customer-profiles/{customer}.md` using `get_template("customer-profile")`.
-5. Create `.cx/product-intel/evidence-briefs/{date}-{slug}.md` using `get_template("evidence-brief")` when the evidence supports a product decision.
+3. Save raw or lightly normalized source material under `.cx/knowledge/internal/sources/`.
+4. If customer-specific, update or create `.cx/knowledge/internal/customer-profiles/{customer}.md` using `get_template("customer-profile")`.
+5. Create `.cx/knowledge/internal/evidence-briefs/{date}-{slug}.md` using `get_template("evidence-brief")` when the evidence supports a product decision.
 6. If evidence is weak but worth preserving, create a signal brief with `get_template("signal-brief")`.
 
 ## Rules
@@ -29,4 +29,4 @@ Always preserve:
 
 ## Storage
 
-Files in `.cx/product-intel/` are indexed by Construct's hybrid retrieval path. Postgres stores them as `product-intel` documents during sync, and the vector layer makes them semantically retrievable for future PRDs and Meta PRDs.
+Files in `.cx/knowledge/` are indexed by Construct's hybrid retrieval path. The vector layer makes them semantically retrievable for future PRDs and Meta PRDs.

package/skills/docs/prfaq-workflow.md

@@ -18,7 +18,7 @@ Use when: the user asks for a PRFAQ, working-backwards doc, launch narrative, or
 4. Write the press release in shipped-state language.
 5. Write external FAQ for customers and internal FAQ for engineering, sales, support, security, finance, and leadership.
 6. Include unknowns as `TBD` with what would resolve them.
-7. Save to `.cx/product-intel/prfaqs/` until approved.
+7. Save to `.cx/knowledge/internal/prfaqs/` until approved.
 
 ## Approval
 

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

@@ -14,7 +14,7 @@ Score each dimension as pass, warning, or fail:
 - Acceptance criteria: observable and pass/fail.
 - Scope discipline: goals, non-goals, and tradeoffs are explicit.
 - Approval safety: external writes and approved status are gated.
-- Storage readiness: artifact path is under `.cx/product-intel/`, `docs/prd/`, or `docs/meta-prd/` so hybrid retrieval can index it.
+- Storage readiness: artifact path is under `.cx/knowledge/`, `docs/prd/`, or `docs/meta-prd/` so hybrid retrieval can index it.
 - Readability: balanced paragraphs, tables, and bullets. Few em dashes.
 
 ## Output

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

@@ -14,7 +14,7 @@ Follow [rules/common/research.md](../../rules/common/research.md) for source ord
 
 Product Intelligence is a Construct-native loop:
 
-1. Capture evidence into `.cx/product-intel/sources/` or link existing sources.
+1. Capture evidence into `.cx/knowledge/internal/sources/` or link existing sources.
 2. Normalize evidence into field notes, customer profiles, and evidence briefs.
 3. Synthesize themes, asks, pain points, product areas, and confidence.
 4. Select the PM flavor: product, platform, enterprise, ai-product, or growth.
@@ -53,9 +53,9 @@ Load the core product-manager role guidance and the selected overlay before draf
 
 ## Storage
 
-Write working artifacts under `.cx/product-intel/` unless they are docs of record. Approved PRDs live in `docs/prd/`; approved Meta PRDs live in `docs/meta-prd/`.
+Write working artifacts under `.cx/knowledge/` unless they are docs of record. Approved PRDs live in `docs/prd/`; approved Meta PRDs live in `docs/meta-prd/`.
 
-The hybrid storage layer indexes `.cx/product-intel/`, `docs/prd/`, and `docs/meta-prd/`. When Postgres is configured, `construct storage sync` can persist these artifacts into shared SQL rows. The vector layer scores the same documents for local, remote, or file-backed semantic retrieval.
+The hybrid storage layer indexes `.cx/knowledge/`, `docs/prd/`, and `docs/meta-prd/`. When Postgres is configured, `construct storage sync` can persist these artifacts into shared SQL rows. The vector layer scores the same documents for local, remote, or file-backed semantic retrieval.
 
 ## Approval boundaries
 

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

@@ -1,31 +1,61 @@
 <!--
-skills/docs/product-signal-workflow.md — Synthesize product signals from evidence.
+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.
 -->
 # Product Signal Workflow
 
 Use when: the user asks what customers are asking for, what themes are emerging, whether evidence is strong enough, or what should become a PRD.
 
-Follow [rules/common/research.md](../../rules/common/research.md) for confidence, contradictions, and source handling.
+## Confidence Rubric
 
-## Steps
+| Level | Criteria |
+|---|---|
+| **high** | ≥ 3 independent customers mention the same problem verbatim, OR 1 enterprise blocker with revenue at risk named |
+| **medium** | 2 independent customers, OR 1 customer with high frequency (≥ 3 mentions), OR corroborated by a competitor signal |
+| **low** | 1 customer mention, OR internal opinion without user observation, OR inferred from adjacent evidence |
+
+## Contradiction Resolution
 
-1. Gather relevant evidence briefs, customer profiles, notes, tickets, research, and product docs.
-2. Group evidence into themes, asks, pain points, affected personas, product areas, and counter-signals.
-3. Assign confidence: high, medium, or low.
-4. Choose the next artifact:
-   - signal brief for weak or early evidence
-   - evidence brief for decision-ready synthesis
-   - PRD or PRFAQ for strong customer-facing product demand
-   - Meta PRD for operating-system or process changes
-   - backlog proposal for tracker changes after approval
-5. Store synthesis in `.cx/product-intel/signals/` or `.cx/product-intel/evidence-briefs/`.
+When two signals conflict:
+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.
 
-## Evidence threshold
+## Artifact Decision Tree
 
-Default threshold for PRD-ready evidence: at least two independent customers, three independent mentions, one severe enterprise blocker, or a clear strategic mandate with named risk. If the threshold is not met, write a signal brief instead of inventing requirements.
+| Condition | Artifact |
+|---|---|
+| < 2 independent sources OR < medium confidence | signal brief |
+| ≥ 2 independent sources AND ≥ medium confidence AND no strategic mandate yet | evidence brief |
+| ≥ 3 sources OR 1 enterprise blocker OR PM has declared this a bet | PRD |
+| PRD is approved AND launch narrative needed | PRFAQ |
+| Subject is an internal process, agent workflow, or governance mechanism | Meta PRD |
+| Artifact is approved AND needs a tracker item | backlog proposal (requires approval gate) |
 
-## Quality bar
+## Strategy Check
 
-Separate asks from requirements. Separate observation from inference. Name what evidence would change the recommendation.
+After grouping evidence, check `.cx/knowledge/decisions/strategy/` for any declared strategy documents:
+- Signal aligns with a declared Bet → raise priority, note alignment explicitly.
+- Signal conflicts with a declared Non-bet → flag the conflict; the user must make an explicit override decision before proceeding.
+- No strategy documents exist → continue without blocking; note that strategy grounding is not available.
+
+## Steps
 
-When a claim depends on time-sensitive or external information, include the date or version basis. If evidence conflicts, state the counter-signal explicitly instead of averaging it away.
+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
+
+| Artifact | Path |
+|---|---|
+| Signal brief | `.cx/knowledge/internal/signals/` |
+| Evidence brief | `.cx/knowledge/internal/evidence-briefs/` |
+| PRD | `docs/prd/` |
+| PRFAQ | `docs/prfaq/` |
+| Meta PRD | `docs/meta-prd/` |
+| Backlog proposal | pending approval gate — do not file until explicit user approval |

package/skills/docs/research-workflow.md

@@ -12,25 +12,37 @@ 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. **Check internal evidence first** — search `.cx/research/`, `.cx/product-intel/`, `docs/prd/`, `docs/meta-prd/`, ADRs, runbooks, and ingested artifacts before going external.
-3. **Choose the research path**:
-   - Library/API/framework/version questions → primary vendor docs, source code, changelogs, exact-version references
-   - Market, competitive, policy, or general evidence → cx-researcher using primary sources first
-4. **Use a source hierarchy**:
-   - Primary: official docs, exact-version API references, standards, source code
-   - Secondary: changelogs, migration guides, maintainer issue comments
-   - Tertiary: blogs/forums/Q&A only to locate primaries
-5. **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)
-6. **Write to `.cx/research/{topic-slug}.md`** — cx-docs-keeper owns this
-7. **Reference the research doc** in the requesting agent's output (link by path)
+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 |
+   |---|---|
+   | AI tools / LLM behavior / multi-agent | arXiv (cs.AI, cs.SE, cs.CL), ACL Anthology, conference proceedings (NeurIPS, ICML, ICLR, HICSS) |
+   | Developer tools / IDE / adoption | Stack Overflow Developer Survey, JetBrains Developer Ecosystem Report, GitHub blog, editor changelogs |
+   | Security / CVEs / supply chain | NVD, GitHub Security Advisories, OWASP, vendor security blogs (Google Project Zero, Microsoft Security), ProjectDiscovery |
+   | Market data / ARR / adoption | Primary company announcements, SEC filings, then TechCrunch/Bloomberg citing company sources |
+   | Cloud / API / SDK / version | Official vendor docs for exact version, changelog, migration guide |
+   | Regulatory / compliance / privacy | Primary regulation text, then official agency guidance |
+
+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
+9. **Reference the research doc** in the requesting agent's output (link by path)
 
 ## Verification bar
 
-- Every load-bearing claim must cite a source path, URL, or document reference.
-- Record publication date, version, or access date for each source.
-- Separate observation from inference.
+- 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`.
 - 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`

package/skills/docs/strategy-workflow.md

@@ -0,0 +1,36 @@
+<!--
+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.
+-->
+# Strategy Workflow
+
+Use when: the user asks about product direction, strategic bets, what to prioritize, whether a signal aligns with strategy, or wants to update the strategy.
+
+## Reading Strategy
+
+1. Read `~/.cx/strategy.md` (or project-local `.cx/strategy.md`).
+2. If the file does not exist, inform the user and offer to create it using `templates/docs/strategy.md`.
+3. Parse sections: Vision, Bets, Non-bets, Time Horizon, North Star Metric, Competitive Positioning.
+
+## Checking Signal Alignment
+
+Given a product signal or PRD, check:
+- Does the signal target a declared Bet? → flag as strategically aligned.
+- Does the signal conflict with a Non-bet? → flag the conflict; the user must make an explicit override decision.
+- Does the signal address the Time Horizon goal? → note this in the signal brief.
+
+## Updating Strategy
+
+1. Show the user the current section being updated.
+2. Propose the change with rationale.
+3. Write the updated section and increment the `updated` date.
+4. If a Bet is being added, check for conflicting Non-bets and surface them.
+5. Strategy changes are always approved by the user before writing.
+
+## Storage
+
+| Scope | Path | Committed? |
+|---|---|---|
+| User-global | `~/.cx/strategy.md` | No — local only |
+| Project-local | `.cx/strategy.md` | Yes — source of truth for this repo |

package/skills/roles/architect.ai-systems.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.ai-systems.md — Anti-pattern guidance for the Architect.ai-systems (ai systems) role.
+skills/roles/architect.ai-systems.md. Anti-pattern guidance for the Architect.ai-systems (ai systems) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the architect.ai-systems (ai systems) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-architect.
 role: architect.ai-systems
 applies_to: [cx-architect]
 inherits: architect
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # AI Systems Architect Overlay
 

package/skills/roles/architect.data.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.data.md — Anti-pattern guidance for the Architect.data (data) role.
+skills/roles/architect.data.md. Anti-pattern guidance for the Architect.data (data) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the architect.data (data) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-architect.
 role: architect.data
 applies_to: [cx-architect]
 inherits: architect
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Data Architect Overlay
 

package/skills/roles/architect.enterprise.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.enterprise.md — Anti-pattern guidance for the Architect.enterprise (enterprise) role.
+skills/roles/architect.enterprise.md. Anti-pattern guidance for the Architect.enterprise (enterprise) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the architect.enterprise (enterprise) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-architect.
 role: architect.enterprise
 applies_to: [cx-architect]
 inherits: architect
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Enterprise Architect Overlay
 

package/skills/roles/architect.integration.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.integration.md — Anti-pattern guidance for the Architect.integration (integration) role.
+skills/roles/architect.integration.md. Anti-pattern guidance for the Architect.integration (integration) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the architect.integration (integration) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-architect.
 role: architect.integration
 applies_to: [cx-architect]
 inherits: architect
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Integration Architect Overlay
 

package/skills/roles/architect.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.md — Anti-pattern guidance for the Architect role.
+skills/roles/architect.md. Anti-pattern guidance for the Architect role.
 
 ## Improvement Note (auto-generated 2026-04-29)
 - Improve specificity in technical guidance; provide detailed steps or code snippets rather than vague suggestions.
@@ -14,11 +14,13 @@ Applies to: cx-architect, cx-rd-lead.
 role: architect
 applies_to: [cx-architect, cx-rd-lead]
 inherits: null
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
-# Architect — Role guidance
+# Architect. Role guidance
 
-Load this before drafting. These are the failure modes that separate strong role output from weak role output — check your draft against each.
+Load this before drafting. These are the failure modes that separate strong role output from weak role output. check your draft against each.
 
 
 ### 1. Premature tech choice
@@ -42,7 +44,7 @@ Load this before drafting. These are the failure modes that separate strong role
 **Counter-move**: label every major decision as one-way or two-way and match the evidence burden to it.
 
 ### 5. Boundary vagueness
-**Symptom**: modules, services, or teams are drawn with arrows but the contracts — inputs, outputs, failure modes — are not specified.
+**Symptom**: modules, services, or teams are drawn with arrows but the contracts. inputs, outputs, failure modes. are not specified.
 **Why it fails**: each team implements its own interpretation; the integration surfaces the gaps in production.
 **Counter-move**: every boundary has a contract. Every contract names its failure modes.
 

package/skills/roles/architect.platform.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/architect.platform.md — Anti-pattern guidance for the Architect.platform (platform) role.
+skills/roles/architect.platform.md. Anti-pattern guidance for the Architect.platform (platform) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the architect.platform (platform) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-architect.
 role: architect.platform
 applies_to: [cx-architect]
 inherits: architect
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Platform Architect Overlay
 

package/skills/roles/data-analyst.experiment.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-analyst.experiment.md — Anti-pattern guidance for the Data-analyst.experiment (experiment) role.
+skills/roles/data-analyst.experiment.md. Anti-pattern guidance for the Data-analyst.experiment (experiment) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-analyst.experiment (experiment) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-analyst.
 role: data-analyst.experiment
 applies_to: [cx-data-analyst]
 inherits: data-analyst
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Experiment Analyst Overlay
 

package/skills/roles/data-analyst.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-analyst.md — Anti-pattern guidance for the Data-analyst role.
+skills/roles/data-analyst.md. Anti-pattern guidance for the Data-analyst role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-analyst domain and counter-moves to avoid them.
@@ -9,27 +9,29 @@ Applies to: cx-data-analyst.
 role: data-analyst
 applies_to: [cx-data-analyst]
 inherits: null
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
-# Data Analyst — Role guidance
+# Data Analyst. Role guidance
 
-Load this before drafting. These are the failure modes that separate strong role output from weak role output — check your draft against each.
+Load this before drafting. These are the failure modes that separate strong role output from weak role output. check your draft against each.
 
 
 ### 1. Metric without definition
-**Symptom**: a metric cited without its precise definition — which events, what time window, deduplication rules, filters.
+**Symptom**: a metric cited without its precise definition. which events, what time window, deduplication rules, filters.
 **Why it fails**: two teams compute "active users" differently. Decisions rest on numbers nobody can reproduce.
 **Counter-move**: name the metric and its SQL-level or event-level definition before any number. Version the definition.
 
 ### 2. Vanity over outcome
-**Symptom**: reports lead with impressions, pageviews, clicks — activity disconnected from whether users got value.
+**Symptom**: reports lead with impressions, pageviews, clicks. activity disconnected from whether users got value.
 **Why it fails**: rewards teams for moving activity numbers while outcomes stagnate.
 **Counter-move**: tie every vanity metric to an outcome metric. Report both. Lead with the outcome.
 
 ### 3. Ignoring data quality
 **Symptom**: analysis assumes the underlying events fire correctly, are deduped, and have consistent schemas.
 **Why it fails**: real pipelines drop, duplicate, and malform events. Analysis without QA produces confident wrong numbers.
-**Counter-move**: run sanity checks — row counts, null rates, distribution shape, schema checks — before analysis. Report data quality alongside findings.
+**Counter-move**: run sanity checks. row counts, null rates, distribution shape, schema checks. before analysis. Report data quality alongside findings.
 
 ### 4. Correlation as causation
 **Symptom**: "users who did X had higher retention" presented as a reason to make everyone do X.

package/skills/roles/data-analyst.product-intelligence.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-analyst.product-intelligence.md — Anti-pattern guidance for the Data-analyst.product-intelligence (product intelligence) role.
+skills/roles/data-analyst.product-intelligence.md. Anti-pattern guidance for the Data-analyst.product-intelligence (product intelligence) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-analyst.product-intelligence (product intelligence) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-analyst, cx-product-manager.
 role: data-analyst.product-intelligence
 applies_to: [cx-data-analyst, cx-product-manager]
 inherits: data-analyst
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Product Intelligence Analyst Overlay
 
@@ -28,7 +30,7 @@ Additional failure modes on top of the data-analyst core.
 ### 3. Evidence store ignored
 **Symptom**: new briefs are written without checking prior Product Intelligence artifacts.
 **Why it fails**: teams rediscover the same signal and lose longitudinal context.
-**Counter-move**: query `.cx/product-intel`, `docs/prd`, and `docs/meta-prd` through hybrid search before drafting.
+**Counter-move**: query `.cx/knowledge`, `docs/prd`, and `docs/meta-prd` through hybrid search before drafting.
 
 ## Self-check before shipping
 - [ ] Evidence count, confidence, and counter-evidence are explicit

package/skills/roles/data-analyst.product.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-analyst.product.md — Anti-pattern guidance for the Data-analyst.product (product) role.
+skills/roles/data-analyst.product.md. Anti-pattern guidance for the Data-analyst.product (product) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-analyst.product (product) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-analyst.
 role: data-analyst.product
 applies_to: [cx-data-analyst]
 inherits: data-analyst
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Product Analytics Overlay
 

package/skills/roles/data-analyst.telemetry.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-analyst.telemetry.md — Anti-pattern guidance for the Data-analyst.telemetry (telemetry) role.
+skills/roles/data-analyst.telemetry.md. Anti-pattern guidance for the Data-analyst.telemetry (telemetry) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-analyst.telemetry (telemetry) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-analyst, cx-sre.
 role: data-analyst.telemetry
 applies_to: [cx-data-analyst, cx-sre]
 inherits: data-analyst
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Telemetry Analyst Overlay
 

package/skills/roles/data-engineer.pipeline.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-engineer.pipeline.md — Anti-pattern guidance for the Data-engineer.pipeline (pipeline) role.
+skills/roles/data-engineer.pipeline.md. Anti-pattern guidance for the Data-engineer.pipeline (pipeline) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-engineer.pipeline (pipeline) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-engineer.
 role: data-engineer.pipeline
 applies_to: [cx-data-engineer]
 inherits: engineer.data
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Data Pipeline Engineer Overlay
 

package/skills/roles/data-engineer.vector-retrieval.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-engineer.vector-retrieval.md — Anti-pattern guidance for the Data-engineer.vector-retrieval (vector retrieval) role.
+skills/roles/data-engineer.vector-retrieval.md. Anti-pattern guidance for the Data-engineer.vector-retrieval (vector retrieval) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-engineer.vector-retrieval (vector retrieval) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-engineer, cx-ai-engineer.
 role: data-engineer.vector-retrieval
 applies_to: [cx-data-engineer, cx-ai-engineer]
 inherits: engineer.data
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Vector Retrieval Engineer Overlay
 

package/skills/roles/data-engineer.warehouse.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/data-engineer.warehouse.md — Anti-pattern guidance for the Data-engineer.warehouse (warehouse) role.
+skills/roles/data-engineer.warehouse.md. Anti-pattern guidance for the Data-engineer.warehouse (warehouse) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the data-engineer.warehouse (warehouse) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-data-engineer.
 role: data-engineer.warehouse
 applies_to: [cx-data-engineer]
 inherits: engineer.data
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Warehouse Engineer Overlay
 

package/skills/roles/debugger.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/debugger.md — Anti-pattern guidance for the Debugger role.
+skills/roles/debugger.md. Anti-pattern guidance for the Debugger role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the debugger domain and counter-moves to avoid them.
@@ -9,11 +9,13 @@ Applies to: cx-debugger.
 role: debugger
 applies_to: [cx-debugger]
 inherits: null
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
-# Debugger — Role guidance
+# Debugger. Role guidance
 
-Load this before drafting. These are the failure modes that separate strong role output from weak role output — check your draft against each.
+Load this before drafting. These are the failure modes that separate strong role output from weak role output. check your draft against each.
 
 
 ### 1. Fixing the symptom
@@ -63,6 +65,6 @@ Load this before drafting. These are the failure modes that separate strong role
 - [ ] Failure reproduced locally and reproduction preserved as a test
 - [ ] No speculative logs, retries, or sleeps in the fix
 - [ ] Earliest anomaly in the log is the starting point
-- [ ] Diff is narrow — fix only, no drive-bys
+- [ ] Diff is narrow. fix only, no drive-bys
 - [ ] Intermittent failures investigated, not shelved
 - [ ] Regression test added alongside the fix

package/skills/roles/designer.accessibility.md

@@ -1,5 +1,5 @@
 <!--
-skills/roles/designer.accessibility.md — Anti-pattern guidance for the Designer.accessibility (accessibility) role.
+skills/roles/designer.accessibility.md. Anti-pattern guidance for the Designer.accessibility (accessibility) role.
 
 Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
 Covers common failure modes for the designer.accessibility (accessibility) domain and counter-moves to avoid them.
@@ -9,7 +9,9 @@ Applies to: cx-accessibility.
 role: designer.accessibility
 applies_to: [cx-accessibility]
 inherits: designer
-version: 1
+version: 2
+profiles: [rnd]
+cap: 1
 ---
 # Accessibility Overlay