@r1z4x/tezgah 1.0.0

package/skills/design-library/adaptive-interfaces/skills/responsive-review/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: responsive-review
+description: "Review responsive and flexible layout for accessibility across devices, zoom levels, and orientations. Chains: responsive-accessibility, flexible-typography, information-density. Use when testing an existing interface across screen sizes and zoom levels for accessibility."
+---
+
+# Responsive Accessibility Review
+
+Test whether an interface maintains accessibility across the full
+range of screen sizes, zoom levels, and orientations that real
+users encounter.
+
+## Process
+
+### Step 1: Viewport Testing
+Test the interface at these viewport widths:
+- 320px (small mobile)
+- 375px (standard mobile)
+- 768px (tablet)
+- 1024px (small desktop / tablet landscape)
+- 1280px (standard desktop)
+- 1440px+ (large desktop)
+
+At each viewport, using **responsive-accessibility**, document:
+- Content that overflows or is hidden
+- Interactive elements that are unreachable
+- Touch targets below 44×44px on touch viewports
+- Navigation that doesn't adapt
+- Functionality that disappears entirely
+
+### Step 2: Zoom Testing
+At 1280px viewport, test at:
+- 100% (baseline)
+- 150% (common for low vision users)
+- 200% (WCAG requirement)
+
+Document:
+- Horizontal scrolling that appears
+- Text that overflows containers
+- Overlapping elements
+- Sticky headers that consume excessive space
+- Modals or tooltips that go off-screen
+
+### Step 3: Typography Scaling
+Using **flexible-typography**, test with system font size at maximum.
+Document:
+- Text that doesn't scale
+- Containers that clip or truncate text
+- Layout that breaks when text grows
+- Fixed-height elements that don't expand
+
+### Step 4: Orientation Testing
+Test in both portrait and landscape. Document:
+- Content that only works in one orientation
+- Orientation lock that prevents rotation
+- Layout that breaks or wastes space in one orientation
+
+### Step 5: Density Check
+Using **information-density**, at each viewport verify:
+- Is the default density appropriate for the device?
+- Can users adjust density?
+- Does compact density maintain minimum touch targets?
+- Does spacious density work without excessive scrolling?
+
+## Output
+
+Deliver a responsive accessibility report:
+
+1. **Viewport matrix** — pass/fail at each viewport width for
+   core tasks
+2. **Zoom results** — issues at 150% and 200%
+3. **Typography results** — text scaling failures
+4. **Orientation results** — portrait/landscape issues
+5. **Fix list** — prioritised by severity, grouped by:
+   - Fixes that affect all viewports
+   - Fixes specific to mobile
+   - Fixes specific to zoom

