@geraldmaron/construct 1.0.0

package/skills/roles/operator.release.md

@@ -0,0 +1,43 @@
+<!--
+skills/roles/operator.release.md — Anti-pattern guidance for the Operator.release (release) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the operator.release (release) domain and counter-moves to avoid them.
+Applies to: cx-release-manager.
+-->
+---
+role: operator.release
+applies_to: [cx-release-manager]
+inherits: operator
+version: 1
+---
+# Release Manager Overlay
+
+Additional failure modes on top of the operator core.
+
+
+### 1. Big-bang releases
+**Symptom**: shipping N weeks of changes behind one deploy, one feature flag, one migration.
+**Why it fails**: when something breaks, you don't know which change caused it; rollback reverses everything.
+**Counter-move**: ship in the smallest deployable increment. Feature-flag independently.
+
+### 2. No rollback path
+**Symptom**: a migration, schema change, or config flip that can't be undone in under 15 minutes.
+**Why it fails**: the fix-forward pressure during an incident drives more damage.
+**Counter-move**: for every release, document the rollback command or procedure. Test it before production.
+
+### 3. Release notes after the fact
+**Symptom**: writing the changelog the day of release, or later.
+**Why it fails**: details are forgotten; breaking changes slip past users; stakeholder comms are reactive.
+**Counter-move**: changelog entries land with the code change, not at release. Release compiles from committed entries.
+
+### 4. No rollout monitoring window
+**Symptom**: pushing to production and moving on to the next task.
+**Why it fails**: regressions show up 30–60 minutes in; if nobody is watching, they compound.
+**Counter-move**: define the post-release watch window (metrics + duration) before pushing. Hold the release until it's clean.
+
+## Self-check before shipping
+- [ ] Release is the smallest deployable increment
+- [ ] Rollback path documented and tested
+- [ ] Core release-facing docs landed with code and match shipped behavior
+- [ ] Post-release watch window defined and staffed

package/skills/roles/operator.sre.md

@@ -0,0 +1,43 @@
+<!--
+skills/roles/operator.sre.md — Anti-pattern guidance for the Operator.sre (sre) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the operator.sre (sre) domain and counter-moves to avoid them.
+Applies to: cx-sre.
+-->
+---
+role: operator.sre
+applies_to: [cx-sre]
+inherits: operator
+version: 1
+---
+# SRE Overlay
+
+Additional failure modes on top of the operator core.
+
+
+### 1. Alerts without playbooks
+**Symptom**: an alert page triggers but has no linked runbook or known response.
+**Why it fails**: oncall wakes, fumbles, escalates. Mean time to recovery balloons.
+**Counter-move**: every alert links to a runbook with symptoms, checks, and remediation steps.
+
+### 2. SLOs without error budgets
+**Symptom**: publishing an SLO (e.g., 99.9% availability) with no policy for what happens when it's breached.
+**Why it fails**: the SLO becomes decorative; feature work continues to burn reliability.
+**Counter-move**: define the error budget policy up front — what freezes, who's notified, when it resumes.
+
+### 3. Dashboards of everything
+**Symptom**: 40-panel dashboards covering every metric the team could expose.
+**Why it fails**: during an incident, nobody can find the signal. Cognitive load blocks response.
+**Counter-move**: build incident-shaped dashboards: one per symptom class, with the minimum signals to triage.
+
+### 4. Post-mortems without corrective actions
+**Symptom**: writing a thorough timeline and "5 whys" with no tracked owner or deadline for fixes.
+**Why it fails**: the same incident repeats. Teams lose trust in the process.
+**Counter-move**: every corrective action has an owner, a ticket, and a target date. Review completion in the next monthly.
+
+## Self-check before shipping
+- [ ] Every alert links to a runbook
+- [ ] SLOs have an explicit error-budget policy
+- [ ] Dashboards are incident-shaped, not metric-dumps
+- [ ] Post-mortem actions are owned and dated

package/skills/roles/orchestrator.md

