reqvire-design

Estrellas15

Forks6

Actualizado1 de julio de 2026 a las 09:52

Use this skill to generate well-branded interfaces and assets for Reqvire (the Reqvire Explorer — a Git-native MBSE knowledge-graph viewer), either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for prototyping.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

reqvire-org

reqvire-org/reqvire

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Diseñadores de interfaces web y digitalesOcupaciones informáticas y matemáticas·SOC 15-1255

Explorador de archivos

100 archivos

SKILL.md

readonly

Más de este repositorio

mismo repositorio

reqvire-audit

reqvire-org/reqvire

Model quality and diagnostic skill for Reqvire. Use when (1) analyzing model structure, coverage gaps, and improvement recommendations, (2) checking verification coverage and identifying unverified leaf requirements, (3) linting and fixing model quality issues, (4) finding redundant verify relations, or (5) analyzing change impact for modified requirements and capabilities.

2026-06-3015

reqvire-concept-authoring

reqvire-org/reqvire

Expert workflow for authoring Reqvire native concept schemes and concepts as SKOS thesauri. Use when creating or revising `concept-scheme` or `concept` elements, designing controlled vocabularies, concept taxonomies, broader/narrower/related links, labels, definitions, scope notes, examples, mappings, concept scheme namespaces, or concept references to native concept elements. Use instead of ontology-authoring when the task is terminology/thesaurus/concept curation rather than structural OWL/Turtle vocabulary or SHACL contracts.

2026-06-3015

reqvire-ontology-authoring

reqvire-org/reqvire

Expert workflow for creating, extending, and validating Reqvire structural ontology elements for IT engineering, systems engineering, MBSE, and system-of-interest modeling. Use for competency-question-driven OWL/Turtle vocabulary, semantic-contract boundaries, ontology hierarchy, domain/range/property modeling, individuals, axioms, SHACL target vocabulary, structural-to-concept bridges, and Reqvire validation; trigger when the assistant needs to add or revise ontology elements, author

2026-06-3015

reqvire-syseng

reqvire-org/reqvire

Expert semantic engineering and MBSE skill for Reqvire. Use when (1) exploring engineering knowledge graphs, (2) adding capabilities with proper ontology, requirement, and verification traceability, (3) refactoring cluttered models and extracting specifications, (4) generating implementation tasks from capability-scoped requirement changes, including governance metadata, owner routing, priority, risk, and status, (5) validating model health or checking coverage, (6) any work involving reqvire commands. Triggers on capability modeling, ontology-driven engineering, requirement governance, ownership/owner routing, specification extraction, verification traceability, change impact analysis, model refactoring, EARS patterns, or any reqvire CLI usage.

reqvire-concept-authoring

reqvire-org/reqvire

2026-06-3015

name	reqvire-design
description	Use this skill to generate well-branded interfaces and assets for Reqvire (the Reqvire Explorer — a Git-native MBSE knowledge-graph viewer), either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for prototyping.
user-invocable	true

Read the readme.md file within this skill, and explore the other available files.

If creating visual artifacts (slides, mocks, throwaway prototypes, etc), copy assets out and create static HTML files for the user to view. If working on production code, you can copy assets and read the rules here to become an expert in designing with this brand.

If the user invokes this skill without any other guidance, ask them what they want to build or design, ask some questions, and act as an expert designer who outputs HTML artifacts or production code, depending on the need.

Where things are

readme.md — the full design guide: product context, content fundamentals, visual foundations, iconography, and a file manifest. Start here.
styles.css — single CSS entry point; link it to inherit all tokens, fonts and base styles. It is import-only and guarded.
tokens/ — colors (warm product surfaces, slate text ramps, rose accent, the six element-type hues), typography (Geist/Geist Mono), spacing, elevation, fonts.
components/<group>/ — typed React primitives (TSX; props are the source of truth) (Alert, Badge, BrandMark, Button, Card, Icon, IconButton, Modal, CodeRef, ElementIcon, TypeBadge, RelationPill, Chip, Stat, Table, ToggleRow, SegmentedControl, SearchInput, Tabs, TreeItem, Breadcrumb, SidebarSection).
product-patterns/<group>/ — typed reusable UX/product-pattern targets (shell, chrome, side-pane, detail, content, feedback) that emit ux-* visual hooks.
index.ts — the barrel; production code imports primitives, product patterns, and the palette API from here (the app aliases it as @ds).
palette.ts — programmatic color API: element-type → token mapping, runtime CSS-variable resolution, Mermaid class defs.
assets/logo-mark.svg — 200x200 source brand mark (reconstruction; replace with the official logo when available). Favicons and app icons are generated from it by npm run generate:icons, not hand-maintained as source.

Using the components

Production Explorer code imports components, product patterns, and palette symbols from @ds. For the local showcase, run npm run dev:showcase or npm run build:showcase; both commands run npm run lint before the Vite step so showcase-only rule breaks fail immediately. Generated bundles, generated CSS, generated browser icons, generated adherence config, and dist output are build/runtime artifacts, never tracked source.

Non-negotiables