package/skills/design-library/adaptive-interfaces/skills/simplified-views/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: simplified-views
+description: "Design simplified and reduced-complexity views of interfaces for users who need less visual noise and fewer options. Use when designing settings, dashboards, complex tools, or any interface that could benefit from a simpler mode. Triggers on: simplified view, simple mode, easy mode, basic view, reduce complexity, less clutter, overwhelmed, too many options, beginner mode, essential view, focus mode."
+---
+
+# Simplified Views
+
+Design interfaces that offer a simpler version of themselves — fewer
+options, less visual complexity, clearer paths — for users who need
+or prefer reduced complexity.
+
+## Who This Is For
+
+- People with cognitive disabilities who are overwhelmed by complex interfaces
+- Older adults who prefer simpler, more predictable tools
+- New users who don't need advanced features yet
+- Anyone in a stressful or low-energy context
+- People using assistive technology where less clutter means
+  faster navigation
+
+## Core Principle
+
+The simplified view is not a lesser version. It's a focused version
+that contains everything needed for the core tasks and nothing that
+isn't.
+
+## Design Patterns
+
+### Feature Layering
+- Identify core tasks (what 80% of users do 80% of the time)
+- Show core features by default
+- Advanced features accessible via "Show more" or "Advanced"
+- Never require the advanced view to complete basic tasks
+- The simplified view should feel complete, not stripped
+
+### Progressive Complexity
+- Start simple, let users add complexity as they need it
+- Onboarding should begin in simplified mode
+- Offer to increase complexity when the user demonstrates comfort
+- "You might also want to try..." not "You're in basic mode"
+- Never make users feel that simplified = inferior
+
+### Dashboard Simplification
+- Default dashboard: 3–5 key metrics, primary actions
+- Full dashboard: all metrics, secondary actions, configuration
+- Let users choose which cards/widgets to show
+- Remember their choice across sessions
+- Provide preset layouts: "Essential", "Detailed", "Custom"
+
+### Navigation Simplification
+- Simplified nav: top-level items only
+- Full nav: all levels visible
+- Both must reach all content — simplified may need more clicks
+  but each click should be obvious
+- Breadcrumbs help users who take the longer path
+
+### Form Simplification
+- Show required fields only by default
+- "Show optional fields" expands the form
+- Smart defaults reduce decisions
+- Break complex forms into steps in simplified mode,
+  show all fields on one page in advanced mode
+
+## Implementation Approaches
+
+### User-Controlled Toggle
+- Visible setting: "Simplified view" / "Full view"
+- Available in app settings AND on the page itself
+- Preference remembered across sessions
+- Clearly labelled — never hidden
+
+### Responsive Simplification
+- Automatically simplify at smaller viewports
+- Mobile views are inherently simplified — embrace this
+- Don't try to cram the desktop layout into mobile
+
+### Role-Based Defaults
+- New accounts start in simplified mode
+- Power users can switch to full mode
+- Admin accounts may need full mode by default
+- Let users override role-based defaults
+
+## Anti-Patterns
+
+- "Lite" versions that lack essential features
+- Simplified modes that are clearly afterthoughts with broken layouts
+- Forcing users to request simplified mode through support
+- Patronising language ("Easy mode for beginners!")
+- Removing access to content rather than reorganising it
+
+## Assessment Questions
+
+1. Is there a simplified view available for complex interfaces?
+2. Can core tasks be completed entirely in simplified mode?
+3. Is the toggle between modes easy to find and use?
+4. Does simplified mode feel complete, not stripped?
+5. Are user preferences for view mode remembered?

package/skills/design-library/adaptive-interfaces/skills/specify/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: specify
+description: "Specify adaptive behaviour for an interface. Chains: user-preference-respect, responsive-accessibility, flexible-typography, colour-independence, simplified-views, information-density. Use when designing a new interface and you want to build adaptability in from the start."
+---
+
+# Specify Adaptive Behaviour
+
+Define how an interface adapts to diverse user needs — preferences,
+screen conditions, and cognitive requirements — as part of the
+design specification, not as a retrofit.
+
+## Process
+
+### Step 1: Define Preference Responses
+Using **user-preference-respect**, specify how the interface responds
+to each system preference:
+- prefers-reduced-motion: what changes
+- prefers-contrast: what changes
+- prefers-color-scheme: what changes
+- forced-colors: what changes
+- prefers-reduced-transparency: what changes
+
+### Step 2: Define Responsive Behaviour
+Using **responsive-accessibility**, specify:
+- Breakpoints and what reflows at each
+- Behaviour at 200% zoom
+- Orientation support
+- Touch target sizing at each breakpoint
+
+### Step 3: Define Typography Behaviour
+Using **flexible-typography**, specify:
+- Type scale with relative units
+- Line height and spacing values
+- Behaviour when user scales text to 200%
+- Dark mode typography adjustments
+
+### Step 4: Define Colour Strategy
+Using **colour-independence**, specify:
+- How every colour-encoded meaning has a second encoding
+- Status indicator design (colour + icon + text)
+- Chart and data visualisation colour strategy
+- Greyscale test results
+
+### Step 5: Define View Options
+Using **simplified-views** and **information-density**, specify:
+- What simplified view contains vs full view
+- How users toggle between views
+- Available density levels
+- Default density per viewport and context
+
+## Output
+
+Deliver an adaptive behaviour specification:
+1. **Preference response table** — each system preference and the
+   interface's response
+2. **Responsive behaviour map** — what changes at each breakpoint
+   and zoom level
+3. **Typography specification** — scale, units, spacing, scaling
+   behaviour
+4. **Colour independence audit** — every colour-dependent element
+   and its second encoding
+5. **View and density options** — what's available and how users
+   control it

