better-layout

能傳達結構的版面配置

使用者還沒讀到任何文字前，版面配置就已經在傳達訊息：位置、間距與對齊方式本身就帶有視覺層級，而適度的留白遠比繁複的裝飾更有傚。優秀的版面配置能經受各種極端狀況（stress）的考驗：無論是縮放尺寸、多語系翻譯、還是鏡射為 RTL（由右至左），結構都依然穩固。在建立或審查 UI 程式碼時請套用這些原則，並一律使用專案現有的樣式系統（如 Tailwind、原生 CSS、CSS-in-JS）來表達修改；切勿引入第二套樣式方案。

點擊區域（hit-area）大小與焦點行為由 better-accessibility Skill 負責；視覺修飾（圓角、陰影、動畫）由 better-ui Skill 負責；行寬與文字間距則由 better-typography Skill 負責。

若介面尚未建立明確的密度或間距系統，請將以下數值作為起步基準。在通過點擊區域、畫面縮放、在地化與視埠（viewport）壓力測試的前提下，應保留刻意設計的平台原生元件（chrome）、緊湊型專業工具及專案既有的 Token 數值。

快速參考

類別	適用時機
Grouping & Alignment	留白 vs 分隔線、對齊邊界、邏輯屬性（logical properties）、重要性排序
Spacing & Adaptivity	目標間距、版面邊距（layout margins）、漸進式揭露、全版/滿版內容（full-bleed）、斷點、多語系（i18n）文字膨脹

核心原則

1. 用留白分組，而非線條

負空間（留白）是首選的分組工具；背景形狀次之；分隔線則是最後手段，僅用於單靠留白無法明確區隔結構之處。組與組之間的間距必須至少是組內間距的 2 倍（例如組內為 8px → 組間應為 16px 以上），否則分組效果會顯得雜亂無章。

2. 讓控制項與內容有所區隔

互動元素必須看起來具備互動性：例如擁有背景形狀、邊框或一致的擺放區域。切勿將控制項的樣式設計得與相鄰的靜態文字完全相同。

3. 對齊共享邊界

確立對齊邊界並貫徹使用；任何游離、未對齊的邊界都會產生視覺噪音。每一個層級遞進應使用一個專案定義的間距階梯（以 16px 為實用的預設值）。涉及方向性的配置請使用邏輯屬性（如 padding-inline-start、margin-inline-end）；實體左右方向（left/right）僅保留給不受語系方向影響的物理幾何形狀。

4. 按重要性排序

最重要的內容應放置在靠近頂部與前緣（leading edge）的位置；閱讀順序由上至下、由前緣至後緣（leading-to-trailing）。請以「前緣/後緣」的思維來設計，而非單純的「左/右」。

5. 對隱藏內容給予視覺提示

漸進式揭露（progressive disclosure）需要明確的視覺預示（affordance）。請使用專案既有的提示樣式；若無既有規範，可讓下一個項目超出滾動邊界露出 16–32px，或提供展開/收合控制項。毫無提示就被隱藏的內容，與不存在無異。

6. 目標之間保留呼吸空間

若尚未建立密度系統，相鄰且帶有邊框或填充背景的控制項之間建議預設留出 12px 間距，無邊框的純文字或圖示控制項四周則保留 24px 的邊界空間。在滿足 better-accessibility 點擊區域不重疊且控制項依然保持視覺可辨識前提下，緊湊型版面可適度縮減此間距。

7. 按鈕應自畫面邊緣縮進

在內容型版面中，全寬按鈕應保持在版面邊距（layout margins）之內（行動端建議行內縮進約 16px）並具備可見的圓角。只有在刻意遵循平台或應用程式原生 Chrome 規範、考量安全區域（safe area）且能與系統 UI 明確區分時，才允許使用無邊距滿版（edge-to-edge）按鈕。

8. 內容滿版延伸，控制項浮動置頂

背景與媒體素材可延伸至視埠邊緣（滿版）；控制項與文字則必須保持在版面邊距與安全區域（env(safe-area-inset-*)）內。黏性（sticky）元件應浮動於內容層之上，而不是擋住或截斷內容流。

9. 保持結構直到無法容納再破版

