@geraldmaron/construct 1.0.15 → 1.0.17

package/skills/exploration/repo-map.md

@@ -1,6 +1,8 @@
 ---
 name: exploration-repo-map
 description: Use this skill when entering an unfamiliar codebase, doing deep investigation work, or producing a `.cx/codebase-map.md` artifact for future sessions.
+inputs: [repo, codebase]
+artifactType: repo-map
 ---
 # Repo Exploration: Codebase Mapping Playbook
 

package/skills/exploration/tracer-bullet-method.md

@@ -1,6 +1,8 @@
 ---
 name: exploration-tracer-bullet-method
 description: Use when beginning implementation in a new system, new integration, or new architectural layer. A tracer bullet is not a prototype; it is the thinnest possible complete path through the real system.
+inputs: [codebase, system-design]
+artifactType: guidance
 ---
 # Tracer Bullet Method
 

package/skills/exploration/unknown-codebase-onboarding.md

@@ -1,6 +1,8 @@
 ---
 name: exploration-unknown-codebase-onboarding
 description: Use when entering an unfamiliar codebase for the first time, or when the task requires understanding a system you haven't touched before.
+inputs: [codebase, repo]
+artifactType: guidance
 ---
 # Unknown Codebase Onboarding
 

package/skills/frameworks/django.md

@@ -1,6 +1,8 @@
 ---
 name: frameworks-django
 description: Patterns, anti-patterns, and reference guidance for Django. Use when the task involves django.
+inputs: [code, feature-spec, repo]
+artifactType: code
 ---
 # Django
 

package/skills/frameworks/nextjs.md

@@ -1,6 +1,8 @@
 ---
 name: frameworks-nextjs
 description: Patterns, anti-patterns, and reference guidance for Next.js (App Router). Use when the task involves next.js (app router).
+inputs: [code, feature-spec, repo]
+artifactType: code
 ---
 # Next.js (App Router)
 

package/skills/frameworks/react.md

@@ -1,6 +1,8 @@
 ---
 name: frameworks-react
 description: "By default, components are **Server Components**: they run on the server, have no state, and can fetch data directly. Add `'use client'` only when you need interactivity, browser APIs, or hooks. Use when the task matches the trigger conditions described in the body."
+inputs: [code, feature-spec, repo]
+artifactType: code
 ---
 # React
 

package/skills/frameworks/spring-boot.md

@@ -1,6 +1,8 @@
 ---
 name: frameworks-spring-boot
 description: Patterns, anti-patterns, and reference guidance for Spring Boot. Use when the task involves spring boot.
+inputs: [code, feature-spec, repo]
+artifactType: code
 ---
 # Spring Boot
 

package/skills/frontend-design/accessibility.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-accessibility
 description: Target **WCAG 2.1 AA** as the minimum for any public-facing product. WCAG 2.2 AA is the current standard (published October 2023) and required by many regulatory frameworks (EU Web Accessibility Directive, ADA, Section 508). Use when the task matches the trigger conditions described in the body.
+inputs: [ui-or-component]
+artifactType: accessibility-findings
 ---
 # Accessibility (WCAG 2.2 / Inclusive Design)
 

package/skills/frontend-design/component-patterns.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-component-patterns
 description: Use this skill when designing component architecture, building design systems, or structuring reusable UI.
+inputs: [ui-or-component, design-spec]
+artifactType: ui-implementation
 ---
 # Component Patterns
 

package/skills/frontend-design/engineering.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-engineering
 description: Use this skill when working on build tooling, bundling, rendering strategies, or frontend infrastructure.
+inputs: [code, repo]
+artifactType: guidance
 ---
 # Frontend Engineering
 

package/skills/frontend-design/screen-reader-testing.md

