@caoscompanybr/merlin 3.5.0

package/.merlin-core/skills/general/elicitation/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: elicitation
+description: Library of 20+ structured elicitation techniques for requirements gathering, analysis, and decision-making
+license: Apache-2.0
+metadata:
+  author: merlin-framework
+  version: "3.0.0"
+  auto_activate: [elicit, brainstorm, requirements, trade-off, pre-mortem]
+---
+
+# Elicitation Techniques
+
+Library of structured techniques for uncovering requirements, analyzing trade-offs, and making decisions. Each technique provides a repeatable prompt framework.
+
+## Brainstorming Discipline
+
+When running any elicitation technique interactively with the user:
+
+- **One question per message** — Never overwhelm with multiple questions. If a topic needs deeper exploration, break it into sequential messages.
+- **Multiple choice preferred** — Offer 2-4 concrete options when possible. Open-ended questions are fine when options aren't clear yet.
+- **Every project gets a design** — Even "simple" projects (a single function, a config change) need a short design (3-5 sentences minimum). "Simple" projects are where unexamined assumptions cause the most wasted work.
+- **Propose 2-3 approaches** — Always present alternatives with trade-offs and your recommendation before settling on one. Lead with the recommended option and explain why.
+
+## Discovery Techniques
+
+### Socratic Method
+
+**When:** Requirements are vague or user hasn't fully articulated needs.
+**Protocol:**
+
+1. Ask "What problem are we solving?" — get the root need
+2. Ask "Why is this a problem?" — uncover deeper motivations
+3. Ask "What happens if we don't solve it?" — establish stakes
+4. Ask "What would the ideal solution look like?" — define success
+5. Ask "What constraints prevent the ideal?" — map reality
+
+### 5 Whys
+
+**When:** Root cause analysis of bugs, failures, or design decisions.
+**Protocol:** Start with the symptom. Ask "Why?" 5 times, each time drilling deeper. Stop when you reach a systemic cause, not a surface symptom.
+
+### Assumption Surfacing
+
+**When:** Early planning, before committing to an approach.
+**Protocol:**
+
+1. List every assumption the current plan relies on
+2. Rate each: confidence (high/med/low) + impact if wrong (high/med/low)
+3. For any low-confidence + high-impact: validate before proceeding
+
+### Context Mapping
+
+**When:** Understanding how a feature fits into the larger system.
+**Protocol:** Map the feature's boundaries: What calls it? What does it call? What data flows in/out? What are the failure modes at each boundary?
+
+## Analysis Techniques
+
+### Six Thinking Hats
+
+**When:** Evaluating a proposal from multiple perspectives.
+**Protocol:** Analyze through 6 lenses sequentially:
+
+- **White Hat (Facts):** What data do we have? What's missing?
+- **Red Hat (Feelings):** What's the gut reaction? What feels risky?
+- **Black Hat (Caution):** What could go wrong? What are the weaknesses?
+- **Yellow Hat (Optimism):** What are the benefits? Best-case scenario?
+- **Green Hat (Creativity):** What alternatives exist? What if we did the opposite?
+- **Blue Hat (Process):** What's the decision? What's the next step?
+
+### Force Field Analysis
+
+**When:** Deciding whether to proceed with a change.
+**Protocol:**
+
+1. State the proposed change
+2. List driving forces (reasons FOR)
+3. List restraining forces (reasons AGAINST)
+4. Score each force 1-5 for strength
+5. Sum each side — net positive = proceed, net negative = reconsider
+
+### SWOT Analysis
+
+**When:** Evaluating a technology choice or architectural approach.
+**Protocol:** Map Strengths, Weaknesses, Opportunities, Threats in a 2x2 matrix. Focus on actionable insights from each quadrant.
+
+### Impact Mapping
+
+**When:** Prioritizing features or deciding scope.
+**Protocol:** Map: Goal → Actors → Impacts → Deliverables. Each deliverable must trace back through impact and actor to the goal.
+
+## Challenge Techniques
+
+### Devil's Advocate
+
+**When:** Before finalizing any major decision.
+**Protocol:** Argue passionately AGAINST the current recommendation. Find the 3 strongest objections. Then evaluate if the recommendation survives.
+
+### Pre-Mortem
+
+**When:** Before starting implementation of a plan.
+**Protocol:** "It's 2 weeks from now and this project has failed. Why?" List every plausible failure mode. For each, add a preventive measure to the plan.
+
+### Red Team
+
+**When:** Security review, adversarial analysis.
+**Protocol:** Adopt the mindset of an attacker. What would you exploit? What data could you steal? What would you break first?
+
+### Inversion
+
+**When:** Stuck on how to solve a problem.
+**Protocol:** Instead of "How do we make this work?", ask "How could we guarantee this FAILS?" Then do the opposite of each failure cause.
+
+## Convergence Techniques
+
+### MoSCoW Priority
+
+**When:** Scope negotiation, feature prioritization.
+**Protocol:** Classify every item as:
+
+- **Must have:** System fails without it
+- **Should have:** Important but workaroundable
+- **Could have:** Nice to have, only if time permits
+- **Won't have:** Explicitly out of scope this iteration
+
+### Decision Matrix
+
+**When:** Choosing between 3+ alternatives with multiple criteria.
+**Protocol:**
+
+1. List alternatives (columns)
+2. List criteria (rows) with weights (1-5)
+3. Score each alternative per criterion (1-5)
+4. Multiply score × weight, sum per alternative
+5. Highest total wins (but sanity-check the result)
+
+### Weighted Scoring
+
+**When:** Quick prioritization of a backlog or feature list.
+**Protocol:** Score each item on: Value (1-5) × Confidence (1-5) ÷ Effort (1-5). Sort descending. Top items are highest priority.
+
+### Dot Voting
+
+**When:** Team alignment on priorities (async-friendly).
+**Protocol:** Each participant gets 3 votes. Distribute across options. Most votes wins. Tie-breaker: discuss only tied items.
+
+## Creative Techniques
+
+### Brainstorming
+
+**When:** Generating alternatives before converging.
+**Protocol:** Generate 10+ ideas without judgment. No filtering during generation. Then evaluate each against criteria.
+
+### SCAMPER
+
+**When:** Improving an existing design.
+**Protocol:** For the current design, ask: Substitute? Combine? Adapt? Modify? Put to other use? Eliminate? Reverse?
+
+### Analogical Thinking
+
+**When:** Novel problems without obvious solutions.
+**Protocol:** Find 3 analogous problems from different domains. How were they solved? What patterns transfer?
+
+### Reverse Brainstorming
+
+**When:** Finding improvement opportunities.
+**Protocol:** "How could we make this WORSE?" List ways to sabotage. Then invert each sabotage into an improvement.
+
+## Technique Selection Guide
+
+| Situation              | Recommended Technique                         |
+| ---------------------- | --------------------------------------------- |
+| Vague requirements     | Socratic Method → Assumption Surfacing        |
+| Bug root cause         | 5 Whys                                        |
+| Technology choice      | Six Hats → Decision Matrix                    |
+| Feature prioritization | MoSCoW → Weighted Scoring                     |
+| Risk assessment        | Pre-Mortem → Force Field                      |
+| Security review        | Red Team → Devil's Advocate                   |
+| Stuck on approach      | Inversion → Analogical Thinking               |
+| Scope negotiation      | MoSCoW → Impact Mapping                       |
+| Architecture decision  | Six Hats → Devil's Advocate → Decision Matrix |
+
+## Chaining Techniques
+
+For deeper analysis, chain 2-3 techniques:
+
+1. **Discovery → Analysis → Decision:** Socratic Method → Six Hats → Decision Matrix
+2. **Risk Assessment:** Pre-Mortem → Force Field → Assumption Surfacing
+3. **Architecture Decision:** Devil's Advocate → Six Hats → Weighted Scoring

