@jini-ai/agent-plugins 0.6.15-rc.2 → 0.6.16

package/ui-ux-design/skills/ui-ux-design/references/components-and-states.md

@@ -1,107 +0,0 @@
-# Components and States
-
-Use this reference when defining the reusable UI pieces and behavior needed for implementation.
-
-## Component-First Rule
-
-Do not spec isolated screens only. Identify the reusable components first, then define where they are used.
-
-## Minimum Component Inventory
-
-Consider whether the feature needs:
-
-- buttons and links
-- text inputs, selects, checkboxes, radios, switches
-- search/filter controls
-- cards, lists, tables
-- tabs, accordions, drawers, modals
-- toasts, alerts, banners
-- skeletons, spinners, progress indicators
-- empty-state blocks
-- navigation elements
-
-## State Matrix
-
-Every key interactive component should define:
-
-- default
-- hover
-- focus-visible
-- active/pressed
-- disabled
-- loading
-- error
-- success
-
-Feature-level surfaces should also define:
-
-- empty
-- partial data
-- failure/retry
-- permission denied
-- offline or degraded mode when relevant
-
-## Interaction Rules
-
-Document:
-
-- trigger action
-- feedback timing
-- validation timing
-- keyboard behavior
-- focus movement
-- escape and dismissal rules
-- optimistic vs confirmed feedback
-
-## Forms
-
-Specify:
-
-- visible labels
-- helper text
-- required/optional treatment
-- inline validation behavior
-- error copy style
-- submit loading state
-- success confirmation behavior
-
-Do not rely on placeholder text as the label.
-
-## Tables and Dense Data
-
-Define:
-
-- row density
-- sorting/filter controls
-- responsive fallback
-- sticky columns/headers if needed
-- loading and empty-state behavior
-- selected-row or bulk-action behavior
-
-## Navigation
-
-Specify:
-
-- information hierarchy
-- current-page indicator
-- hover/focus treatment
-- mobile adaptation
-- overflow behavior
-
-## Anti-Patterns
-
-- components with only happy-path states
-- focus styles omitted because they "look ugly"
-- error feedback shown only through color
-- modal/dialog flows without focus return
-- hover-only affordances on mobile-relevant UI
-- components invented without checking existing system primitives
-
-## Output Checklist
-
-- component inventory listed
-- state matrix covered
-- interaction rules documented
-- form behavior defined where needed
-- navigation behavior defined where needed
-- implementation notes point to reusable primitives, not one-off styling

package/ui-ux-design/skills/ui-ux-design/references/delight-and-motion.md

@@ -1,65 +0,0 @@
-# Delight and Motion
-
-Use this reference when the product should feel lively, memorable, or distinctive without sacrificing usability.
-
-## Default Rule
-
-Delight is optional. Clarity, speed, and accessibility are not.
-
-## Appropriate Uses
-
-- celebratory success states
-- onboarding encouragement
-- empty states that benefit from warmth
-- lightweight hover/focus feedback
-- brand personality in low-risk surfaces
-
-## Motion Rules
-
-Motion should:
-
-- clarify state change
-- reinforce hierarchy
-- acknowledge user action
-- reduce abruptness
-
-Motion should not:
-
-- block task completion
-- hide information
-- trigger distraction loops
-- ignore reduced-motion preferences
-
-## Microcopy Rules
-
-Use personality carefully in:
-
-- loading text
-- empty states
-- success confirmations
-- low-severity errors
-
-Keep copy:
-
-- short
-- helpful
-- brand-consistent
-- non-patronizing
-
-Avoid jokey or cute copy in high-stress flows such as payments, security, legal consent, or destructive actions.
-
-## Delight Spectrum
-
-- subtle: hover, focus, small success feedback
-- moderate: celebratory completion feedback, richer empty states, guided encouragement
-- strong: campaign-specific personality, easter eggs, playful brand moments
-
-Default to subtle unless the product context supports more.
-
-## Anti-Patterns
-
-- confetti for routine actions
-- whimsical error text during serious failure states
-- animations that slow repeated workflows
-- easter eggs on business-critical surfaces
-- personality that breaks brand trust