@@ -0,0 +1,34 @@
+---
+name: frontend-design-screen-reader-testing
+description: "Use when: a UI needs to be tested with a screen reader and keyboard to verify it is actually operable non-visually, not just compliant on paper."
+inputs: [ui-or-component]
+artifactType: accessibility-findings
+---
+# Screen Reader Testing
+
+Use this skill when a UI needs to be verified as operable with a screen reader and keyboard — accessibility measured by use, not by an automated checklist.
+
+Automated scanners catch missing alt text and contrast, but they cannot tell you whether a flow is *usable* non-visually. That requires driving the interface the way a screen-reader user does: keyboard only, listening to what is announced.
+
+## Steps
+
+1. **Pick the flow, not the page.** Test a complete task (sign in, submit a form), because accessibility failures cluster at transitions and dynamic updates.
+2. **Keyboard-only first.** Unplug the mouse. Tab through: is every interactive element reachable, in a sensible order, with a visible focus indicator? Can you complete the task? Note any keyboard trap.
+3. **Screen reader pass** (VoiceOver/NVDA/Orca). For each control, confirm the announced name, role, and state match what's on screen. A button announced as "button" with no name is a failure.
+4. **Dynamic content**: trigger validation errors, loading states, toasts, modals. Confirm they are announced (live regions) and that focus moves correctly — a modal that opens without moving focus is unusable.
+5. **Forms**: confirm each field's label is associated, errors are announced and linked to the field, and required state is conveyed non-visually.
+6. **Record findings** by severity: blocker (task cannot be completed), serious (completable but confusing), minor.
+
+## Output shape
+
+```
+## Flow: <task>
+| step | issue | severity | expected |
+|---|---|---|---|
+```
+
+## Verification bar
+
+- Findings come from actually driving the flow with keyboard + screen reader, not from inspecting markup alone.
+- Each finding names the expected announced name/role/state, so the fix is unambiguous.
+- Severity reflects task impact, not rule count.

package/skills/frontend-design/state-management.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-state-management
 description: Use this skill when choosing state management tools, structuring application state, or debugging state issues.
+inputs: [ui-or-component, code]
+artifactType: guidance
 ---
 # Frontend State Management
 

package/skills/frontend-design/ui-aesthetics.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-ui-aesthetics
 description: "Use this skill when making visual design decisions: color, typography, layout, spacing, and visual hierarchy."
+inputs: [ui-or-component, design-spec]
+artifactType: ui-implementation
 ---
 # UI Aesthetics
 

package/skills/frontend-design/ux-principles.md

@@ -1,6 +1,8 @@
 ---
 name: frontend-design-ux-principles
 description: Use this skill when designing user flows, evaluating usability, or planning information architecture.
+inputs: [ui-or-component, design-spec]
+artifactType: guidance
 ---
 # UX Principles
 

package/skills/operating/change-management.md

@@ -1,6 +1,8 @@
 ---
 name: operating-change-management
 description: Use when a change needs to be categorized by reversibility, when designing rollout gates, or when the team is uncertain how much approval process a change warrants.
+inputs: [change-or-diff]
+artifactType: guidance
 ---
 # Change Management
 

package/skills/operating/incident-response.md

@@ -1,6 +1,8 @@
 ---
 name: operating-incident-response
 description: Use when an issue is active in production, when building incident process from scratch, or when reviewing postmortems for quality.
+inputs: [task-context]
+artifactType: guidance
 ---
 # Incident Response
 

package/skills/operating/oncall-rotation.md

@@ -1,6 +1,8 @@
 ---
 name: operating-oncall-rotation
 description: Use when setting up on-call, reviewing its health, or handling an escalation during a rotation.
+inputs: [task-context]
+artifactType: guidance
 ---
 # On-Call Rotation
 

package/skills/operating/orchestration-reference.md

@@ -1,6 +1,8 @@
 ---
 name: operating-orchestration-reference
 description: detailed orchestration reference loaded on demand. Use when the task matches the trigger conditions described in the body.
+inputs: [task-context]
+artifactType: guidance
 ---
 # Orchestration Reference
 

package/skills/operating/raw-data-structuring.md