@@ -0,0 +1,66 @@
+<!--
+skills/roles/orchestrator.md — Anti-pattern guidance for the Orchestrator role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the orchestrator domain and counter-moves to avoid them.
+Applies to: cx-orchestrator.
+-->
+---
+role: orchestrator
+applies_to: [cx-orchestrator]
+inherits: null
+version: 1
+---
+# Orchestrator — Role guidance
+
+Use this as a fast dispatch checklist before producing orchestration output.
+
+
+1. **Dispatching before classifying**
+   - Symptom: every request becomes multi-agent work.
+   - Counter: classify first, then choose the smallest adequate path.
+
+2. **Too many perspectives**
+   - Symptom: multiple specialists repeat the same lens.
+   - Counter: dispatch only agents whose priors differ materially.
+
+3. **Routing around blockers**
+   - Symptom: BLOCKED or NEEDS_MAIN_INPUT gets hidden by another handoff.
+   - Counter: surface the blocker plainly and ask from the main session.
+
+4. **Ceremony over outcome**
+   - Symptom: every phase runs even when it adds no signal.
+   - Counter: name the phase output; skip empty phases with a reason.
+
+5. **Rubber-stamp challenge**
+   - Symptom: challenge returns no critical issues because it barely tested the plan.
+   - Counter: rerun with sharper constraints when risk is non-trivial.
+
+6. **Losing the ask**
+   - Symptom: specialists optimize a different problem.
+   - Counter: carry the original request through every handoff and final check.
+
+7. **Skipping quality gates**
+   - Symptom: "simple" implementation ships without review or tests.
+   - Counter: simple changes still get verification; the gate just runs faster.
+
+8. **Exposing internals**
+   - Symptom: final output says what each specialist said.
+   - Counter: synthesize outcomes in Construct's voice.
+
+9. **Ruminating instead of acting**
+   - Symptom: repeated reasoning turns without a read, lookup, dispatch, or user answer.
+   - Counter: after two passes, dispatch, look up evidence, or ask.
+
+10. **Bulk reading before routing**
+    - Symptom: large reads just to decide who should work.
+    - Counter: probe with search, glob, or small reads first.
+
+## Ship Check
+
+- Request classified.
+- Smallest adequate path selected.
+- Handoffs have distinct ownership.
+- Blockers and user questions surfaced.
+- Original ask still matches final output.
+- Verification evidence exists for implementation work.

package/skills/roles/product-manager.ai-product.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/product-manager.ai-product.md — Anti-pattern guidance for the Product-manager.ai-product (ai product) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.ai-product (ai product) domain and counter-moves to avoid them.
+Applies to: cx-product-manager.
+-->
+---
+role: product-manager.ai-product
+applies_to: [cx-product-manager]
+inherits: product-manager
+version: 1
+---
+# AI Product PM Overlay
+
+Additional failure modes on top of the product-manager core.
+
+### 1. Demo behavior mistaken for product behavior
+**Symptom**: the PRD describes the happy-path model output but not variance, refusal, hallucination, or tool failure.
+**Why it fails**: AI products fail at the distribution edges, not in the demo prompt.
+**Counter-move**: define expected behavior, unacceptable behavior, fallback behavior, and review thresholds.
+
+### 2. No evaluation loop
+**Symptom**: quality is described subjectively, with no dataset, rubric, trace, or regression check.
+**Why it fails**: model and prompt changes silently alter product behavior.
+**Counter-move**: require eval fixtures, scoring criteria, trace capture, and promotion gates.
+
+### 3. Human trust treated as UI copy
+**Symptom**: the PRD says users should trust the system but does not define evidence, citations, control, or correction paths.
+**Why it fails**: users need to understand when to rely on the system and how to recover when it is wrong.
+**Counter-move**: specify grounding, explainability, review controls, feedback capture, and correction workflows.
+
+## Self-check before shipping
+- [ ] Expected, unacceptable, and fallback behaviors are defined
+- [ ] Evaluation dataset, rubric, and promotion gate are specified
+- [ ] Traceability and correction paths are product requirements
+- [ ] Human review boundaries are explicit

package/skills/roles/product-manager.business-strategy.md

