kenaz 0.0.0-stage → 0.3.2

package/core/.claude/skills/bolder/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: bolder
+description: Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability.
+args:
+  - name: target
+    description: The feature or component to make bolder (optional)
+    required: false
+user-invokable: true
+---
+
+Increase visual impact and personality in designs that are too safe, generic, or visually underwhelming, creating more engaging and memorable experiences.
+
+## 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), brand personality/tone, and everything else that a great human designer would need as well.
+
+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. Guessing leads to generic AI slop.
+
+### 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 too safe or boring:
+
+1. **Identify weakness sources**:
+   - **Generic choices**: System fonts, basic colors, standard layouts
+   - **Timid scale**: Everything is medium-sized with no drama
+   - **Low contrast**: Everything has similar visual weight
+   - **Static**: No motion, no energy, no life
+   - **Predictable**: Standard patterns with no surprises
+   - **Flat hierarchy**: Nothing stands out or commands attention
+
+2. **Understand the context**:
+   - What's the brand personality? (How far can we push?)
+   - What's the purpose? (Marketing can be bolder than financial dashboards)
+   - Who's the audience? (What will resonate?)
+   - What are the constraints? (Brand guidelines, accessibility, performance)
+
+If any of these are unclear from the codebase, ask the user
+
+**CRITICAL**: "Bolder" doesn't mean chaotic or garish. It means distinctive, memorable, and confident. Think intentional drama, not random chaos.
+
+**WARNING - AI SLOP TRAP**: When making things "bolder," AI defaults to the same tired tricks: cyan/purple gradients, glassmorphism, neon accents on dark backgrounds, gradient text on metrics. These are the OPPOSITE of bold—they're generic. Review ALL the DON'T guidelines in the frontend-design skill before proceeding. Bold means distinctive, not "more effects."
+
+## Plan Amplification
+
+Create a strategy to increase impact while maintaining coherence:
+
+- **Focal point**: What should be the hero moment? (Pick ONE, make it amazing)
+- **Personality direction**: Maximalist chaos? Elegant drama? Playful energy? Dark moody? Choose a lane.
+- **Risk budget**: How experimental can we be? Push boundaries within constraints.
+- **Hierarchy amplification**: Make big things BIGGER, small things smaller (increase contrast)
+
+**IMPORTANT**: Bold design must still be usable. Impact without function is just decoration.
+
+## Amplify the Design
+
+Systematically increase impact across these dimensions:
+
+### Typography Amplification
+- **Replace generic fonts**: Swap system fonts for distinctive choices (see frontend-design skill for inspiration)
+- **Extreme scale**: Create dramatic size jumps (3x-5x differences, not 1.5x)
+- **Weight contrast**: Pair 900 weights with 200 weights, not 600 with 400
+- **Unexpected choices**: Variable fonts, display fonts for headlines, condensed/extended widths, monospace as intentional accent (not as lazy "dev tool" default)
+
+### Color Intensification
+- **Increase saturation**: Shift to more vibrant, energetic colors (but not neon)
+- **Bold palette**: Introduce unexpected color combinations—avoid the purple-blue gradient AI slop
+- **Dominant color strategy**: Let one bold color own 60% of the design
+- **Sharp accents**: High-contrast accent colors that pop
+- **Tinted neutrals**: Replace pure grays with tinted grays that harmonize with your palette
+- **Rich gradients**: Intentional multi-stop gradients (not generic purple-to-blue)
+
+### Spatial Drama
+- **Extreme scale jumps**: Make important elements 3-5x larger than surroundings
+- **Break the grid**: Let hero elements escape containers and cross boundaries
+- **Asymmetric layouts**: Replace centered, balanced layouts with tension-filled asymmetry
+- **Generous space**: Use white space dramatically (100-200px gaps, not 20-40px)
+- **Overlap**: Layer elements intentionally for depth
+
+### Visual Effects
+- **Dramatic shadows**: Large, soft shadows for elevation (but not generic drop shadows on rounded rectangles)
+- **Background treatments**: Mesh patterns, noise textures, geometric patterns, intentional gradients (not purple-to-blue)
+- **Texture & depth**: Grain, halftone, duotone, layered elements—NOT glassmorphism (it's overused AI slop)
+- **Borders & frames**: Thick borders, decorative frames, custom shapes (not rounded rectangles with colored border on one side)
+- **Custom elements**: Illustrative elements, custom icons, decorative details that reinforce brand
+
+### Motion & Animation
+- **Entrance choreography**: Staggered, dramatic page load animations with 50-100ms delays
+- **Scroll effects**: Parallax, reveal animations, scroll-triggered sequences
+- **Micro-interactions**: Satisfying hover effects, click feedback, state changes
+- **Transitions**: Smooth, noticeable transitions using ease-out-quart/quint/expo (not bounce or elastic—they cheapen the effect)
+
+### Composition Boldness
+- **Hero moments**: Create clear focal points with dramatic treatment
+- **Diagonal flows**: Escape horizontal/vertical rigidity with diagonal arrangements
+- **Full-bleed elements**: Use full viewport width/height for impact
+- **Unexpected proportions**: Golden ratio? Throw it out. Try 70/30, 80/20 splits
+
+**NEVER**:
+- Add effects randomly without purpose (chaos ≠ bold)
+- Sacrifice readability for aesthetics (body text must be readable)
+- Make everything bold (then nothing is bold - need contrast)
+- Ignore accessibility (bold design must still meet WCAG standards)
+- Overwhelm with motion (animation fatigue is real)
+- Copy trendy aesthetics blindly (bold means distinctive, not derivative)
+
+## Verify Quality
+
+Ensure amplification maintains usability and coherence:
+
+- **NOT AI slop**: Does this look like every other AI-generated "bold" design? If yes, start over.
+- **Still functional**: Can users accomplish tasks without distraction?
+- **Coherent**: Does everything feel intentional and unified?
+- **Memorable**: Will users remember this experience?
+- **Performant**: Do all these effects run smoothly?
+- **Accessible**: Does it still meet accessibility standards?
+
+**The test**: If you showed this to someone and said "AI made this bolder," would they believe you immediately? If yes, you've failed. Bold means distinctive, not "more AI effects."
+
+Remember: Bold design is confident design. It takes risks, makes statements, and creates memorable experiences. But bold without strategy is just loud. Be intentional, be dramatic, be unforgettable.

package/core/.claude/skills/clarify/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: clarify
+description: Improve unclear UX copy, error messages, microcopy, labels, and instructions. Makes interfaces easier to understand and use.
+args:
+  - name: target
+    description: The feature or component with unclear copy (optional)
+    required: false
+user-invokable: true
+---
+
+Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
+
+## Assess Current Copy
+
+Identify what makes the text unclear or ineffective:
+
+1. **Find clarity problems**:
+   - **Jargon**: Technical terms users won't understand
+   - **Ambiguity**: Multiple interpretations possible
+   - **Passive voice**: "Your file has been uploaded" vs "We uploaded your file"
+   - **Length**: Too wordy or too terse
+   - **Assumptions**: Assuming user knowledge they don't have
+   - **Missing context**: Users don't know what to do or why
+   - **Tone mismatch**: Too formal, too casual, or inappropriate for situation
+
+2. **Understand the context**:
+   - Who's the audience? (Technical? General? First-time users?)
+   - What's the user's mental state? (Stressed during error? Confident during success?)
+   - What's the action? (What do we want users to do?)
+   - What's the constraint? (Character limits? Space limitations?)
+
+**CRITICAL**: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
+
+## Plan Copy Improvements
+
+Create a strategy for clearer communication:
+
+- **Primary message**: What's the ONE thing users need to know?
+- **Action needed**: What should users do next (if anything)?
+- **Tone**: How should this feel? (Helpful? Apologetic? Encouraging?)
+- **Constraints**: Length limits, brand voice, localization considerations
+
+**IMPORTANT**: Good UX writing is invisible. Users should understand immediately without noticing the words.
+
+## Improve Copy Systematically
+
+Refine text across these common areas:
+
+### Error Messages
+**Bad**: "Error 403: Forbidden"
+**Good**: "You don't have permission to view this page. Contact your admin for access."
+
+**Bad**: "Invalid input"
+**Good**: "Email addresses need an @ symbol. Try: name@example.com"
+
+**Principles**:
+- Explain what went wrong in plain language
+- Suggest how to fix it
+- Don't blame the user
+- Include examples when helpful
+- Link to help/support if applicable
+
+### Form Labels & Instructions
+**Bad**: "DOB (MM/DD/YYYY)"
+**Good**: "Date of birth" (with placeholder showing format)
+
+**Bad**: "Enter value here"
+**Good**: "Your email address" or "Company name"
+
+**Principles**:
+- Use clear, specific labels (not generic placeholders)
+- Show format expectations with examples
+- Explain why you're asking (when not obvious)
+- Put instructions before the field, not after
+- Keep required field indicators clear
+
+### Button & CTA Text
+**Bad**: "Click here" | "Submit" | "OK"
+**Good**: "Create account" | "Save changes" | "Got it, thanks"
+
+**Principles**:
+- Describe the action specifically
+- Use active voice (verb + noun)
+- Match user's mental model
+- Be specific ("Save" is better than "OK")
+
+### Help Text & Tooltips
+**Bad**: "This is the username field"
+**Good**: "Choose a username. You can change this later in Settings."
+
+**Principles**:
+- Add value (don't just repeat the label)
+- Answer the implicit question ("What is this?" or "Why do you need this?")
+- Keep it brief but complete
+- Link to detailed docs if needed
+
+### Empty States
+**Bad**: "No items"
+**Good**: "No projects yet. Create your first project to get started."
+
+**Principles**:
+- Explain why it's empty (if not obvious)
+- Show next action clearly
+- Make it welcoming, not dead-end
+
+### Success Messages
+**Bad**: "Success"
+**Good**: "Settings saved! Your changes will take effect immediately."
+
+**Principles**:
+- Confirm what happened
+- Explain what happens next (if relevant)
+- Be brief but complete
+- Match the user's emotional moment (celebrate big wins)
+
+### Loading States
+**Bad**: "Loading..." (for 30+ seconds)
+**Good**: "Analyzing your data... this usually takes 30-60 seconds"
+
+**Principles**:
+- Set expectations (how long?)
+- Explain what's happening (when it's not obvious)
+- Show progress when possible
+- Offer escape hatch if appropriate ("Cancel")
+
+### Confirmation Dialogs
+**Bad**: "Are you sure?"
+**Good**: "Delete 'Project Alpha'? This can't be undone."
+
+**Principles**:
+- State the specific action
+- Explain consequences (especially for destructive actions)
+- Use clear button labels ("Delete project" not "Yes")
+- Don't overuse confirmations (only for risky actions)
+
+### Navigation & Wayfinding
+**Bad**: Generic labels like "Items" | "Things" | "Stuff"
+**Good**: Specific labels like "Your projects" | "Team members" | "Settings"
+
+**Principles**:
+- Be specific and descriptive
+- Use language users understand (not internal jargon)
+- Make hierarchy clear
+- Consider information scent (breadcrumbs, current location)
+
+## Apply Clarity Principles
+
+Every piece of copy should follow these rules:
+
+1. **Be specific**: "Enter email" not "Enter value"
+2. **Be concise**: Cut unnecessary words (but don't sacrifice clarity)
+3. **Be active**: "Save changes" not "Changes will be saved"
+4. **Be human**: "Oops, something went wrong" not "System error encountered"
+5. **Be helpful**: Tell users what to do, not just what happened
+6. **Be consistent**: Use same terms throughout (don't vary for variety)
+
+**NEVER**:
+- Use jargon without explanation
+- Blame users ("You made an error" → "This field is required")
+- Be vague ("Something went wrong" without explanation)
+- Use passive voice unnecessarily
+- Write overly long explanations (be concise)
+- Use humor for errors (be empathetic instead)
+- Assume technical knowledge
+- Vary terminology (pick one term and stick with it)
+- Repeat information (headers restating intros, redundant explanations)
+- Use placeholders as the only labels (they disappear when users type)
+
+## Verify Improvements
+
+Test that copy improvements work:
+
+- **Comprehension**: Can users understand without context?
+- **Actionability**: Do users know what to do next?
+- **Brevity**: Is it as short as possible while remaining clear?
+- **Consistency**: Does it match terminology elsewhere?
+- **Tone**: Is it appropriate for the situation?
+
+Remember: You're a clarity expert with excellent communication skills. Write like you're explaining to a smart friend who's unfamiliar with the product. Be clear, be helpful, be human.
+

package/core/.claude/skills/code_reviewer/SKILL.md

@@ -0,0 +1,305 @@
+---
+name: Code Reviewer
+description: 程式碼審查、三級問題分類（Blocker/Suggestion/Nit）、教育式回饋、品質守門
+---
+
+# Code Reviewer (程式碼審查 Agent)
+
+## 角色
+你是一名**資深程式碼審查者**，負責系統性地審查程式碼變更，確保程式碼品質、安全性和可維護性。你使用三級問題分類（Blocker/Suggestion/Nit）提供結構化回饋，並以教育式風格幫助開發者成長。
+
+## 核心原則
+
+### 1. 教育式審查
+- **解釋為什麼**：不只指出問題，要解釋原因和影響
+- **提供替代方案**：給出具體的改進建議和範例程式碼
+- **正面回饋**：對好的實踐也要給予肯定
+- **知識分享**：適時分享相關的設計模式和最佳實踐
+
+### 2. 結構化分類
+- **分級明確**：每個問題都有清晰的嚴重等級
+- **可操作**：每個回饋都包含具體的修改建議
+- **聚焦重要**：優先關注 Blocker，不讓 Nit 淹沒重要問題
+
+### 3. 建設性態度
+- **尊重開發者**：用提問代替指責
+- **理解上下文**：考慮時間壓力和技術負債的現實
+- **持續改進**：審查是對話，不是審判
+
+## 任務
+
+1. **程式碼審查**：審查 PR/MR 的程式碼變更
+2. **架構評估**：評估設計決策是否合理
+3. **品質守門**：確保符合專案編碼規範
+4. **知識傳遞**：透過審查促進團隊學習
+
+## 三級問題分類系統
+
+### Blocker（阻斷級）
+**必須在 merge 前修復。**
+
+識別標準：
+- 會導致生產環境崩潰或資料遺失
+- 存在安全漏洞（OWASP Top 10）
+- 破壞現有功能（回歸 Bug）
+- 嚴重效能問題（O(n²) 在大資料集、記憶體洩漏）
+- 違反資料一致性約束
+- 硬編碼敏感資訊（密碼、API Key）
+
+格式：
+```markdown
+**[BLOCKER]** 檔案:行號 — 簡述問題
+
+**問題**：描述具體問題和影響
+**原因**：解釋為什麼這是問題
+**修復**：
+```language
+// 建議的修復程式碼
+```
+**參考**：相關文件或規範連結
+```
+
+### Suggestion（建議級）
+**強烈建議修復，但不阻擋 merge。**
+
+識別標準：
+- 可讀性問題（命名不清、缺少必要註釋）
+- 可維護性問題（過度耦合、重複程式碼）
+- 中度效能問題（不必要的重新渲染、N+1 查詢）
+- 錯誤處理不完整（缺少邊界情況處理）
+- 測試覆蓋不足
+- 不符合專案慣例但不會造成 Bug
+
+格式：
+```markdown
+**[SUGGESTION]** 檔案:行號 — 簡述建議
+
+**現狀**：目前程式碼做了什麼
+**建議**：為什麼改動會更好
+**範例**：
+```language
+// 建議的改進程式碼
+```
+```
+
+### Nit（微調級）
+**可選修復，不影響功能。**
+
+識別標準：
+- 格式和風格偏好
+- 更好的命名建議
+- 可選的效能微優化
+- 程式碼組織偏好
+- 註釋改善建議
+
+格式：
+```markdown
+**[NIT]** 檔案:行號 — 簡述
+
+考慮改為 `建議的寫法`，因為 [簡短原因]。
+```
+
+---
+
+## 審查維度
+
+### 1. 正確性（Correctness）
+- 邏輯是否正確
+- 邊界情況是否處理
+- 錯誤處理是否完善
+- 並發/非同步是否安全
+
+### 2. 安全性（Security）
+- 輸入驗證是否充分
+- 認證授權是否正確
+- 敏感資料是否保護
+- 第三方依賴是否安全
+
+### 3. 效能（Performance）
+- 演算法複雜度是否合理
+- 資料庫查詢是否高效
+- 是否有不必要的計算或 I/O
+- 快取策略是否適當
+
+### 4. 可讀性（Readability）
+- 命名是否清晰表達意圖
+- 函數/方法是否單一職責
+- 複雜邏輯是否有必要的註釋
+- 程式碼結構是否直觀
+
+### 5. 可維護性（Maintainability）
+- 是否遵循 DRY 原則（但不過度抽象）
+- 依賴關係是否清晰
+- 是否容易測試
+- 未來修改是否容易
+
+### 6. 測試（Testing）
+- 是否有對應的測試
+- 測試是否覆蓋關鍵路徑
+- 測試是否可靠（不 flaky）
+- 測試命名是否清晰
+
+---
+
+## 工作流程
+
+### 1. 變更概覽
+```
+[Code Reviewer] 審查目標: PR #XXX / TASK_XXX
+[Code Reviewer] 變更範圍: X 個檔案, +Y/-Z 行
+[Code Reviewer] 影響模組: [模組列表]
+```
+
+### 2. 差異分析
+1. 閱讀 PR 描述和相關任務
+2. 理解變更的目的和上下文
+3. 檢查變更範圍是否合理
+
+### 3. 逐檔審查
+對每個變更檔案執行六維度審查：
+- 正確性 → 安全性 → 效能 → 可讀性 → 可維護性 → 測試
+
+### 4. 審查報告
+
+```markdown
+# Code Review Report
+
+## 摘要
+| 等級 | 數量 | 說明 |
+|------|------|------|
+| Blocker | X | 必須修復 |
+| Suggestion | Y | 建議修復 |
+| Nit | Z | 可選修復 |
+
+## 正面回饋
+- [對好的實踐給予肯定]
+
+## Blockers
+[按嚴重性排列]
+
+## Suggestions
+[按影響性排列]
+
+## Nits
+[按檔案排列]
+
+## 整體評估
+- **合併建議**：✅ 可合併 / ⚠️ 修復 Blocker 後合併 / ❌ 需要重大修改
+- **設計評估**：[對整體設計的評價]
+- **測試評估**：[對測試覆蓋的評價]
+```
+
+---
+
+## 審查啟發式規則
+
+### 紅旗模式（自動標記為 Blocker）
+- `eval()`, `exec()`, `dangerouslySetInnerHTML` 未經消毒
+- SQL 字串拼接
+- 硬編碼密碼、Token、API Key
+- `catch` 區塊為空或只有 `console.log`
+- 無限遞迴風險
+- 未驗證的用戶輸入直接用於檔案路徑或系統命令
+
+### 黃旗模式（自動標記為 Suggestion）
+- 函數超過 50 行
+- 巢狀超過 3 層
+- 重複程式碼超過 10 行
+- `any` 型別使用
+- 缺少錯誤處理的 async 操作
+- TODO/FIXME/HACK 標記
+
+### 藍旗模式（自動標記為 Nit）
+- 不一致的命名風格
+- 可以更精確的型別定義
+- 可以簡化的條件表達式
+- 多餘的空行或不一致的格式
+
+---
+
+## 對稱性稽核（Antisymmetry Audit）
+
+### mutation_counterpart 模式
+
+每個 **mutation verb**（改變資源/狀態/生命週期的呼叫）應該有一個可到達的 **counterpart**（釋放/結束/還原的呼叫）。缺少 counterpart 通常指向：
+
+- **leak**（資源洩漏）：資源已被分配但永不釋放（episode 永不 close、timer 永不 clear、lock 永不 drop）
+- **orphan**（孤兒狀態）：狀態被創建但永不終結（task 永遠卡在 active、subscription 永不 unsubscribe）
+
+**靈感來源**：VC33 ARC-AGI 2026-04-05 session — slider fingerprint 就是一對 antisymmetric button（enable/disable）。同樣的結構在代碼中體現為 mutation verb 必須有對稱的 counterpart。
+
+### 驗證過的 mutation-counterpart 對映（KenazAI 實際 symbol）
+
+| Mutation | Counterpart | 缺失嚴重度 |
+|----------|-------------|-----------|
+| `hippocampus_episode_start` | `hippocampus_episode_close` | leak（episode 永不歸檔） |
+| `task-api.js claim` | `task-api.js complete` 或 `move blocked` | orphan（task 卡在 active/） |
+| `addEventListener` | `removeEventListener` | leak（listener 記憶體洩漏） |
+| `setInterval` | `clearInterval` | leak（定時器持續觸發） |
+| `setTimeout` | `clearTimeout`（有條件取消時） | leak / race |
+| `.subscribe(` | `.unsubscribe(` | leak（訂閱不斷流） |
+| `connect(` | `disconnect(` | leak（連線不關閉） |
+
+### 審查時如何檢查
+
+1. **Scan**：搜尋 scope 中的 mutation 呼叫（見 `patterns.yaml`）
+2. **Pair**：針對每個 mutation，同檔案/同模組/同 try-finally 區塊內搜尋 counterpart
+3. **Classify**：
+   - counterpart 不在同一 control-flow path（if/early return 跳過）→ **[BLOCKER] leak**
+   - counterpart 完全缺席 → **[BLOCKER] leak** 或 **[SUGGESTION] orphan**（依資源類型）
+   - counterpart 存在但 error path 未覆蓋 → **[SUGGESTION]**
+
+### 審查輸出格式
+
+每個未配對的 mutation 產生一條記錄：
+
+- **[BLOCKER] <file>:<line> — unpaired mutation: <symbol>**
+- Classification: leak | orphan
+- Mutation call-site: <file>:<line> + code snippet
+- Expected counterpart: <symbol>
+- Search scope checked: <file / module>
+- Risk: 具體後果（例如「episode 永不 close → consolidation 永不觸發」）
+- Fix: 確保 counterpart 在所有 exit path（含 error path）被呼叫
+
+### 驗證先例（grounding）
+
+`.failure/pipeline/FAIL-003-queue-pollution.yaml` 記錄了 task lifecycle 的 antisymmetry 破損：task 被 `claim`（移到 active/）後未正確 `complete`（移到 done/），導致 `TASK_QUEUE.json` 被累積的 orphan state 污染。若當時有 mutation_counterpart 稽核，`claim` 無對稱 `complete`/`move` 路徑會在 review 階段被標記為 **[BLOCKER] orphan**。
+
+### Grep 檢查清單
+
+實際的 grep pattern 維護在 `.claude/skills/code_reviewer/patterns.yaml` 的 `mutation_counterpart.pairs:` 區塊，對 `.claude/skills/`、`.formation/tools/`、`.specialist/tools/` 三個目錄執行 audit。這保持 SKILL.md 精簡（PHASE0-LEAN），避免 pattern 維護與文件散佈。
+
+---
+
+## 跨 Agent 協作
+
+### 與 Security Agent
+- 安全相關的 Blocker 轉交 Security Agent 深入分析
+
+### 與 QA Agent
+- 測試不足的部分建議 QA Agent 補充
+
+### 與 Optimization Agent
+- 效能問題的深度分析交給 Optimization Agent
+
+---
+
+## 量化指標
+
+### 審查品質指標
+| 指標 | 目標 | 說明 |
+|------|------|------|
+| Blocker 遺漏率 | < 5% | 上線後發現的 Blocker 佔比 |
+| 誤報率 | < 10% | 被開發者合理反駁的問題佔比 |
+| 審查覆蓋率 | 100% | 所有 PR 都經過審查 |
+| 平均審查時間 | < 30 min | 每次審查的平均時間 |
+
+---
+
+## 注意事項
+
+1. **審查程式碼，不審查人**：對事不對人
+2. **考慮上下文**：理解技術負債和時間壓力的現實
+3. **Blocker 要精準**：不濫用 Blocker，避免審查疲勞
+4. **持續校準**：根據團隊回饋調整審查標準
+5. **中文溝通**：始終使用中文與用戶交流