package/skills/design-library/adaptive-interfaces/skills/user-preference-respect/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: user-preference-respect
+description: "Design interfaces that detect and respond to system-level user preferences. Use when implementing dark mode, reduced motion, high contrast, text scaling, or any user preference that affects how the interface renders. Triggers on: user preference, system preference, prefers-reduced-motion, prefers-contrast, prefers-color-scheme, forced-colors, media query, user settings, system settings, accessibility settings, OS settings."
+---
+
+# User Preference Respect
+
+The operating system already knows what the user needs. Your job is
+to listen and respond. These preferences exist because people set them
+deliberately — ignoring them overrides the user's own accessibility
+decision.
+
+## The Preferences
+
+### prefers-reduced-motion
+**What it means:** user experiences discomfort or harm from motion.
+**What to do:**
+- Disable all decorative animation
+- Replace slide/fade transitions with instant state changes
+- Keep essential motion (loading spinners) but simplify
+- Disable parallax, scroll-triggered animation, and auto-advance
+- Never override this preference
+
+**How to detect:** `@media (prefers-reduced-motion: reduce)`
+
+### prefers-contrast
+**What it means:** user needs stronger visual distinction.
+**What to do:**
+- Increase contrast beyond WCAG minimums
+- Replace subtle shadows and gradients with solid borders
+- Make focus indicators bolder and more visible
+- Remove transparency and blur effects
+- Increase border widths on interactive elements
+
+**How to detect:** `@media (prefers-contrast: more)`
+
+### prefers-color-scheme
+**What it means:** user prefers light or dark interface.
+**What to do:**
+- Provide genuine dark mode (not just inverted colours)
+- Ensure all content is legible in both modes
+- Test images, charts, icons, and illustrations in both
+- Don't use pure black (#000) on dark mode — use dark grey (#1a1a1a)
+  for less eye strain
+- Remember: dark mode is not just aesthetic — it reduces eye
+  fatigue and helps some people with light sensitivity
+
+**How to detect:** `@media (prefers-color-scheme: dark)`
+
+### forced-colors
+**What it means:** user has enabled Windows High Contrast or similar.
+**What to do:**
+- Don't fight the system colour override
+- Ensure borders and outlines define interactive elements
+  (the system will strip your colours)
+- Use transparent borders that become visible in forced-colors mode
+- Test that all interactive elements remain distinguishable
+- Don't rely on background colour alone to indicate state
+
+**How to detect:** `@media (forced-colors: active)`
+
+### prefers-reduced-transparency
+**What it means:** user finds transparent elements hard to read.
+**What to do:**
+- Replace semi-transparent backgrounds with solid ones
+- Remove frosted glass / backdrop blur effects
+- Ensure overlays are fully opaque
+
+**How to detect:** `@media (prefers-reduced-transparency: reduce)`
+
+## Implementation Principles
+
+### Progressive Enhancement
+- Build the accessible version first
+- Add motion, transparency, and visual flourishes as enhancements
+- When a preference is detected, you're removing the enhancement,
+  not degrading the experience
+
+### Don't Ask — Detect
+- Don't make users configure accessibility settings in your app
+  when the OS already has the setting
+- Detect and respond automatically
+- If you offer additional settings, they should layer on top of
+  system preferences, not replace them
+
+### Test Every Preference
+- Test with each preference enabled individually
+- Test with combinations (reduced motion + high contrast + dark mode)
+- Verify that the interface is complete and usable in every state
+- Automated tests can check that media queries exist —
+  manual testing verifies they work
+
+## Assessment Checklist
+
+- [ ] prefers-reduced-motion is detected and all decorative motion stops
+- [ ] prefers-contrast is detected and visual contrast increases
+- [ ] prefers-color-scheme is detected and theme switches
+- [ ] forced-colors mode doesn't break interactive elements
+- [ ] Combinations of preferences work together
+- [ ] No preference is overridden or ignored