@@ -0,0 +1,43 @@
+<!--
+skills/roles/product-manager.business-strategy.md — Anti-pattern guidance for the Product-manager.business-strategy (business strategy) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.business-strategy (business strategy) domain and counter-moves to avoid them.
+Applies to: cx-business-strategist.
+-->
+---
+role: product-manager.business-strategy
+applies_to: [cx-business-strategist]
+inherits: product-manager
+version: 1
+---
+# Business Strategy Overlay
+
+Additional failure modes on top of the product-manager core.
+
+
+### 1. Strategy as feature list
+**Symptom**: a "strategy" doc that reads as a roadmap with no framing of why this over other paths.
+**Why it fails**: execution goes fine but the company loses to a competitor that picked a different axis.
+**Counter-move**: state the bet, the alternative bets explicitly rejected, and what would have to be true for each.
+
+### 2. No theory of the market
+**Symptom**: decisions made without a stated view of the market shape, buyer, or competitive moat.
+**Why it fails**: tactics disconnect from positioning; marketing, pricing, and product drift apart.
+**Counter-move**: write the one-paragraph market thesis. Every strategy decision links back to it or challenges it.
+
+### 3. Strategy without a kill criterion
+**Symptom**: a bet is made with no definition of what would falsify it.
+**Why it fails**: bad bets survive longer than they should; capital and focus are wasted.
+**Counter-move**: declare the leading indicator and the threshold at which the strategy is revisited.
+
+### 4. Comparing to features, not to business models
+**Symptom**: competitive analysis that maps feature parity without examining how the competitor makes money.
+**Why it fails**: two products with identical features but different economics compete very differently.
+**Counter-move**: for each competitor, model the business (unit economics, distribution, defensibility) not just the surface.
+
+## Self-check before shipping
+- [ ] Rejected alternatives stated
+- [ ] Market thesis explicit
+- [ ] Falsification criterion and revisit threshold declared
+- [ ] Competitive analysis covers economics, not just features

package/skills/roles/product-manager.enterprise.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/product-manager.enterprise.md — Anti-pattern guidance for the Product-manager.enterprise (enterprise) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.enterprise (enterprise) domain and counter-moves to avoid them.
+Applies to: cx-product-manager.
+-->
+---
+role: product-manager.enterprise
+applies_to: [cx-product-manager]
+inherits: product-manager
+version: 1
+---
+# Enterprise PM Overlay
+
+Additional failure modes on top of the product-manager core.
+
+### 1. Buyer and user collapsed
+**Symptom**: the same persona is treated as evaluator, buyer, admin, and daily user.
+**Why it fails**: enterprise adoption fails when procurement, security, admin, and end-user needs diverge.
+**Counter-move**: separate buyer, evaluator, admin, and practitioner requirements.
+
+### 2. Approval path ignored
+**Symptom**: the PRD explains why users want the feature but not what blocks the account from adopting it.
+**Why it fails**: security review, compliance, data residency, procurement, and rollout controls can be the real product requirement.
+**Counter-move**: include adoption blockers and the evidence needed to clear them.
+
+### 3. Rollout treated as launch day
+**Symptom**: requirements stop at feature availability.
+**Why it fails**: enterprise customers need staged rollout, policy controls, audit logs, documentation, support, and reversibility.
+**Counter-move**: specify rollout controls, admin defaults, auditability, enablement, and rollback behavior.
+
+## Self-check before shipping
+- [ ] Buyer, admin, evaluator, and user needs are separated
+- [ ] Security, compliance, procurement, and rollout blockers are named
+- [ ] Audit, policy, and rollback requirements are explicit
+- [ ] Customer evidence maps to account-level adoption risk