package/.merlin-core/skills/general/engineering-audit/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: engineering-audit
+description: "6-axis engineering audit — evaluates code across Architecture, Security, Performance, Resiliency, Quality, and Scale with severity-based findings and ship/fix/rethink verdicts."
+license: Apache-2.0
+metadata:
+  author: merlin-framework
+  version: "3.0.0"
+  auto_activate:
+    [audit, engineering-audit, engineering-review, codebase-audit, full-review]
+---
+
+# Engineering Audit
+
+Full-stack code evaluation across 6 dimensions. Not style. Not lint. Structure, security, resilience, and quality.
+
+## The Bar
+
+If the world's best engineers audited this codebase, they'd find nothing to complain about. That's the bar.
+
+## What You Audit
+
+### 1. Architecture
+
+- Responsibilities separated cleanly?
+- Module boundaries clear and respected?
+- Data flow obvious from structure?
+- Circular dependencies?
+- A new engineer understands the system in 30 minutes?
+- Separation of concerns at the right granularity?
+
+### 2. Security
+
+- Input validation at every boundary (client input, API input, third-party data)?
+- Authentication and authorization on every protected route?
+- No secrets, keys, or tokens exposed? — hand off to `secret-safe-commit` (preventive, gitleaks pre-commit + CI) and `purge-leaked-secret` (reactive, 5-phase incident response) when findings appear.
+- Protection against SQL injection, XSS, CSRF?
+- Trust boundaries explicitly defined?
+- Rate limiting on public endpoints?
+- Security headers configured?
+- Dependencies checked for known CVEs?
+- If the project ships a Dockerfile or container image: hand off to `container-security` (Dockerfile hardening checklist + Grype scanning + CVSS×EPSS×KEV triage matrix).
+- If the project is hosted on a self-managed VPS: hand off to `vps-security-hardening` (7-step protocol — SSH key auth, ufw, fail2ban, sshd hardening, recovery kit).
+- If the project processes PII of Brazilian residents: hand off to `lgpd-compliance-audit` (6-phase audit — inventory, lawful basis, consent, DSR endpoints, audit logs, breach response).
+
+### 3. Performance
+
+**Frontend:**
+
+- No unnecessary re-renders?
+- Bundle size awareness?
+- Lazy loading for heavy resources?
+- Core Web Vitals within budget (LCP ≤2.5s, CLS ≤0.1, INP ≤200ms)?
+
+**Backend:**
+
+- No N+1 queries?
+- Indexes on frequently queried columns?
+- No blocking operations on main thread?
+- Caching where appropriate?
+- Connection pooling configured?
+- Pagination on list endpoints?
+- Streaming for large payloads?
+
+### 4. Resiliency
+
+- Error handling preserves context (no empty catches)?
+- Retry logic that doesn't amplify failures (exponential backoff, circuit breaker)?
+- Graceful degradation when dependencies fail?
+- Race conditions identified and handled?
+- Data integrity under concurrent operations?
+- Transactions where atomicity matters?
+- Timeout configuration on external calls?
+
+### 5. Quality
+
+- Tests exist and test the right thing (not just line coverage)?
+- Naming is clear and consistent?
+- Abstractions at the right level (not over-engineered, not under-engineered)?
+- No dead code?
+- Dependencies maintained and up-to-date?
+- No duplicated logic?
+- Functions < 30 LOC, files < 300 lines?
+
+### 6. Scale
+
+- Where are the bottlenecks at 10x load?
+- And at 100x?
+- Database queries efficient at scale?
+- Architecture horizontally scalable if needed?
+- Stateless where possible for horizontal scaling?
+- Queue/worker patterns for heavy processing?
+- Cache invalidation strategy defined?
+
+## Finding Format
+
+For each finding:
+
+```
+[CRITICAL/HIGH/MEDIUM/LOW] Title
+Where: file or area
+Problem: what's wrong
+Impact: what happens if not fixed
+Fix: specific change needed
+```
+
+## Rules
+
+- Don't point out style preferences. Not about tabs vs spaces.
+- Every finding must include the specific fix.
+- If the code is solid, say it in one line. Don't invent problems.
+- Be direct. No "you might want to consider." Say what needs to change.
+- Check ALL dimensions. Don't skip the harder ones.
+- Reference existing Merlin skills for deep dives: static-analysis (SAST tooling), secret-safe-commit (gitleaks/pre-commit), purge-leaked-secret (credential rotation runbook), container-security (Docker + Grype), vps-security-hardening (server-side controls), lgpd-compliance-audit (Brazilian PII), web-quality (frontend vitals), load-testing (capacity), code-style (structural rules).
+
+## Verdict
+
+At the end, summarize:
+
+- Total findings by severity
+- **SHIPPA** — World-class. Ship it.
+- **CORRIGE PRIMEIRO** — Fix the findings, then ship.
+- **REPENSA** — Fundamental issues. Rethink the approach before proceeding.