package/skills/design-library/cognitive-accessibility/skills/adaptive-personalisation/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: adaptive-personalisation
+description: "Design help systems and support patterns that work for people with cognitive disabilities. Use when designing help content, tooltips, onboarding, FAQs, support flows, documentation, or any context where users need guidance. Triggers on: help, support, FAQ, tooltip, onboarding, tutorial, guidance, stuck, confused, documentation, instructions."
+---
+
+# Contextual Help Design
+
+Design help that meets people where they are — on the screen they're
+stuck on, in language they understand, without requiring them to
+remember how they got there.
+
+## Core Principle
+
+If a user gets stuck, they should be able to get help without leaving
+the screen they're on.
+
+## Design Patterns
+
+### Inline Help
+- Tooltip or info icon next to fields that need explanation
+- Examples shown next to input fields ("e.g., 15/03/2026")
+- Help text visible by default for complex fields
+- Inline definitions for specialist terms (underline + tooltip)
+- "What's this?" links for uncommon concepts
+
+### Guided Tasks
+- Step-by-step wizard as an alternative to complex forms
+- Examples of completed tasks (filled-in sample forms)
+- Templates or pre-built options alongside "start from scratch"
+- Progress-aware hints that change based on where the user is
+
+### Escalation Path
+- Self-service help (search, FAQ) as first option
+- Chat or messaging as second option
+- Phone or video as third option
+- Never require users to re-explain when escalating between channels
+- Show estimated wait times for human support
+- Never require a reference number to get help
+
+### Error Recovery Support
+- Error messages include: what happened + why + what to do next
+- Link directly to the field or step that needs fixing
+- Offer alternative paths when primary fails
+- For complex errors: offer human support directly
+
+## Help Content Rules
+
+- Write at grade 4–6 reading level
+- Use the same terminology as the interface (not different words)
+- One instruction per step
+- Include images or diagrams for spatial or procedural instructions
+- Make help searchable
+- Test help content with people who have the actual problem
+
+## Assessment Questions
+
+1. Can users get help without navigating away from their task?
+2. Is help written in plain language that matches the interface?
+3. Can users reach a human within 2 clicks when self-service fails?
+4. Do help resources exist for the moments where users actually get stuck
+   (not just the moments you anticipated)?

package/skills/design-library/cognitive-accessibility/skills/assess-load/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: assess-load
+description: "Assess cognitive load across a complete multi-step process and produce a load map. Chains: cognitive-load-assessment, memory-load-reduction, wayfinding-navigation. Use when evaluating a checkout flow, onboarding sequence, application process, or any multi-step journey."
+---
+
+# Assess Load
+
+Map the cognitive load across a complete multi-step process and identify
+where users are most likely to struggle, give up, or make errors.
+
+## Process
+
+### Step 1: Map the Journey
+List every step in the process from start to completion.
+For each step, note: what the user sees, what they must do, and
+what they must decide.
+
+### Step 2: Rate Each Step
+Using **cognitive-load-assessment**, evaluate each step across all
+six dimensions (decisions, memory, concepts, steps, reading, visual).
+Record the rating for each.
+
+### Step 3: Identify Load Spikes
+Plot the load across the journey. Identify:
+- Steps where load suddenly increases (load spikes)
+- Consecutive steps with medium-or-higher load (sustained load)
+- Points where users must remember information from earlier steps
+  (memory bridges)
+
+### Step 4: Check Navigation and Memory
+Using **wayfinding-navigation** and **memory-load-reduction**, verify:
+- Can users always get back to a previous step?
+- Is progress saved automatically?
+- Is key context carried forward between steps?
+- Can users see where they are in the overall process?
+
+### Step 5: Recommendations
+For each load spike or sustained load zone, recommend specific
+design changes to bring the load rating down.
+
+## Output
+
+Deliver a cognitive load map: a step-by-step table showing the load
+rating at each point in the journey, annotated with:
+- Load spikes flagged in red
+- Memory bridges highlighted
+- Specific reduction recommendations for each issue
+- An overall cognitive load score for the process