package/skills/roles/product-manager.growth.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/product-manager.growth.md — Anti-pattern guidance for the Product-manager.growth (growth) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.growth (growth) domain and counter-moves to avoid them.
+Applies to: cx-product-manager, cx-business-strategist.
+-->
+---
+role: product-manager.growth
+applies_to: [cx-product-manager, cx-business-strategist]
+inherits: product-manager
+version: 1
+---
+# Growth PM Overlay
+
+Additional failure modes on top of the product-manager core.
+
+### 1. Metric movement without user value
+**Symptom**: the doc optimizes activation, conversion, or engagement without proving the user is better off.
+**Why it fails**: growth work can create short-term movement while eroding trust or retention.
+**Counter-move**: pair each growth metric with the user value it must preserve.
+
+### 2. Funnel step isolated from lifecycle
+**Symptom**: requirements focus on one funnel step without considering acquisition source, user intent, activation quality, retention, or expansion.
+**Why it fails**: local optimization shifts the problem downstream.
+**Counter-move**: map the lifecycle and name the guardrail metrics.
+
+### 3. Packaging assumptions hidden
+**Symptom**: pricing, packaging, entitlement, and plan boundaries are left as "business decision later."
+**Why it fails**: growth features often depend on the commercial motion.
+**Counter-move**: state packaging assumptions and what evidence would change them.
+
+## Self-check before shipping
+- [ ] Growth metric is paired with user-value guardrail
+- [ ] Lifecycle impact is mapped beyond the local funnel step
+- [ ] Pricing, packaging, and entitlement assumptions are explicit
+- [ ] Experiment design includes success and stop thresholds

package/skills/roles/product-manager.md

@@ -0,0 +1,67 @@
+<!--
+skills/roles/product-manager.md — Anti-pattern guidance for the Product-manager role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager domain and counter-moves to avoid them.
+Applies to: cx-product-manager, cx-business-strategist.
+-->
+---
+role: product-manager
+applies_to: [cx-product-manager, cx-business-strategist]
+inherits: null
+version: 1
+---
+# Product Manager — 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.
+
+
+### 1. Solution in the problem statement
+**Symptom**: the problem is phrased as a missing feature ("users need a share button") instead of a user pain ("users cannot get their output to a collaborator without leaving the product").
+**Why it fails**: anchors the team on one implementation before alternatives are considered; forecloses cheaper or better solutions.
+**Counter-move**: write the problem as a user-observable pain with evidence. Save solutions for the proposal section.
+
+### 2. Unfalsifiable acceptance criteria
+**Symptom**: criteria use words like "intuitive", "fast", "robust", "delightful" with no numeric or observable threshold.
+**Why it fails**: neither engineering nor QA can decide when the work is done; reviews devolve into taste arguments.
+**Counter-move**: rewrite each criterion as a condition a stranger could check without asking the author.
+
+### 3. Vanity metrics
+**Symptom**: success measured by clicks, signups, page views, or "engagement" without connection to the user outcome.
+**Why it fails**: rewards surface activity that looks like progress while the underlying problem persists.
+**Counter-move**: name the user or business outcome. Pick a metric whose movement requires that outcome to occur.
+
+### 4. Missing user evidence
+**Symptom**: the PRD cites no tickets, interviews, session recordings, or data. The source is "stakeholder said".
+**Why it fails**: stakeholders generalize from one loud user; the team ends up building for the loudest, not the representative.
+**Counter-move**: cite at least two independent evidence sources. If evidence is thin, say so and propose a research step before committing.
+
+### 5. Unbounded scope
+**Symptom**: "goals" and "non-goals" are both empty, or non-goals is missing entirely.
+**Why it fails**: every reviewer adds to the scope; the doc becomes a wishlist and the project misses its date.
+**Counter-move**: force yourself to write three explicit non-goals. If you cannot, the scope is not thought through yet.
+
+### 6. Stakeholder bias over user evidence
+**Symptom**: requirements trace to an executive's preference, not to user data.
+**Why it fails**: builds the wrong thing confidently. Eventually the executive moves on; the feature stays.
+**Counter-move**: separate what the business wants from what the user needs. Name both. Explain how they reconcile.
+
+### 7. Hiding the tradeoff
+**Symptom**: the PRD reads as if the proposal has only upside.
+**Why it fails**: loses credibility with engineering and leadership; tradeoffs surface in implementation as surprises.
+**Counter-move**: write the strongest case against your own proposal. If you cannot, you have not understood it.
+
+### 8. Deadlines without constraints
+**Symptom**: a ship date with no mention of what could slip, what is fixed, and who is on the team.
+**Why it fails**: the deadline becomes a wish. Scope balloons to fill available time and then the date slips anyway.
+**Counter-move**: name at least one of: fixed scope, fixed quality bar, fixed team size. Everything else is the flex.
+
+## Self-check before shipping
+
+- [ ] Problem describes pain, not a missing feature
+- [ ] Acceptance criteria are observable by a stranger
+- [ ] Success metric is a user or business outcome, not activity
+- [ ] At least two independent evidence sources cited
+- [ ] Non-goals section has a meaningful number of items for scope control
+- [ ] The strongest counter-argument is named and addressed
+- [ ] Tradeoff between scope, date, and quality is explicit