Keep the element-type color code meaningful: capability=blue, requirement=violet, contract=orange, verification=green, ontology=gold, resource=amber, other=slate. Never reuse these hues decoratively. Use --contract* for source/specification/constraint/behavior/state/input-output contract elements.
Rose is the only chrome accent; primary buttons/active segments use dark slate ink. Dense 13px UI text. Geist. 4px grid. Soft, low shadows. No emoji, no decorative gradients, no hand-drawn SVG icons (use Icon / ElementIcon).
Primitive components own interaction state styling. Product patterns and showcase examples may use documented primitive props and documented context/density/composition --ds-* variables, but must not assign primitive state-policy variables like --ds-*-sel-*, --ds-*-hover-*, --ds-*-active-*, --ds-*-focus-*, or --ds-*-off-*; add a primitive prop/variant instead.
Product patterns must not use inline style={...}, CSSProperties, ad hoc CSS-variable objects, computed colors, or imperative .style.* mutations. If a dynamic visual value is legitimate, move it behind a reusable primitive API in components/** (for example ElementIcon, TypeBadge, TokenSwatch, DonutMeter, BarMeterFill) and compose that primitive from the product pattern.
When reviewing or refactoring DS code, search for style={, CSSProperties, --... style objects, setProperty(, and .style. across design-system and src. Classify findings: primitive API plumbing may be acceptable; product-pattern and app visual policy is not.
Showcase primitive pages demonstrate primitives only. Product vocabulary and product compositions such as panes, filters, graph legends, model trees, detail dialogs, reports, and Explorer chrome belong in ProductPatternsPage and must use exported product-pattern components from @ds.

Before editing visual code

Classify the ownership first: tokens, components primitive, product-patterns, showcase scaffold, or app logic. Put the visual rule in the owning layer, not where the bug happened to show up.
If a component only looks correct after a parent wrapper dresses it, the contract is wrong. Move the visual contract into the primitive or product-pattern component that owns that UI.
Product patterns must look correct when mounted alone. Shell/view wrappers may provide layout space and routing context, but not the final visual styling for the pattern.
Consumer app code owns state, data loading, routing, selection, and events. It consumes DS/product-pattern components; it does not define visual CSS policy.
If code needs dynamic visuals, do not use inline style. Prefer semantic props, typed token props, data-* attributes with token selectors, SVG presentation attributes, or a new primitive API.
If a product pattern needs different hover/selection/focus/active/off behavior, do not override --ds-* state variables. Add a primitive variant or prop and keep that state CSS in components/**.
If lint blocks a visual change, either change the DS API or update the conservative guard/allowlist in the same patch with a clear reason. Do not bypass the guard with local CSS, inline style, generated CSS, or consumer-owned selectors.

What guards should catch

No inline style={...}, CSSProperties, .style.*, or setProperty(...) in reusable DS components, product patterns, showcase pages, or app UI, except explicit renderer boundaries.
No app or product-pattern CSS targeting .ds-* internals. Consumers use public props, data-*, documented CSS variables, or exported product-pattern components.
No undocumented --ds-* assignments outside DS primitives. The allowlist is deny-by-default and should contain only context, density, or composition variables.
No primitive state-policy variables outside primitives: --ds-*-sel-*, --ds-*-hover-*, --ds-*-active-*, --ds-*-focus-*, --ds-*-off-*.
No unknown custom-property plumbing. Product patterns and app UI may use owned --ux-*; showcase scaffolding may use --showcase-*; any other var(--*) must be a real token, documented --ds-* customization, or owned local variable.
No raw visual values outside token/source-of-truth files: raw px/rem/colors, color-mix, raw filter functions, durations, easing, z-index, or font stacks.
No generated artifacts tracked as source, no hand-maintained generated CSS/icons/bundles, and no direct DS internal imports from consumer app code.
Exported component/product-pattern prop types that extend React DOM attributes must omit "style" by default.
DS/public visual APIs must not accept arbitrary visual strings such as color?: string, background?: string, pipColorToken, or unconstrained --${string}; use semantic variants or typed token unions such as DesignSystemColorToken.
Showcase pages use showcase-* classes for scaffolding. Primitive showcase pages import primitives/tokens only; product-pattern and mock pages own Explorer/product vocabulary.
showcase-* is not a customization escape hatch. Showcase CSS may style only the demo scaffold around examples; it must not target .ds-*, .ux-*, [data-product-pattern], or DOM elements inside rendered components. If showcase needs a different size, placement, or state, add/use a public primitive or product-pattern API.

What requires human or agent judgment

Whether a --ds-* variable is legitimate context/density customization or hidden primitive styling.
Whether a product pattern truly matches the real Explorer usage, especially after refactors. Prefer mounting the real exported product-pattern component in showcase rather than recreating a lookalike.
Whether a showcase primitive example has crossed into product vocabulary. If it has panes, filters, graph legends, model trees, detail dialogs, reports, or Explorer chrome, move it to product patterns or mocks.
Whether a dynamic visual value belongs in a generic primitive, a product-specific pattern, or an app-renderer boundary.
Whether shell/view wrappers are doing layout only or are visually dressing child components. Dressing child components is a contract smell.