@@ -0,0 +1,44 @@
+---
+name: operating-raw-data-structuring
+description: "Use when: a raw dataset (CSV, TSV, JSON export, log dump) needs to be parsed, validated, and profiled into a described, trustworthy shape before analysis."
+inputs: [raw-dataset]
+artifactType: data-profile
+---
+# Raw Data Structuring
+
+Use this skill when a raw dataset (CSV, TSV, JSON export, log dump) arrives and must be made trustworthy before anyone analyzes or charts it.
+
+Raw data lies by omission: silent type coercions, missing values encoded three different ways, duplicated rows, and columns whose meaning no one wrote down. Structure it before trusting it.
+
+## Steps
+
+1. **Identify the grain.** What does one row represent (one event, one user, one day)? State it explicitly; analysis built on the wrong grain is wrong.
+2. **Profile each column**: inferred type, null rate, distinct count, min/max or top values. Flag columns that are >50% null or all-distinct (likely an id) or single-valued (likely useless).
+3. **Detect encoding hazards**: mixed types in one column, multiple null sentinels (`""`, `NA`, `null`, `-1`), inconsistent date formats, numbers stored as strings. List each; do not silently coerce.
+4. **Check for duplicates** on the candidate key; report the duplicate rate.
+5. **Describe each column** in one line — what it means, its unit, and its source if known. Where meaning is genuinely unknown, write `meaning: unknown` rather than inventing one.
+6. **State what the data cannot answer** — questions that look answerable but aren't, given the grain or missingness.
+
+## Output shape
+
+```
+## Dataset profile
+- grain: <one row = …>
+- rows: <n> · columns: <n> · duplicate rate: <%>
+
+## Columns
+| name | type | null% | distinct | meaning |
+|---|---|---|---|---|
+
+## Hazards
+- <column>: <encoding/quality hazard>
+
+## Out of scope
+- <question the data cannot answer> — <why>
+```
+
+## Verification bar
+
+- Every reported statistic is computed from the data, not estimated.
+- Column meanings are stated only where known; unknowns are labeled `unknown`.
+- Hazards are surfaced before any downstream metric is derived.

package/skills/operating/unstructured-triage.md

@@ -0,0 +1,45 @@
+---
+name: operating-unstructured-triage
+description: "Use when: a brain-dump, rough notes, or free-form input has no clear type and needs to be structured into intents, candidate work items, and open questions before routing."
+inputs: [unstructured-text]
+artifactType: triage-summary
+---
+# Unstructured Triage
+
+Use this skill when free-form input — a brain-dump, rough notes, a stream of thoughts — arrives with no clear type and the classifier returned low confidence or `unknown`.
+
+The goal is not to force a classification. It is to extract the latent intents and candidate work items so a human (or a follow-up workflow) can decide what, if anything, to act on. Inventing structure that isn't there is the failure mode.
+
+## Steps
+
+1. **Read for intent, not form.** Separate the few actionable signals from thinking-out-loud.
+2. **Extract candidate work items** — each as a one-line `{ intent, possibleType }` where `possibleType` is your best guess at the taxonomy (bug, requirement, research, memo, …) or `unclear`.
+3. **Extract open questions and unknowns** explicitly — these are usually the point of a brain-dump.
+4. **Note what is missing** to act: a brain-dump rarely has enough to execute. Name the clarifications a human would need.
+5. **Do not assign owners or due dates** unless the text states them.
+6. **Recommend a next step**, not a commitment: "clarify X", "split into N items", or "discard — no actionable signal".
+
+## Output shape
+
+```
+## Read
+<2–4 sentence neutral summary of what this seems to be>
+
+## Candidate items
+- <intent> — possibleType: <type|unclear>
+
+## Open questions
+- <question>
+
+## To act, we'd need
+- <missing information>
+
+## Recommended next step
+<clarify | split | route to <type> | discard>
+```
+
+## Verification bar
+
+- Candidate items reflect intents actually present in the text; nothing is fabricated to look productive.
+- Confidence stays low where the input is genuinely vague — the output says so rather than manufacturing certainty.
+- No owners, dates, or decisions are asserted unless the input states them.

package/skills/quality-gates/premortem.md

