@geraldmaron/construct 1.0.16 → 1.0.17

package/skills/devops/monorepo.md

@@ -1,6 +1,8 @@
 ---
 name: devops-monorepo
 description: Use this skill when selecting monorepo tooling, structuring packages, or optimizing affected-only builds.
+inputs: [repo, pipeline-config]
+artifactType: guidance
 ---
 # Monorepo
 

package/skills/devops/observability.md

@@ -1,6 +1,8 @@
 ---
 name: devops-observability
 description: Use this skill when designing logging, tracing, metrics, or alerting systems.
+inputs: [service, metrics]
+artifactType: observability-plan
 ---
 # Observability
 

package/skills/devops/performance.md

@@ -1,6 +1,8 @@
 ---
 name: devops-performance
 description: Use this skill when profiling, load testing, or optimizing application and infrastructure performance.
+inputs: [service, metrics]
+artifactType: performance-plan
 ---
 # Performance Engineering
 

package/skills/devops/testing.md

@@ -1,6 +1,8 @@
 ---
 name: devops-testing
 description: Use this skill when planning test coverage, selecting test types, or establishing testing practices.
+inputs: [repo, task-context]
+artifactType: test-plan
 ---
 # Testing Strategy
 

package/skills/docs/adr-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-adr-workflow
 description: "Use when: an architectural decision is made that affects the system structure, data model, API contracts, or technology choices."
+inputs: [decision-context]
+artifactType: adr
 ---
 # ADR Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-backlog-proposal-workflow
 description: "Use when: product evidence should create or update Jira, Linear, GitHub Issues, or another tracker."
+inputs: [evidence-brief, prd, signal]
+artifactType: backlog-proposal
 ---
 # Backlog Proposal Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-customer-profile-workflow
 description: "Use when: customer evidence should update durable product memory."
+inputs: [signal, customer-profile]
+artifactType: customer-profile
 ---
 # Customer Profile Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-document-ingest-workflow
 description: "Use when: the user points at a PDF, Word doc, spreadsheet, slide deck, export, or mixed document folder and wants a markdown version that Construct can search efficiently later."
+inputs: [document]
+artifactType: ingested-markdown
 ---
 # Document Ingest Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-evidence-ingest-workflow
 description: "Use when: the user pastes customer notes, Slack threads, support tickets, sales notes, research snippets, RFCs, analytics summaries, or competitor signals."
+inputs: [signal, document]
+artifactType: evidence-brief
 ---
 # Evidence Ingest Workflow
 

package/skills/docs/init-docs.md

@@ -1,6 +1,8 @@
 ---
 name: docs-init-docs
 description: "`init docs`, `create docs structure`, `set up documentation`, `docs scaffold`, `documentation init`. Use when the task matches the trigger conditions described in the body."
+inputs: [task-context]
+artifactType: docs-scaffold
 ---
 # Skill: init-docs: Initialize Project Documentation Structure
 

package/skills/docs/init-project.md

@@ -1,6 +1,8 @@
 ---
 name: docs-init-project
 description: "Use when: starting work on a new project or joining an existing one without doc structure."
+inputs: [repo]
+artifactType: docs-scaffold
 ---
 # Project Initialization
 

package/skills/docs/memo-and-decision-capture.md

@@ -0,0 +1,45 @@
+---
+name: docs-memo-and-decision-capture
+description: "Use when: a decision, status update, or announcement needs to be captured as a short, durable memo that states the decision, its rationale, and what changes."
+inputs: [decision-context]
+artifactType: memo
+---
+# Memo & Decision Capture
+
+Use this skill when a decision, status update, or announcement needs to be captured as a short, durable memo.
+
+A good memo is short and load-bearing: a reader six months later should understand what was decided, why, and what it changed — without attending the meeting. Length is not value; a memo that buries the decision under context has failed.
+
+## Steps
+
+1. **Lead with the decision or update** in the first sentence. The reader should not have to hunt for it.
+2. **State the context** in 2–4 sentences: what prompted this, what problem it addresses.
+3. **Record the rationale** — why this option over the alternatives actually considered. If alternatives were weighed, name them and why they lost.
+4. **State what changes** as a result: who does what differently, what is now in or out of scope.
+5. **List action items** with owners, if any.
+6. **Date and attribute** the memo. A memo without a date is not durable.
+
+## Output shape
+
+```
+# Memo: <subject>
+_<date> · <author>_
+
+**Decision/Update:** <one sentence>
+
+## Context
+<2–4 sentences>
+
+## Rationale
+<why this, over what alternatives>
+
+## What changes
+- <change> — owner: <name>
+```
+
+## Verification bar
+
+- The decision/update is stated in the first sentence, unhedged where the decision is firm.
+- Rationale references only alternatives actually considered — no invented options.
+- The memo is dated and attributed.
+- Nothing load-bearing is asserted that the source context does not support; unknowns are written as `unknown`.

