tribunal-kit 1.0.0 → 2.4.2

package/.agent/skills/testing-patterns/SKILL.md

@@ -1,178 +1,205 @@
 ---
 name: testing-patterns
 description: Testing patterns and principles. Unit, integration, mocking strategies.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
 # Testing Patterns
 
-> Principles for reliable test suites.
+> Tests don't prove code works. They make it safe to change.
+> A codebase without tests is a codebase you're afraid to touch.
 
 ---
 
-## 1. Testing Pyramid
+## Test Pyramid
+
+Write tests at the right level. Most tests should be unit tests. Fewer integration tests. Fewest E2E tests.
 
 ```
-        /\          E2E (Few)
-       /  \         Critical flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, DB queries
-   /          \
-  /------------\    Unit (Many)
-                    Functions, classes
+         /\
+        /E2E\         Fewest — expensive to write and run
+       /------\
+      /Integr. \      Some — verify component interactions  
+     /----------\
+    /  Unit Tests \   Most — fast, isolated, focused
+   /--------------\
 ```
 
+**Why this shape:**
+- Unit tests run in milliseconds — you can have thousands
+- E2E tests take seconds — you want dozens, not hundreds
+- Inverting the pyramid = slow CI, fragile test suite, low confidence
+
 ---
 
-## 2. AAA Pattern
+## AAA Pattern
 
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify outcome |
+Every test follows this structure:
 
----
+```ts
+it('should return 401 when token is expired', async () => {
+  // Arrange — set up the scenario
+  const expiredToken = generateToken({ expiresIn: '-1s' });
+  const request = buildRequest({ authorization: `Bearer ${expiredToken}` });
 
-## 3. Test Type Selection
+  // Act — do the thing being tested
+  const response = await authMiddleware(request);
 
-### When to Use Each
+  // Assert — verify the outcome
+  expect(response.status).toBe(401);
+  expect(response.body.error).toBe('Token expired');
+});
+```
 
-| Type | Best For | Speed |
-|------|----------|-------|
-| **Unit** | Pure functions, logic | Fast (<50ms) |
-| **Integration** | API, DB, services | Medium |
-| **E2E** | Critical user flows | Slow |
+Never combine Arrange and Assert. Never skip Arrange by relying on test state from a previous test.
 
 ---
 
-## 4. Unit Test Principles
+## Unit Tests
+
+Unit tests test one unit of logic in isolation. Everything external is replaced with a controlled substitute.
 
-### Good Unit Tests
+```ts
+// Test the function's logic — not the database, not the network
+it('should hash the password before saving', async () => {
+  const mockSave = vi.fn().mockResolvedValue({ id: '1' });
+  const userRepo = { save: mockSave };
 
-| Principle | Meaning |
-|-----------|---------|
-| Fast | < 100ms each |
-| Isolated | No external deps |
-| Repeatable | Same result always |
-| Self-checking | No manual verification |
-| Timely | Written with code |
+  await createUser({ email: 'a@b.com', password: 'secret' }, userRepo);
 
-### What to Unit Test
+  const savedUser = mockSave.mock.calls[0][0];
+  expect(savedUser.password).not.toBe('secret');          // was hashed
+  expect(savedUser.password).toMatch(/^\$2b\$/);           // bcrypt format
+});
+```
 
-| Test | Don't Test |
-|------|------------|
-| Business logic | Framework code |
-| Edge cases | Third-party libs |
-| Error handling | Simple getters |
+**Rules for unit tests:**
+- One assertion per concept (multiple `expect` calls are fine if they verify the same behavior)
+- No network calls, no file system, no real database
+- Tests are order-independent — they don't rely on state from other tests
+- Test names describe behavior: `should X when Y` or `returns X given Y`
 
 ---
 
-## 5. Integration Test Principles
+## Integration Tests
 
-### What to Test
+Integration tests verify that two or more components work together correctly.
 
-| Area | Focus |
-|------|-------|
-| API endpoints | Request/response |
-| Database | Queries, transactions |
-| External services | Contracts |
+```ts
+// Tests the real database interaction
+it('should save and retrieve a user', async () => {
+  const user = await UserService.create({ email: 'test@test.com', name: 'Test' });
+  const found = await UserService.findById(user.id);
 
-### Setup/Teardown
+  expect(found.email).toBe('test@test.com');
+});
+```
 
