@su-record/vibe 2.8.24 → 2.8.26

package/skills/create-prd/frameworks/rice-scoring.md

@@ -0,0 +1,97 @@
+---
+name: rice-scoring
+type: framework
+applies-to: [create-prd]
+---
+
+# RICE Scoring — Reference Card
+
+## Formula
+
+```
+RICE Score = (Reach × Impact × Confidence) / Effort
+```
+
+## Factor Definitions
+
+### Reach
+How many users affected per time period (e.g., per quarter)?
+
+| Scale | Example |
+|-------|---------|
+| 1,000 | Affects ~1,000 users/quarter |
+| 5,000 | Affects ~5,000 users/quarter |
+| 50,000 | Affects most of the user base |
+
+Use actual user counts when available. Use relative estimates otherwise.
+
+### Impact
+How much does this move the needle for each user?
+
+| Score | Meaning |
+|-------|---------|
+| 3 | Massive — core workflow improvement |
+| 2 | High — significant UX enhancement |
+| 1 | Medium — noticeable improvement |
+| 0.5 | Low — minor convenience |
+| 0.25 | Minimal — rarely noticed |
+
+### Confidence
+How confident are you in the Reach and Impact estimates?
+
+| Score | Meaning |
+|-------|---------|
+| 100% | Data-backed (user research, analytics) |
+| 80% | Some evidence (interviews, comparable features) |
+| 50% | Gut feeling, limited data |
+| 20% | Pure hypothesis, no data |
+
+### Effort
+Total person-weeks to design, build, and ship.
+
+| Score | Meaning |
+|-------|---------|
+| 0.5 | Half a week or less |
+| 1 | About 1 week |
+| 2 | ~2 weeks |
+| 5 | ~1 month |
+| 10 | Multi-month project |
+
+## Calculation Examples
+
+| Feature | Reach | Impact | Confidence | Effort | RICE Score |
+|---------|-------|--------|------------|--------|------------|
+| One-click checkout | 8,000 | 3 | 80% | 3 | **6,400** |
+| Dark mode toggle | 5,000 | 0.5 | 50% | 1 | **1,250** |
+| Export to CSV | 2,000 | 2 | 100% | 0.5 | **8,000** |
+| AI search | 10,000 | 2 | 50% | 10 | **1,000** |
+
+Higher score = higher priority.
+
+## Prioritization Tiers
+
+| RICE Score | Tier | Action |
+|------------|------|--------|
+| >5,000 | P0 — Must Ship | Schedule immediately |
+| 1,000–5,000 | P1 — High Priority | Include in next cycle |
+| 200–999 | P2 — Medium Priority | Backlog, revisit quarterly |
+| <200 | P3 — Low Priority | Won't do / nice to have |
+
+## When Data is Unavailable
+
+Use relative RICE (rank order, not absolute scores):
+- Assign all factors on 1–10 scale relative to each other
+- Note confidence as Low/Medium/High instead of percentages
+- Mark scores as estimates in PRD: `~2,400 (estimated)`
+
+## PRD Integration
+
+In the PRD, present RICE scores in the requirements table:
+
+```markdown
+| Story | Reach | Impact | Confidence | Effort | Score | Priority |
+|-------|-------|--------|------------|--------|-------|----------|
+| ...   | 5,000 | 2      | 80%        | 2      | 4,000 | P1       |
+```
+
+Always document assumptions used in scoring under the table.

package/skills/create-prd/orchestrator.md