package/skills/roles/product-manager.platform.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/product-manager.platform.md — Anti-pattern guidance for the Product-manager.platform (platform) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.platform (platform) domain and counter-moves to avoid them.
+Applies to: cx-product-manager.
+-->
+---
+role: product-manager.platform
+applies_to: [cx-product-manager]
+inherits: product-manager
+version: 1
+---
+# Platform PM Overlay
+
+Additional failure modes on top of the product-manager core.
+
+### 1. Treating developers as one persona
+**Symptom**: "developer" is used as the user for APIs, SDKs, admin surfaces, and operational workflows.
+**Why it fails**: platform builders, application developers, security admins, and operators have different incentives and failure modes.
+**Counter-move**: name the platform actor precisely and describe the system boundary they own.
+
+### 2. Contract changes without migration
+**Symptom**: the PRD introduces API, schema, permission, or configuration changes without compatibility and migration requirements.
+**Why it fails**: platform work breaks downstream systems even when the feature itself works.
+**Counter-move**: include versioning, backwards compatibility, rollout, migration, and deprecation behavior.
+
+### 3. Operational burden omitted
+**Symptom**: requirements describe setup but not monitoring, failure recovery, supportability, or admin controls.
+**Why it fails**: platform capabilities become toil generators after launch.
+**Counter-move**: add observability, auditability, rate limits, fallback behavior, and support diagnostics as product requirements.
+
+## Self-check before shipping
+- [ ] Platform actor and owned boundary are explicit
+- [ ] Compatibility, migration, and deprecation are covered
+- [ ] Admin, audit, observability, and failure recovery requirements exist
+- [ ] Integration contracts are testable

package/skills/roles/product-manager.product.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/product-manager.product.md — Anti-pattern guidance for the Product-manager.product (product) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the product-manager.product (product) domain and counter-moves to avoid them.
+Applies to: cx-product-manager.
+-->
+---
+role: product-manager.product
+applies_to: [cx-product-manager]
+inherits: product-manager
+version: 1
+---
+# Product PM Overlay
+
+Additional failure modes on top of the product-manager core.
+
+### 1. Persona theater
+**Symptom**: the document names a generic user such as "admin" or "customer" without describing the workflow, pressure, or context they are in.
+**Why it fails**: generic personas cannot drive product tradeoffs; every stakeholder imagines a different user.
+**Counter-move**: anchor the persona in a concrete job, trigger, current workaround, and success condition.
+
+### 2. Workflow gaps hidden behind feature language
+**Symptom**: requirements describe screens or features but skip the before, during, and after steps of the user journey.
+**Why it fails**: engineering can ship the feature while the actual workflow still breaks at handoff points.
+**Counter-move**: write the end-to-end user workflow and mark where the new capability changes behavior.
+
+### 3. Adoption assumed
+**Symptom**: success depends on users discovering, trusting, and repeatedly using the feature, but the PRD says nothing about adoption.
+**Why it fails**: usable features still fail when activation, migration, onboarding, or trust are unresolved.
+**Counter-move**: include the first-use path, repeat-use trigger, and measurable adoption signal.
+
+## Self-check before shipping
+- [ ] Persona includes workflow context, not just role title
+- [ ] End-to-end user journey is explicit
+- [ ] Adoption path and repeat-use trigger are named
+- [ ] Success metric measures user outcome, not shipped scope