package/skills/docs/prd-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-prd-workflow
 description: "Use when: the user asks to create a PRD, platform spec, business case, RFC, or requirements document."
+inputs: [research-question, evidence-brief]
+artifactType: prd
 ---
 # PRD Workflow
 

package/skills/docs/prfaq-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-prfaq-workflow
 description: "Use when: the user asks for a PRFAQ, working-backwards doc, launch narrative, or FAQ grounded in product evidence."
+inputs: [prd, evidence-brief]
+artifactType: prfaq
 ---
 # PRFAQ Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-product-intelligence-review
 description: "Use when: reviewing PRDs, Meta PRDs, PRFAQs, evidence briefs, signal briefs, customer profiles, or backlog proposals."
+inputs: [prd, evidence-brief]
+artifactType: review
 ---
 # Product Intelligence Review
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-product-intelligence-workflow
 description: "Use when: the request involves customer evidence, PM synthesis, product requirements, PRDs, PRFAQs, customer profiles, product signals, or backlog proposals."
+inputs: [signal, evidence-brief]
+artifactType: prd
 ---
 # Product Intelligence Workflow
 

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

@@ -1,6 +1,8 @@
 ---
 name: docs-product-signal-workflow
 description: "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."
+inputs: [signal, evidence-brief]
+artifactType: signal-brief
 ---
 # Product Signal Workflow
 

package/skills/docs/research-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-research-workflow
 description: "Use when: the user asks to research a topic, investigate a question, or gather evidence for a decision."
+inputs: [research-question]
+artifactType: research-brief
 ---
 # Research Workflow
 

package/skills/docs/runbook-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-runbook-workflow
 description: "Use when: creating operational procedures for services, alerts, or recurring operations."
+inputs: [service, incident]
+artifactType: runbook
 ---
 # Runbook Workflow
 

package/skills/docs/strategy-workflow.md

@@ -1,6 +1,8 @@
 ---
 name: docs-strategy-workflow
 description: "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."
+inputs: [signal, decision-context]
+artifactType: strategy
 ---
 # Strategy Workflow
 

package/skills/docs/transcript-synthesis.md

@@ -0,0 +1,43 @@
+---
+name: docs-transcript-synthesis
+description: "Use when: a meeting, call, or interview transcript needs to be turned into a summary, the decisions made, and concrete action items with owners."
+inputs: [transcript-text]
+artifactType: meeting-summary
+---
+# Transcript Synthesis
+
+Use this skill when a meeting, call, or interview transcript needs to be turned into a structured summary with decisions and action items.
+
+A raw transcript is a low-signal artifact: speaker turns, filler, and tangents bury the few load-bearing outcomes. The job is to extract those outcomes faithfully without inventing any that were not actually stated.
+
+## Steps
+
+1. **Read the whole transcript first.** Do not summarize incrementally — a decision late in the call often reverses an earlier one.
+2. **Identify participants and roles** if stated. Note who owns what. If unstated, write `owner: unassigned` rather than guessing.
+3. **Extract decisions.** A decision is an explicit commitment ("we'll ship X", "we're not doing Y"). Quote or tightly paraphrase the line that establishes it. Do not promote a musing ("maybe we could…") to a decision.
+4. **Extract action items** as `{ action, owner, due? }`. Only include items someone actually committed to. Mark `due` only if a date was stated.
+5. **Extract open questions** — anything raised and left unresolved.
+6. **Write a 3–6 sentence summary** of what the conversation was about and what changed as a result.
+7. **Flag low-confidence sections** — crosstalk, inaudible markers, ambiguous antecedents — as `[unclear]` rather than smoothing them over.
+
+## Output shape
+
+```
+## Summary
+<3–6 sentences>
+
+## Decisions
+- <decision> — basis: "<quoted/paraphrased line>"
+
+## Action items
+- [ ] <action> — owner: <name|unassigned>[, due: <date>]
+
+## Open questions
+- <question>
+```
+
+## Verification bar
+
+- Every decision and action item traces to an actual statement in the transcript — no invented commitments or owners.
+- Tentative language stays tentative; do not sharpen "maybe" into "will".
+- Unresolved or inaudible content is surfaced, not silently dropped.

package/skills/exploration/dependency-graph-reading.md

@@ -1,6 +1,8 @@
 ---
 name: exploration-dependency-graph-reading
 description: Use when assessing the risk surface of a project's dependencies, planning upgrades, or evaluating a new codebase's supply chain posture.
+inputs: [dependency-manifest, repo]
+artifactType: dependency-graph
 ---
 # Dependency Graph Reading
 

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