# get-design Adopt this skill: https://proskills.md/skills/other/rizqinrr-viserys-agent-skills-get-design Page: https://proskills.md/skills/other/rizqinrr-viserys-agent-skills-get-design This document is the public skill bundle for that page. It contains SKILL.md and every helper file the catalog carries. No login is required. ## File: skills/get-design/SKILL.md size: 22195 sha: f69c3dcc92cbfddbe6e7ae6b2da4421941336367 upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/SKILL.md ````text --- name: get-design description: Interviews users on UI/UX aesthetics, establishes bespoke visual direction, removes generic AI aesthetics, and produces a complete design specification document at docs/design.md. Use when a user asks to design a UI, dashboard, landing page, or mobile app, establish visual direction, critique AI slop, or specify UI components, color palettes, typography, responsive layouts, accessibility, and interaction states. --- # Get Design ## Overview Run a product-grounded UI design workflow. The goal is not merely polished CSS: it is an interface with a clear job, a recognizable visual point of view, content that carries the design, hierarchy that reflects user priorities, and interaction states that work in the real usage scene. For new users, `get-design` acts as an interactive design partner: it asks targeted questions about the product feel, audience, and constraints, derivations of anti-AI-slop visual systems, and outputs a concrete, executable `docs/design.md` (or `design.md`) specification covering design tokens, layouts, component states, and accessibility standards. This skill is a native Viserys adaptation of the Impeccable design playbook and anti-slop catalog. It contains no runtime dependency on Impeccable, its CLI, hooks, binaries, or external detector. The rulebook is advisory evidence; a deliberate choice can override a default when the product brief, brand, platform, or accessibility requirement earns it. ## When to Use - Creating a new page, screen, component, landing page, dashboard, checkout, settings flow, docs surface, portfolio, or mobile UI. - Interviewing a user on visual direction, layout, and UX expectations to produce `docs/design.md`. - Redesigning an existing visual world rather than only fixing a local defect. - Reviewing a UI that feels generic, templated, “AI-generated”, or disconnected from its product. - Establishing design tokens (palette, typography, spacing, radius, depth), component hierarchies, and interactive states. - Auditing a rendered interface for usability, accessibility (WCAG AA), performance, responsive behavior, or implementation integrity. - Documenting or extracting an existing design system into `docs/design.md`. **When NOT to use:** Pure backend changes, non-visual CLI tools, or algorithmic database work with no user-facing interface. ## The Design Workflow Choose the route from the user's request. If the request is ambiguous, ask before editing. Load [routing](references/routing.md) for mode selection and the context-aware menu. Load the complete [anti-AI-slop catalog](references/anti-ai-slop-catalog.md) for every mode, including `new`, `shape`, `critique`, `audit`, focused refinements, `document`, and `extract`; it is the baseline before any design decision, edit, critique, or audit. For deep review use [critique](references/critique.md) or [audit](references/audit.md); for a focused refinement use the matching section in [focused playbooks](references/focused-playbooks.md). ### Universal Principles for the Design Partner 1. **Natural Language & Visual Guidance:** Converse in the user's language (Indonesian or English). If the user says *"saya buta desain, tolong arahkan"* (I don't know design, please guide me), do not ask them for hex codes or typography scale ratios. Present 2–3 cohesive visual archetypes (e.g. *Utilitarian High-Density, Modern Clean Monochrome, or Warm Crafted*) with concrete explanations of why each fits their audience. 2. **Strict Anti-AI-Slop Standard:** Deliberately reject category clichés: no purple/cyan gradient text, no floating cards with massive blur shadows, no identical 3-card repetition, and no giant rounded pills eating up dense screen real estate. 3. **Complete State Lifecycles:** Never output a design that only looks good in a static screenshot. Every interactive element in `docs/design.md` must document its full state lifecycle (Default, Hover, Focus-visible ring, Active, Disabled, Loading skeleton, Empty state, and Error flash). 1. **Context** → establish product truth, audience, task, platform, constraints, existing visual authority, and the evidence available. 2. **Direction** → choose the surface mode and visual direction before implementation. 3. **Build** → implement the chosen direction as a coherent system, not as disconnected decorations. 4. **Inspect** → review the whole path at representative viewports and states. 5. **Finish** → fix the highest-impact issues, verify again once, and document durable system decisions. ### Route A: `new` or `shape` 1. Read `PRODUCT.md`, `DESIGN.md`, surface briefs, existing tokens, components, copy, assets, and neighboring flows when present. 2. Classify the surface: **Persuade** (decide and act), **Operate** (complete a task), **Read** (understand), or **Experience** (explore the work). 3. Decide what is already true: - Extend an established surface by inheriting its visual world. - Create a surface inside an established world without inventing a new identity. - Redesign only when the user explicitly asks to replace the visual world. - Create a new world when no visual authority exists. 4. Ask two or three focused questions about success, must-keep constraints, content/proof, interaction, and what would feel wrong. Never ask the user to pick CSS values as a substitute for design reasoning. 5. Derive at least five materially different structures from the product's content and audience world for an open-ended surface. Reject category-default layouts before selecting one. 6. Commit a direction with: - THESIS: what the surface owns and which default arrangement it refuses. - OWN-WORLD: palette, type character, shape, depth, imagery, and component language. - STORY: what the visitor understands, believes, and does. - FIRST VIEWPORT: exact composition, proof, hierarchy, and primary action. - FORM: why this structure fits the task and audience. - FINISH: evidence required before calling it complete. 7. If the user asks only for `shape`, present the direction and stop before implementation. If building, continue with the chosen direction. ### Route B: `critique` 1. Resolve one concrete target and identify whether source, rendered page, or both are available. 2. Run an independent design review before looking at automated findings. Evaluate specificity, hierarchy, IA, emotional journey, cognitive load, Nielsen's ten heuristics, accessibility, states, copy, and edge cases. 3. If a browser or subagent is available, delegate independent implementation/evidence checks without letting one assessment anchor the other. If unavailable, state the degraded method explicitly. 4. Synthesize rather than concatenate. Start with method, health score, specificity verdict, what works, three to five prioritized issues, persona red flags, minor observations, and targeted questions. 5. Questions are last. Ask only questions tied to findings; if fewer than three priority issues exist, write `Questions skipped: fewer than 3 priority issues`. 6. Do not change files during critique unless the user explicitly asks to act on the findings. ### Route C: `audit` 1. Audit implementation, not taste alone, across Accessibility, Performance, Theming, Responsive Design, and Implementation Integrity. 2. Score each dimension from 0–4 and report a total out of 20. 3. Tag findings P0 Blocking, P1 Major, P2 Minor, or P3 Polish. Include location, impact, standard when applicable, and a concrete fix. 4. Separate deterministic evidence from design judgment. Verify each suspected issue against the target and call out false positives. 5. Include systemic patterns, positive findings, and prioritized next actions. Do not fix files inside the audit route. ### Route D: `polish` 1. Preserve the incumbent visual world, content, behavior, and scope. Polish is not a concealed redesign. 2. Read DESIGN.md, tokens, shared components, neighboring flows, and any prior critique. Classify each gap as missing token, one-off implementation, conceptual mismatch, or local defect. 3. Triage in this order: blocked tasks/data loss/inaccessible paths; missing states; flow/hierarchy/responsive/design-system drift; visual/motion inconsistency; cleanup. 4. Walk the actual path at desktop, mobile, intermediate, and wide sizes with mouse, keyboard, and touch where applicable. 5. Fix the narrowest correct cause. Preserve factual copy and ask before changing claims. 6. Run one batched final inspection. Finish only when the path, states, responsive behavior, and design system agree. ### Route E: focused refinements - `layout`: fix spatial hierarchy, rhythm, grouping, density, optical alignment, and responsive composition. - `typeset`: fix type character, hierarchy, measure, line-height, weight, wrapping, localization expansion, and font loading. - `colorize`: establish palette roles, contrast, semantic states, theme behavior, and intentional color at page scale. - `animate`: add one or a few purposeful moments tied to state, relationship, or feedback; preserve reduced motion and visible defaults. - `bolder`: amplify a bland but coherent design without replacing its product truth. - `quieter`: reduce noise, competing emphasis, glow, decoration, and unnecessary motion while retaining personality. - `distill`: remove clutter, duplicate explanation, redundant chrome, and competing actions. - `clarify`: rewrite labels, instructions, errors, empty states, and calls to action around the user's next decision. - `adapt`: preserve the world while adapting composition, interaction, and density to another viewport or platform. - `harden`: handle loading, empty, error, success, disabled, permission, offline, slow, long-content, missing-content, and localization states. - `onboard`: design first-run, activation, empty-state, and learning-by-doing flows around the first useful result. - `optimize`: measure and improve UI performance without adding speculative micro-optimizations. - `delight`: add a product-specific, useful moment rather than decorative novelty. - `overdrive`: push ambition only when the brief permits it; keep performance, clarity, accessibility, and product truth intact. ### Route F: `document` 1. Scan CSS variables, theme files, token files, component primitives, global styles, and representative rendered output. 2. Extract only observed colors, typography, spacing, radius, depth, breakpoint, component, state, and responsive values. Never invent tokens to fill a template. 3. Write or update `DESIGN.md` only after checking whether one already exists. If it exists, ask whether to refresh, overwrite, or merge. 4. Keep the canonical sections: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. 5. Distinguish durable design-system rules from route-specific strategy. Record a decision only when the implementation or user explicitly supports it. ### Route G: `extract` 1. Inventory repeated visual patterns and confirm that they have the same semantic purpose and behavior. 2. Separate true shared patterns from merely similar-looking elements; preserve meaningful variants. 3. Promote stable values to tokens and stable behavior to shared components. 4. Migrate usages incrementally, preserving content, states, accessibility, and visual parity. 5. Verify all affected surfaces and document the extracted boundary. ### Deliverable: `docs/design.md` Specification When completing a design interview or visual direction pass, commit the agreed direction to `docs/design.md` (or `design.md`) so downstream task planning has a concrete reference: ```markdown # Design Specification: [Product/Surface Name] ## 1. Visual Thesis & Audience - **Product Job:** - **Audience & Scene:** - **Aesthetic Thesis:** ## 2. Design Tokens & Visual World - **Color Palette:** - Surface & Background: - Text & Hierarchy: = 4.5:1 contrast> - Brand & Semantic: - **Typography:** - Display & Headings: - Body & Labels: - **Spacing & Elevation:** ## 3. Layout & Responsive Breakpoints - **Mobile (375px):** = 44px> - **Tablet (768px):** - **Desktop (1280px+):** ## 4. Component Hierarchy & Interactive States - State coverage: default, hover, focus-visible (high contrast outline), active, disabled, loading, empty, and error. ## 5. Micro-Interactions & Motion - Purposeful transitions (150-250ms ease-out), full `@media (prefers-reduced-motion)` fallback. ## 6. Accessibility & Performance Bar - WCAG 2.1 AA compliant, full keyboard tab order, font preloading, layout shift prevention (CLS). ``` ## Core Design Rules ### Product specificity - Start from the user's task, content, audience, and operating scene—not a category template. - The first viewport must communicate the product's mechanism or primary task, not only its mood. - Use proof, realistic content, and authored details. Demonstration data may be synthetic, but label it honestly; never invent commercial or factual claims. - Every visual choice needs a reason connected to product identity, audience recognition, hierarchy, state, or interaction. - Familiar and effective is valid when chosen deliberately. Familiar by reflex is the problem. ### Structure and hierarchy - Use content priority to determine composition; do not give every section the same weight. - Prefer purposeful grouping and varied density over identical repeated blocks. - Keep related items close and separate unrelated groups generously. - Use progressive disclosure for complexity and keep visible decisions manageable. - Use a modal only for interruption, protected focus, or a task that genuinely benefits from isolation. - Use numbered labels only when sequence carries information. - Treat the first viewport as a thesis, not a generic header. ### Typography - Choose type for character, reading need, platform, and product world. Preserve an established brand face when it is intentional. - Establish visible steps between display, heading, title, body, and label roles. - Keep body measure near 65–75 characters where appropriate; use enough line-height for comfortable reading. - Use sentence case for prose. Reserve uppercase and tracking for short labels. - Prefer weight, size, spacing, and placement for emphasis before decorative gradient text. - Test real copy, long labels, localization expansion, zoom, and font loading at every breakpoint. ### Color, depth, and shape - Choose light/dark from the use scene, not category habit. - Define semantic roles and use color at page scale where the surface owns it; do not scatter accent color as decoration. - Meet WCAG contrast: 4.5:1 normal text and 3:1 large text; tint secondary text from the surface hue rather than default gray on color. - Declare elevation once: border, tonal layering, or shadow. A hairline border plus broad shadow usually defines the same edge twice. - Keep radii proportional to the element. Pills belong to compact controls; large rounded blobs are not a universal card language. - Use gradients, glass, blur, glow, hard shadows, stripes, and grids only when the chosen world or function gives them a clear job. ### Imagery and icons - Use real, verified imagery when the subject or brief calls for it; one decisive image beats several generic substitutes. - Prefer an authored illustration, diagram, photo, or no image over placeholder circles and blocks. - Use a consistent icon library or authored SVG with coherent stroke, fill, optical size, and alignment. Do not use emoji or arbitrary Unicode glyphs as an icon system. - Use prepared transparent cutouts or clean crops; do not approximate photographic contours with geometric masks. - Do not hide useful imagery beneath opaque overlays or ship broken/placeholder sources. - Give every shipped raster provenance: source, license, or generation prompt. ### Motion and interaction - Motion must explain change, relationship, status, or feedback. Author one coherent motion grammar instead of scattering effects. - Keep content visible by default; entrance animation must not be the only path to visibility. - Use transform/opacity and bounded effects where appropriate; avoid animating layout properties that shift nearby content. - Provide a meaningful reduced-motion alternative that preserves state and hierarchy. - Keep static status dots static; pulse only when the motion communicates active change. - Do not use automatic marquee, decorative blinking cursors, image hover zoom, or bounce/elastic easing without a strong product-specific reason. - Make controls interruptible, keyboard accessible, touch-safe, and predictable. ### Copy and credibility - Write the product's language. Name what the person can do and what changes for them. - Replace generic claims such as “world-class”, “next-generation”, or “supercharge” with concrete outcomes and proof. - Avoid repeated labels, slogan-like forced contrasts, and em-dash-heavy prose. - Errors name the problem and recovery. Controls name their action. Empty states explain what happened and the next useful step. - Never change factual claims, prices, availability, customer proof, or capabilities without confirmation. ### Shipping floor Every UI route must account for default, hover, focus-visible, active, disabled, loading, error, empty, success, and permission states where relevant. Verify keyboard focus, semantic structure, screen-reader names, contrast, responsive composition, touch targets, overflow, console errors, image loading, and reduced motion. ## Common Rationalizations | Rationalization | Reality | |---|---| | “The brief is only ‘make it modern’.” | Ask for the user's task, audience, scene, and success. A vague adjective is not a visual direction. | | “The category uses this template.” | Category convention is a candidate, not a reason. Derive structure from content and behavior. | | “The gradient/glow/card makes it feel premium.” | Decoration is not hierarchy. Name the product job or remove the effect. | | “I will use placeholder copy and fix it later.” | Realistic content exposes wrapping, hierarchy, and overflow problems now. | | “Everything can be a card.” | Cards flatten relationships and create depth noise. Use grouping, type, spacing, and dividers. | | “A clean screenshot proves it.” | A screenshot misses keyboard, states, overflow, loading, errors, and runtime failures. Walk the path. | | “The animation makes the page feel alive.” | Motion without a state or relationship is attention tax. Give it a job and a reduced-motion path. | | “Accessibility is separate from design.” | Accessibility changes hierarchy, content, controls, motion, and error recovery. Design it from the start. | | “The design system can be documented later.” | Undocumented decisions drift. Record durable choices after the world is coherent and before reuse. | ## Red Flags - The page could be reskinned for an unrelated product without changing its structure or copy. - A generic hero, oversized headline, eyebrow badge, metric block, or identical card grid carries the whole page. - Purple/blue gradients, cyan neon, cream/editorial defaults, glass panels, glow halos, stripes, or grid backgrounds appear without a product job. - Inter/Geist/system display type is selected without a character or usage reason. - Icons, illustrations, or data are placeholders, decorative, or inconsistent. - Every section has the same padding, density, animation, and card treatment. - The primary action is unclear, buried, duplicated, or visually equal to secondary actions. - Real copy causes wrapping, overflow, clipped menus, or broken hierarchy. - No visible focus, reduced-motion behavior, loading/error/empty states, or touch-safe interaction exists. - Review relies on memory or one desktop screenshot rather than rendered evidence across sizes. ## Verification - [ ] The route, surface mode, audience, primary task, success, constraints, and visual authority are explicit. - [ ] The chosen direction has THESIS, OWN-WORLD, STORY, FIRST VIEWPORT, FORM, and FINISH blocks when creating or replacing a surface. - [ ] The composition is driven by content and task; it is not a category template with renamed copy. - [ ] Typography, palette, spacing, shape, depth, imagery, icons, and motion have documented reasons and follow the design system. - [ ] Realistic content, assets, and factual claims were checked; no broken or placeholder media ships. - [ ] Default, hover, focus, active, disabled, loading, error, empty, success, and permission states are handled where relevant. - [ ] Desktop, mobile, intermediate, and wide layouts were inspected; no overflow, clipping, or collapsed hierarchy remains. - [ ] Keyboard navigation, focus visibility, semantics, labels, contrast, touch targets, and reduced motion were checked. - [ ] Browser console, image loading, layout shift, and interaction behavior were checked when runtime evidence is available. - [ ] The final pass is bounded: one batched inspection, one fix batch, and at most one confirmation round. - [ ] Durable visual decisions are recorded in `DESIGN.md`; task-specific strategy remains in a surface brief. ## See Also - `../../references/accessibility-checklist.md` for the shared accessibility baseline. ## Attribution This skill is a native Viserys adaptation of the Impeccable design guidance and anti-pattern catalog by Paul Bakaus, derived from https://github.com/pbakaus/impeccable and https://impeccable.style/. The upstream work is Apache-2.0 licensed. Viserys does not include the upstream runtime, binary, hooks, detector, or extension. ```` ## File: skills/get-design/references/anti-ai-slop-catalog.md size: 10884 sha: a13772acd835e474ca5882426bf6bee3066d914b upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/references/anti-ai-slop-catalog.md ```text # AI Slop and Quality Catalog Use this catalog during design, critique, audit, and polish. A finding is a reason to inspect the product context, not an automatic ban. Preserve a deliberate choice when the brief, established design system, platform convention, or user need earns it; document the reason. ## Design-system consistency — 4 checks 1. **Font outside the documented system** — Use an approved face or update DESIGN.md when the addition is intentional. 2. **Color outside the documented palette** — Use a semantic token or record the new role; avoid one-off raw colors. 3. **Radius outside the documented scale** — Use the shape scale or establish a new reusable form rule. 4. **Font size outside the type scale** — Use an existing role or add a deliberate scale step. ## Visual details — 8 checks 1. **Decorative grid-line background** — Grids belong to canvases, maps, blueprints, or measurement tasks; otherwise use a surface or subject-specific texture. 2. **Border accent on a rounded element** — A thick colored outline competes with content; use a quiet edge or background-defined grouping. 3. **Glassmorphism everywhere** — Blur, glass, and glow need a layering or material reason, not generic “premium” decoration. 4. **Side-tab accent border** — A thick colored side stripe signals status or alert. Remove it when no state is communicated. 5. **Hairline border with wide shadow** — Pick one depth definition: edge, tonal layering, or shadow. 6. **Repeating-gradient stripes** — Use only when stripes belong to the subject or task; otherwise they are empty-space noise. 7. **Extreme border-radius on cards** — Match the curve to size, density, content, and system hierarchy; avoid blob-like containers by reflex. 8. **Rough SVG illustrations** — Ship a finished vector, diagram, photo, or no illustration. A sketchy placeholder lowers the finish of the whole surface. ## Typography — 11 checks 1. **Label above a heading** — Remove an eyebrow/kicker that repeats the heading; integrate useful context into the heading or nearby copy. 2. **Tiny interface text** — Navigation, controls, and links must remain legible without zoom. 3. **Flat type hierarchy** — Make roles visibly distinct through size, weight, spacing, width, and placement. 4. **Icon tile stacked above heading** — Place the icon beside its label or remove the tile unless the container carries real meaning. 5. **Italic serif display headline by reflex** — Choose a display treatment from product character, not the default editorial shortcut. 6. **Badge above the main headline** — Pills look clickable and compete with the offer. Keep only information that genuinely helps the decision. 7. **Oversized hero headline** — Leave first-screen room for meaning, proof, and action; shorten or scale long display copy. 8. **Crushed letter spacing** — Keep display tracking no tighter than roughly -0.04em and test every breakpoint. 9. **Overused font** — Inter, Geist, and system defaults are valid workhorses, but a brand surface needs a deliberate reason and sufficient hierarchy. 10. **Single font with flat treatment** — One family can work; vary roles before adding another family. Add a second only when it creates useful contrast. 11. **All-caps body text** — Reserve uppercase for short labels; use sentence case for prose. ## Color and contrast — 7 checks 1. **Radial-gradient background halo** — Remove a bright ambient glow when it has no role or competes with content. 2. **Soft spotlight behind content** — Use hierarchy, spacing, and contrast to guide attention before adding a vague glow. 3. **AI-default palette** — Purple-to-blue gradients and bright cyan on dark surfaces need a product-specific reason. 4. **Dark mode with glowing accents** — Dark does not imply neon. Reduce glow so information, state, and action dominate. 5. **Gradient text** — Prefer solid color plus weight, scale, or placement for emphasis. 6. **Gray text on a colored background** — Tint secondary text from the surface hue or use a contrasting light/dark foreground; verify WCAG contrast. 7. **Cream/beige palette by reflex** — Warm neutrals are legitimate when they belong to the product world; do not use them as a substitute for art direction. ## Layout and space — 12 checks 1. **Tiny numbered section labels** — Keep numbers only when order or sequence matters. 2. **Cards flush against scroller edges** — Give the first and last item matching boundary space. 3. **Text covered by another element** — Reserve space or move the layer; readable content must remain readable. 4. **Unbalanced opening columns** — Rebalance, align by intent, or move the long content below rather than leaving accidental dead space. 5. **Heading closer to the previous section** — Give headings more space above than below so ownership is obvious. 6. **Hero metric template** — Lead with a metric only when it explains value and has enough context to mean something. 7. **Identical card grids** — Group related ideas and vary treatment according to information priority. 8. **Monotonous spacing** — Use tight groups and larger separation between distinct concepts; equal gaps erase relationships. 9. **Nested cards** — Flatten the hierarchy with spacing, type, dividers, or tonal surfaces. 10. **Line length too long** — Keep prose near 65–75 characters per line, adjusted for typeface and context. 11. **Content overflow** — Let content wrap and containers shrink; use a deliberate scrolling region when necessary. 12. **Clipped menus and popovers** — Remove the clipping ancestor or render overlays in an appropriate layer/portal. ## Motion — 6 checks 1. **Pulsing status dot** — Static status stays still; pulse only for active change that deserves attention. 2. **Decorative blinking cursor** — Use a cursor only where text is editable or a terminal metaphor is real. 3. **Auto-scrolling marquee** — Keep information still or provide pause and manual controls. 4. **Bounce/elastic easing** — Routine actions should settle quickly; playful overshoot needs a product-appropriate moment. 5. **Animation that changes layout** — Prefer transforms for visual movement; when layout must change, measure and prevent shifts. 6. **Images that move on hover** — Give the actionable container feedback; keep non-action imagery stable unless motion explains interaction. ## Copy — 5 checks 1. **Same text repeated inside one container** — Keep the label once at the point of decision. 2. **Em-dash overuse** — Use full stops, commas, colons, or parentheses when they make the thought easier to follow. 3. **Generic marketing claims** — Replace “supercharge”, “world-class”, “enterprise-grade”, and “next-generation” with concrete capabilities, outcomes, and proof. 4. **Forced contrast slogan** — Avoid repetitive “Not X. Y.” constructions; explain the useful distinction directly. 5. **Calling things “theater”** — Name the ineffective behavior and explain why rather than dismissing it with attitude. ## Imagery — 4 checks 1. **Placeholder-style illustrations** — Generic circles and blocks say little. Use imagery specific to the product or omit it. 2. **Jagged image masks** — Use a prepared alpha matte or clean crop for organic subjects rather than a crude polygon/radial cutout. 3. **Images hidden under overlays** — Reduce the overlay until the image contributes, or remove an image with no purpose. 4. **Broken or placeholder image source** — Add the intended asset and verify loading, or remove the element. ## General quality — 10 checks 1. **JavaScript errors on load** — Fix runtime errors before visual polish. 2. **Content stuck waiting to appear** — Content must be visible by default and remain usable when animation fails. 3. **Cramped padding** — Separate text and controls from edges using the spacing scale. 4. **Body text touching the viewport edge** — Add responsive horizontal containment. 5. **Justified text without careful hyphenation** — Prefer start alignment when justification produces rivers and uneven gaps. 6. **Low-contrast text** — Meet WCAG AA: 4.5:1 normal text, 3:1 large text. 7. **Skipped heading level** — Match headings to document structure for scanning and assistive navigation. 8. **Tight line-height** — Start body copy around 1.5 and tune for face, size, and measure. 9. **Tiny body text** — Start around 16px for ordinary web prose and verify on actual mobile and desktop rendering. 10. **Wide letter spacing on body text** — Keep prose near the font's default tracking; reserve wide tracking for short labels. ## Craft floor A design is not complete until it also clears these cross-cutting checks: - **Contrast:** body/placeholder ≥4.5:1; large text ≥3:1. - **Depth:** an offset plus soft blur can express elevation; a zero-offset colored halo is decoration. - **Spacing:** related groups are tight, distinct groups have room, and headings have more space above than below. - **Type:** readable measure, visible scale steps, bounded display size, tracking floor, real copy at every breakpoint. - **Motion:** one coherent grammar, visible defaults, smooth bounded effects, meaningful reduced-motion behavior. - **States:** default, hover, focus, active, disabled, loading, error, empty, success, permission, and offline where relevant. - **Browser surfaces:** selection, caret, scrollbar, focus ring, underline offset, and tabular numerals should not accidentally contradict the system. - **Copy:** controls state their action; errors state problem and recovery. - **Coverage:** every brief requirement is present and findable within seconds. ## Category defaults to challenge Challenge these when the brief leaves the axis open: - Generic hero plus feature grid plus metrics plus CTA. - Same-size cards with icon, heading, and paragraph as the page scaffold. - Big number plus tiny label and supporting stats as the hero. - Eyebrow labels and numbered sections with no informational purpose. - Modal-by-reflex. - Gradient text, decorative glass, side stripes, hard offset shadows outside an actual neobrutalist system. - Progress rings, sparklines, and rounded soft-shadow rectangles standing in for content. - Monospace as a costume for “technical”. - System display faces as a brand voice without intent. - Emoji/Unicode glyphs as the icon system. - Geometric masks pretending to be organic cutouts. - Light/dark selected from category stereotype rather than the use scene. ## Attribution Adapted and expanded for Viserys from Impeccable's Slop catalog and craft-floor guidance by Paul Bakaus. Upstream: https://github.com/pbakaus/impeccable and https://impeccable.style/slop. Apache License 2.0; modifications were made for native Viserys workflow and terminology. ``` ## File: skills/get-design/references/audit.md size: 2708 sha: f2922f2f3aec08a0ae08f7d4a23527340dc08b88 upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/references/audit.md ```text # Technical UI Audit Use this reference for `/get-design audit`. Audit measurable implementation quality; do not redesign or fix files. ## Dimensions Score each dimension 0–4. ### Accessibility Check contrast, semantic HTML, heading order, labels, names/roles/states, keyboard navigation, focus order/visibility/traps, alt text, error association, motion sensitivity, zoom/reflow, and non-color state cues. ### Performance Check layout thrashing, unbounded blur/filter/shadow, layout-property animation, image sizing/loading/format, font loading, unnecessary dependencies, render churn, bundle weight, layout shift, and interaction latency. Do not claim measured impact without measurements. ### Theming Check semantic tokens, hard-coded colors, theme switching, light/dark contrast, token consistency, browser surfaces, and state colors. ### Responsive design Check fixed widths, intermediate widths, overflow, content reordering, text scaling, touch targets, touch gestures, safe areas, orientation, and keyboard/mobile viewport behavior. A resized desktop viewport is not proof of touch behavior. ### Implementation integrity Check the anti-slop catalog, product specificity, realistic content, complete states, working controls, design-system drift, placeholder media, misleading claims, and whether an unrelated product could reuse the structure unchanged. ## Evidence rules - Cite file and line for source findings. - Cite URL, viewport, element, and interaction for browser findings. - Label static performance observations `potential impact`. - Distinguish measured, observed, inferred, and unavailable evidence. - Verify suspected findings and call out false positives. ## Score bands - 18–20 Excellent. - 14–17 Good. - 10–13 Acceptable but significant work remains. - 6–9 Poor. - 0–5 Critical. ## Severity - P0 Blocking: prevents task completion or creates severe risk. - P1 Major: release-blocking WCAG AA failure or significant task difficulty. - P2 Minor: contained friction or inconsistency. - P3 Polish: low-impact finish issue. ## Report format 1. Audit Health Score table, total `/20`. 2. Implementation Integrity Verdict. 3. Executive Summary and severity counts. 4. Detailed Findings by severity; each includes location, category, impact, standard, evidence type, and concrete recommendation. 5. Patterns and Systemic Issues. 6. Positive Findings. 7. Recommended Actions using `/get-design `. Prioritize ruthlessly. Do not bury P0/P1 findings under a list of cosmetic details. ## Attribution Adapted for Viserys from Impeccable's audit guidance by Paul Bakaus, Apache-2.0. Modifications remove upstream runtime and detector dependencies. ``` ## File: skills/get-design/references/critique.md size: 3434 sha: 1dc51b71a4013153691fb598ab01b0eb4e3e6a15 upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/references/critique.md ```text # Design Review Framework Use this reference for `/get-design critique`. Review one concrete target. The report is the deliverable; do not change files. ## Independent assessments ### A. Design judgment Assess before reading mechanical findings: - Product specificity: authored for this product or category-interchangeable? - Information architecture and hierarchy. - Task discoverability and primary-action clarity. - Typography, color, composition, imagery, motion, copy, states, edge cases. - Cognitive load and working-memory demand. - Emotional journey: reassurance, high-stakes valleys, and the final impression. - Accessibility and platform conventions. ### B. Evidence Inspect source and rendered output when available. Use a fresh browser context/tab and representative desktop/mobile viewports. Check console, DOM semantics, computed layout, keyboard path, touch behavior where applicable, and the anti-slop catalog. Report unavailable evidence explicitly. When subagents exist, run A and B independently so one does not anchor the other. Otherwise write: `DEGRADED: single-context ()` ## Nielsen scoring Score each applicable heuristic 0–4. `4` means excellent, not merely acceptable. Mark genuinely irrelevant rows `n/a` and adjust the denominator. 1. Visibility of system status. 2. Match between system and real world. 3. User control and freedom. 4. Consistency and standards. 5. Error prevention. 6. Recognition rather than recall. 7. Flexibility and efficiency. 8. Aesthetic and minimalist design. 9. Error recognition, diagnosis, and recovery. 10. Help and documentation. Rating uses the percentage of the applicable maximum: - 90–100%: Excellent. - 70–89%: Good. - 50–69%: Significant work needed. - 30–49%: Poor. - Below 30%: Critical. ## Cognitive-load assessment Count failed checks: - One obvious primary focus. - Information chunked into manageable groups. - Related material visually grouped. - Visual hierarchy is immediately legible. - One decision at a time where possible. - No decision point presents more than four ungrouped choices. - The user does not carry hidden information between steps. - Complexity appears progressively. 0–1 failures is low load, 2–3 moderate, 4+ high. Do not confuse necessary domain complexity with avoidable interface complexity. ## Severity - **P0 Blocking:** prevents task completion, causes data loss, or creates a severe accessibility barrier. - **P1 Major:** materially harms comprehension, trust, conversion, or task efficiency. - **P2 Minor:** noticeable friction with a workaround. - **P3 Polish:** finish issue with limited user impact. ## Report format 1. Method. 2. Design Health Score table. 3. Design Specificity Verdict. 4. Overall Impression. 5. What's Working (2–3 concrete strengths). 6. Priority Issues (3–5, ordered; each includes severity, why, location, and concrete fix). 7. Persona Red Flags (2–3 relevant user perspectives walking the primary task). 8. Minor Observations. 9. Questions to Consider. If there are at least three priority issues, end with 2–4 targeted questions with concrete options. If fewer, end with: `Questions skipped: fewer than 3 priority issues` ## Attribution Adapted for Viserys from Impeccable's critique guidance by Paul Bakaus, Apache-2.0. Modifications replace Impeccable-specific runtime, persistence, overlay, and command mechanics with native Viserys workflows. ``` ## File: skills/get-design/references/focused-playbooks.md size: 7076 sha: 6ea554c274b11499cb1df3351b2cf04967a6022e upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/references/focused-playbooks.md ```text # Focused Design Playbooks Load only the section matching `/get-design `. ## layout 1. Identify the primary task, reading order, and information priority. 2. Map groups by relationship; use proximity before containers. 3. Establish a spacing scale with tight internal gaps and larger inter-group gaps. 4. Balance density and quiet; vary section rhythm without breaking the grammar. 5. Build fluid responsive composition at narrow, intermediate, and wide widths. 6. Check optical alignment, heading ownership, scroll boundaries, overflow, and overlay layers. ## typeset 1. Inventory actual fonts, sizes, weights, line-heights, widths, and roles. 2. Choose type character from product, mode, platform, and reading need. 3. Create visible hierarchy steps; avoid labels and badges that repeat headings. 4. Set body measure near 65–75ch and body line-height near 1.5 as a starting point. 5. Keep display tracking above roughly -0.04em and display size within the viewport's content needs. 6. Test real copy, long words, localization, zoom, font loading, and every breakpoint. ## colorize 1. Identify semantic roles: background, surface, foreground, muted, action, border, success, warning, error, focus. 2. Pick a strategy: restrained, committed, full palette, or drenched. 3. Choose light/dark from the usage scene, not category habit. 4. Use color in meaningful regions and states, not scattered decoration. 5. Tint secondary text from colored surfaces and verify contrast. 6. Check every interactive/state combination and both themes when supported. ## animate 1. Name the state change, relationship, feedback, or narrative moment. 2. Choose one motion grammar and one authored moment. 3. Keep content visible by default and interactions interruptible. 4. Prefer performant properties; bound blur/filter/shadow and avoid layout shifts. 5. Design a reduced-motion alternative that preserves meaning. 6. Test keyboard, touch, rapid repeated input, cancellation, and low-performance behavior. ## bolder 1. Preserve product truth and working behavior. 2. Increase hierarchy contrast, compositional commitment, type scale, imagery confidence, or page-scale color—not all indiscriminately. 3. Replace timid symmetry and repeated cards with one stronger structural idea. 4. Add one memorable product-specific moment. 5. Verify the result remains clear, accessible, and usable. ## quieter 1. Identify competing emphasis, redundant decoration, and unnecessary motion. 2. Reduce the number of accents, depth signals, type voices, and simultaneously loud elements. 3. Preserve one clear primary action and the incumbent identity. 4. Remove glow, gradients, glass, stripes, pills, badges, and shadows that carry no task or state. 5. Verify hierarchy remains strong rather than becoming flat. ## distill 1. Identify the user's primary decision or action. 2. Remove duplicate labels, repeated explanation, redundant cards, and decorative chrome. 3. Group secondary actions and progressively disclose advanced options. 4. Flatten nested surfaces and reduce visible choices to manageable groups. 5. Verify required information, recovery, and accessibility remain intact. ## clarify 1. Identify what the user must understand and do next. 2. Replace jargon and generic claims with concrete actions and outcomes. 3. Make controls name their action; make errors name problem and recovery. 4. Remove repeated copy, forced contrast slogans, and em-dash-heavy phrasing. 5. Test labels in context, including destructive actions and empty/error states. ## adapt 1. Preserve product truth, visual world, and task. 2. Recompose rather than merely scale: reorder, collapse, pin, scroll, or disclose according to the target device. 3. Respect platform-native navigation, controls, safe areas, input methods, and density. 4. Test intermediate sizes, orientation, text scaling, touch, keyboard, and reduced motion. 5. Verify no content or capability disappears without an intentional alternative. ## harden Design and test default, loading, empty, error, success, disabled, permission, offline, slow, missing-data, long-content, localization, and concurrent-action states. Make recovery explicit, preserve entered data, prevent duplicate actions, handle interrupted navigation, and verify screen-reader announcements. ## onboard 1. Define the first useful result, not a tour completion. 2. Teach through action with realistic defaults or sample data. 3. Use empty states as activation paths. 4. Defer optional setup and advanced configuration. 5. Preserve skip, back, resume, and recovery paths. 6. Measure whether users reach value, not whether slides were viewed. ## optimize 1. Establish a baseline from browser measurements or profiler evidence. 2. Prioritize user-visible bottlenecks: loading, LCP, INP, CLS, long tasks, images, fonts, and render churn. 3. Fix the cause at the narrowest level. 4. Re-measure under the same conditions. 5. Report before/after evidence; label anything unmeasured as potential impact. ## delight 1. Find a meaningful moment: completion, discovery, mastery, collaboration, or recovery. 2. Tie delight to product language, data, assets, or interaction—not generic confetti. 3. Keep it brief, optional, accessible, and repeat-safe. 4. Ensure it never delays the task or obscures state. ## overdrive 1. Confirm the brief permits experimental expression. 2. Choose one technically ambitious mechanism rooted in the product world. 3. Build the real technique rather than a static imitation. 4. Budget performance, input compatibility, fallbacks, reduced motion, and accessibility. 5. Keep task, content, and action legible; spectacle cannot become the only interface. ## polish 1. Read the incumbent system and preserve its identity. 2. Classify each issue: missing token, one-off implementation, conceptual mismatch, or local defect. 3. Triage task blockers and missing states before visual details. 4. Fix the whole path at representative viewports and input methods. 5. Run one batched inspection, one fix batch, and one confirmation round. 6. Finish with a clean diff and no temporary artifacts. ## document 1. Extract observed tokens and component patterns from source and rendered output. 2. Ask before replacing an existing DESIGN.md. 3. Write canonical sections: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. 4. Keep token values normative and prose contextual. 5. Record only durable, evidenced decisions. ## extract 1. Inventory repeated visual patterns and their semantics. 2. Merge only patterns with the same purpose and behavior; similarity alone is insufficient. 3. Promote stable primitives to tokens and stable behavior to shared components. 4. Preserve variants that express real state or task differences. 5. Migrate usages incrementally and verify visual/behavioral parity. ## Attribution Adapted for Viserys from Impeccable command guidance by Paul Bakaus, Apache-2.0. Modifications consolidate command playbooks and remove upstream-specific runtime mechanics. ``` ## File: skills/get-design/references/routing.md size: 3316 sha: c3cd25ea68ac66db7a0bf33c3c3fd4ffbde9d5bb upstream: https://github.com/rizqinrr/viserys-agent/blob/main/skills/get-design/references/routing.md ```text # Get Design Router Resolve `/get-design ` into one workflow. Never run every branch. ## Modes | Mode | Purpose | Writes files? | |---|---|---| | `new` | Create or replace a surface and visual direction, then implement when requested | Yes | | `shape` | Resolve UX, composition, and visual direction before code | Only design artifacts | | `critique` | Design-director review of specificity, usability, cognition, and emotional fit | No | | `audit` | Technical review of accessibility, performance, theming, responsive behavior, and integrity | No | | `polish` | Finish an existing interface while preserving its identity | Yes | | `layout` | Improve hierarchy, grouping, rhythm, density, and responsive composition | Yes | | `typeset` | Improve type character, hierarchy, measure, wrapping, and readability | Yes | | `colorize` | Improve palette roles, contrast, states, and thematic coherence | Yes | | `animate` | Add purposeful state and relationship motion | Yes | | `bolder` | Increase presence while preserving product truth and system coherence | Yes | | `quieter` | Reduce noise and competing emphasis without erasing identity | Yes | | `distill` | Remove clutter, redundant chrome, explanation, and actions | Yes | | `clarify` | Improve labels, instructions, errors, empty states, and calls to action | Yes | | `adapt` | Adapt an existing surface to another viewport, device, or platform | Yes | | `harden` | Complete failure, edge, data, content, localization, and permission states | Yes | | `onboard` | Design first-run, activation, empty state, and learning-by-doing flows | Yes | | `optimize` | Measure and improve UI performance | Yes | | `delight` | Add a product-specific meaningful moment | Yes | | `overdrive` | Push visual/technical ambition without sacrificing clarity or accessibility | Yes | | `document` | Capture the existing design system in DESIGN.md | Design artifacts | | `extract` | Consolidate repeated visual patterns into tokens/components when semantics match | Yes | ## No mode supplied Inspect available context and present 2–3 recommendations followed by the compact mode table. Do not auto-run a mode. Prefer: - Missing product context → ask for audience, task, success, constraints. - New or replacement surface → `new` or `shape`. - Generic or confusing existing page → `critique`. - Accessibility/responsive/runtime concern → `audit`. - Known issues and desired fixes → focused mode, then `polish`. - Repeated visual drift with no DESIGN.md → `document` or `extract`. ## Composition with Viserys - Requirements: `get-prd` supplies product requirements and entity models in `docs/PRD.md`. - Visual & Design: `get-design` supplies bespoke visual direction, design tokens, responsive breakpoints, and component state specifications in `docs/design.md`. - Tasks & Execution: `get-tasks` decomposes the approved PRD and design direction into executable task files. - Verification: run the surface in a browser and capture runtime evidence with the tooling available in the harness. ## Rule loading Every mode uses `anti-ai-slop-catalog.md` as a review baseline. Load it immediately before design edits or a critique/audit pass. Apply the craft floor and relevant category checks, but preserve explicit product and design-system decisions. ``` ## File: README.md upstream: https://github.com/rizqinrr/viserys-agent/blob/main/README.md ````text ``` .---------------------------------------------------------------. |'||' '|' '||' .|'''.| '||''''| '||''|. '||' '|' .|'''.| | | '|. .' || ||.. ' || . || || || | ||.. ' | | || | || ''|||. ||''| ||''|' || ''|||. | | ||| || . '|| || || |. || . '||| | | .||. |'....|' .||.....| .||. '|' .||. |'....|' | '---------------------------------------------------------------' ``` # Viserys [![Agent Skills](https://img.shields.io/badge/skills.sh-rizqinrr%2Fviserys--agent-18181b?logo=vercel&logoColor=white)](https://skills.sh/rizqinrr/viserys-agent) [![Showcase Web](https://img.shields.io/badge/demo-GitHub%20Pages-2563eb)](https://rizqinrr.github.io/viserys-agent/) [![License](https://img.shields.io/badge/license-Apache%202.0-green.svg)](LICENSE) [![Tests Passing](https://img.shields.io/badge/tests-62%20passed-brightgreen)](#validation) Engineering workflow pack untuk AI coding agents. Viserys memberi AI proses rekayasa perangkat lunak yang terstruktur—mencegah agent melakukan *vibe coding* serampangan tanpa spesifikasi, tanpa dekomposisi tugas, dan tanpa standar visual. ```text INTERVIEW & SPEC (get-prd) ──→ VERTICAL TASK SLICES (get-tasks) ──→ BESPOKE UI SPEC (get-design) ``` Core Viserys terdiri dari Markdown murni dan validator Node.js tanpa runtime aplikasi atau dependensi network. Kompatibel out-of-the-box dengan Claude Code, Cursor, Windsurf, OpenCode, Gemini CLI, dan Antigravity. --- ## Quick Install ### 1. Universal Install (`npx skills`) Gunakan package manager skill dari Vercel / Agent Skills ecosystem untuk menambahkan Viserys ke agent pilihan Anda (Claude Code, Cursor, Windsurf, Codex, dll.): ```bash # Install semua core skills ke agent aktif npx skills add rizqinrr/viserys-agent # Atau install secara spesifik per skill npx skills add rizqinrr/viserys-agent --skill get-prd ``` ### 2. OpenCode Project Scope Buka repositori ini langsung dari OpenCode: ```text 1. Buka folder repositori dari OpenCode. 2. Tekan Tab. 3. Pilih agent viserys. ``` ### 3. Claude Code Plugin Install langsung dari checkout lokal repositori: ```bash claude plugin validate . claude plugin marketplace add ./ claude plugin install viserys@viserys --scope user ``` --- ## 3 Core Pillars Viserys berfokus pada tiga alur kerja rekayasa berkekuatan tinggi yang menghasilkan deliverable terstandarisasi: ``` get-prd (docs/PRD.md) ──→ get-tasks (tasks//plan.md) ──→ get-design (docs/design.md) ``` | Skill | Deliverable | Kapan Digunakan | |---|---|---| | **`get-prd`** | `docs/PRD.md` | Memulai inisiatif, fitur, atau sistem baru. Menjalankan *structured interview*, validasi problem, ekstraksi intent, identifikasi batasan (NFRs/SLAs), dan perancangan entitas data inti. | | **`get-tasks`** | `tasks//plan.md` & `task-*.md` | PRD telah disetujui. Memecah spesifikasi menjadi *vertical task slices*, urutan dependensi, kriteria penerimaan terukur, dan gate verifikasi TDD. | | **`get-design`** | `docs/design.md` | Merancang antarmuka produk web/aplikasi. Menghapus estetika generik "AI slop", menetapkan token desain unik, breakpoint responsif (mobile-first), dan kelengkapan state interaktif. | Detail trigger, batasan, dan kontrak tiap skill: [`docs/skills.md`](docs/skills.md). --- ## Cara Memakai Viserys ### 1. Natural Language Intent (Automatic Routing) Cukup ajak bicara agent Anda secara natural, agent akan memilih skill yang sesuai secara otomatis: ```text "Saya mau bikin fitur autentikasi multi-tenant baru, tolong interview saya." → Memanggil get-prd ``` ```text "PRD di docs/PRD.md sudah disetujui, tolong breakdown jadi task yang bisa dieksekusi subagent." → Memanggil get-tasks ``` ```text "Desain antarmuka dashboard monitoring ini, jangan buat yang terlihat generic AI slop." → Memanggil get-design ``` ### 2. Direct Slash Commands Tersedia slash command untuk Claude Code, Gemini CLI, dan Antigravity: | Perintah | Deskripsi | Target Deliverable | |---|---|---| | `/get-prd` | Wawancara terstruktur & spesifikasi mendalam | `docs/PRD.md` | | `/get-tasks` | Dekomposisi tugas vertikal & verifikasi TDD | `tasks//plan.md` | | `/get-design` | Arah visual, tokens, dan state antarmuka | `docs/design.md` | Detail kontrak perintah: [`docs/commands.md`](docs/commands.md). --- ## Ekosistem & Komponen Pendukung Selain 3 core skills, Viserys menyertakan komponen rekayasa pendukung: - **7 Specialist Personas** (`agents/`) — persona prompt ahli untuk subagent (`strategist`, `maester`, `kingsguard`, `prover`, `racer`, `artisan`, `chronicler`). - **7 Shared Checklists** (`references/`) — checklist siap pakai untuk security, testing, Core Web Vitals, definition of done, dan orchestrasi. - **Structural Validators & Evals** (`scripts/`, `evals/`) — suite pengujian otomatis untuk memverifikasi konsistensi routing, format frontmatter, versioning, dan trigger rank-1. --- ## Matriks Dukungan Harness | Platform / Agent | Metode Integrasi | Status | |---|---|---| | **Claude Code** | Plugin lokal atau `npx skills add` | Didukung penuh & diuji di CI | | **Cursor / Windsurf** | `npx skills add rizqinrr/viserys-agent` | Didukung via open agent-skills standard | | **OpenCode** | Project adapter (`.opencode/`) & global config | Didukung | | **Antigravity** | Adapter di `commands/` | Structurally validated | | **Gemini CLI** | Adapter di `.gemini/commands/` | Structurally validated | Panduan instalasi lengkap: [`docs/installation.md`](docs/installation.md). --- ## Repository Map | Path | Isi | |---|---| | `skills/` | 3 core workflow skills (`get-prd`, `get-tasks`, `get-design`) dan per-skill references | | `agents/` | 7 specialist persona prompts | | `site/` | Web showcase & viewer interaktif untuk GitHub Pages | | `references/` | Shared checklists dan panduan orkestrasi | | `.claude/commands/` | Claude Code command adapters | | `.gemini/commands/` | Gemini CLI command adapters | | `commands/` | Antigravity command adapters | | `.opencode/` + `opencode.json` | OpenCode agent/command adapters dan root project config | | `evals/` | Evals suite deterministik & behavioral fixtures | | `scripts/` | Validator struktural, eval runner, dan unit test suites | | `docs/` | Dokumentasi spesifikasi, instalasi, dan authoring | --- ## Validation Semua perubahan pada repositori dijaga oleh validator deterministik: ```bash # Validasi struktur skill, perintah, dan manifest node scripts/validate-skills.js node scripts/validate-commands.js node scripts/validate-personas.js node scripts/validate-artifact-paths.js node scripts/validate-reference-links.js node scripts/validate-versions.js # Validasi trigger evals (Tier-2) node scripts/run-evals.js --min-rank1 95 # Unit test suites (62 tests) node --test scripts/*-test.js scripts/lib/*-test.js ``` --- ## Community & Links - **Web Showcase**: [https://rizqinrr.github.io/viserys-agent/](https://rizqinrr.github.io/viserys-agent/) - **Skills.sh Registry**: [https://skills.sh/rizqinrr/viserys-agent](https://skills.sh/rizqinrr/viserys-agent) - **Discord Community**: [Join Discord Viserys](https://discord.gg/WR6rg5YAy) --- ## License Viserys dilisensikan di bawah [Apache License 2.0](LICENSE). Copyright 2026 rizqinrr. Materi `get-design` mengadaptasi panduan Apache-2.0 dari Impeccable; atribusi upstream dipertahankan pada file adaptasi yang relevan. ````