package/ui-ux-design/skills/ui-ux-design/references/foundations.md

@@ -1,144 +0,0 @@
-# Foundations
-
-Use this reference when creating or extending the visual system for a product or feature.
-
-## Goals
-
-- Define a stable visual foundation before designing individual screens.
-- Give Programmer a constrained, reusable system instead of one-off styling decisions.
-- Preserve existing product patterns unless the user explicitly wants a new direction.
-
-## Required Decisions
-
-1. Visual direction
-2. Color and semantic token system
-3. Typography hierarchy
-4. Spacing scale
-5. Layout/container/grid rules
-6. Breakpoint behavior
-7. Elevation, border, radius, and motion primitives
-
-## Minimum Foundation Contract
-
-### Visual Direction
-
-Define:
-
-- product character in 3-5 adjectives
-- intended level of formality
-- density target: compact, balanced, spacious
-- contrast profile: restrained, moderate, bold
-- reuse vs reinvention decision
-
-If working within an existing system, document continuation rules instead of inventing a new style.
-
-### Token Categories
-
-Create or extend tokens for:
-
-- surface/background
-- text/foreground
-- border/separator
-- interactive/brand
-- success/warning/error/info
-- focus ring
-- shadow/elevation
-- radius
-- spacing
-- typography
-- motion duration/easing
-
-Prefer semantic names over raw color names.
-
-### Typography
-
-Define:
-
-- display or hero style if needed
-- heading scale
-- body sizes
-- caption/supporting text
-- monospace usage if relevant
-- line-height and weight rules
-
-Check:
-
-- readable body sizing on mobile first
-- heading contrast and hierarchy
-- no decorative type that harms readability
-
-### Spacing
-
-Use a consistent scale. Typical safe pattern:
-
-- `4, 8, 12, 16, 24, 32, 48, 64`
-
-Apply the same scale to:
-
-- margins
-- padding
-- grid gaps
-- section rhythm
-- component spacing
-
-### Layout
-
-Define:
-
-- max content widths
-- section padding rules
-- grid column behavior
-- stack behavior on narrow screens
-- sticky or persistent UI elements if any
-
-Default to mobile-first.
-
-### Breakpoints
-
-Document behavior at:
-
-- mobile
-- tablet
-- desktop
-- large desktop if relevant
-
-Describe behavior, not just widths:
-
-- navigation changes
-- card/list reflow
-- sidebar collapse/expand
-- media cropping
-- density and spacing adjustments
-
-## Theming
-
-Do not require multiple themes by default.
-
-If theming is in scope, define:
-
-- what tokens change
-- contrast rules
-- image/media treatment changes
-- persistence behavior
-
-Do not add a theme toggle only because it is possible.
-
-## Anti-Patterns
-
-- hardcoded one-off colors across components
-- spacing chosen ad hoc per screen
-- headings without a system
-- desktop-first layout that collapses poorly on mobile
-- decorative motion without purpose
-- dark mode or theme switching as mandatory default
-
-## Output Checklist
-
-- visual direction named
-- semantic token groups defined
-- typography hierarchy defined
-- spacing scale defined
-- breakpoints documented
-- layout rules documented
-- motion/elevation basics documented
-- assumptions and constraints explicitly noted

package/ui-ux-design/skills/ui-ux-design/references/inclusive-ai-imagery.md