package/.merlin-core/skills/general/find-and-edit/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: find-and-edit
+description: Systematic pattern for locating code, understanding context, and applying precise edits across files. Reduces wasted tool calls and prevents blind edits.
+license: Apache-2.0
+metadata:
+  author: merlin-framework
+  version: "3.0.0"
+  auto_activate: []
+  file_triggers:
+    [
+      "*.js",
+      "*.ts",
+      "*.jsx",
+      "*.tsx",
+      "*.py",
+      "*.go",
+      "*.rs",
+      "*.java",
+      "*.css",
+      "*.html",
+    ]
+  tool_reminders:
+    [
+      Always Read a file before editing it — never edit blind,
+      Use Grep to locate patterns across the codebase before making changes,
+      After editing,
+      verify the change didn't break imports or references,
+    ]
+---
+
+# Find-and-Edit — Systematic Code Modification
+
+A structured protocol for locating, understanding, and modifying code. Prevents blind edits, reduces unnecessary tool calls, and ensures changes are consistent across the codebase.
+
+## The Find-Read-Edit Cycle
+
+Every code modification follows this sequence:
+
+1. **FIND** — Locate the target using the right tool
+2. **READ** — Understand the context around the target
+3. **EDIT** — Apply the precise change
+4. **VERIFY** — Confirm the change is correct and consistent
+
+Never skip steps. Never edit a file you haven't read.
+
+## Finding Code Efficiently
+
+### Use the Right Tool for the Search
+
+| Goal                             | Tool           | Example                                    |
+| -------------------------------- | -------------- | ------------------------------------------ |
+| Find a file by name/pattern      | Glob           | `*.controller.ts`, `src/**/*.test.js`      |
+| Find code by content             | Grep           | `function authenticate`, `TODO:.*security` |
+| Find a class/function definition | Grep           | `class UserService`, `export function`     |
+| Find all usages of a symbol      | Grep           | `import.*UserService`, `UserService`       |
+| Explore unknown area             | Agent(Explore) | "How does auth work in this codebase?"     |
+
+### Search Strategy
+
+1. **Start narrow, widen if needed** — Search for the exact symbol first, then broaden
+2. **Use file type filters** — `--type ts` or `--glob "*.py"` to reduce noise
+3. **Check imports/exports** — When renaming, find all import sites first
+4. **Count before changing** — Use `output_mode: count` to know how many occurrences exist
+
+## Reading for Context
+
+Before editing, read enough context to understand:
+
+- **What the code does** — Not just the line, but the surrounding function/block
+- **Why it's structured this way** — Comments, naming, patterns that suggest intent
+- **What depends on it** — Callers, importers, tests that reference the target
+- **What it depends on** — Imports, shared state, configuration
+
+### Read Heuristics
+
+- Read ±20 lines around the target for function-level changes
+- Read the full file for structural changes (new exports, class modifications)
+- Read related test files when modifying behavior
+
+## Editing Precisely
+
+### Single-File Edits
+
+- Use `Edit` with the smallest unique `old_string` that captures the change
+- Include surrounding context in `old_string` to ensure uniqueness
+- Preserve exact indentation (tabs vs spaces, nesting level)
+
+### Multi-File Edits (Rename, Move, Migrate)
+
+1. **Enumerate all sites** — Grep for the symbol across the codebase
+2. **Plan the order** — Edit the definition first, then usages, then tests
+3. **Use `replace_all: true`** for safe renames within a single file
+4. **Verify imports** — After renaming an export, update all import statements
+
+## Verification Checklist
+
+After every edit:
+
+- [ ] The edited file still parses (no syntax errors)
+- [ ] Import/export names are consistent across files
+- [ ] Related tests still reference the correct symbols
+- [ ] No orphaned references to the old name/pattern

