@jini-ai/agent-plugins 0.4.0

package/ui-ux-design/skills/gstack-design/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: gstack-design
+version: 0.1.0
+last_updated: 2026-06-05
+description: Use when a user manually invokes gstack-inspired design workflows for product design consultation, visual variants, frontend implementation handoff, or UI design review.
+---
+
+# Skill: gstack Design
+
+Manual/slash-invoked domain skill adapted from gstack design workflows. This skill is not wired into the default pipeline.
+
+## Execution
+
+- Determine the user's requested design mode from the prompt or slash command arguments.
+- Select exactly one mode per invocation: `consultation`, `shotgun`, `html`, or `review`.
+- Read exactly one matching reference file from `references/` before taking action.
+- Do not load all references, chain modes, or silently expand into pipeline agent dispatch.
+- Preserve existing AI Dev Shop design rules, accessibility expectations, and project constraints.
+- If the user request spans multiple modes, ask which mode to run first.
+
+## Guardrails
+
+- Do not assume upstream-specific runtime services, generated boards, analytics hooks, or external binaries exist.
+- Do not implement code during `consultation`, `shotgun`, or `review` unless the user explicitly changes scope.
+- In `html` mode, treat "html" as a legacy shorthand for frontend implementation/prototype handoff; do not force raw HTML when the project has a framework.
+- Do not replace existing brand or design systems without explicit user approval.
+- Do not claim browser or screenshot evidence unless it was actually captured in the current host.
+
+## Output
+
+Return a concise design artifact for the selected mode:
+
+- selected mode and reference used
+- inputs inspected
+- recommendation or findings
+- open questions or approval gates
+- next action, if any
+
+## Reference
+
+Read exactly one reference based on intent:
+
+- `references/consultation.md` - new product direction, design system, brand/aesthetic proposal, or design strategy.
+- `references/shotgun.md` - multiple visual directions, option exploration, comparison, or taste feedback.
+- `references/html.md` - approved design to frontend implementation guidance or static prototype.
+- `references/review.md` - audit existing UI for hierarchy, spacing, accessibility, consistency, or AI slop.
+- `references/upstream-notes.md` - provenance only; do not load for normal execution unless reviewing upstream drift.
+
+## Failure Path
+
+- If no mode is clear, ask for one choice.
+- If required product context is missing, produce a bounded assumption list rather than inventing facts.
+- If a requested action conflicts with AI Dev Shop frontend/design guardrails, state the conflict and ask for approval before proceeding.

package/ui-ux-design/skills/gstack-design/references/consultation.md

@@ -0,0 +1,30 @@
+# Design Consultation
+
+## When
+
+Use for a new product surface, design direction, brand/aesthetic pass, or design-system proposal before implementation.
+
+## Workflow
+
+1. Gather product context: target users, core workflow, business goal, platform, existing brand, and UI constraints.
+2. Inspect existing UI or design artifacts when available before proposing a new direction.
+3. Identify the design problem in plain terms: what must be easier, clearer, faster, more trusted, or more memorable.
+4. Optionally research comparable products or patterns when the user asks for market/landscape awareness.
+5. Propose one primary design direction and one credible alternative.
+6. Define foundations only as far as needed: layout principles, typography direction, color role, spacing scale, motion posture, and component tone.
+7. Call out tradeoffs: implementation complexity, accessibility risk, brand risk, and where taste decisions need human input.
+
+## Output
+
+- Context summary
+- Recommended design direction
+- Alternative direction
+- Foundations and component implications
+- Decisions needed from the user
+- Suggested next mode: `shotgun`, `html`, or `review`
+
+## Guardrails
+
+- Do not invent user research or brand evidence.
+- Do not prescribe a full redesign when a smaller design repair would solve the problem.
+- Do not pick decorative visual trends over usability, accessibility, or product fit.

package/ui-ux-design/skills/gstack-design/references/html.md

@@ -0,0 +1,29 @@
+# Frontend Implementation Handoff
+
+## When
+
+Use after a design direction is approved and the user wants a frontend implementation plan, static prototype, or production handoff. The `html` mode name is legacy shorthand; it is not a raw HTML-only constraint.
+
+## Workflow
+
+1. Confirm the approved design source: consultation output, shotgun winner, screenshot, mockup, or user description.
+2. Detect the project frontend stack when a repo is present; prefer the existing framework and design system.
+3. Convert design intent into implementable structure: layout, components, states, tokens, responsive rules, and content hierarchy.
+4. If producing static HTML/CSS, keep it semantic, responsive, accessible, and clearly labeled as a prototype.
+5. If producing framework guidance, specify components, props, state handling, CSS strategy, and verification steps.
+6. Verify the result against the approved direction using browser evidence when browser automation is available.
+
+## Output
+
+- Implementation target and assumptions
+- Component/layout plan
+- Token and style notes
+- Accessibility and responsive checks
+- Prototype or implementation handoff
+- Verification checklist
+
+## Guardrails
+
+- Do not assume upstream-specific prototype tooling or generated design-board services exist.
+- Do not ignore the host app's current framework or design system.
+- Do not skip final visual verification when browser automation is available.