@@ -1,57 +0,0 @@
-# Inclusive AI Imagery
-
-Use this reference only when image or video generation is part of the design task.
-
-## Core Rule
-
-Identity is not a decorative adjective. Generated imagery must avoid stereotype defaults, tokenism, and incoherent cultural details.
-
-## Prompt Structure
-
-Build prompts in layers:
-
-1. subject
-2. action or pose
-3. environment and geographic/cultural context
-4. lighting and camera treatment
-5. style or medium
-6. explicit negative constraints
-
-## Inclusive Representation Constraints
-
-Specify when relevant:
-
-- distinct faces, body types, ages, and attire
-- authentic geography and architecture
-- accurate cultural clothing or symbols
-- realistic lighting for different skin tones
-- mobility aids and assistive devices with physical realism
-
-## Negative Prompt Themes
-
-Block:
-
-- clone faces
-- gibberish text or fake signage
-- exoticized or sensationalized framing
-- oversized symbolic props replacing the human subject
-- malformed hands, limbs, or devices
-- futuristic or stock-photo tropes unless intentionally requested
-
-## Review Checklist
-
-Before approving generated imagery, check:
-
-- is the subject depicted with dignity and agency
-- does the environment fit the claimed context
-- are there stereotype shortcuts
-- do multiple people look meaningfully distinct
-- is any text, signage, or symbolism coherent
-- do clothing, hair, and movement obey physical reality
-
-## Anti-Patterns
-
-- "diverse team" prompts with no specificity
-- relying on ethnicity descriptors without contextual realism
-- using image prompts as a substitute for real brand/art direction
-- importing imagery guidance into tasks that only need UI design

package/ui-ux-design/skills/ui-ux-design/references/kole-jain-uiux-concepts.md