-| Phase | Action |
-|-------|--------|
-| Before All | Connect resources |
-| Before Each | Reset state |
-| After Each | Clean up |
-| After All | Disconnect |
+**Integration test rules:**
+- Use a real test database — not a mock
+- Clean up data before or after each test (use transactions that rollback, or seed scripts)
+- Slower than unit tests — run on CI but not on every file save
 
 ---
 
-## 6. Mocking Principles
+## Mocking Principles
 
-### When to Mock
+Mocks replace external dependencies. Use them accurately.
 
-| Mock | Don't Mock |
-|------|------------|
-| External APIs | The code under test |
-| Database (unit) | Simple dependencies |
-| Time/random | Pure functions |
-| Network | In-memory stores |
+```ts
+// ❌ Mock that returns nothing useful
+vi.mock('./mailer', () => ({ send: vi.fn() }));
 
-### Mock Types
+// ✅ Mock that reflects real behavior
+vi.mock('./mailer', () => ({
+  send: vi.fn().mockResolvedValue({ messageId: 'mock-id-123' }),
+}));
+```
 
-| Type | Use |
-|------|-----|
-| Stub | Return fixed values |
-| Spy | Track calls |
-| Mock | Set expectations |
-| Fake | Simplified implementation |
+**What to mock:**
+- External HTTP calls (payment gateways, third-party APIs)
+- Time (`Date.now()`, `new Date()`) when time-dependent
+- File system in unit tests
+- Email/SMS sending
 
----
+**What not to mock:**
+- Your own business logic
+- The function being tested
+- Simple pure utility functions
 
-## 7. Test Organization
+---
 
-### Naming
+## Test Coverage
 
-| Pattern | Example |
-|---------|---------|
-| Should behavior | "should return error when..." |
-| When condition | "when user not found..." |
-| Given-when-then | "given X, when Y, then Z" |
+Coverage measures which lines are executed during tests. 100% coverage does not mean the code is correct.
 
-### Grouping
+**Useful coverage:**
+- `> 80%` for business logic modules
+- Focus on statement + branch coverage (not just line coverage)
+- Low coverage on infrastructure/config files is acceptable
 
-| Level | Use |
-|-------|-----|
-| describe | Group related tests |
-| it/test | Individual case |
-| beforeEach | Common setup |
+**Coverage anti-patterns:**
+- Tests written solely to increase coverage numbers
+- Asserting that mocks were called instead of asserting real outcomes
+- Tautology tests: `expect(result).toBe(result)`
 
 ---
 
-## 8. Test Data
+## Scripts
 
-### Strategies
+| Script | Purpose | Run With |
+|---|---|---|
+| `scripts/test_runner.py` | Runs test suite and reports results | `python scripts/test_runner.py <project_path>` |
 
-| Approach | Use |
-|----------|-----|
-| Factories | Generate test data |
-| Fixtures | Predefined datasets |
-| Builders | Fluent object creation |
+---
 
-### Principles
+## Output Format
 
-- Use realistic data
-- Randomize non-essential values (faker)
-- Share common fixtures
-- Keep data minimal
+When this skill produces or reviews code, structure your output as follows:
 
----
+```
+━━━ Testing Patterns Report ━━━━━━━━━━━━━━━━━━━━━━━━
+Skill:       Testing Patterns
+Language:    [detected language / framework]
+Scope:       [N files · N functions]
+─────────────────────────────────────────────────
+✅ Passed:   [checks that passed, or "All clean"]
+⚠️  Warnings: [non-blocking issues, or "None"]
+❌ Blocked:  [blocking issues requiring fix, or "None"]
+─────────────────────────────────────────────────
+VBC status:  PENDING → VERIFIED
+Evidence:    [test output / lint pass / compile success]
+```
 
-## 9. Best Practices
+**VBC (Verification-Before-Completion) is mandatory.**
+Do not mark status as VERIFIED until concrete terminal evidence is provided.
 
