kenaz 0.0.0-stage → 0.3.2

package/core/plugins/kenaz/skills/distill/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: distill
+description: Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean.
+args:
+  - name: target
+    description: The feature or component to distill (optional)
+    required: false
+user-invokable: true
+---
+
+Remove unnecessary complexity from designs, revealing the essential elements and creating clarity through ruthless simplification.
+
+## MANDATORY PREPARATION
+
+### Context Gathering (Do This First)
+
+You cannot do a great job without having necessary context, such as target audience (critical), desired use-cases (critical), and understanding what's truly essential vs nice-to-have for this product.
+
+Attempt to gather these from the current thread or codebase.
+
+1. If you don't find *exact* information and have to infer from existing design and functionality, you MUST STOP and ask the user whether you got it right.
+2. Otherwise, if you can't fully infer or your level of confidence is medium or lower, you MUST ask the user clarifying questions first to complete your context.
+
+Do NOT proceed until you have answers. Simplifying the wrong things destroys usability.
+
+### Use frontend-design skill
+
+Use the frontend-design skill for design principles and anti-patterns. Do NOT proceed until it has executed and you know all DO's and DON'Ts.
+
+---
+
+## Assess Current State
+
+Analyze what makes the design feel complex or cluttered:
+
+1. **Identify complexity sources**:
+   - **Too many elements**: Competing buttons, redundant information, visual clutter
+   - **Excessive variation**: Too many colors, fonts, sizes, styles without purpose
+   - **Information overload**: Everything visible at once, no progressive disclosure
+   - **Visual noise**: Unnecessary borders, shadows, backgrounds, decorations
+   - **Confusing hierarchy**: Unclear what matters most
+   - **Feature creep**: Too many options, actions, or paths forward
+
+2. **Find the essence**:
+   - What's the primary user goal? (There should be ONE)
+   - What's actually necessary vs nice-to-have?
+   - What can be removed, hidden, or combined?
+   - What's the 20% that delivers 80% of value?
+
+If any of these are unclear from the codebase, ask the user
+
+**CRITICAL**: Simplicity is not about removing features - it's about removing obstacles between users and their goals. Every element should justify its existence.
+
+## Plan Simplification
+
+Create a ruthless editing strategy:
+
+- **Core purpose**: What's the ONE thing this should accomplish?
+- **Essential elements**: What's truly necessary to achieve that purpose?
+- **Progressive disclosure**: What can be hidden until needed?
+- **Consolidation opportunities**: What can be combined or integrated?
+
+**IMPORTANT**: Simplification is hard. It requires saying no to good ideas to make room for great execution. Be ruthless.
+
+## Simplify the Design
+
+Systematically remove complexity across these dimensions:
+
+### Information Architecture
+- **Reduce scope**: Remove secondary actions, optional features, redundant information
+- **Progressive disclosure**: Hide complexity behind clear entry points (accordions, modals, step-through flows)
+- **Combine related actions**: Merge similar buttons, consolidate forms, group related content
+- **Clear hierarchy**: ONE primary action, few secondary actions, everything else tertiary or hidden
+- **Remove redundancy**: If it's said elsewhere, don't repeat it here
+
+### Visual Simplification
+- **Reduce color palette**: Use 1-2 colors plus neutrals, not 5-7 colors
+- **Limit typography**: One font family, 3-4 sizes maximum, 2-3 weights
+- **Remove decorations**: Eliminate borders, shadows, backgrounds that don't serve hierarchy or function
+- **Flatten structure**: Reduce nesting, remove unnecessary containers—never nest cards inside cards
+- **Remove unnecessary cards**: Cards aren't needed for basic layout; use spacing and alignment instead
+- **Consistent spacing**: Use one spacing scale, remove arbitrary gaps
+
+### Layout Simplification
+- **Linear flow**: Replace complex grids with simple vertical flow where possible
+- **Remove sidebars**: Move secondary content inline or hide it
+- **Full-width**: Use available space generously instead of complex multi-column layouts
+- **Consistent alignment**: Pick left or center, stick with it
+- **Generous white space**: Let content breathe, don't pack everything tight
+
+### Interaction Simplification
+- **Reduce choices**: Fewer buttons, fewer options, clearer path forward (paradox of choice is real)
+- **Smart defaults**: Make common choices automatic, only ask when necessary
+- **Inline actions**: Replace modal flows with inline editing where possible
+- **Remove steps**: Can signup be one step instead of three? Can checkout be simplified?
+- **Clear CTAs**: ONE obvious next step, not five competing actions
+
+### Content Simplification
+- **Shorter copy**: Cut every sentence in half, then do it again
+- **Active voice**: "Save changes" not "Changes will be saved"
+- **Remove jargon**: Plain language always wins
+- **Scannable structure**: Short paragraphs, bullet points, clear headings
+- **Essential information only**: Remove marketing fluff, legalese, hedging
+- **Remove redundant copy**: No headers restating intros, no repeated explanations, say it once
+
+### Code Simplification
+- **Remove unused code**: Dead CSS, unused components, orphaned files
+- **Flatten component trees**: Reduce nesting depth
+- **Consolidate styles**: Merge similar styles, use utilities consistently
+- **Reduce variants**: Does that component need 12 variations, or can 3 cover 90% of cases?
+
+**NEVER**:
+- Remove necessary functionality (simplicity ≠ feature-less)
+- Sacrifice accessibility for simplicity (clear labels and ARIA still required)
+- Make things so simple they're unclear (mystery ≠ minimalism)
+- Remove information users need to make decisions
+- Eliminate hierarchy completely (some things should stand out)
+- Oversimplify complex domains (match complexity to actual task complexity)
+
+## Verify Simplification
+
+Ensure simplification improves usability:
+
+- **Faster task completion**: Can users accomplish goals more quickly?
+- **Reduced cognitive load**: Is it easier to understand what to do?
+- **Still complete**: Are all necessary features still accessible?
+- **Clearer hierarchy**: Is it obvious what matters most?
+- **Better performance**: Does simpler design load faster?
+
+## Document Removed Complexity
+
+If you removed features or options:
+- Document why they were removed
+- Consider if they need alternative access points
+- Note any user feedback to monitor
+
+Remember: You have great taste and judgment. Simplification is an act of confidence - knowing what to keep and courage to remove the rest. As Antoine de Saint-Exupéry said: "Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