@@ -1,102 +0,0 @@
-# Kole Jain UI/UX Concepts Notes
-
-Source context: extracted from the user-provided transcript `Every UIUX Concept Explained in Under 10 Minutes.txt`, attributed to Kole Jain.
-
-## Core Thesis
-
-Good UI/UX makes behavior legible without explanation. Interfaces should communicate relationship, importance, state, affordance, and feedback through visual structure: signifiers, hierarchy, whitespace, typography, color, depth, icons, component states, and micro-interactions.
-
-## Signifiers And Affordances
-
-- Use visible cues to show what an element is, what it can do, and what state it is in.
-- Examples: active nav highlights, selected containers, disabled opacity, button press states, hover states, focus states, and tooltips.
-- A user should often understand interaction rules before reading instructions.
-- Treat missing state feedback as a UX bug, not just a polish gap.
-
-## Hierarchy
-
-- Use size, position, color, imagery, and contrast to tell users what matters first.
-- Put the most important information near the top or in the strongest visual position.
-- Use images when they materially improve scanning or recognition.
-- Make high-value facts visually distinct: for example, price, status, active item, or primary action.
-- Use icons and visual relationships to reduce unnecessary labels when the meaning is clear.
-
-## Layout, Whitespace, And Grids
-
-- Treat column grids and spacing systems as guidelines, not hard laws.
-- Use grids most strictly for structured repeated content such as galleries, blogs, lists, and responsive card layouts.
-- For custom landing pages, prioritize breathing room and visual composition over forcing every element into a rigid grid.
-- Use whitespace to group related elements and separate unrelated elements.
-- A 4-point grid can work well because values split cleanly and keep spacing consistent.
-- Keep spacing intentional even when it is not mathematically rigid.
-
-## Typography
-
-- Most UI is text, so typography carries a large part of the design.
-- One strong sans-serif family is often enough for product UI.
-- Tighten large heading letter spacing slightly and use compact heading line height, roughly 110-120%, when it improves polish and readability.
-- Landing pages can use a broader type range, but keep the number of font sizes limited.
-- Dense dashboards and app screens usually need a tighter type range; large display sizes often become impractical.
-- Spend less time hunting fonts for product UI and more time making hierarchy, spacing, and states work.
-
-## Color
-
-- Start with one primary brand color and derive lighter backgrounds or darker text treatments from it.
-- Build toward a color ramp when the interface needs chips, states, charts, and repeated semantic uses.
-- Use semantic colors for meaning: danger, warning, success, trust, focus, urgency, or newness.
-- Use color for purpose, not decoration.
-- In dark mode, reduce harsh borders and create depth by making foreground surfaces slightly lighter than the background.
-- Dim overly bright chips or accents in dark mode and preserve hierarchy with adjusted saturation, brightness, and text contrast.
-
-## Depth And Shadows
-
-- In light mode, use shadows to separate layers, but keep them subtle.
-- Reduce shadow opacity and increase blur when shadows feel too harsh.
-- Cards generally need lighter shadows than popovers or surfaces that sit above other content.
-- Use inner and outer shadows when a tactile raised control is appropriate.
-- If the shadow is the first thing the user notices, it is too strong.
-
-## Icons And Buttons
-
-- Size icons to match the related text line height where practical.
-- Tighten icon-and-label spacing so pairs feel intentional.
-- Treat sidebar links and subtle nav actions as ghost buttons: no background by default, visible response on hover or active state.
-- For button padding, a useful default is more horizontal than vertical padding, often about double.
-- Use icons in buttons when they clarify action, status, or scanability.
-
-## States And Feedback
-
-- Every user action should produce a response.
-- Buttons need at least default, hover, active/pressed, and disabled states; loading states are needed when work is pending.
-- Inputs need focus, error, and message states; warning states can help with optional or recoverable issues.
-- Data fetching needs loading feedback. Completed actions need success feedback.
-- Swipe, scroll, copy, submit, selection, and navigation actions should make the result visible.
-
-## Micro-Interactions
-
-- Use micro-interactions as feedback that confirms an action or helps the user understand what changed.
-- Practical examples include a copied confirmation, a small chip animation, a state transition, or a completion cue.
-- Keep playful motion subordinate to clarity and task completion.
-
-## Text Over Images
-
-- Do not put text directly over images without protecting readability.
-- Use overlays, gradients, or progressive blur to preserve the image while creating a readable text zone.
-- Prefer a directional gradient when the text occupies one side or edge of the image.
-- Ensure the final composition preserves both image quality and text contrast.
-
-## Practical Audit Checklist
-
-- Does the UI communicate clickable, selected, disabled, loading, and error states?
-- Can users infer what controls afford before reading instructions?
-- Is the most important information visually dominant?
-- Are related elements grouped by proximity, container, or spacing?
-- Does whitespace make the screen easier to parse?
-- Are type sizes appropriate for the surface: broader for landing pages, tighter for dense apps?
-- Are colors semantic and purposeful?
-- Does dark mode avoid harsh borders and overbright accents?
-- Are shadows subtle and layer-appropriate?
-- Do icons align with the text they support?
-- Do all user actions produce visible feedback?
-- Are micro-interactions confirming real outcomes rather than decorating the page?
-- Is text over imagery protected by a readable overlay or blur treatment?

package/ui-ux-design/skills/ui-ux-design/references/openai-frontend-skill.md