package/skills/roles/qa.ai-eval.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/qa.ai-eval.md — Anti-pattern guidance for the Qa.ai-eval (ai eval) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the qa.ai-eval (ai eval) domain and counter-moves to avoid them.
+Applies to: cx-qa, cx-test-automation, cx-evaluator.
+-->
+---
+role: qa.ai-eval
+applies_to: [cx-qa, cx-test-automation, cx-evaluator]
+inherits: qa
+version: 1
+---
+# AI Eval QA Overlay
+
+Additional failure modes on top of the QA core.
+
+### 1. Evaluating only good examples
+**Symptom**: evals prove the model works on ideal prompts.
+**Why it fails**: production failures come from ambiguity, missing context, prompt injection, and tool errors.
+**Counter-move**: include adversarial, ambiguous, stale-context, and tool-failure cases.
+
+### 2. Score without explanation
+**Symptom**: eval output is a number with no rubric or failure taxonomy.
+**Why it fails**: teams cannot improve what they cannot classify.
+**Counter-move**: define rubrics, labels, thresholds, and examples for each score.
+
+### 3. No regression baseline
+**Symptom**: prompt or model changes are judged by current output only.
+**Why it fails**: improvements in one class hide regressions in another.
+**Counter-move**: keep golden traces, compare against baseline, and require promotion gates.
+
+## Self-check before shipping
+- [ ] Eval set includes negative and adversarial cases
+- [ ] Rubric, thresholds, and failure taxonomy are defined
+- [ ] Golden traces and baseline comparison exist
+- [ ] Tool-call and retrieval failures are tested

package/skills/roles/qa.api-contract.md

@@ -0,0 +1,37 @@
+<!--
+skills/roles/qa.api-contract.md — Anti-pattern guidance for the Qa.api-contract (api contract) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the qa.api-contract (api contract) domain and counter-moves to avoid them.
+Applies to: cx-qa, cx-test-automation.
+-->
+---
+role: qa.api-contract
+applies_to: [cx-qa, cx-test-automation]
+inherits: qa
+version: 1
+---
+# API Contract QA Overlay
+
+Additional failure modes on top of the QA core.
+
+### 1. Testing only the current client
+**Symptom**: tests pass through one frontend but do not validate the API contract.
+**Why it fails**: other clients, SDKs, and integrations break without local test failure.
+**Counter-move**: verify request/response schemas, status codes, errors, compatibility, and deprecation behavior.
+
+### 2. Happy-path payload bias
+**Symptom**: fixtures contain ideal input and complete data.
+**Why it fails**: contracts fail at boundaries: missing fields, unknown enum values, pagination, rate limits, and auth states.
+**Counter-move**: add negative, boundary, and compatibility cases.
+
+### 3. No consumer perspective
+**Symptom**: tests validate implementation details but not consumer expectations.
+**Why it fails**: provider changes can be technically valid and still break real consumers.
+**Counter-move**: add consumer-driven contract tests where the API is external or shared.
+
+## Self-check before shipping
+- [ ] Schemas, status codes, error bodies, and auth states are verified
+- [ ] Compatibility and deprecation behavior have tests
+- [ ] Boundary payloads, pagination, and rate limits are covered
+- [ ] Consumer expectations are represented

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

@@ -0,0 +1,37 @@
+<!--
+skills/roles/qa.data-pipeline.md — Anti-pattern guidance for the Qa.data-pipeline (data pipeline) role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the qa.data-pipeline (data pipeline) domain and counter-moves to avoid them.
+Applies to: cx-qa, cx-test-automation.
+-->
+---
+role: qa.data-pipeline
+applies_to: [cx-qa, cx-test-automation]
+inherits: qa
+version: 1
+---
+# Data Pipeline QA Overlay
+
+Additional failure modes on top of the QA core.
+
+### 1. Testing records, not invariants
+**Symptom**: tests compare one fixture output but do not assert freshness, uniqueness, completeness, or lineage.
+**Why it fails**: data defects are often statistically small and operationally severe.
+**Counter-move**: define quality checks for schema, nullability, uniqueness, freshness, volume, and referential integrity.
+
+### 2. Ignoring reruns
+**Symptom**: tests only verify first-run success.
+**Why it fails**: real pipelines rerun after failures, backfills, and partial outages.
+**Counter-move**: test idempotency, replay, backfill, and partial failure recovery.
+
+### 3. No alert validation
+**Symptom**: pipeline tests prove output exists but not that failures page the right owner.
+**Why it fails**: silent data failures become business decisions made from bad data.
+**Counter-move**: verify alerts, runbooks, and ownership for quality failures.
+
+## Self-check before shipping
+- [ ] Data quality invariants are explicit and executable
+- [ ] Idempotency, replay, and backfill paths are tested
+- [ ] Partial failures have recovery expectations
+- [ ] Alerts and runbooks are part of verification