package/ui-ux-design/skills/gstack-design/references/review.md

@@ -0,0 +1,28 @@
+# Design Review
+
+## When
+
+Use to audit an existing UI for design quality, usability, accessibility, visual consistency, or AI-generated slop patterns.
+
+## Workflow
+
+1. Identify the target screen, flow, or component set.
+2. Inspect available evidence: screenshots, browser state, DOM, component code, design docs, or user reports.
+3. Audit hierarchy, spacing, alignment, typography, color contrast, responsive behavior, component states, loading/empty/error states, and interaction clarity.
+4. Look for common AI slop: generic gradients, meaningless decorative visuals, mismatched radii, low-density cards, vague copy, and inconsistent spacing.
+5. Classify findings as blocker, should-fix, or polish.
+6. Recommend the smallest design change that fixes the issue before proposing a broad redesign.
+
+## Output
+
+- Evidence inspected
+- Findings by severity
+- Specific recommended fixes
+- Accessibility and responsive notes
+- Follow-up mode if needed
+
+## Guardrails
+
+- Do not claim visual evidence without inspection.
+- Do not rewrite the product's visual direction unless the user asks.
+- Do not bury accessibility blockers under polish comments.

package/ui-ux-design/skills/gstack-design/references/shotgun.md

@@ -0,0 +1,33 @@
+# Design Shotgun
+
+## When
+
+Use when the user wants visual options, competing design directions, or a fast comparison before committing to one direction.
+
+## Workflow
+
+1. Confirm the target surface and constraints: product, audience, platform, existing UI, and non-negotiable brand or accessibility rules.
+2. Generate 3-6 meaningfully distinct directions. Avoid small variations of the same idea.
+3. For each direction, provide:
+   - name
+   - core idea
+   - visual language
+   - interaction posture
+   - accessibility and implementation tradeoffs
+4. Compare directions across brand fit, clarity, speed to build, accessibility, novelty, and maintenance cost.
+5. Ask the user for structured preference feedback: keep, reject, combine, or revise.
+6. Capture taste signals as explicit notes so the next mode can reuse them.
+
+## Output
+
+- Variant list
+- Comparison matrix
+- Recommended short list
+- Preference questions
+- Next step recommendation
+
+## Guardrails
+
+- Do not auto-select a final direction without user feedback.
+- Do not generate implementation code in this mode.
+- Do not present impossible or inaccessible designs as production-ready.

package/ui-ux-design/skills/gstack-design/references/upstream-notes.md

@@ -0,0 +1,23 @@
+# Upstream Notes
+
+## Source
+
+- Repo: `https://github.com/garrytan/gstack`
+- Local source: `/Users/la/Desktop/Multi-Agent Swarm Foundation/other-repos-to-learn-from/gstack`
+- Source commit: `cab774cc`
+- Adapted source files: `design-consultation/SKILL.md`, `design-shotgun/SKILL.md`, `design-html/SKILL.md`, `design-review/SKILL.md`
+
+## Kept
+
+- Product-context-first design consultation
+- Multiple visual directions before commitment
+- Structured comparison and taste feedback
+- Approved-design implementation/prototype handoff
+- UI review for hierarchy, spacing, accessibility, and AI slop
+
+## Stripped
+
+- Generated shared preambles and Claude-specific AskUserQuestion plumbing
+- Telemetry/config setup, taste databases, and local state scripts
+- gstack design daemon, comparison board binary, and Pretext runtime assumptions
+- Any hardcoded gstack install paths or external service requirements

package/ui-ux-design/skills/interface-design/ORIGINAL.md

@@ -0,0 +1,16 @@
+# Original Source Notes
+
+Imported from `Dammyjay93/interface-design`.
+
+Source characteristics:
+
+- plugin-oriented package for Claude Code
+- active command set under `.claude/commands`
+- source examples and system template under `reference/`
+- markdown-first design workflow centered on craft, memory, and consistency
+
+This repo normalizes that package into a single runtime skill with supporting material under `references/`.
+
+Source URL:
+
+- https://github.com/Dammyjay93/interface-design