package/.merlin-core/skills/general/first-party-docs/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: first-party-docs
+description: Guides agents to prefer first-party documentation sources over web search. Integrates with Constitution XII Information Priority Hierarchy.
+license: Apache-2.0
+metadata:
+  author: merlin-framework
+  version: "3.0.0"
+  auto_activate: [official-docs, api-reference, library-docs, framework-docs, sdk-docs]
+  tool_reminders: [Check first-party documentation BEFORE web searching — see the trusted docs registry, Flag information with source tier: [FIRST-PARTY] or [WEB-SEARCH] or [GENERAL-KNOWLEDGE]]
+---
+
+## First-Party Documentation Priority
+
+Per Constitution Article XII, information sources are ranked by reliability. First-party documentation (Tier 3) takes priority over web search (Tier 4) and model knowledge (Tier 5).
+
+## Trusted Documentation Sources
+
+When researching a technology, always check its official documentation first:
+
+| Technology   | First-Party Source      |
+| ------------ | ----------------------- |
+| Node.js      | nodejs.org/docs         |
+| React        | react.dev               |
+| Next.js      | nextjs.org/docs         |
+| TypeScript   | typescriptlang.org/docs |
+| Tailwind CSS | tailwindcss.com/docs    |
+| Electron     | electronjs.org/docs     |
+| PostgreSQL   | postgresql.org/docs     |
+| SQLite       | sqlite.org/docs         |
+| Express      | expressjs.com           |
+| Vite         | vite.dev/guide          |
+| Claude API   | docs.anthropic.com      |
+| Stripe       | docs.stripe.com         |
+| Resend       | resend.com/docs         |
+| React Email  | react.email/docs        |
+
+## Source Tier Labeling
+
+When presenting information to agents or users, label the source tier:
+
+- `[FIRST-PARTY]` — From official documentation of the technology
+- `[WEB-SEARCH]` — From web search results (blogs, Stack Overflow, tutorials)
+- `[GENERAL-KNOWLEDGE]` — From model training data with no specific source
+- `[PROJECT-LOCAL]` — From project learnings, decisions, or research documents
+
+## Research Flow
+
+1. Check project-local knowledge first (`thoughts/shared/learnings/`, `thoughts/shared/research/`)
+2. Check first-party documentation for the relevant technology
+3. Only then fall back to web search for community solutions or edge cases
+4. Flag any information that comes solely from Tier 4-5 sources