@@ -1,139 +0,0 @@
-# OpenAI Frontend Skill Reference
-
-Use this reference for visually led landing pages, branded demos, polished prototypes, and other frontend work where composition and art direction matter more than component count.
-
-Source note: adapted into local reference form from OpenAI's curated frontend skill on 2026-03-21 so this repo does not need to fetch it from the web during use.
-
-## Activation Guardrail
-
-- Hard guard: if you activate this reference, explicitly tell the user in your next reply that you are using `openai-frontend-skill.md`.
-- Say why it was activated in plain language, such as landing-page composition, branded demo direction, or anti-generic UI guidance.
-- Do this before presenting design direction, layout proposals, or stylistic recommendations derived from this reference.
-- If the user does not want this direction, stop using this reference and fall back to the base UX skill plus the other applicable local references.
-
-## Working Model
-
-Before designing, define:
-
-1. visual thesis: the mood, material, and energy
-2. content plan: hero, support, detail, final CTA
-3. interaction thesis: 2-3 motions that materially change the feel
-
-Each section should have one job, one dominant visual idea, and one primary takeaway or action.
-
-## Composition Defaults
-
-- Start with composition before components.
-- Prefer one strong visual anchor in the first viewport.
-- Treat the first screen like a poster, not a document.
-- Make the brand or product name the loudest text on branded pages.
-- Use spacing, scale, alignment, contrast, and cropping before adding extra UI chrome.
-- Limit the system by default: two typefaces max, one accent color max.
-- Default to cardless layouts unless the card itself is the interaction.
-
-## Landing Page Sequence
-
-Default structure:
-
-1. hero: product or brand, promise, CTA, dominant visual
-2. support: one concrete feature, offer, or proof point
-3. detail: workflow, atmosphere, depth, or story
-4. final CTA: start, contact, convert, or visit
-
-## Hero Rules
-
-- One composition only.
-- Use a full-bleed image or another dominant visual plane when the brief supports it.
-- Keep the text column narrow and placed over a calm visual area.
-- Keep headlines readable in one glance.
-- Preserve contrast and tap-target clarity for text over imagery.
-- If the header is sticky or fixed, count it against the viewport budget.
-- Avoid stacking persistent chrome above a `100vh` or `100svh` hero without accounting for that space.
-
-## Product UI Rules
-
-For app surfaces, use restraint:
-
-- calm hierarchy
-- strong typography
-- dense but readable information
-- minimal chrome
-- cards only when the card is the interaction
-
-Organize product UI around:
-
-- primary workspace
-- navigation
-- secondary context or inspector
-- one clear accent for action or state
-
-## Imagery Rules
-
-- Imagery must do narrative work, not just fill space.
-- Prefer strong, real-looking photography for brands, editorial, venue, or lifestyle surfaces.
-- Choose crops with a stable tonal area for text.
-- Avoid embedded signage, logos, or typography fighting the UI.
-- If several moments are needed, use several images instead of a collage.
-
-## Copy Rules
-
-- Write in product language, not design commentary.
-- Let the headline carry meaning.
-- Keep supporting copy short.
-- Cut repetition between sections.
-- Give each section one responsibility: explain, prove, deepen, or convert.
-
-For dashboards or operational UI:
-
-- prefer utility copy over marketing copy
-- lead with status, action, scope, or decision value
-- avoid homepage-style hero language unless explicitly requested
-
-## Motion Rules
-
-Ship a small number of intentional motions for visually led work:
-
-- one entrance sequence in the hero
-- one scroll, sticky, or depth effect
-- one hover, reveal, or layout transition
-
-Motion should be:
-
-- noticeable in a quick recording
-- smooth on mobile
-- fast and restrained
-- consistent across the page
-- removed when it is ornamental only
-
-## Hard Bans
-
-- no cards by default
-- no hero cards by default
-- no boxed center-column hero when the brief wants full bleed
-- no more than one dominant idea per section
-- no filler copy
-- no busy imagery behind text
-- no split-screen hero unless one side stays visually calm
-- no more than two typefaces without a reason
-- no more than one accent color unless the product already has a system
-
-## Failure Checks
-
-Reject or revise when you see:
-
-- generic SaaS card grid as the first impression
-- strong image but weak brand presence
-- strong headline but no clear action
-- repeated mood-setting sections with no informational progression
-- carousel with no narrative purpose
-- app UI built from stacked cards instead of layout
-
-## Litmus Checks
-
-- Is the brand or product unmistakable in the first screen?
-- Is there one strong visual anchor?
-- Can the page be understood by scanning headlines?
-- Does each section have one job?
-- Are cards actually necessary?
-- Does motion improve hierarchy or atmosphere?
-- Would the design still feel strong if shadows and decorative polish were removed?

package/ui-ux-design/skills/ui-ux-design/references/premium-ui.md