package/ui-ux-design/skills/interface-design/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: interface-design
+version: 1.0.0
+last_updated: 2026-03-18
+description: Use when designing interfaces for dashboards, apps, tools, or admin panels where craft, memory, and consistency matter. Not for marketing sites.
+---
+
+# Skill: Interface Design
+
+Interface design here means deliberate visual systems, not generic UI output. Use this skill when the user wants a project-specific look and repeatable design decisions across sessions.
+
+## Scope
+
+- Use for product interfaces, internal tools, dashboards, admin panels, and workflow apps.
+- Do not use for marketing sites or copy-first landing pages.
+- Prefer this skill when the user wants a visual system rather than isolated component styling.
+
+## Load Strategy
+
+Read this file for the runtime contract. Open references only when you need the heavier material:
+
+- `references/system-template.md` for the `.interface-design/system.md` shape and token scaffold
+- `references/commands/init.md` for the build-first workflow
+- `references/commands/audit.md` for checking existing code against a system
+- `references/commands/extract.md` for deriving a system from existing code
+- `references/commands/status.md` for reporting the active design system
+- `references/commands/critique.md` for craft-focused review and rebuild guidance
+- `references/examples/system-precision.md` and `references/examples/system-warmth.md` for two concrete directions
+
+## Core Contract
+
+- Establish or load `.interface-design/system.md` before making repeated UI decisions.
+- Reuse spacing, radius, depth, and typography choices consistently.
+- State the design direction explicitly before building a component or screen.
+- Capture new stable patterns in `.interface-design/system.md` instead of letting them drift across files.
+
+## Practical Defaults
+
+- Keep the system tangible: direction, foundation, depth, tokens, patterns.
+- Prefer a small number of explicit design choices over a long list of vague principles.
+- When an existing interface already has a recognizable pattern set, preserve it and extend it rather than replacing it wholesale.

package/ui-ux-design/skills/interface-design/references/commands/audit.md

@@ -0,0 +1,40 @@
+# interface-design:audit
+
+Check existing interface code against the active design system.
+
+## When a System Exists
+
+Audit for:
+
+- spacing values that are off-grid
+- depth violations such as unsupported shadows or borders
+- colors outside the defined palette
+- pattern drift in buttons, cards, inputs, tables, or surfaces
+
+## Report Format
+
+```text
+Audit Results: src/components/
+
+Violations:
+  Button.tsx:12 - Height 38px (pattern: 36px)
+  Card.tsx:8 - Shadow used (system: borders-only)
+  Input.tsx:20 - Spacing 14px (grid: 4px, nearest: 12px or 16px)
+
+Suggestions:
+  - Update Button height to match pattern
+  - Replace shadow with border
+  - Adjust spacing to grid
+```
+
+## When No System Exists
+
+- State that no design system is available yet.
+- Recommend building one by implementing a screen or extracting patterns from existing code.
+
+## Implementation Notes
+
+- Read the active system file.
+- Read the target files.
+- Compare the code against the active direction, tokens, and patterns.
+- Report violations with the smallest practical fix.

package/ui-ux-design/skills/interface-design/references/commands/critique.md

@@ -0,0 +1,21 @@
+# interface-design:critique
+
+Critique a completed interface for craft, then rebuild the parts that defaulted.
+
+## Review Pass
+
+Look for:
+
+- flat or monotone composition
+- weak rhythm or spacing
+- unclear hierarchy
+- generic surfaces or border/shadow choices
+- missing interactive states
+- structure held together with layout hacks
+
+## Process
+
+1. Review the output as a design lead would.
+2. Identify where the work defaulted instead of deciding.
+3. Rebuild those parts from the decision, not from a patch.
+4. Keep the critique focused on the visible interface.

package/ui-ux-design/skills/interface-design/references/commands/extract.md

@@ -0,0 +1,34 @@
+# interface-design:extract
+
+Extract a design system from existing UI code.
+
+## What to Look For
+
+- repeated spacing values
+- repeated radius values
+- common button sizes and padding
+- repeated card treatment
+- depth strategy, especially borders vs shadows
+
+## Output Shape
+
+```text
+Extracted patterns:
+
+Spacing:
+  Base: 4px
+  Scale: 4, 8, 12, 16, 24, 32
+
+Depth: Borders-only
+
+Patterns:
+  Button: 36px h, 12px 16px pad, 6px radius
+  Card: 1px border, 16px pad
+```
+
+## Workflow
+
+1. Scan UI files.
+2. Aggregate repeated values and component patterns.
+3. Propose a system that matches the dominant pattern set.
+4. Let the user customize before saving.

package/ui-ux-design/skills/interface-design/references/commands/init.md

@@ -0,0 +1,31 @@
+# interface-design:init
+
+Build UI with a craft-first system instead of ad hoc component choices.
+
+## Workflow
+
+1. Read `SKILL.md`.
+2. Check whether `.interface-design/system.md` already exists.
+3. If it exists, apply the existing direction and patterns.
+4. If it does not exist, infer a direction from the product context and ask for confirmation before locking it in.
+5. Build the UI using the chosen direction.
+6. Offer to save any stable decisions into `.interface-design/system.md`.
+
+## Before Building Each Component
+
+State the intent and the technical approach before writing code:
+
+- who the human is
+- what they need to accomplish
+- what the screen should feel like
+- palette choice and why it fits
+- depth choice and why it fits
+- surfaces and why they fit
+- typography and why it fits
+- spacing base
+
+## Guardrails
+
+- Do not default to generic UI if the product has a distinct world or tone.
+- Do not skip the system decision step when repeated UI work is likely.
+- Do not narrate internal process to the user unless they need the design decision explained.