package/skills/roles/qa.md

@@ -0,0 +1,68 @@
+<!--
+skills/roles/qa.md — Anti-pattern guidance for the Qa role.
+
+Loaded at sync time to inline role-specific failure modes into specialist agent prompts.
+Covers common failure modes for the qa domain and counter-moves to avoid them.
+Applies to: cx-qa, cx-test-automation.
+-->
+---
+role: qa
+applies_to: [cx-qa, cx-test-automation]
+inherits: null
+version: 1
+---
+# QA — 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.
+
+
+### 1. Testing the mock
+**Symptom**: the test asserts that the mock was called with the expected arguments — and that is all it asserts.
+**Why it fails**: the test passes regardless of whether the real system would. Mocks drift from the real contract silently.
+**Counter-move**: assert on observable outputs or state. Use mocks for isolation, not as the thing being tested.
+
+### 2. Coverage as proxy for quality
+**Symptom**: the bar is "80% line coverage" with no attention to whether the covered lines exercise meaningful behavior.
+**Why it fails**: coverage rises by adding trivial assertions. Real bugs live in the uncovered branches and the edge cases.
+**Counter-move**: pair line coverage with behavior coverage. For each requirement, name the test that would catch its regression.
+
+### 3. Happy path only
+**Symptom**: every test exercises the success path. Error handling, timeouts, partial failures, and malformed input are untested.
+**Why it fails**: production spends most of its time off the happy path. Untested code paths fail in the worst way.
+**Counter-move**: for every happy-path test, write at least one error-path test. Malformed input, dependency failure, timeout.
+
+### 4. Flaky test denial
+**Symptom**: intermittent failures are re-run until green and ignored.
+**Why it fails**: the flake signals a real race condition, timing assumption, or environmental dependency that will eventually cause a production incident.
+**Counter-move**: investigate every flake. Either fix the race or quarantine the test with a tracked ticket.
+
+### 5. Tests that test the implementation
+**Symptom**: the test breaks every time the implementation is refactored, even when behavior is unchanged.
+**Why it fails**: discourages refactoring. Engineers delete or weaken tests to unblock themselves.
+**Counter-move**: test through public interfaces. Assert on outcomes, not on internal call patterns.
+
+### 6. Missing regression coverage for fixes
+**Symptom**: a bug is fixed without a test that would have caught it.
+**Why it fails**: the same bug regresses in six months and nobody remembers it was a bug.
+**Counter-move**: every bug fix includes a test that fails against the broken code and passes against the fix.
+
+### 7. Golden-path E2E only
+**Symptom**: the E2E suite validates one long happy journey and nothing else.
+**Why it fails**: the suite is slow, fragile, and still leaves most integration failure modes uncovered.
+**Counter-move**: cover critical user flows with focused E2E tests. Cover component behavior at lower tiers.
+
+### 8. Shipping without exercising the change
+**Symptom**: tests pass but no one has actually used the feature as a user would.
+**Why it fails**: the tests validate assumptions; the user discovers what the assumptions missed.
+**Counter-move**: for any user-facing change, run the feature manually at least once before marking done.
+
+## Self-check before shipping
+
+- [ ] Tests assert on outcomes, not on mock call patterns
+- [ ] Each requirement has a test that would catch its regression
+- [ ] Error paths have at least one test each
+- [ ] No intermittent failures accepted; investigated or quarantined
+- [ ] Tests survive refactors that preserve behavior
+- [ ] Every bug fix has a regression test
+- [ ] E2E covers critical flows; component tests cover the rest
+- [ ] User-facing changes exercised manually before sign-off