-| Practice | Why |
-|----------|-----|
-| One assert per test | Clear failure reason |
-| Independent tests | No order dependency |
-| Fast tests | Run frequently |
-| Descriptive names | Self-documenting |
-| Clean up | Avoid side effects |
 
 ---
 
-## 10. Anti-Patterns
+## 🏛️ Tribunal Integration (Anti-Hallucination)
 
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Duplicate test code | Use factories |
-| Complex test setup | Simplify or split |
-| Ignore flaky tests | Fix root cause |
-| Skip cleanup | Reset state |
+**Slash command: `/test`**
+**Active reviewers: `logic` · `test-coverage-reviewer`**
 
----
+### ❌ Forbidden AI Tropes in Testing
 
-> **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.
+1. **Tautological Tests** — writing `expect(x).toBe(x)` or testing that a mock returns what it was mocked to return, ignoring actual behavior.
+2. **Missing the "Arrange" Step** — relying on test state leftover from a previous `it()` block.
+3. **Over-mocking** — mocking the system under test or mocking out so much that the test is completely useless.
+4. **Assertions in loops** — writing loops with dynamic assertions instead of explicit, readable test cases.
+5. **Ignoring Async Failures** — forgetting to `await` the assertions or the function under test, leading to false positives.
+
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before generating test code:
+```
+✅ Does each test explicitly follow the Arrange-Act-Assert (AAA) pattern?
+✅ Are external dependencies (DBs, Networks) isolated efficiently using proper mocks?
+✅ Is the test asserting verifying behavioral OUTCOMES rather than internal implementation details?
+✅ Did I properly `await` asynchronous operations to prevent false positives?
+✅ Are test names readable and descriptive of the tested behavior?
+```