package/ui-ux-design/skills/interface-design/references/commands/status.md

@@ -0,0 +1,22 @@
+# interface-design:status
+
+Show the current design system state.
+
+## If a System Exists
+
+Display:
+
+- direction
+- foundation
+- depth
+- spacing base and scale
+- color token count
+- core component patterns
+- last updated timestamp
+
+## If No System Exists
+
+State that no design system is present yet and suggest:
+
+- build a screen to establish patterns
+- run `interface-design:extract` on existing code

package/ui-ux-design/skills/interface-design/references/examples/system-precision.md

@@ -0,0 +1,29 @@
+# Design System Example - Precision & Density
+
+Use this when the interface is a dense dashboard, admin panel, or technical tool.
+
+## Direction
+
+**Personality:** Precision & Density
+**Foundation:** Cool
+**Depth:** Borders-only
+
+## Tokens
+
+- Spacing base: 4px
+- Radius scale: 4px, 6px, 8px
+- Font: system-ui or Geist
+- Scale: 11, 12, 13, 14, 16, 18
+- Weights: 400, 500, 600
+
+## Patterns
+
+- Button: 32px height, compact padding, 4px radius, border-first
+- Card: faint border, 12px padding, 6px radius, no shadow
+- Table cell: 8px 12px padding, tabular numbers
+
+## Decision Bias
+
+- Prefer information density over decorative lift.
+- Prefer borders and tonal separation over heavy shadows.
+- Use compact sizing for power-user workflows.

package/ui-ux-design/skills/interface-design/references/examples/system-warmth.md

@@ -0,0 +1,29 @@
+# Design System Example - Warmth & Approachability
+
+Use this when the interface should feel friendly, collaborative, or consumer-oriented.
+
+## Direction
+
+**Personality:** Warmth & Approachability
+**Foundation:** Warm
+**Depth:** Subtle shadows
+
+## Tokens
+
+- Spacing base: 4px
+- Radius scale: 8px, 12px, 16px
+- Font: Inter or another approachable UI face
+- Scale: 13, 14, 15, 16, 18, 20, 24
+- Weights: 400, 500, 600
+
+## Patterns
+
+- Button: 40px height, comfortable padding, 8px radius
+- Card: soft shadow, 20px padding, rounded corners
+- Input: 44px height, generous padding, visible focus state
+
+## Decision Bias
+
+- Prefer soft depth and generous whitespace.
+- Prefer readable, inviting surfaces over technical density.
+- Use this when the product benefits from calm and friendliness.

package/ui-ux-design/skills/interface-design/references/system-template.md

@@ -0,0 +1,57 @@
+# Design System Template
+
+Use this as the starting shape for `.interface-design/system.md`.
+
+## Direction
+
+**Personality:** [Precision & Density | Warmth & Approachability | Sophistication & Trust | Boldness & Clarity | Utility & Function | Data & Analysis]
+
+**Foundation:** [warm | cool | neutral | tinted]
+
+**Depth:** [borders-only | subtle-shadows | layered-shadows]
+
+## Tokens
+
+### Spacing
+Base: [4px | 8px]
+Scale: [4, 8, 12, 16, 24, 32, 64]
+
+### Colors
+```css
+--foreground: [slate-900]
+--secondary: [slate-600]
+--muted: [slate-400]
+--faint: [slate-200]
+--accent: [blue-600]
+```
+
+### Radius
+Scale: [4px, 6px, 8px] (sharp) or [8px, 12px, 16px] (soft)
+
+### Typography
+Font: [system | Inter | Geist]
+Scale: 12, 13, 14 (base), 16, 18, 24, 32
+Weights: 400, 500, 600
+
+## Patterns
+
+### Button Primary
+- Height: 36px
+- Padding: 12px 16px
+- Radius: 6px
+- Font: 14px, 500 weight
+- Usage: primary actions
+
+### Card Default
+- Border: 0.5px solid (faint)
+- Padding: 16px
+- Radius: 8px
+- Background: white
+- Usage: content containers
+
+## Decisions
+
+| Decision | Rationale | Date |
+|---|---|---|
+| Borders-only depth | Dashboard tool, users want density. Shadows add visual weight without information value. | YYYY-MM-DD |
+| 4px spacing base | Tight enough for data tables, divisible by common UI sizes | YYYY-MM-DD |