@@ -0,0 +1,37 @@
+---
+name: quality-gates-premortem
+description: "Use when: a plan or design needs a premortem — imagining it has already failed and working backward to the failure modes — before committing to it."
+inputs: [plan-or-design]
+artifactType: risk-list
+---
+# Premortem
+
+Use this skill when a plan, design, or proposal needs to be stress-tested before commitment, by imagining it has already failed.
+
+A premortem inverts optimism: instead of asking "will this work?", it asserts "it's six months later and this failed — why?". Stating failure as a given frees people to name risks that politeness or momentum would otherwise suppress.
+
+## Steps
+
+1. **Set the frame**: "It is <horizon> from now. This shipped and failed badly. Write the post-mortem headline."
+2. **Generate failure modes** independently across categories: technical (it didn't work), adoption (no one used it), operational (it broke in prod), people (the owner left), external (a dependency/market moved).
+3. **For each failure mode**, state the mechanism (how it leads to failure), a rough likelihood (low/med/high), and the earliest observable signal that it is happening.
+4. **Separate the fatal from the survivable.** A premortem's value is finding the one or two failures that would be unrecoverable.
+5. **Propose a cheap probe or guardrail** for each high-likelihood or fatal mode — something that would surface it early.
+6. **Name the assumption** each fatal failure depends on, and whether it has been validated.
+
+## Output shape
+
+```
+## Failure modes
+| failure | category | likelihood | earliest signal | guardrail |
+|---|---|---|---|---|
+
+## Fatal (unrecoverable) modes
+- <failure> — depends on assumption: <assumption> (validated? yes/no)
+```
+
+## Verification bar
+
+- Failure modes are concrete mechanisms, not vague worries ("it might be hard").
+- Each fatal mode names the specific assumption it rests on.
+- Likelihoods are stated as judgments, labeled as such — not presented as data.

package/skills/quality-gates/review-work.md

@@ -1,6 +1,8 @@
 ---
 name: quality-gates-review-work
 description: Use this methodology when a change needs rigorous pre-merge validation. Five independent review roles run concurrently. All must pass.
+inputs: [change-or-diff, acceptance-criteria]
+artifactType: review-report
 ---
 # Parallel Adversarial Review
 

package/skills/quality-gates/verify-change.md

@@ -1,6 +1,8 @@
 ---
 name: quality-gates-verify-change
 description: Use this skill to analyze the impact of code changes and verify documentation and tests are in sync.
+inputs: [change-or-diff]
+artifactType: review-report
 ---
 # Verify Change
 

package/skills/quality-gates/verify-module.md

@@ -1,6 +1,8 @@
 ---
 name: quality-gates-verify-module
 description: Use this skill to check that a module or package is structurally complete and ready for use.
+inputs: [change-or-diff]
+artifactType: review-report
 ---
 # Verify Module
 

package/skills/quality-gates/verify-quality.md

@@ -1,6 +1,8 @@
 ---
 name: quality-gates-verify-quality
 description: Use this skill to check code quality, complexity, and maintainability after changes.
+inputs: [change-or-diff]
+artifactType: review-report
 ---
 # Verify Quality
 

package/skills/quality-gates/verify-security.md

@@ -1,6 +1,8 @@
 ---
 name: quality-gates-verify-security
 description: Use this skill to scan code for security vulnerabilities before commits or releases.
+inputs: [change-or-diff]
+artifactType: vulnerability-report
 ---
 # Verify Security
 

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

@@ -1,6 +1,8 @@
 ---
 name: roles-architect-ai-systems
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect — AI Systems role. Use when reviewing or generating work by cx-architect, or when an agent is acting in the Architect — AI Systems role.
+inputs: [architecture-design, adr]
+artifactType: role-guidance
 role: architect.ai-systems
 applies_to:
   - cx-architect

package/skills/roles/architect.data.md

@@ -1,6 +1,8 @@
 ---
 name: roles-architect-data
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect — Data role. Use when reviewing or generating work by cx-architect, or when an agent is acting in the Architect — Data role.
+inputs: [data-model, architecture-design]
+artifactType: role-guidance
 role: architect.data
 applies_to:
   - cx-architect

package/skills/roles/architect.enterprise.md

@@ -1,6 +1,8 @@
 ---
 name: roles-architect-enterprise
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect — Enterprise role. Use when reviewing or generating work by cx-architect, or when an agent is acting in the Architect — Enterprise role.
+inputs: [architecture-design, compliance-requirements]
+artifactType: role-guidance
 role: architect.enterprise
 applies_to:
   - cx-architect

package/skills/roles/architect.integration.md

@@ -1,6 +1,8 @@
 ---
 name: roles-architect-integration
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect — Integration role. Use when reviewing or generating work by cx-architect, or when an agent is acting in the Architect — Integration role.
+inputs: [integration-design, sequence-diagram]
+artifactType: role-guidance
 role: architect.integration
 applies_to:
   - cx-architect

package/skills/roles/architect.md

@@ -1,6 +1,8 @@
 ---
 name: roles-architect
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect role. Use when reviewing or generating work by cx-architect, cx-rd-lead, or when an agent is acting in the Architect role.
+inputs: [architecture-design, requirements]
+artifactType: role-guidance
 role: architect
 applies_to:
   - cx-architect

package/skills/roles/architect.platform.md

@@ -1,6 +1,8 @@
 ---
 name: roles-architect-platform
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Architect — Platform role. Use when reviewing or generating work by cx-architect, or when an agent is acting in the Architect — Platform role.
+inputs: [platform-design, adr]
+artifactType: role-guidance
 role: architect.platform
 applies_to:
   - cx-architect

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-analyst-experiment
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Analyst — Experiment role. Use when reviewing or generating work by cx-data-analyst, or when an agent is acting in the Data Analyst — Experiment role.
+inputs: [experiment-plan, metrics]
+artifactType: role-guidance
 role: data-analyst.experiment
 applies_to:
   - cx-data-analyst

package/skills/roles/data-analyst.md

@@ -1,6 +1,8 @@
 ---
 name: roles-data-analyst
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Analyst role. Use when reviewing or generating work by cx-data-analyst, or when an agent is acting in the Data Analyst role.
+inputs: [dataset, metrics-analysis]
+artifactType: role-guidance
 role: data-analyst
 applies_to:
   - cx-data-analyst

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-analyst-product-intelligence
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Analyst — Product Intelligence role. Use when reviewing or generating work by cx-data-analyst, cx-product-manager, or when an agent is acting in the Data Analyst — Product Intelligence role.
+inputs: [customer-signals, telemetry]
+artifactType: role-guidance
 role: data-analyst.product-intelligence
 applies_to:
   - cx-data-analyst

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-analyst-product
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Analyst — Product role. Use when reviewing or generating work by cx-data-analyst, or when an agent is acting in the Data Analyst — Product role.
+inputs: [product-metrics, funnel-data]
+artifactType: role-guidance
 role: data-analyst.product
 applies_to:
   - cx-data-analyst

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-analyst-telemetry
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Analyst — Telemetry role. Use when reviewing or generating work by cx-data-analyst, cx-sre, or when an agent is acting in the Data Analyst — Telemetry role.
+inputs: [telemetry, metrics]
+artifactType: role-guidance
 role: data-analyst.telemetry
 applies_to:
   - cx-data-analyst

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-engineer-pipeline
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Engineer — Pipeline role. Use when reviewing or generating work by cx-data-engineer, or when an agent is acting in the Data Engineer — Pipeline role.
+inputs: [pipeline-design, data-contract]
+artifactType: role-guidance
 role: data-engineer.pipeline
 applies_to:
   - cx-data-engineer

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-engineer-vector-retrieval
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Engineer — Vector Retrieval role. Use when reviewing or generating work by cx-data-engineer, cx-ai-engineer, or when an agent is acting in the Data Engineer — Vector Retrieval role.
+inputs: [retrieval-design, embeddings]
+artifactType: role-guidance
 role: data-engineer.vector-retrieval
 applies_to:
   - cx-data-engineer

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

@@ -1,6 +1,8 @@
 ---
 name: roles-data-engineer-warehouse
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Data Engineer — Warehouse role. Use when reviewing or generating work by cx-data-engineer, or when an agent is acting in the Data Engineer — Warehouse role.
+inputs: [warehouse-model, metrics]
+artifactType: role-guidance
 role: data-engineer.warehouse
 applies_to:
   - cx-data-engineer

package/skills/roles/debugger.md

@@ -1,6 +1,8 @@
 ---
 name: roles-debugger
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Debugger role. Use when reviewing or generating work by cx-debugger, or when an agent is acting in the Debugger role.
+inputs: [bug-report, failure-signal]
+artifactType: role-guidance
 role: debugger
 applies_to:
   - cx-debugger

package/skills/roles/designer.accessibility.md

@@ -1,6 +1,8 @@
 ---
 name: roles-designer-accessibility
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Designer — Accessibility role. Use when reviewing or generating work by cx-accessibility, or when an agent is acting in the Designer — Accessibility role.
+inputs: [ui-design, component]
+artifactType: role-guidance
 role: designer.accessibility
 applies_to:
   - cx-accessibility

package/skills/roles/designer.md

@@ -1,6 +1,8 @@
 ---
 name: roles-designer
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Designer role. Use when reviewing or generating work by cx-designer, cx-accessibility, or when an agent is acting in the Designer role.
+inputs: [ui-design]
+artifactType: role-guidance
 role: designer
 applies_to:
   - cx-designer

package/skills/roles/engineer.ai.md

@@ -1,6 +1,8 @@
 ---
 name: roles-engineer-ai
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Engineer — AI role. Use when reviewing or generating work by cx-ai-engineer, or when an agent is acting in the Engineer — AI role.
+inputs: [code-diff, prompt]
+artifactType: role-guidance
 role: engineer.ai
 applies_to:
   - cx-ai-engineer

package/skills/roles/engineer.data.md

@@ -1,6 +1,8 @@
 ---
 name: roles-engineer-data
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Engineer — Data role. Use when reviewing or generating work by cx-data-engineer, or when an agent is acting in the Engineer — Data role.
+inputs: [code-diff, data-pipeline]
+artifactType: role-guidance
 role: engineer.data
 applies_to:
   - cx-data-engineer

package/skills/roles/engineer.md

@@ -1,6 +1,8 @@
 ---
 name: roles-engineer
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Engineer role. Use when reviewing or generating work by cx-engineer, cx-ai-engineer, cx-data-engineer, cx-platform-engineer, or when an agent is acting in the Engineer role.
+inputs: [code-diff, task-context]
+artifactType: role-guidance
 role: engineer
 applies_to:
   - cx-engineer

package/skills/roles/engineer.platform.md

@@ -1,6 +1,8 @@
 ---
 name: roles-engineer-platform
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Engineer — Platform role. Use when reviewing or generating work by cx-platform-engineer, or when an agent is acting in the Engineer — Platform role.
+inputs: [code-diff, internal-tooling]
+artifactType: role-guidance
 role: engineer.platform
 applies_to:
   - cx-platform-engineer

package/skills/roles/operator.docs.md

@@ -1,6 +1,8 @@
 ---
 name: roles-operator-docs
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Operator — Docs role. Use when reviewing or generating work by cx-docs-keeper, or when an agent is acting in the Operator — Docs role.
+inputs: [docs, runbook]
+artifactType: role-guidance
 role: operator.docs
 applies_to:
   - cx-docs-keeper

package/skills/roles/operator.md

@@ -1,6 +1,8 @@
 ---
 name: roles-operator
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Operator role. Use when reviewing or generating work by cx-sre, cx-operations, cx-release-manager, cx-docs-keeper, or when an agent is acting in the Operator role.
+inputs: [runbook, deployment-plan]
+artifactType: role-guidance
 role: operator
 applies_to:
   - cx-sre

package/skills/roles/operator.release.md

@@ -1,6 +1,8 @@
 ---
 name: roles-operator-release
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Operator — Release role. Use when reviewing or generating work by cx-release-manager, or when an agent is acting in the Operator — Release role.
+inputs: [release-plan, changelog]
+artifactType: role-guidance
 role: operator.release
 applies_to:
   - cx-release-manager

package/skills/roles/operator.sre.md

@@ -1,6 +1,8 @@
 ---
 name: roles-operator-sre
 description: Surfaces anti-patterns, failure modes, and counter-moves specific to the Operator — SRE role. Use when reviewing or generating work by cx-sre, or when an agent is acting in the Operator — SRE role.
+inputs: [alert-config, slo]
+artifactType: role-guidance
 role: operator.sre
 applies_to:
   - cx-sre