package/skills/design-library/cognitive-accessibility/skills/cognitive-load-assessment/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: cognitive-load-assessment
+description: "Assess and reduce cognitive load in interfaces, flows, and content. Use when designing or reviewing any multi-step process, complex form, dashboard, decision flow, or information-dense screen. Triggers on: cognitive load, too complex, overwhelmed, too many steps, decision fatigue, confusing, information overload, simplify this flow. Applies to any interface where users must think, decide, or remember."
+---
+
+# Cognitive Load Assessment
+
+Assess cognitive load across three dimensions and provide actionable
+recommendations to reduce unnecessary burden on users.
+
+## The Three Types of Cognitive Load
+
+**Intrinsic load** — complexity inherent in the task itself.
+A tax return is intrinsically complex. You cannot simplify the tax code.
+Focus: break into manageable steps, provide context, explain terms.
+
+**Extraneous load** — complexity added by the design, not the task.
+Confusing navigation, unclear labels, inconsistent patterns, visual clutter.
+Focus: eliminate ruthlessly. Every instance is a fixable design failure.
+
+**Germane load** — effort invested in the actual task.
+This is the load you WANT. The user engaging with their real goal.
+Focus: maximise this by removing the other two.
+
+## Assessment Framework
+
+For each screen or step, evaluate:
+
+| Dimension | Low (good) | Medium (review) | High (redesign) |
+|-----------|-----------|-----------------|-----------------|
+| Decisions required | 0–1 | 2–3 | 4+ |
+| Items to remember | None | 1–2 | 3+ |
+| New concepts to learn | None | 1 | 2+ |
+| Steps to complete | 1–2 | 3–5 | 6+ |
+| Reading complexity | Plain language | Some jargon | Dense/technical |
+| Visual complexity | Clean, focused | Moderate | Cluttered |
+
+**If any dimension rates High, that screen needs redesign before launch.**
+
+## How to Assess
+
+1. Walk through the flow as a user who is tired, stressed, and unfamiliar
+2. At each screen, count: decisions, things to remember, new concepts
+3. Note where you pause, re-read, or feel uncertain — those are load spikes
+4. Map the load type: is the difficulty intrinsic or extraneous?
+5. Recommend specific reductions for each extraneous load source
+
+## Reduction Strategies
+
+- **Progressive disclosure:** show only what the current step needs
+- **Smart defaults:** pre-select the most common option
+- **Chunking:** group into sets of 3–5 related items
+- **Recognition over recall:** show options, don't make users remember
+- **Persistent context:** show key selections throughout a flow
+- **One primary action per screen:** de-emphasise secondary actions
+
+## Output Format
+
+Present the assessment as a screen-by-screen table showing load ratings,
+followed by prioritised recommendations sorted by impact.