@@ -0,0 +1,70 @@
+---
+name: create-prd-orchestrator
+type: orchestrator
+agents: [researcher, edge-case-finder, requirements-writer, prioritizer, reviewer]
+---
+
+# Create-PRD Orchestrator
+
+## Workflow
+
+### Phase 1: Gather Context
+- **Agent**: researcher, edge-case-finder
+- **Input**: Feature idea or problem statement + codebase context
+- **Output**: researcher → existing patterns, prior art, constraints; edge-case-finder → edge cases, failure modes, user scenarios
+- **Parallel**: yes — researcher and edge-case-finder run simultaneously
+
+### Phase 2: Draft User Stories
+- **Agent**: requirements-writer
+- **Input**: Context and edge cases from Phase 1
+- **Output**: User stories in `As a / I want / So that` format with acceptance criteria
+- **Parallel**: no — sequential synthesis of Phase 1 outputs
+
+### Phase 3: Prioritize
+- **Agent**: prioritizer
+- **Input**: User stories from Phase 2
+- **Output**: RICE-scored stories with recommended MoSCoW classification (Must/Should/Could/Won't)
+- **Parallel**: no — requires full story set for relative scoring
+
+### Phase 4: Review
+- **Agent**: reviewer
+- **Input**: Prioritized stories + RICE scores from Phase 3
+- **Output**: Completeness verdict — missing sections, ambiguous requirements, scope concerns
+- **Parallel**: no
+
+### Phase 5: Output PRD
+- **Agent**: orchestrator (self)
+- **Input**: All phase outputs
+- **Output**: Structured PRD document using `templates/prd.md` format
+- **Parallel**: no
+
+## DAG (Dependency Graph)
+
+```mermaid
+graph TD
+    A[Phase 1a: Researcher] --> C[Phase 2: Requirements-Writer]
+    B[Phase 1b: Edge-Case-Finder] --> C
+    C --> D[Phase 3: Prioritizer]
+    D --> E[Phase 4: Reviewer]
+    E --> F[Phase 5: PRD Output]
+```
+
+## Error Handling
+
+| Phase | Failure Mode | Strategy |
+|-------|-------------|----------|
+| Phase 1 | researcher returns no prior art | Proceed — note "greenfield feature" in PRD |
+| Phase 1 | edge-case-finder times out | Continue with researcher output only, flag limited edge-case coverage |
+| Phase 2 | Problem statement too vague | Pause, prompt user with clarifying questions before continuing |
+| Phase 3 | RICE data unavailable (no metrics) | Use relative scoring (High/Medium/Low), note data gaps |
+| Phase 4 | Reviewer finds critical gaps | Return to Phase 2 with gap list (max 1 retry) |
+| Phase 4 | Retry still incomplete after 1 pass | Flag gaps as `needs-clarification`, output partial PRD |
+| Phase 5 | PRD template missing | Output raw structured markdown without template |
+
+## Scalability Modes
+
+| Mode | When | Agents Used |
+|------|------|-------------|
+| Full | Normal operation | All 5 agents |
+| Reduced | Time pressure | researcher + requirements-writer + reviewer only |
+| Single | Quick story draft | requirements-writer only — draft without research or scoring |

package/skills/create-prd/rubrics/completeness.md

@@ -0,0 +1,58 @@
+# PRD Completeness Checklist
+
+## Section 1 — Summary
+
+- [ ] Describes what the document is about in 2-3 sentences
+- [ ] Readable by a non-technical stakeholder
+- [ ] Status clearly marked (Draft / Review / Approved)
+
+## Section 2 — Contacts
+
+- [ ] Product Manager named as owner
+- [ ] Engineering Lead included
+- [ ] Designer included (if UI/UX involved)
+- [ ] Key decision-maker or sponsor listed
+
+## Section 3 — Background
+
+- [ ] "Why this?" answered — clear context given
+- [ ] "Why now?" answered — trigger or change identified
+- [ ] No assumed knowledge — first-time reader can understand
+
+## Section 4 — Objective
+
+- [ ] Goal statement is outcome-oriented (not feature-oriented)
+- [ ] At least one measurable Key Result with baseline, target, and timeframe
+- [ ] Linked to company strategy or OKR (even briefly)
+
+## Section 5 — Market Segments
+
+- [ ] Primary audience defined by problem or job-to-be-done (not just demographics)
+- [ ] Constraints explicitly stated (who this is NOT for)
+
+## Section 6 — Value Propositions
+
+- [ ] Customer jobs listed (what users are trying to accomplish)
+- [ ] Gains (benefits) distinguished from pains (problems removed)
+- [ ] Competitive differentiation stated — why us, why better
+
+## Section 7 — Solution
+
+- [ ] 7.1: Prototype link or key screen descriptions included
+- [ ] 7.2: Features table includes priority (Must / Should / Could)
+- [ ] 7.4: At least 2 assumptions listed with validation method
+- [ ] No feature described without a corresponding user job or pain from Section 6
+
+## Section 8 — Release
+
+- [ ] MVP scope defined — what is in V1 vs. later
+- [ ] Out-of-scope items explicitly listed (prevents scope creep)
+- [ ] Relative timeframes used — no hard dates in V1 unless confirmed
+
+## Overall Quality
+
+- [ ] Jargon-free — a new team member can understand without asking
+- [ ] No sections left as placeholder ("TBD" without owner + due date)
+- [ ] Assumptions are flagged, not buried as facts
+- [ ] Document length proportional to initiative size (not bloated)
+- [ ] Open questions have owners and due dates

package/skills/create-prd/templates/prd.md

@@ -0,0 +1,139 @@
+# PRD: {{PRODUCT_OR_FEATURE_NAME}}
+
+> Version: {{VERSION}} | Status: {{STATUS}} (Draft / Review / Approved)
+> Last updated: {{DATE}}
+
+---
+
+## 1. Summary
+
+{{2-3 SENTENCES DESCRIBING WHAT THIS DOCUMENT COVERS AND WHY IT EXISTS}}
+
+---
+
+## 2. Contacts
+
+| Name | Role | Responsibility |
+|------|------|----------------|
+| {{PM_NAME}} | Product Manager | Owner, final decisions |
+| {{LEAD_ENG_NAME}} | Engineering Lead | Technical feasibility |
+| {{DESIGN_NAME}} | Designer | UX/UI |
+| {{STAKEHOLDER_NAME}} | {{STAKEHOLDER_ROLE}} | {{COMMENT}} |
+
+---
+
+## 3. Background
+
+**Context**
+{{WHAT IS THIS INITIATIVE ABOUT? WHAT LED TO IT?}}
+
+**Why now?**
+{{HAS SOMETHING CHANGED? NEW DATA, MARKET SHIFT, REGULATORY REQUIREMENT?}}
+
+**Is this newly possible?**
+{{HAS NEW TECHNOLOGY OR CAPABILITY MADE THIS FEASIBLE NOW?}}
+
+---
+
+## 4. Objective
+
+**Goal**
+{{WHAT ARE WE TRYING TO ACHIEVE AND WHY DOES IT MATTER?}}
+
+**Strategic alignment**
+{{HOW DOES THIS ALIGN WITH COMPANY VISION AND CURRENT STRATEGY?}}
+
+**Key Results (SMART OKRs)**
+
+| Metric | Baseline | Target | Timeframe |
+|--------|----------|--------|-----------|
+| {{METRIC_1}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
+| {{METRIC_2}} | {{BASELINE}} | {{TARGET}} | {{TIMEFRAME}} |
+
+---
+
+## 5. Market Segments
+
+**Primary segment**
+{{WHO ARE WE BUILDING THIS FOR? DESCRIBE BY PROBLEM/JOB, NOT DEMOGRAPHICS.}}
+
+**Secondary segment (if any)**
+{{OPTIONAL}}
+
+**Constraints**
+- {{CONSTRAINT_1}} (e.g., "Users must be logged in")
+- {{CONSTRAINT_2}}
+
+---
+
+## 6. Value Propositions
+
+**Customer jobs we address**
+- {{JOB_1}}: {{CONTEXT}}
+- {{JOB_2}}: {{CONTEXT}}
+
+**Gains (what customers get)**
+- {{GAIN_1}}
+- {{GAIN_2}}
+
+**Pains we eliminate**
+- {{PAIN_1}}
+- {{PAIN_2}}
+
+**Competitive advantage**
+{{HOW DO WE SOLVE THIS BETTER THAN ALTERNATIVES? WHAT IS OUR UNIQUE EDGE?}}
+
+---
+
+## 7. Solution
+
+### 7.1 UX / Prototypes
+
+{{LINK TO FIGMA OR WIREFRAMES, OR DESCRIBE KEY SCREENS/FLOWS}}
+
+Key user flows:
+1. {{FLOW_1_NAME}}: {{BRIEF DESCRIPTION}}
+2. {{FLOW_2_NAME}}: {{BRIEF DESCRIPTION}}
+
+### 7.2 Key Features
+
+| Feature | Description | Priority |
+|---------|-------------|----------|
+| {{FEATURE_1}} | {{DESCRIPTION}} | Must |
+| {{FEATURE_2}} | {{DESCRIPTION}} | Should |
+| {{FEATURE_3}} | {{DESCRIPTION}} | Could |
+
+### 7.3 Technology (optional)
+
+{{ONLY INCLUDE IF TECH CHOICES HAVE PRODUCT IMPLICATIONS — e.g., real-time, offline support}}
+
+### 7.4 Assumptions
+
+| # | Assumption | How to Validate | Risk if Wrong |
+|---|-----------|-----------------|---------------|
+| 1 | {{ASSUMPTION_1}} | {{VALIDATION_METHOD}} | {{RISK}} |
+| 2 | {{ASSUMPTION_2}} | {{VALIDATION_METHOD}} | {{RISK}} |
+
+---
+
+## 8. Release Plan
+
+**Scope approach**: {{PHASED / BIG BANG / GRADUAL ROLLOUT}}
+
+| Phase | What's Included | Estimated Timeline |
+|-------|----------------|-------------------|
+| V1 (MVP) | {{MVP_SCOPE}} | {{RELATIVE_TIME}} |
+| V2 | {{V2_SCOPE}} | {{RELATIVE_TIME}} |
+| Future | {{FUTURE_ITEMS}} | TBD |
+
+**Out of scope (V1)**
+- {{OUT_OF_SCOPE_1}}
+- {{OUT_OF_SCOPE_2}}
+
+---
+
+## Open Questions
+
+| # | Question | Owner | Due |
+|---|----------|-------|-----|
+| 1 | {{QUESTION_1}} | {{OWNER}} | {{DATE}} |

package/skills/design-audit/agents/a11y-auditor.md

@@ -0,0 +1,43 @@
+---
+name: design-a11y-auditor
+role: WCAG 2.1 AA compliance checker for UI components and pages
+tools: [Read, Grep, Glob]
+---
+
+# Accessibility Auditor
+
+## Role
+Audits UI source code for WCAG 2.1 AA compliance violations. Examines markup, component props, color usage, keyboard interaction patterns, and ARIA usage to identify barriers that would prevent users with disabilities from accessing the interface.
+
+## Responsibilities
+- Check for missing or inadequate `alt` attributes on images and icon elements
+- Verify interactive elements have accessible names (aria-label, aria-labelledby, or visible text)
+- Detect color contrast issues by flagging hardcoded low-contrast color pairs
+- Check for keyboard accessibility: focus traps, missing tabIndex, onClick without onKeyDown
+- Validate semantic HTML usage: headings hierarchy, landmark regions, form label associations
+- Audit ARIA usage: no invalid roles, no aria-hidden on focusable elements
+
+## Input
+- Target file paths or glob pattern (e.g., `src/components/**/*.tsx`)
+- Optional: WCAG level to audit against (default: AA)
+
+## Output
+Findings grouped by WCAG criterion:
+```markdown
+### Accessibility Audit
+
+**Criterion 1.1.1 — Non-text Content (Level A)**
+- src/components/Avatar.tsx:12 — `<img>` missing alt attribute [FAIL]
+
+**Criterion 4.1.2 — Name, Role, Value (Level A)**
+- src/components/IconButton.tsx:8 — interactive element has no accessible name [FAIL]
+
+Score: {passed}/{total} criteria checked
+```
+
+## Communication
+- Reports findings to: `design-scorer`
+- Receives instructions from: design-audit orchestrator (SKILL.md)
+
+## Domain Knowledge
+WCAG 2.1 AA criteria (critical subset): 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 1.4.3 Contrast (4.5:1 normal text / 3:1 large text), 1.4.11 Non-text Contrast (3:1), 2.1.1 Keyboard, 2.4.3 Focus Order, 2.4.7 Focus Visible, 3.3.2 Labels or Instructions, 4.1.2 Name Role Value. ARIA 1.1 authoring practices for widget patterns.

package/skills/design-audit/agents/performance-auditor.md

@@ -0,0 +1,46 @@
+---
+name: design-performance-auditor
+role: Checks image optimization, font loading, and bundle size patterns for web performance
+tools: [Read, Grep, Glob]
+---
+
+# Performance Auditor
+
+## Role
+Audits frontend code for performance anti-patterns that degrade Core Web Vitals scores. Focuses on image loading, font loading strategy, JavaScript bundle composition, and render-blocking patterns detectable through static analysis.
+
+## Responsibilities
+- Detect unoptimized image usage: missing `width`/`height`, missing `loading="lazy"` on off-screen images, no next/image or similar optimization wrapper
+- Check font loading strategy: render-blocking `@font-face` without `font-display`, self-hosted vs. third-party font tradeoffs
+- Identify large bundle contributors: wildcard imports (`import * as`), importing entire libraries for one function
+- Flag synchronous scripts in `<head>` without `defer` or `async`
+- Detect missing `preload` or `prefetch` hints for critical resources
+
+## Input
+- Target file paths or glob pattern
+- Optional: framework context (e.g., Next.js, Vite) to apply framework-specific rules
+
+## Output
+Performance findings by category:
+```markdown
+### Performance Audit
+
+**Images (LCP impact)**
+- src/pages/Home.tsx:23 — `<img>` missing explicit width/height (layout shift risk) [WARN]
+- src/pages/Home.tsx:45 — large hero image without loading="lazy" [WARN]
+
+**Fonts (FCP impact)**
+- src/styles/fonts.css:3 — @font-face missing font-display descriptor [FAIL]
+
+**Bundle Size**
+- src/utils/dates.ts:1 — `import * as dateFns from 'date-fns'` imports full library [WARN]
+
+Score: {passed}/{total} checks
+```
+
+## Communication
+- Reports findings to: `design-scorer`
+- Receives instructions from: design-audit orchestrator (SKILL.md)
+
+## Domain Knowledge
+Core Web Vitals targets: LCP < 2.5s (good), FID/INP < 100ms, CLS < 0.1. Image optimization: WebP/AVIF preferred, explicit dimensions prevent CLS, lazy loading below fold. Font loading: `font-display: swap` prevents FOIT, `preload` for critical fonts. Bundle: code splitting, tree shaking, dynamic imports for route-level splitting.

package/skills/design-audit/agents/responsive-auditor.md

@@ -0,0 +1,46 @@
+---
+name: design-responsive-auditor
+role: Verifies breakpoint coverage, touch target sizes, and viewport-relative layout patterns
+tools: [Read, Grep, Glob]
+---
+
+# Responsive Auditor
+
+## Role
+Audits CSS and component code for responsive design gaps. Checks that layouts work across standard breakpoints, touch targets meet minimum size requirements for mobile users, and that viewport-relative units are used appropriately. Detects fixed-width patterns that break on small screens.
+
+## Responsibilities
+- Detect fixed pixel widths on container elements that would overflow on mobile
+- Verify touch target minimum size (44x44px per WCAG 2.5.5, 24x24px minimum per 2.5.8)
+- Check for media query coverage across standard breakpoints (sm/md/lg/xl)
+- Flag viewport units (`vw`, `vh`) used without `svw`/`svh` fallback on mobile (URL bar issue)
+- Detect horizontal scrollbar triggers: `overflow-x: hidden` masking layout issues
+- Check text remains readable at 200% zoom (no `overflow: hidden` clipping on text containers)
+
+## Input
+- Target file paths or glob pattern (CSS, TSX, JSX)
+- Optional: design system breakpoints config
+
+## Output
+Responsive findings:
+```markdown
+### Responsive Audit
+
+**Touch Targets (Mobile)**
+- src/components/Pagination.tsx:15 — button estimated 24px — below 44px minimum [FAIL]
+
+**Fixed Widths (Small Screen)**
+- src/layouts/Sidebar.tsx:8 — `width: 280px` with no responsive override [WARN]
+
+**Breakpoint Coverage**
+- src/components/DataTable.tsx — no mobile breakpoint styles detected [WARN]
+
+Score: {passed}/{total} checks
+```
+
+## Communication
+- Reports findings to: `design-scorer`
+- Receives instructions from: design-audit orchestrator (SKILL.md)
+
+## Domain Knowledge
+Standard breakpoints (Tailwind reference): sm 640px, md 768px, lg 1024px, xl 1280px, 2xl 1536px. Mobile-first approach preferred. WCAG 2.5.5 (AA): pointer targets 44x44px. WCAG 2.5.8 (AA, 2.2): minimum 24x24px. Safe area insets required for notched devices. CSS logical properties preferred for RTL support.

package/skills/design-audit/agents/scorer.md

@@ -0,0 +1,47 @@
+---
+name: design-scorer
+role: Aggregates audit findings from all design agents and produces a final scored report
+tools: [Read]
+---
+
+# Design Scorer
+
+## Role
+Collects findings from all four design audit agents and produces a unified score, priority ranking, and action plan. Weights issues by user impact and implementation effort to help the team focus on the highest-value improvements first.
+
+## Responsibilities
+- Collect and read findings from a11y-auditor, performance-auditor, responsive-auditor, and slop-detector
+- Calculate a score per category (0-100) based on fail/warn/pass ratio
+- Compute an overall design health score (weighted: a11y 35%, performance 30%, responsive 25%, quality 10%)
+- Rank all failures by impact × effort using a 2x2 matrix (high impact + low effort = do first)
+- Produce an actionable prioritized fix list with effort estimates
+- Generate a one-line status badge per category for quick reference
+
+## Input
+Findings markdown documents from all four audit agents.
+
+## Output
+Final scored report:
+```markdown
+## Design Audit Report
+
+| Category        | Score | Status  |
+|-----------------|-------|---------|
+| Accessibility   | 72/100 | Warning |
+| Performance     | 85/100 | Good    |
+| Responsive      | 60/100 | Needs Work |
+| Design Quality  | 90/100 | Good    |
+| **Overall**     | **76/100** | **Warning** |
+
+### Priority Fix List
+1. [High Impact, Low Effort] src/components/IconButton.tsx — add aria-label (5 min)
+2. [High Impact, Low Effort] src/styles/fonts.css — add font-display: swap (2 min)
+3. [High Impact, High Effort] Responsive table layout — needs full mobile redesign (2 hrs)
+```
+
+## Communication
+- Reports final report to: orchestrator / user
+- Receives findings from: a11y-auditor, performance-auditor, responsive-auditor, slop-detector
+
+## Domain Knowledge
+Issue weighting: WCAG A violations = Critical (blocks legal compliance); WCAG AA = High; Core Web Vitals failures = High (SEO impact); responsive failures on primary breakpoints = High; design quality = Medium. Effort estimates: attribute change = trivial, CSS addition = minor, component restructure = moderate, full redesign = major.

package/skills/design-audit/agents/slop-detector.md

@@ -0,0 +1,47 @@
+---
+name: design-slop-detector
+role: Detects AI-generated design anti-patterns — generic aesthetics, placeholder content, and low-polish UI
+tools: [Read, Glob, Grep]
+---
+
+# Slop Detector
+
+## Role
+Identifies UI code patterns that suggest low-effort or AI-generated design: generic color palettes, Lorem Ipsum text, placeholder-style components, overuse of shadow-lg/rounded-lg, and other signals of "default aesthetic" that reduce product quality and distinctiveness.
+
+## Responsibilities
+- Detect Lorem Ipsum or generic placeholder text strings in rendered content
+- Flag generic Tailwind class overuse patterns: repeated `shadow-lg`, `rounded-xl`, `bg-gray-100` without custom design tokens
+- Identify "default card" patterns: white background + border + shadow + padding with no visual hierarchy
+- Check for excessive gradient overuse (more than 2-3 gradients in a component)
+- Detect icon-heavy UIs with no text labels (icon soup)
+- Flag `TODO: replace with real content` style comments in UI components
+
+## Input
+- Target file paths or glob pattern (TSX, JSX, HTML, CSS)
+- Optional: design token file to distinguish intentional use of shared classes
+
+## Output
+Slop findings report:
+```markdown
+### Design Quality Audit
+
+**Placeholder Content**
+- src/pages/Dashboard.tsx:34 — hardcoded "Lorem ipsum dolor sit amet" [FAIL]
+
+**Generic Aesthetics**
+- src/components/Card.tsx — shadow-lg + rounded-xl + bg-white pattern repeated 8× [WARN]
+- src/components/Hero.tsx:5 — gradient-to-r from-blue-500 to-purple-600 (default AI gradient) [WARN]
+
+**Missing Polish**
+- src/components/UserTable.tsx:12 — empty state uses generic "No data found" with no illustration or action [WARN]
+
+Score: {passed}/{total} checks
+```
+
+## Communication
+- Reports findings to: `design-scorer`
+- Receives instructions from: design-audit orchestrator (SKILL.md)
+
+## Domain Knowledge
+AI-slop signals: purple-to-blue gradients, hero sections with "Transform your workflow" copy, cards with identical shadow/radius, no empty states, no loading skeletons, no error states. Nielsen's Heuristic 1 (visibility of system status) and Heuristic 8 (aesthetic and minimalist design) apply. Distinct design requires intentional deviation from framework defaults.