package/.agent/skills/trend-researcher/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: trend-researcher
+description: Creative muse and design trend analyzer for modern web/mobile interfaces.
+skills:
+  - frontend-design
+  - web-design-guidelines
+  - seo-fundamentals
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# Trend Researcher Skill
+
+You are a creative muse and design trend analyst. Your purpose is to bridge the gap between "generic UI" and "stunning, intentional design" by grounding aesthetic decisions in real-world trends, documented design systems, and measurable user impact.
+
+## When to Activate
+
+- When asked to "brainstorm for design", "find inspiration", or "select a style guide".
+- During `/ui-ux-pro-max` or `/create` workflows when a visual direction hasn't been set.
+- Before any frontend build to establish a Design Token foundation.
+- When paired with `ui-ux-researcher` for a full "Design Intelligence" pass.
+
+## Core Capabilities
+
+### 1. Trend Identification & Classification
+
+Leverage `search_web` to scan top design aggregators and classify trends by maturity:
+
+| Maturity | Description | Examples (2025–2026) | Risk |
+|---|---|---|---|
+| **Established** | Widely adopted, safe to use | Bento Grids, Glassmorphism, Dark Mode | Low |
+| **Rising** | Gaining traction, differentiating | Claymorphism, Spatial UI, Kinetic Typography | Medium |
+| **Experimental** | Cutting-edge, high differentiation | Generative Art Backgrounds, 3D Morphing Cards, AI-Responsive Layouts | High |
+| **Declining** | Overused, losing impact | Flat Minimalism, Neumorphism, Full-bleed hero images | Avoid unless justified |
+
+**Banned Clichés (Unless Explicitly Requested):**
+- ❌ Purple/violet gradients as primary AI branding
+- ❌ Generic mesh gradient backgrounds
+- ❌ Standard "left text / right image" hero layouts without creative justification
+- ❌ "Futuristic" dark themes with neon accents (overused since 2023)
+
+### 2. Palette Generation Protocol
+
+Generate harmonized color palettes using HSL for precise control:
+
+```
+Primary    → The brand's identity color (used sparingly: CTAs, key icons)
+Surface    → Background tones (light: hsl(0, 0%, 98%), dark: hsl(220, 20%, 10%))
+Accent     → Complementary pop color (split-complementary for sophistication)
+Neutral    → Text and border hierarchy (at least 4 shades)
+Semantic   → Success (green), Warning (amber), Error (red), Info (blue)
+```
+
+**Rules:**
+- Always provide both light and dark mode variants.
+- Contrast ratios must meet WCAG 2.2 AA (4.5:1 normal text, 3:1 large text).
+- Generate a test swatch block showing all colors in context.
+
+### 3. Typography Pairing Engine
+
+Recommend Google Font pairings based on personality:
+
+| Personality | Heading Font | Body Font | Usage |
+|---|---|---|---|
+| **Elevated Minimalist** | Playfair Display | Inter | Luxury, editorial |
+| **Modern Tech** | Space Grotesk | DM Sans | SaaS, dashboards |
+| **Friendly Product** | Outfit | Source Sans 3 | Consumer apps |
+| **Bold Creative** | Clash Display | Satoshi | Portfolios, agencies |
+| **Corporate Trust** | Plus Jakarta Sans | Noto Sans | Enterprise, fintech |
+| **Editorial Long-form** | Fraunces | Literata | Blogs, magazines |
+
+**Scale:** Always recommend a modular scale (Major Third 1.25 or Perfect Fourth 1.333).
+
+### 4. Layout Pattern Library
+
+Translate trends into structured layout decisions:
+
+| Pattern | When to Use | CSS Approach |
+|---|---|---|
+| **Bento Grid** | Dashboards, landing page feature sections | `grid-template-areas` with varied spans |
+| **Asymmetric Split** | Hero sections, about pages | 60/40 or 70/30 grid columns |
+| **Full-bleed Cards** | Mobile-first content lists | `width: 100vw` with negative margin |
+| **Stacked Sections** | Long-form landing pages | `scroll-snap-type: y mandatory` |
+| **Sidebar + Canvas** | App layouts, admin panels | `grid-template-columns: 240px 1fr` |
+| **Overlapping Layers** | Creative portfolios, editorials | Negative margins + z-index layering |
+
+### 5. Motion & Interaction Direction
+
+Pair with `whimsy-injector` for implementation. Here, define the *intention*:
+
+| Intent | Motion Type | Duration | Easing |
+|---|---|---|---|
+| **Guide attention** | Subtle pulse / scale on CTA | 200ms | ease-out |
+| **Show hierarchy** | Staggered entrance on scroll | 300ms per item, 50ms stagger | cubic-bezier(0.4, 0, 0.2, 1) |
+| **Confirm action** | Checkmark draw / color flash | 150ms | ease-in-out |
+| **Create depth** | Parallax on scroll | Continuous | linear (scroll-driven) |
+
+## Interaction Protocol
+
+### Phase 1: Discovery
+```
+1. Ask: "What is the product type?" (SaaS, e-commerce, portfolio, etc.)
+2. Ask: "Who is the target audience?" (developers, consumers, enterprise)
+3. Ask: "What 3 words should users associate with this brand?"
+4. Search for industry-specific trends using search_web.
+5. Cross-reference with `frontend-design` and `web-design-guidelines` skills.
+```
+
+### Phase 2: Muse Report
+Provide a structured "Design Muse" report:
+
+```
+━━━ Design Muse Report ━━━━━━━━━━━━━━━━━━━
+
+Direction:  [Trend Name] (e.g., "Soft Brutalism with Warmth")
+Maturity:   [Established / Rising / Experimental]
+
+━━━ Color System ━━━━━━━━━━━━━━━━━━━━━━━━━
+Primary:   hsl(220, 80%, 55%)   → #3366CC
+Surface:   hsl(220, 15%, 97%)   → #F5F6F8
+Accent:    hsl(35, 90%, 60%)    → #E8A030
+Neutral:   hsl(220, 10%, 40%)   → #5C6370
+
+━━━ Typography ━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Heading:  Space Grotesk (700)  — Scale: 1.333
+Body:     DM Sans (400/500)    — Base: 16px / 1.6 line-height
+
+━━━ Layout Direction ━━━━━━━━━━━━━━━━━━━━━
+Pattern:    Bento Grid with Asymmetric Hero
+Grid:       8px base unit
+Radius:     12px outer / 8px inner
+Depth:      Soft shadows, no hard borders
+
+━━━ Motion Intent ━━━━━━━━━━━━━━━━━━━━━━━━
+Entrance:   Staggered fade-up (300ms, 50ms stagger)
+Hover:      Subtle lift + shadow expansion
+Scroll:     Section snap with parallax accents
+
+━━━ References ━━━━━━━━━━━━━━━━━━━━━━━━━━━
+[1] [Real URL from search — Dribbble/Awwwards/Mobbin]
+[2] [Real URL from search]
+```
+
+### Phase 3: Application
+When implementing designs:
+- Generate CSS custom properties from the palette.
+- Create a `design-tokens.css` or inject into `index.css`.
+- Pass motion intent to `whimsy-injector` for implementation.
+- Validate accessibility with `ui-ux-researcher`.
+
+## Cross-Skill Integration
+
+| Paired Skill | Integration Point |
+|---|---|
+| `ui-ux-researcher` | Validate palette contrast + cognitive load after applying trend |
+| `whimsy-injector` | Pass motion intent → receive implementation snippets |
+| `frontend-design` | Use as reference for component-level styling |
+| `web-design-guidelines` | Ensure trend suggestions comply with established guidelines |
+| `seo-fundamentals` | Verify that trend choices don't harm Core Web Vitals |
+
+## Anti-Hallucination Guard
+
+- **Never suggest a design trend without a real-world reference** — cite Dribbble shots, Awwwards winners, or published design systems.
+- **Banned clichés are enforced** — do not suggest purple/violet AI gradients or mesh backgrounds without explicit user request.
+- **Always verify fonts** are available on Google Fonts or system defaults before recommending.
+- **Color contrast must be calculated**, not assumed — use the formula or a known tool.
+- **No fictional design systems** — only reference Material Design, Apple HIG, Ant Design, Radix, Shadcn, or other documented systems.
+
+---
+
+## Output Format
+
+When this skill produces a recommendation or design decision, structure your output as:
+
+```
+━━━ Trend Researcher Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```
+
+
+
+---
+
+## 🤖 LLM-Specific Traps
+
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+
+---
+
+## 🏛️ Tribunal Integration (Anti-Hallucination)
+
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
+
+### ❌ Forbidden AI Tropes
+
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before confirming output:
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 Verification-Before-Completion (VBC) Protocol
+
+**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
+- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.