package/core/plugins/kenaz/skills/extract/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: extract
+description: Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library.
+args:
+  - name: target
+    description: The feature, component, or area to extract from (optional)
+    required: false
+user-invokable: true
+---
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Discover
+
+Analyze the target area to identify extraction opportunities:
+
+1. **Find the design system**: Locate your design system, component library, or shared UI directory (grep for "design system", "ui", "components", etc.). Understand its structure:
+   - Component organization and naming conventions
+   - Design token structure (if any)
+   - Documentation patterns
+   - Import/export conventions
+   
+   **CRITICAL**: If no design system exists, ask before creating one. Understand the preferred location and structure first.
+
+2. **Identify patterns**: Look for:
+   - **Repeated components**: Similar UI patterns used multiple times (buttons, cards, inputs, etc.)
+   - **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+   - **Inconsistent variations**: Multiple implementations of the same concept (3 different button styles)
+   - **Reusable patterns**: Layout patterns, composition patterns, interaction patterns worth systematizing
+
+3. **Assess value**: Not everything should be extracted. Consider:
+   - Is this used 3+ times, or likely to be reused?
+   - Would systematizing this improve consistency?
+   - Is this a general pattern or context-specific?
+   - What's the maintenance cost vs benefit?
+
+## Plan Extraction
+
+Create a systematic extraction plan:
+
+- **Components to extract**: Which UI elements become reusable components?
+- **Tokens to create**: Which hard-coded values become design tokens?
+- **Variants to support**: What variations does each component need?
+- **Naming conventions**: Component names, token names, prop names that match existing patterns
+- **Migration path**: How to refactor existing uses to consume the new shared versions
+
+**IMPORTANT**: Design systems grow incrementally. Extract what's clearly reusable now, not everything that might someday be reusable.
+
+## Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: Create well-designed components with:
+  - Clear props API with sensible defaults
+  - Proper variants for different use cases
+  - Accessibility built in (ARIA, keyboard navigation, focus management)
+  - Documentation and usage examples
+  
+- **Design tokens**: Create tokens with:
+  - Clear naming (primitive vs semantic)
+  - Proper hierarchy and organization
+  - Documentation of when to use each token
+  
+- **Patterns**: Document patterns with:
+  - When to use this pattern
+  - Code examples
+  - Variations and combinations
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they're useless
+- Extract without considering existing design system conventions
+- Skip proper TypeScript types or prop documentation
+- Create tokens for every single value (tokens should have semantic meaning)
+
+## Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you've extracted
+- **Replace systematically**: Update each use to consume the shared version
+- **Test thoroughly**: Ensure visual and functional parity
+- **Delete dead code**: Remove the old implementations
+
+## Document
+
+Update design system documentation:
+
+- Add new components to the component library
+- Document token usage and values
+- Add examples and guidelines
+- Update any Storybook or component catalog
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
+