斷點（breakpoints）應由內容決定，而非裝置預設值。只要內容還能合理容納，就盡量保持展開狀態的配置，延後收合；元件層級的自適應優先使用容器查詢（container queries）。測試時請優先驗證最小與最大視埠尺寸。

10. 為文字膨脹與截斷預留彈性

應預先考慮不同語言字串可能帶來的顯著膨脹，而非依賴固定的百分比：切勿在文字容器上設定固定寬高，並允許自動折行。絕不要將關鍵操作放在調整尺寸或滾動時容易被截斷的位置；應確保其在正常文件流或適當的固定 UI 區域（chrome）中始終可被觸及。

常見錯誤

錯誤習慣	修正方式
在可用留白區隔處使用分隔線	移除分隔線，將組間間距加倍
在需要支援多語系在地化的版面上使用 margin-left / padding-right	改用 margin-inline-start / padding-inline-end
內容版面中的按鈕不小心貼滿視埠邊緣	內縮至專案設定的邊距內；僅保留刻意設計的原生 Chrome 規範
輪播/滾動視窗看起來像已顯示完畢	讓下一個項目超出邊緣露出 16–32px
相鄰控制項融合在一起或擴大的點擊區域重疊	使用專案間距規範加大間距；可將 12px/24px 作為起步參考值
僅因預設值就將斷點設在 768 / 1024	應在內容實際無法容納的位置設定斷點
針對單一語言設計固定寬度的文字容器	使用 max-width 並允許自動折行；透過偽在地化（pseudo-localization）與代表性語系進行測試
將主要操作放在面板底部容易被截斷的位置	使用黏性定位（sticky）或帶有安全區域邊距的固定 Chrome

審查輸出格式

僅在使用者要求進行單獨的版面配置審查時使用此格式。當由 better-interface 統籌審查時，請將該領域的證據與發現提供給該 Skill，並以其輸出格式、嚴重程度分級、整合規則、數量上限與最終裁決為準。

單獨審查報告請分為兩個部分呈現。

發現事項 (Findings)

按原則將所有已確認的發現事項進行分組。使用包含 Severity（嚴重程度）、Location（位置）、Before（修改前）、After（修改後）與 Why（原因）欄位的 Markdown 表格。切勿使用獨立的 "Before:" / "After:" 文字行。

• Severity：HIGH 會在支援的視埠尺寸下阻礙內容顯示或操作；MEDIUM 會損害視覺層級、閱讀順序或自適應能力；LOW 屬於單點的對齊或間距優化。
• Location：引用 path/to/file:line。若成品無原始碼檔案，請改為引用明確的畫面與元件名稱。
• Before / After：展示目前的版面配置與具體可執行的替換方案。
• Why：指出違反的原則及其對可讀性或自適應能力的影響。

將重複發生的系統性問題整合為單一列，並列出所有受影響的位置。無發現事項的原則請予以省略。

範例

用留白分組，而非線條

Severity	Location	Before	After	Why
LOW	src/Settings.tsx:41	每一個設定列皆帶有 border-b	移除邊框；組內改用 space-y-2，組間改用 space-y-8	留白能傳達分組關係，且視覺雜訊更少
LOW	src/ProfileForm.tsx:58	表單區段之間使用 <hr>	改為在每個區段標題加上 mt-10	區段層級不應依賴重複的分隔線

對齊共享邊界

Severity	Location	Before	After	Why
LOW	src/Card.tsx:24	卡片文字設為 pl-4，卡片圖示設為 pl-3	將兩者皆對齊至相同的 pl-4 邊界	共享邊界能建立清晰易讀的結構
MEDIUM	src/Nav.css:19	margin-left: 16px	margin-inline-start: 16px	物理屬性會破壞具備方向感知（RTL/LTR）的版面

驗證與裁決 (Verification and Verdict)

在發現事項之後：

1. Verification：列出在相關視埠寬度、閱讀順序、畫面縮放及 RTL 狀態下執行的確切檢查項目與觀察結果。若有未執行的檢查，請註明仍需驗證的項目。
2. Verdict：若仍存在任何 HIGH 級別發現則為 Block；若僅剩 MEDIUM 或 LOW 發現則為 Needs changes；僅在無任何需處理的發現時才為 Approve。

若無任何發現事項，請省略表格，註明「無需要處理的版面配置發現事項（No actionable layout findings）」，回報驗證結果，並以 Approve 結尾。