package/.agent/skills/ui-ux-pro-max/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: ui-ux-pro-max
+description: Plan and implement cutting-edge advanced UI/UX. Create distinctive, production-grade frontend interfaces with high design quality that avoid generic AI aesthetics.
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+# UI/UX Pro Max: Peak Performance Frontend Aesthetics
+
+This skill guides the creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
+
+## Scope
+Use this skill when the user asks to build web components, pages, or applications and expects creative, polished code that avoids generic AI aesthetics.
+
+## Design Thinking
+
+Before coding, understand the context and commit to a BOLD aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. These are inspiration—design one that is true to the direction.
+- **Constraints**: Technical requirements (framework, performance, accessibility).
+- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
+
+**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
+
+Then implement working code (HTML/CSS/JS, React, Vue, Tailwind, etc.) that is:
+- Production-grade and functional
+- Visually striking and memorable
+- Cohesive with a clear aesthetic point-of-view
+- Meticulously refined in every detail
+
+## Frontend Aesthetics Guidelines
+
+Focus on:
+- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
+- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
+- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
+- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
+
+**NEVER** use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
+
+**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
+
+Remember: Claude (and any AI agent using this skill) is capable of extraordinary creative work. Don't hold back; show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
+
+---
+
+## Output Format
+
+When this skill produces a recommendation or design decision, structure your output as:
+
+```
+━━━ Ui Ux Pro Max Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```
+
+
+
+---
+
+## 🤖 LLM-Specific Traps
+
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+
+---
+
+## 🏛️ Tribunal Integration (Anti-Hallucination)
+
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
+
+### ❌ Forbidden AI Tropes
+
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+
+### ✅ Pre-Flight Self-Audit
+
+Review these questions before confirming output:
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 Verification-Before-Completion (VBC) Protocol
+
+**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
+- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.