qualia-framework 2.5.1 → 3.1.0

package/framework/skills/normalize/SKILL.md

@@ -1,79 +0,0 @@
----
-name: normalize
-description: Normalize design to match your design system and ensure consistency
-user-invokable: true
-args:
-  - name: feature
-    description: The page, route, or feature to normalize (optional)
-    required: false
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## Read DESIGN.md (Authoritative Source)
-
-Before searching for design system documentation, check for the project's DESIGN.md:
-
-```bash
-cat .planning/DESIGN.md 2>/dev/null
-```
-
-**If DESIGN.md exists:** This IS the design system for this project. Use it as the primary reference for tokens, patterns, and constraints. Still search for additional design system docs (component libraries, style guides), but DESIGN.md decisions take precedence.
-
-**If DESIGN.md does not exist:** Proceed with the design system discovery step below.
-
-## Plan
-
-Before making changes, deeply understand the context:
-
-1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand:
-   - Core design principles and aesthetic direction
-   - Target audience and personas
-   - Component patterns and conventions
-   - Design tokens (colors, typography, spacing)
-   
-   **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles.
-
-2. **Analyze the current feature**: Assess what works and what doesn't:
-   - Where does it deviate from design system patterns?
-   - Which inconsistencies are cosmetic vs. functional?
-   - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment?
-
-3. **Create a normalization plan**: Define specific changes that will align the feature with the design system:
-   - Which components can be replaced with design system equivalents?
-   - Which styles need to use design tokens instead of hard-coded values?
-   - How can UX patterns match established user flows?
-   
-   **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first.
-
-## Execute
-
-Systematically address all inconsistencies across these dimensions:
-
-- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes.
-- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette.
-- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere.
-- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns.
-- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features.
-- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards.
-- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements.
-- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns.
-
-**NEVER**:
-- Create new one-off components when design system equivalents exist
-- Hard-code values that should use design tokens
-- Introduce new patterns that diverge from the design system
-- Compromise accessibility for visual consistency
-
-This is not an exhaustive list—apply judgment to identify all areas needing normalization.
-
-## Clean Up
-
-After normalization, ensure code quality:
-
-- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path.
-- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization.
-- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions.
-- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate.
-
-Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness.

package/framework/skills/onboard/SKILL.md

@@ -1,242 +0,0 @@
----
-name: onboard
-description: Design or improve onboarding flows, empty states, and first-time user experiences. Helps users get started successfully and understand value quickly.
-user-invokable: true
-args:
-  - name: target
-    description: The feature or area needing onboarding (optional)
-    required: false
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.