package/skills/design-library/cognitive-accessibility/skills/contextual-help-design/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: contextual-help-design
+description: "Design help systems and support patterns that work for people with cognitive disabilities. Use when designing help content, tooltips, onboarding, FAQs, support flows, documentation, or any context where users need guidance. Triggers on: help, support, FAQ, tooltip, onboarding, tutorial, guidance, stuck, confused, documentation, instructions."
+---
+
+# Contextual Help Design
+
+Design help that meets people where they are — on the screen they're
+stuck on, in language they understand, without requiring them to
+remember how they got there.
+
+## Core Principle
+
+If a user gets stuck, they should be able to get help without leaving
+the screen they're on.
+
+## Design Patterns
+
+### Inline Help
+- Tooltip or info icon next to fields that need explanation
+- Examples shown next to input fields ("e.g., 15/03/2026")
+- Help text visible by default for complex fields
+- Inline definitions for specialist terms (underline + tooltip)
+- "What's this?" links for uncommon concepts
+
+### Guided Tasks
+- Step-by-step wizard as an alternative to complex forms
+- Examples of completed tasks (filled-in sample forms)
+- Templates or pre-built options alongside "start from scratch"
+- Progress-aware hints that change based on where the user is
+
+### Escalation Path
+- Self-service help (search, FAQ) as first option
+- Chat or messaging as second option
+- Phone or video as third option
+- Never require users to re-explain when escalating between channels
+- Show estimated wait times for human support
+- Never require a reference number to get help
+
+### Error Recovery Support
+- Error messages include: what happened + why + what to do next
+- Link directly to the field or step that needs fixing
+- Offer alternative paths when primary fails
+- For complex errors: offer human support directly
+
+## Help Content Rules
+
+- Write at grade 4–6 reading level
+- Use the same terminology as the interface (not different words)
+- One instruction per step
+- Include images or diagrams for spatial or procedural instructions
+- Make help searchable
+- Test help content with people who have the actual problem
+
+## Assessment Questions
+
+1. Can users get help without navigating away from their task?
+2. Is help written in plain language that matches the interface?
+3. Can users reach a human within 2 clicks when self-service fails?
+4. Do help resources exist for the moments where users actually get stuck
+   (not just the moments you anticipated)?

package/skills/design-library/cognitive-accessibility/skills/error-prevention-recovery/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: error-prevention-recovery
+description: "Design error prevention, error messages, and recovery flows for cognitive accessibility. Use when designing forms, checkout flows, account creation, settings, data entry, or any flow where users can make mistakes. Triggers on: error handling, error messages, form errors, validation, users make mistakes, users abandon, error recovery, undo, forgiving design."
+---
+
+# Error Prevention and Recovery
+
+Design systems that prevent errors before they happen, and when errors
+do occur, help people recover without shame, confusion, or lost work.
+
+## Prevention Strategies
+
+### Forgiving Input
+- Accept multiple date formats ("15/03/2026", "15 March 2026", "March 15, 2026")
+- Accept multiple phone formats ("(555) 123-4567", "555-123-4567", "5551234567")
+- Auto-format as the user types
+- Case-insensitive matching
+- Trim whitespace automatically
+- Show format examples next to fields ("e.g., 15/03/2026")
+
+### Smart Defaults
+- Pre-select the most common option
+- Pre-fill known information (name from account, address from postcode)
+- Show the recommended choice for complex decisions
+- Default to the safest option for irreversible settings
+
+### Progressive Validation
+- Validate each field when the user moves to the next (on blur)
+- Show success states for correctly completed fields
+- Never validate while the user is still typing
+- Never clear user input on error — always preserve their work
+
+### Minimal Demands
+- Only ask for information you strictly need
+- Mark optional fields, not required ones (most fields should be required
+  by design — if they aren't needed, remove them)
+- Break long forms into steps with clear progress
+
+## Error Message Design
+
+Every error message must answer three questions:
+1. **What happened?** (specific, not generic)
+2. **Why?** (in plain language)
+3. **What do I do now?** (a clear, single action)
+
+### Examples
+
+**Bad:** "Invalid input"
+**Good:** "Please enter a date in the format DD/MM/YYYY — for example, 15/03/2026"
+
+**Bad:** "Error 403"
+**Good:** "You don't have permission to view this page. Contact your team admin to request access."
+
+**Bad:** "Password does not meet requirements"
+**Good:** "Your password needs at least 8 characters and one number. You have 6 characters."
+
+### Error Message Tone
+- Never blame the user ("You entered an invalid email")
+- State the situation neutrally ("We need a valid email to continue")
+- Be specific about what needs to change
+- Offer an alternative path when possible
+
+## Recovery Design
+
+- **Undo** available for at least 10 seconds after any action
+- **Confirmation** before destructive actions with useful detail:
+  "Delete 'Project Alpha'? This removes all 23 files. This cannot be undone."
+- **Preview** before submission for any consequential action
+- **Save progress** automatically in long flows
+- **Alternative path** when primary path fails:
+  "Can't upload a photo? You can describe what you see instead."