package/core/plugins/kenaz/skills/feature_agent/SKILL.md

@@ -0,0 +1,303 @@
+---
+name: Feature Agent
+description: 功能開發、Git Branch 隔離、Scope 限制、跨 Agent 通訊、持續迭代
+---
+
+# Feature Agent (功能開發 Agent)
+
+## 角色
+你是一個**功能開發 Agent**，在獨立的 Git Branch 中執行具體的開發任務。你專注於實現單一、具體的功能模組，並嚴格遵守 Scope 限制，不修改超出範圍的檔案。
+
+## 核心原則
+
+### 1. Scope 隔離
+- **只能修改** `scope.paths` 和 `scope.files` 定義的路徑
+- 需要其他模組時，**在 todo.md 留言**而非自己修改
+- 違反 Scope 的修改會被自動拒絕
+
+### 2. Branch 隔離
+- 每個任務在獨立的 Branch 工作
+- Branch 命名格式：`task-{id}-{slug}`
+- 完成後提交有意義的 Commit Message
+
+### 3. 接口遵守
+- 嚴格遵守 `docs/api_spec.md` 的接口定義
+- 如需新增或修改接口，先更新規格文件
+
+### 4. File 預算與 SRP（ARCH-001）
+- 單檔行數：warn=2000 / hard=4000。接近 warn 就停筆，優先 extraction 而非累加
+- 拆分模式：module / hooks/ / components/ / types.ts（依 CODE-STR-002）
+- verify 步驟跑 `node dev/scripts/check-file-size.js --staged`，有 BLOCK 先拆再提交
+
+## 任務
+1. **接收任務**：從 Orchestrator 接收任務分配
+2. **環境準備**：Checkout 到指定 Branch
+3. **Context 獲取**：使用 RAG 查詢相關代碼
+4. **功能實作**：按照規格實現功能
+5. **本地測試**：執行相關測試確保功能正確
+6. **提交變更**：Commit 並標記任務完成
+
+## 技能
+* **Git 操作**：Branch 管理、Commit、Merge 準備
+* **Scope 感知**：自動檢測是否違反 Scope 限制
+* **RAG 查詢**：使用語義檢索獲取相關代碼 Context
+* **跨 Agent 通訊**：透過 todo.md 與其他 Agent 協作
+* **測試執行**：運行單元測試和整合測試
+
+---
+
+## 工作流程
+
+### 1. 任務接收與環境準備
+
+```
+收到任務分配
+    │
+    ▼
+讀取任務詳情
+    │
+    ├─ task_id: 任務唯一識別
+    ├─ title: 任務標題
+    ├─ scope: 允許修改的路徑
+    └─ branch: 工作分支名稱
+    │
+    ▼
+Git Checkout Branch
+    │
+    ▼
+確認 Scope 路徑存在
+```
+
+**輸出範例**：
+```
+[Feature Agent] 任務已接收: TASK_022 - 實作用戶登入表單
+[Feature Agent] 工作分支: task-022-user-login-form
+[Feature Agent] Scope 路徑: src/components/auth/
+[Feature Agent] 正在切換分支...
+```
+
+### 2. Context 獲取 (RAG)
+
+```python
+# 使用 RAG 查詢相關代碼
+from cortex.api.search import SearchAPI
+
+search = SearchAPI()
+
+# 查詢與任務相關的代碼
+results = search.query(
+    query="用戶登入表單 認證",
+    top_k=5
+)
+
+# 查詢特定模組
+auth_code = search.get_file_chunks("src/components/auth/")
+```
+
+**注意事項**：
+- 優先查詢 Scope 內的代碼
+- 了解現有模式和命名規範
+- 識別可複用的組件或函數
+
+### 3. 功能實作
+
+**Scope 驗證**：
+```python
+# 在修改任何檔案前，驗證是否在 Scope 內
+def is_in_scope(file_path: str, scope: TaskScope) -> bool:
+    for allowed_path in scope.paths:
+        if file_path.startswith(allowed_path):
+            return True
+    return file_path in scope.files
+```
+
+**實作規範**：
+- 遵循專案現有的程式風格
+- 使用 TypeScript 強型別定義
+- 添加必要的錯誤處理
+- 編寫內聯註釋說明複雜邏輯
+
+**跨模組需求處理**：
+如果需要其他模組的支援（超出 Scope），**不要自行修改**，而是：
+
+```markdown
+<!-- todo.md -->
+## 待處理需求
+
+### TASK_022 (Feature Agent: frontend_001)
+- [ ] 需要 Backend Agent 提供 `/api/auth/login` 端點
+- [ ] 需要 SRE Agent 在資料庫新增 `user_sessions` 表
+```
+
+### 4. 本地測試
+
+```bash
+# 執行 Scope 內的測試
+npm test -- --testPathPattern="auth"
+
+# 或 Python
+pytest tests/auth/ -v
+```
+
+**測試檢查清單**：
+- [ ] 單元測試通過
+- [ ] 無 TypeScript/ESLint 錯誤
+- [ ] 功能可正常運作
+
+### 5. 提交變更
+
+**Commit Message 格式**：
+```
+feat(auth): 實作用戶登入表單
+
+- 新增 LoginForm 組件
+- 整合 useAuth hook
+- 添加表單驗證邏輯
+
+TASK_022
+```
+
+**提交前檢查**：
+- [ ] 只修改了 Scope 內的檔案
+- [ ] 測試全部通過
+- [ ] Commit Message 清晰明確
+
+### 6. 任務完成
+
+```python
+# 通知 Orchestrator 任務完成
+agent.signal_complete(
+    task_id="TASK_022",
+    status="completed",
+    commits=["abc1234"],
+    files_changed=["src/components/auth/LoginForm.tsx"]
+)
+```
+
+**完成狀態**：
+```
+[Feature Agent] TASK_022 已完成
+[Feature Agent] 分支: task-022-user-login-form
+[Feature Agent] Commits: 1
+[Feature Agent] 檔案變更: 3
+[Feature Agent] 等待 Merge 審核...
+```
+
+---
+
+## Agent 狀態
+
+| 狀態 | 說明 |
+|-----|------|
+| `idle` | 閒置，可接受新任務 |
+| `initializing` | 正在初始化（checkout branch） |
+| `working` | 執行任務中 |
+| `testing` | 正在執行測試 |
+| `blocked` | 等待其他 Agent 或外部依賴 |
+| `completed` | 任務完成，等待確認 |
+| `terminated` | 已終止 |
+
+---
+
+## 通訊機制
+
+### todo.md 格式
+
+Feature Agent 之間透過 `dev/pipeline/todo.md` 進行非同步通訊：
+
+```markdown
+# Agent 通訊板
+
+## 待處理需求
+
+### TASK_022 → Backend Agent
+**提出者**: frontend_001
+**時間**: 2026-01-29 10:30
+**需求**:
+- 需要 `/api/auth/login` POST 端點
+- 請求格式: `{ email: string, password: string }`
+- 回應格式: `{ token: string, user: User }`
+
+### TASK_023 → Frontend Agent
+**提出者**: backend_001
+**時間**: 2026-01-29 11:00
+**通知**:
+- `/api/auth/login` 已完成
+- 可使用 `src/api/auth.ts` 中的 `loginUser()` 函數
+```
+
+---
+
+## 錯誤處理
+
+### Scope 違規
+```
+[ERROR] Scope 違規: 嘗試修改 src/api/auth.py
+[ERROR] 此路徑不在任務 Scope 內: ["src/components/auth/"]
+[ACTION] 請在 todo.md 提出跨模組需求
+```
+
+### Branch 衝突
+```
+[ERROR] Branch 衝突: task-022-user-login-form
+[ERROR] 遠端分支已有變更
+[ACTION] 執行 git pull --rebase 並解決衝突
+```
+
+### 測試失敗
+```
+[ERROR] 測試失敗: 2 個測試未通過
+[ERROR] - LoginForm.test.tsx: 驗證邏輯錯誤
+[ERROR] - useAuth.test.tsx: Mock 設定不正確
+[ACTION] 修復測試後重新提交
+```
+
+---
+
+## 配置
+
+### Agent 配置 (ORCHESTRATOR_CONFIG.json)
+
+```json
+{
+    "feature_agents": {
+        "max_instances": 3,
+        "default_timeout_minutes": 120,
+        "auto_test": true,
+        "require_passing_tests": true
+    }
+}
+```
+
+### Scope 配置 (Task)
+
+```json
+{
+    "id": "TASK_022",
+    "title": "實作用戶登入表單",
+    "scope": {
+        "paths": ["src/components/auth/"],
+        "files": ["src/hooks/useAuth.ts"]
+    }
+}
+```
+
+---
+
+## 與其他 Agent 的協作
+
+### Architect Agent
+- 從 Architect Agent 接收任務拆解結果
+- 遵循 Architect 定義的接口規範
+
+### Backend/Frontend Agent
+- 透過 todo.md 交換需求
+- 接口定義在 `docs/api_spec.md`
+
+### QA Agent
+- 功能完成後，QA Agent 進行驗證
+- 接收 Bug 報告並修復
+
+### SRE Agent
+- 資料庫變更需求透過 todo.md 提出
+- 環境配置問題向 SRE Agent 回報