@@ -1,63 +0,0 @@
-# Premium UI
-
-Premium web and product UI guidance: raising perceived quality without sacrificing
-clarity, conversion, performance, accessibility, or maintainability.
-
-Load for websites, landing pages, SaaS screens, hero sections, service pages,
-ecommerce pages, portfolios, dashboards, and UI copy where the ask is a premium,
-expensive, luxury, high-converting, agency-grade, high-trust, or visually elevated
-result.
-
-## Workflow
-
-1. Define the desired first-impression feeling: calm, confidence, authority, excitement, exclusivity, technical competence, or another specific mood.
-2. Design for scanners first: make the offer, audience, proof, and next action obvious within seconds.
-3. Reduce cognitive load: simplify navigation, remove weak copy, make each section serve one primary job, and preserve strong visual hierarchy.
-4. Add premium signals deliberately: bespoke assets, cohesive brand system, real imagery, credible metrics, careful typography, generous spacing, and subtle interaction feedback.
-5. Protect business outcomes: keep CTAs clear, page flow intentional, pricing/filtering honest where appropriate, and pages focused on the customer result.
-6. Validate with a blink test, mobile performance check, responsive review, and conversion-path review.
-
-## Read These Three With This File
-
-**Load all three now — do not wait for a trigger.** They are ~19KB combined
-(~5k tokens), and they carry the specifics this file only summarizes. An earlier
-version gated them on the user naming their sources, which is a condition that
-never fires: nobody asks for design help by naming the transcript it came from.
-The result was premium work done from the summary alone, which is how output ends
-up looking templated.
-
-| File | What it gives you |
-|---|---|
-| `sam-crawford-premium-websites.md` | The premium-website audit checklist and the psychology behind it — halo effect, cognitive fluency, hero and first-viewport decisions, brand polish, copy density, real imagery, page structure, restrained animation, client ownership and post-launch care |
-| `self-made-web-designer-core-skills.md` | The repeatable fundamentals — typography, layout, spacing, color, code literacy, conversion thinking — plus fast upgrades to an existing site: font pairing, a focal visual idea, visual rhyming, depth, opacity hierarchy, and forcing divergent variants instead of shipping the first workable one |
-| `kole-jain-uiux-concepts.md` | Product-UI specifics — signifiers and affordances, hierarchy, whitespace, typography ranges, color semantics, dark mode, shadows, icons, buttons, component states, micro-interactions, text-over-image overlays |
-
-Skip one only when the surface is plainly outside its scope — `kole-jain` adds
-little to a one-page marketing site with no components, and `sam-crawford` adds
-little to an internal admin panel nobody is being sold on.
-
-They are design schools, not absolute rules. When they conflict, state the
-tradeoff, pick the advice that best fits the product, audience, and business goal,
-and avoid blending incompatible aesthetics without a clear reason.
-
-## Standards
-
-- Prefer clear, confident layouts over decorative complexity.
-- Use real product, team, customer, venue, or process imagery when authenticity matters; avoid generic stock-photo signals.
-- Make bespoke visuals purposeful: guide the eye, break up content, explain value, or create brand distinction.
-- Keep animation subtle enough to be felt more than noticed. Use it for feedback, orientation, and flow, not spectacle.
-- Let copy sell outcomes and transformations, not just features or internal history.
-- Give every page a job and every section a next step.
-- If a site is meant to be client-owned or maintained, design editing surfaces and content models that make updates practical.
-- Avoid premium-looking decisions that harm load time, accessibility, comprehension, or buyer confidence.
-
-## Output Expectations
-
-Include the concrete decisions that matter most for the task:
-
-- First-impression target
-- Visual hierarchy and layout direction
-- Asset and imagery plan
-- Copy/CTA approach
-- Interaction and animation restraint
-- Risks or tradeoffs, especially around performance, accessibility, conversion, and maintainability