package/.merlin-core/skills/general/frontend-design/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: frontend-design
+description: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code and UI design that avoids generic AI aesthetics."
+license: MIT (Anthropic)
+compatibility: claude-code
+metadata:
+  source: anthropic/skills
+  imported: 2026-03-15
+  version: "1.0"
+  auto_activate:
+    [
+      frontend-design,
+      design-philosophy,
+      design-aesthetic,
+      ui-philosophy,
+      distinctive-ui,
+    ]
+---
+
+# Frontend Design Philosophy
+
+This skill provides the **design thinking layer** that sits above Merlin's existing design skills (design-system, design-palette, design-typography, design-ux-patterns, design-inspiration). While those skills handle specific technical domains, this skill governs the overall aesthetic direction and design philosophy.
+
+## Core Principle
+
+**Intentional aesthetic direction before coding.** Identify purpose, select a clear tonal approach, and commit fully to that vision rather than defaulting to common patterns.
+
+## Design Thinking Process
+
+Before writing any code, answer these questions:
+
+1. **Purpose** — What is this interface trying to accomplish? What emotions should it evoke?
+2. **Tone** — What's the aesthetic direction? (brutalist, maximalist, retro, organic, minimal, editorial, etc.)
+3. **Constraints** — What are the technical limits? (browser support, performance, accessibility)
+4. **Differentiation** — What makes this feel unique? What would make someone remember it?
+
+## Aesthetic Guidelines
+
+### Typography
+
+Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter in favor of distinctive, characterful selections paired strategically.
+
+**Font pairing strategies:**
+
+- Contrast weights dramatically (thin display + bold body, or vice versa)
+- Mix serif + sans-serif (not two of the same category)
+- Use one distinctive font + one neutral companion
+- Consider variable fonts for maximum flexibility
+
+### Color
+
+Commit to a dominant tone with sharp accents. Never give all colors equal visual weight.
+
+**Color principles:**
+
+- **60-30-10 rule**: 60% dominant, 30% secondary, 10% accent
+- Dark backgrounds for premium feel; light for clarity
+- Use opacity/transparency layers for depth
+- Color should reinforce meaning, not just decorate
+
+### Motion & Animation
+
+High-impact page loads with staggered reveals outperform scattered interactions.
+
+**Motion principles:**
+
+- Entrance animations: stagger elements 50-100ms apart
+- Scroll-triggered effects should surprise, not annoy
+- Hover states should feel responsive (100-200ms)
+- Exit animations: faster than entrances (perception of speed)
+- Always respect `prefers-reduced-motion`
+
+### Spatial Composition
+
+Use unexpected layouts — asymmetry, overlap, diagonal flow, grid-breaking elements.
+
+**Layout principles:**
+
+- Break the grid intentionally (not accidentally)
+- Negative space is a design element, not wasted space
+- Overlapping elements create depth and interest
+- Asymmetric layouts feel more dynamic than centered ones
+
+### Backgrounds & Texture
+
+Create atmosphere through textures, gradients, and layered effects.
+
+**Background techniques:**
+
+- Gradient meshes for organic feel
+- Subtle noise/grain for tactile quality
+- Layered semi-transparent shapes for depth
+- Ambient video/animation for immersion (with fallbacks)
+
+## Anti-Patterns to Avoid
+
+These patterns scream "generic AI-generated":
+
+- **Inter/Geist/system font defaults** — Choose something with character
+- **Purple-to-blue gradient heroes** — Every AI demo uses this
+- **Cookie-cutter card grids** — All identical, evenly spaced
+- **Centered everything** — Left-align body text, vary composition
+- **Rounded corners on everything** — Mix sharp and soft edges intentionally
+- **Generic stock illustration style** — Use photography, icons, or custom graphics
+- **Equally-weighted navigation items** — Create visual hierarchy
+- **Flat solid backgrounds** — Add texture, gradients, or atmosphere
+
+## Complexity Matches Vision
+
+The amount of code should match the design ambition:
+
+- **Maximalist designs** warrant elaborate CSS, animations, and layered compositions
+- **Minimalist designs** require restraint and precision in spacing, typography, and subtle details
+- **Don't over-engineer simple designs** and **don't under-engineer ambitious ones**
+
+## Integration with Existing Merlin Skills
+
+This skill works alongside:
+
+- **design-system**: Semantic tokens, spacing grid, component architecture
+- **design-palette**: Industry-specific palettes, WCAG contrast
+- **design-typography**: Font pairing (20 combos), size scales
+- **design-ux-patterns**: Landing pages, dashboards, accessibility
+- **design-inspiration**: Generates design briefs before visual work
+- **mage-beauty**: Operational verbs (critique, polish, bolder, …) and consolidated anti-patterns. Invoke via `/beauty <verb>`.
+
+Use this skill for the **overall aesthetic direction**, then consult the specific skills for implementation details.
+
+## Design Evaluation Rubric
+
+When reviewing or evaluating an interface, assess across these 6 dimensions:
+
+### Sophistication
+
+Every element on screen has a reason to exist. If you can't explain why something is there, it shouldn't be. Decoration without purpose fails. Complexity without clarity fails.
+
+### Differentiation
+
+This interface could only belong to this product. If you swap the logo and it could be anything, the design failed. Identity isn't a logo. It's how everything feels together.
+
+### Experience
+
+Using this software must feel like something. Not neutral. Not invisible. There must be moments where the user feels someone cared deeply about the craft. Transitions, micro-interactions, loading states, empty states, error states — every state is designed, not default.
+
+### Enchantment
+
+The small things that make someone pause. A hover animation that feels exactly right. A transition that guides instead of distracts. Typography that breathes. Color that means something.
+
+### Usability
+
+Effortless. The user never wonders what to do. Information hierarchy is clear. Primary actions are obvious. Navigation is intuitive. The interface teaches itself.
+
+### Beauty
+
+Judged against the best products ever built, not the most common. Dark-first consideration. Editorial typography. Cinematic sensibility. Generous whitespace. Sophisticated color with restraint.
+
+## Benchmark Products
+
+These are the reference — not to copy, but to match in craft, intention, and care:
+
+- **Apple**: Restraint, material quality, every pixel considered
+- **Airbnb**: Experience design, emotional resonance, storytelling through interface
+- **Linear**: Density with elegance, dark mode mastery, information architecture
+- **Stripe**: Layout sophistication, editorial typography, documentation as product
+- **Vercel**: Whitespace as design element, typographic precision, minimalism that communicates
+
+## Rejection Criteria (Immediate Fail)
+
+These patterns fail immediately — no discussion:
+
+- **Template energy** — Looks like a UI kit with swapped content
+- **All defaults** — System fonts, default spacing, default colors
+- **No dark mode consideration** — Light-only without justification
+- **Generic SaaS aesthetic** — Card grids with gray borders and blue buttons
+- **Flat visual hierarchy** — Everything has the same weight
+- **2015 admin panel aesthetic** — Outdated patterns presented as modern
+- **"We'll make it pretty later"** — Quality is built in, not added
+
+## Fix Specificity Standard
+
+When a design fails evaluation, fixes must be specific — not vague:
+
+**Bad:** "Make the background darker"
+**Good:** "Change background to #0A0A0B, increase heading font-weight to 600 with letter-spacing -0.02em"
+
+**Bad:** "Add more spacing"
+**Good:** "Increase section padding from 24px to 64px, add 32px gap between card rows"
+
+**Bad:** "The colors feel off"
+**Good:** "Replace #6366F1 accent with #818CF8 at 80% opacity on dark surfaces for better contrast"
+
+Every design fix must include exact values: hex codes, pixel values, font-weight numbers, opacity percentages, letter-spacing values.
+
+### Pass Format
+
+If the design meets the bar: "Atende a barra." One sentence about what works. Move on.
+
+### Fail Format
+
+For each issue:
+
+1. **What** is wrong (specific element or pattern)
+2. **Why** it fails (which principle it violates)
+3. **How to fix** (exact values — colors, spacing, typography, layout changes)