package/core/plugins/kenaz/skills/frontend-design/SKILL.md

@@ -0,0 +1,127 @@
+---
+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 that avoids generic AI aesthetics.
+license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
+---
+
+This skill guides 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.
+
+## Design Direction
+
+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. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic 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 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
+
+### Typography
+→ *Consult [typography reference](reference/typography.md) for scales, pairing, and loading strategies.*
+
+Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.
+
+**DO**: Use a modular type scale with fluid sizing (clamp)
+**DO**: Vary font weights and sizes to create clear visual hierarchy
+**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults
+**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes
+**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated
+
+### Color & Theme
+→ *Consult [color reference](reference/color-and-contrast.md) for OKLCH, palettes, and dark mode.*
+
+Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
+
+**DO**: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes
+**DO**: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion
+**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead
+**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature
+**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds
+**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful
+**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions
+
+### Layout & Space
+→ *Consult [spatial reference](reference/spatial-design.md) for grids, rhythm, and container queries.*
+
+Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.
+
+**DO**: Create visual rhythm through varied spacing—tight groupings, generous separations
+**DO**: Use fluid spacing with clamp() that breathes on larger screens
+**DO**: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis
+**DON'T**: Wrap everything in cards—not everything needs a container
+**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy
+**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly
+**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent
+**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed
+**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous
+
+### Visual Details
+**DO**: Use intentional, purposeful decorative elements that reinforce brand
+**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully
+**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional
+**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful
+**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output
+**DON'T**: Use modals unless there's truly no better alternative—modals are lazy
+
+### Motion
+→ *Consult [motion reference](reference/motion-design.md) for timing, easing, and reduced motion.*
+
+Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.
+
+**DO**: Use motion to convey state changes—entrances, exits, feedback
+**DO**: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration
+**DO**: For height animations, use grid-template-rows transitions instead of animating height directly
+**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only
+**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly
+
+### Interaction
+→ *Consult [interaction reference](reference/interaction-design.md) for forms, focus, and loading patterns.*
+
+Make interactions feel fast. Use optimistic UI—update immediately, sync later.
+
+**DO**: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions)
+**DO**: Design empty states that teach the interface, not just say "nothing here"
+**DO**: Make every interactive surface feel intentional and responsive
+**DON'T**: Repeat the same information—redundant headers, intros that restate the heading
+**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters
+
+### Responsive
+→ *Consult [responsive reference](reference/responsive-design.md) for mobile-first, fluid design, and container queries.*
+
+**DO**: Use container queries (@container) for component-level responsiveness
+**DO**: Adapt the interface for different contexts—don't just shrink it
+**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it
+
+### UX Writing
+→ *Consult [ux-writing reference](reference/ux-writing.md) for labels, errors, and empty states.*
+
+**DO**: Make every word earn its place
+**DON'T**: Repeat information users can already see
+
+---
+
+## The AI Slop Test
+
+**Critical quality check**: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.
+
+A distinctive interface should make someone ask "how was this made?" not "which AI made this?"
+
+Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.
+
+---
+
+## Implementation Principles
+
+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.
+
+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 across generations.
+
+Remember: Claude 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.