@pheem49/mint 1.9.0 → 1.10.0

package/temp_gridgeist/README.th.md

@@ -0,0 +1,325 @@
+<p align="center">
+  <img src="skills/gridgeist/assets/gridgeist.svg" alt="Gridgeist — Agent Skill สำหรับกำหนดทิศทาง Web Interface" width="240" />
+</p>
+
+# Gridgeist — คู่มือภาษาไทย
+
+[English](README.md) · **ภาษาไทย** · [เว็บไซต์](https://ohmiler.github.io/gridgeist/th/) · [ตัวอย่าง](https://ohmiler.github.io/gridgeist/examples/)
+
+Gridgeist คือ Agent Skill สำหรับสร้าง ปรับดีไซน์ และรีวิวหน้าเว็บที่มีระบบเฉพาะกับผลิตภัณฑ์ โดยปรับ Structure, Typography, Imagery, Interaction และหลักฐานจากผลิตภัณฑ์ให้เข้ากับแบรนด์ ใช้ Grid เป็นตรรกะที่มองเห็นได้ เบาบาง หรือซ่อนอยู่เบื้องหลัง ช่วยลดหน้าตาแบบ Generic AI SaaS โดยยังรักษาแบรนด์ ฟังก์ชัน Responsive behavior และ Accessibility
+
+## เห็นความต่างได้ทันที
+
+ตัวอย่าง Northline Logistics นี้สร้างจากหน้า HTML/CSS แบบเต็มสองเวอร์ชัน โดยใช้ผลิตภัณฑ์ เนื้อหา ข้อมูลปฏิบัติการตัวอย่าง และขนาดหน้าจอชุดเดียวกัน หน้าและภาพ After ถูกสร้างใหม่ด้วย Workflow แบบเป็นระบบของ **Gridgeist v1.2.0** โดย Northline และข้อมูลทั้งหมดเป็นเรื่องสมมติ
+
+<table>
+  <tr>
+    <th width='50%'>ไม่ใช้ Gridgeist - Generic SaaS</th>
+    <th width='50%'>ใช้ Gridgeist v1.2.0 - ระบบที่สะท้อนผลิตภัณฑ์</th>
+  </tr>
+  <tr>
+    <td><img src='docs/assets/northline-before.png' alt='หน้าเว็บ Northline Logistics แบบ Generic ที่ใช้ข้อความการตลาด กราฟ และการ์ดตัวเลขซึ่งพบได้ทั่วไป' width='100%' /></td>
+    <td><img src='docs/assets/northline-after.png' alt='ตัวอย่าง Northline ที่ใช้ Gridgeist v1.2.0 เป็นระบบปฏิบัติการเดียวกัน โดยมี topology ของเครือข่าย สถานะเที่ยวขนส่งเชิงความหมาย เวลาถึง และ priority exception' width='100%' /></td>
+  </tr>
+</table>
+
+เนื้อหาและข้อมูลปฏิบัติการตัวอย่างเหมือนเดิม แต่ใช้ระบบการออกแบบต่างกัน Gridgeist ทำให้ topology, ตารางเส้นทาง, exception, action และ metrics เชื่อมเป็นพื้นผิวปฏิบัติการเดียวที่สร้างจากหลักฐานของผลิตภัณฑ์ พร้อมระบุชัดว่าเป็น concept ภาพทั้งสองใน README เป็นภาพที่ capture จากหน้าเว็บจริง [เปิดหน้า Before](https://ohmiler.github.io/gridgeist/readme-showcase/?view=before) หรือ [เปิดหน้า After ของ v1.2.0](https://ohmiler.github.io/gridgeist/readme-showcase/?view=after&rev=ab77ceb6)
+
+## v1.2.0 เปลี่ยนอะไรบ้าง
+
+Gridgeist มองการตัดสินใจด้านภาพเป็นระบบเดียว ไม่ใช่ชุดการตกแต่งที่แยกจากกันทีละส่วน
+
+| ด้าน | พฤติกรรมใน v1.2.0 |
+| --- | --- |
+| System contract | กำหนดสี Typography, Layout, Spacing, Shape, Components, States, Media และ Motion เป็นทิศทางย่อชุดเดียวก่อนลงมือ |
+| Semantic roles | เชื่อม Foundation tokens ไปยัง Semantic roles และการตัดสินใจระดับ Component ทำให้ Contrast และความสัมพันธ์ของสถานะมีเจตนาชัดเจน |
+| Component grammar | กำหนด Anatomy, Variants, Density, States และกติกาเมื่อเนื้อหายาวให้ Component ที่เกี่ยวข้อง แทนการแต่งแต่ละจุดแยกกัน |
+| Direction safety | เมื่อแนวคิดภาพยังกว้าง จะเสนอทิศทางที่ต่างกันอย่างชัดเจนและรอให้เลือกก่อนกำหนด Tokens หรือแก้ Interface |
+| Skill coordination | ระบุผู้รับผิดชอบทิศทางเพียงหนึ่งตัวเมื่อใช้หลาย UI Skills เพื่อไม่ให้เกิดระบบภาพที่แข่งขันกัน |
+| Verification | ตรวจหลายความกว้าง, Overflow, Focus, Interaction states, Themes และ Reduced motion พร้อมจำกัดคำกล่าวอ้างตามหลักฐานที่สังเกตได้ |
+
+ผลลัพธ์คือ Interface ที่เป็นเนื้อเดียวกันมากขึ้น ดู Generic น้อยลง และต่อยอดได้ง่ายโดยไม่ทำให้เอกลักษณ์ผลิตภัณฑ์หายไป การทดสอบ v1.2.0 ครอบคลุม System-contract scenarios ภาษาอังกฤษ 3 รอบและภาษาไทย 3 รอบ, การตรวจ Responsive ด้วย Browser แบบอิสระ และ Guardrail tests ที่ซ่อมแล้ว
+
+## เริ่มใช้ใน 60 วินาที
+
+1. ติดตั้ง Gridgeist ผ่านช่องทางหลักของ Agent ที่ใช้งาน
+
+   สำหรับ Codex ให้เพิ่ม Git Marketplace แล้วติดตั้ง Plugin:
+
+   ```powershell
+   codex plugin marketplace add ohmiler/gridgeist
+   codex plugin add gridgeist@gridgeist
+   ```
+
+   สำหรับ Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenCode และ Agent อื่นที่รองรับ ให้ใช้ตัวติดตั้งแบบ Universal:
+
+   ```powershell
+   npx skills add ohmiler/gridgeist -g
+   ```
+
+   **วิธีสำรอง:** หากใช้ตัวติดตั้งทั้งสองแบบไม่ได้ ให้ไปที่ [ติดตั้งด้วยตนเอง](#ติดตั้งด้วยตนเอง)
+2. เปิด Agent session ใหม่ในโปรเจกต์เว็บของคุณ แล้ววาง Prompt นี้:
+
+   ```text
+   ใช้ Skill Gridgeist รีวิว Interface นี้โดยยังไม่ต้องแก้โค้ด
+   สรุปคำตัดสินหนึ่งบรรทัด ตามด้วยปัญหาที่เรียงตามความสำคัญพร้อมหลักฐาน
+   และเสนอทิศทาง Redesign ที่สอดคล้องกันหนึ่งทิศทาง โดยรักษาฟังก์ชันและแบรนด์เดิม
+   ```
+
+Agent ที่รองรับการเรียก Skill แบบตรงตัวสามารถใช้ `$gridgeist` ใน Prompt ได้ ดูรายละเอียดเฉพาะผลิตภัณฑ์และตัวอย่างเพิ่มเติมที่ [การติดตั้ง](#การติดตั้ง)
+
+## เหมาะกับงานแบบไหน
+
+- Landing page, Dashboard, Documentation, Portfolio และ Learning platform
+- ปรับดีไซน์หน้าเว็บเดิมโดยไม่ทำให้ฟังก์ชันหรือแบรนด์เสีย
+- รีวิว Draft และจัดลำดับปัญหาด้าน Hierarchy, Composition, Responsive และ Accessibility
+- งานที่ต้องการทิศทางแบบ Technical, Editorial, Image-led, Playful, Utilitarian หรือ Visible grid โดยไม่ทำให้เอกลักษณ์แบรนด์หายไป
+
+## การติดตั้ง
+
+### Codex Plugin
+
+Repository นี้เตรียมเป็น Codex Plugin ผ่าน [`.codex-plugin/plugin.json`](.codex-plugin/plugin.json) โดย Plugin ชี้ไปยังโฟลเดอร์ `skills/gridgeist/` ชุดเดียวกับช่องทางอื่น ทำให้ทุกวิธีติดตั้งใช้แหล่งข้อมูลเดียวกัน
+
+เพิ่ม Gridgeist Marketplace แล้วติดตั้ง Plugin ด้วยคำสั่ง:
+
+```powershell
+codex plugin marketplace add ohmiler/gridgeist
+codex plugin add gridgeist@gridgeist
+```
+
+หลังติดตั้งให้เปิด Codex session ใหม่ เพื่อให้ระบบตรวจพบ Skill ที่อยู่ใน Plugin
+
+### ตัวติดตั้งแบบ Universal
+
+สำหรับ Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenCode และ Agent อื่นที่รองรับ ใช้ [open agent skills CLI](https://github.com/vercel-labs/skills) ติดตั้ง Gridgeist ได้ด้วยคำสั่งเดียว:
+
+```powershell
+npx skills add ohmiler/gridgeist -g
+```
+
+ตัวติดตั้งจะค้นพบ `skills/gridgeist/` และให้เลือก Agent เป้าหมาย หากต้องการระบุ Agent โดยตรง ให้ส่งชื่อ Agent เช่น:
+
+```powershell
+npx skills add ohmiler/gridgeist -g -a claude-code
+```
+
+### ติดตั้งด้วยตนเอง
+
+ใช้การคัดลอกด้วยตนเองเมื่อไม่สามารถใช้ Plugin หรือตัวติดตั้งแบบ Universal ได้:
+
+```powershell
+git clone https://github.com/ohmiler/gridgeist.git
+Copy-Item -Recurse .\gridgeist\skills\gridgeist "$HOME\.agents\skills\gridgeist"
+```
+
+สำหรับ Agent อื่น ให้คัดลอก `skills/gridgeist/` ไปยัง Skills directory ของผลิตภัณฑ์นั้น Agent ต้องรองรับมาตรฐาน Agent Skills `SKILL.md` และการตรวจพบหรือวิธีเรียกใช้อาจแตกต่างกัน หลังคัดลอกแล้วให้เปิด Agent session ใหม่
+
+## การอัปเดต
+
+Gridgeist จะไม่อัปเดตแบบเงียบในเบื้องหลัง ให้ใช้คำสั่งตามช่องทางที่ติดตั้ง แล้วเริ่ม Agent session ใหม่
+
+### Codex Plugin
+
+ดึง Git-backed marketplace snapshot ล่าสุด แล้วติดตั้ง Plugin version ที่ Release นั้นประกาศอีกครั้ง:
+
+```powershell
+codex plugin marketplace upgrade gridgeist
+codex plugin add gridgeist@gridgeist
+```
+
+ตรวจเวอร์ชันที่ติดตั้งด้วย `codex plugin list` หาก Session ปัจจุบันยังใช้คำสั่งเดิม ให้เปิด Thread ใหม่หรือ Restart Codex app
+
+### Universal installer
+
+อัปเดต Gridgeist ที่ติดตั้งระดับผู้ใช้:
+
+```powershell
+npx skills update gridgeist -g -y
+```
+
+หากติดตั้งระดับโปรเจกต์ ให้ใช้ `npx skills update gridgeist -p -y`
+
+### Git clone หรือคัดลอกเอง
+
+รัน `git pull --ff-only` ใน Repository ที่ Clone ไว้ แล้วติดตั้งจาก `skills/gridgeist/` อีกครั้ง การคัดลอกเองไม่มีข้อมูล Source หรือ Version จึงต้องแทนที่โฟลเดอร์ Skill ทั้งชุดจาก Release tag แนะนำให้ใช้ Codex Plugin หรือ Universal installer หากต้องการอัปเดตในอนาคต
+
+## วิธีเรียกใช้
+
+เรียกใช้โดยตรงด้วย `$gridgeist` แล้วระบุ 4 อย่าง:
+
+1. ผลิตภัณฑ์และกลุ่มผู้ใช้
+2. งานที่ต้องการ: สร้างใหม่ ปรับดีไซน์ หรือรีวิว
+3. สิ่งที่ต้องรักษา เช่น ฟังก์ชัน สีแบรนด์ หรือเนื้อหา
+4. สิ่งที่ต้องตรวจ เช่น Desktop, Mobile, Keyboard และ Accessibility
+
+### Create — สร้างหน้าใหม่
+
+```text
+ใช้ $gridgeist ออกแบบ Landing Page สำหรับแพลตฟอร์มเรียน SQL
+ให้บทเรียน Query editor และผลลัพธ์เป็นส่วนสำคัญของงานภาพ
+หลีกเลี่ยงการ์ด SaaS แบบทั่วไป และตรวจทั้ง Desktop กับ Mobile
+```
+
+### Redesign — ปรับดีไซน์เดิม
+
+```text
+ใช้ $gridgeist ปรับดีไซน์ Dashboard นี้ใหม่
+รักษาฟังก์ชัน เส้นทาง เนื้อหา และสีแบรนด์เดิมทั้งหมด
+จัดลำดับข้อมูลตามความสำคัญ และอย่าแก้เพียงแค่ลดความโค้งของการ์ด
+```
+
+### Review — รีวิวโดยยังไม่แก้โค้ด
+
+```text
+รีวิวหน้าเว็บนี้ด้วย $gridgeist โดยยังไม่ต้องแก้โค้ด
+สรุปคำตัดสินหนึ่งบรรทัด ตามด้วยปัญหาที่เรียงตามความสำคัญ
+หลักฐาน และทิศทางใหม่ที่สอดคล้องกัน
+```
+
+### บรีฟอย่างไรให้ผลลัพธ์ตรงใจ
+
+หากต้องการผลลัพธ์ที่แม่นขึ้น ให้ระบุรายละเอียดเหล่านี้เท่าที่เกี่ยวข้อง:
+
+- **ผลิตภัณฑ์และผู้ใช้** — เว็บทำอะไรและใครเป็นคนใช้
+- **Primary task** — สิ่งสำคัญที่สุดที่ผู้ใช้ต้องทำให้สำเร็จ
+- **ทิศทางภาพ** — บุคลิกที่ต้องการ เช่น Warm editorial, Precise technical หรือ
+  Playful tactile
+- **ของจริงจากผลิตภัณฑ์** — Product UI, ข้อมูล, เนื้อหา, ภาพ, Artwork, Code หรือ
+  Workflow ที่ควรเป็นพระเอก
+- **สิ่งที่ต้องรักษา** — แบรนด์ เนื้อหา Route พฤติกรรม Component ความเป็นส่วนตัว
+  หรือข้อจำกัดของ Platform
+- **สิ่งที่ไม่ต้องการ** — ภาษาภาพหรือพฤติกรรมที่ไม่เหมาะกับผลิตภัณฑ์
+- **Flow และสถานะ** — Default, Loading, Empty, Error, Success, Disabled และ
+  Destructive ที่สำคัญ
+- **การตรวจผล** — Viewport, Keyboard, Touch, Focus, Overflow, Reduced motion และ
+  Primary flow ที่ต้องทดสอบ
+
+หากทิศทางชัดแล้ว ให้บอกทิศทางนั้นและให้ Gridgeist ทำต่อโดยไม่ต้องถามรสนิยมซ้ำ
+หากยังมีหลายทิศทางที่เป็นไปได้จริง ให้สั่ง Gridgeist ตรวจของเดิมก่อน เสนอ 2–3
+ทิศทางพร้อมข้อแลกเปลี่ยนและคำแนะนำ แล้วรอให้เลือกก่อนแก้โค้ด
+
+คัดลอก Template นี้ไปปรับใช้ได้เลย:
+
+```text
+ใช้ $gridgeist เพื่อ [สร้างใหม่ / ปรับดีไซน์ / รีวิว] [หน้าเว็บหรือผลิตภัณฑ์]
+
+ผลิตภัณฑ์และผู้ใช้:
+[เว็บทำอะไรและใครเป็นคนใช้]
+
+Primary task:
+[ผลลัพธ์สำคัญที่สุดที่ผู้ใช้ต้องทำให้สำเร็จ]
+
+ทิศทางภาพ:
+[ทิศทางที่ยืนยันแล้ว หรือ: ตรวจของเดิมก่อน เสนอ 2–3 ทิศทางพร้อมข้อแลกเปลี่ยน
+และคำแนะนำ และยังไม่ต้องแก้โค้ดจนกว่าผมจะเลือก]
+
+สิ่งที่ควรเป็นพระเอก:
+[Product UI / ข้อมูล / เนื้อหา / ภาพ / Artwork / Code / Workflow]
+
+ต้องรักษา:
+[แบรนด์ เนื้อหา Route พฤติกรรม Component และข้อจำกัด]
+
+ไม่ต้องการ:
+[ภาษาภาพหรือพฤติกรรมที่ไม่เหมาะ]
+
+Flow และสถานะสำคัญ:
+[Primary flow และ Default/Loading/Empty/Error/Success/Disabled ที่เกี่ยวข้อง]
+
+ให้ตรวจ:
+[Viewport, Keyboard, Touch, Focus, Overflow, Reduced motion และ Primary flow]
+
+ตรวจ Repository และหน้าเว็บที่ Render จริงก่อนเริ่มทำงาน
+```
+
+ควรบอกผลลัพธ์และข้อจำกัดที่มีเหตุผล แทนการสั่ง CSS ทีละค่า หากไม่ได้เป็นข้อกำหนด
+ของแบรนด์ ให้ Gridgeist กำหนดขนาดตัวอักษร Spacing, Radius, Shadow และจำนวนคอลัมน์
+เป็นระบบเดียวกันจากผลิตภัณฑ์และทิศทางที่เลือก
+
+หากโปรเจกต์มี `DESIGN.md`, Theme, Token set หรือ Component library อยู่แล้ว
+Gridgeist จะตรวจสิ่งเหล่านี้ร่วมกับ Implementation และ Interface ที่ Render จริง
+แทนการสมมติว่าทุกแหล่งสอดคล้องกัน `DESIGN.md` เป็นช่องทางเชื่อมต่อแบบเลือกใช้
+ไม่ใช่ Dependency โดย Gridgeist ไม่ควรสร้างหรือแก้ไฟล์นี้ เว้นแต่คุณขอ
+Design-system artifact ที่นำไปใช้ต่อได้ หรือระบุให้งานรวมเอกสารระบบที่ต้องเก็บถาวร
+อย่างชัดเจน
+
+## ใช้ร่วมกับ Skill อื่น
+
+Gridgeist ทำงานได้ดีที่สุดเมื่อเป็นผู้กำหนดทิศทางผลิตภัณฑ์และงานภาพเพียง Skill เดียว ส่วน Skill อื่นควรเข้ามาเสริมเฉพาะการส่ง Context การตรวจเชิงเทคนิค หรือการยืนยันผลจากหน้าเว็บที่ Render แล้ว สำหรับโปรเจกต์ส่วนใหญ่ แนะนำ workflow ที่เบาที่สุดดังนี้:
+
+```text
+Gridgeist -> Playwright
+```
+
+Gridgeist กำหนด Interface thesis, ลำดับชั้น, ระบบภาพ และทิศทางการ Implement จากนั้น Playwright ตรวจผลที่ Render จริงในขนาดหน้าจอและ Interaction ที่สำคัญ รวมถึงทำ [Visual comparison](https://playwright.dev/docs/test-snapshots) แบบทำซ้ำได้
+
+| ลักษณะงาน | Workflow ที่แนะนำ | การแบ่งหน้าที่ |
+| --- | --- | --- |
+| โปรเจกต์เว็บทั่วไป | `Gridgeist -> Playwright` | ออกแบบและ Implement แล้วตรวจผลที่ Render จริง |
+| ใช้ Figma เป็น Source of truth | `Figma -> Gridgeist -> Playwright` | ดึง Component, Variable และ Layout context; ปรับให้เข้ากับผลิตภัณฑ์และ Codebase; แล้วตรวจผล ดูรายละเอียดที่ [Figma MCP server](https://developers.figma.com/docs/figma-mcp-server/) |
+| React หรือ Next.js | `Gridgeist -> Vercel React Best Practices -> Playwright` | กำหนดทิศทาง Interface; ตรวจ Performance ตาม Framework; แล้วยืนยัน Behavior ดู [Vercel Agent Skills](https://github.com/vercel-labs/agent-skills) |
+| ตรวจคุณภาพก่อน Release | `Gridgeist -> Web Quality Audit -> Playwright` | ตรวจลำดับชั้นและความเข้ากับแบรนด์; Audit ด้าน Accessibility, Performance, SEO และ Web quality; แล้วยืนยันหน้าเว็บจริง ดู [Web Quality Skills](https://github.com/addyosmani/web-quality-skills) |
+| ต้องสร้างภาพต้นฉบับใหม่ | `Gridgeist -> สร้างภาพ -> Gridgeist -> Playwright` | กำหนด Thesis ก่อนสร้าง Asset; นำภาพที่เลือกมาจัดองค์ประกอบ; แล้วตรวจ Interface |
+
+ทั้งหมดนี้เป็น workflow เสริม ไม่ใช่ Dependency ให้เพิ่มเฉพาะ Skill ที่ตอบโจทย์จริง และไม่ควรใช้ Frontend-design หรือ Art-direction skill แบบกว้างอีกตัวในช่วงออกแบบเดียวกัน เพราะทิศทางภาพที่แข่งขันกันอาจทำให้ผลลัพธ์ไม่เป็นระบบ ชื่อและความพร้อมใช้งานของ Skill เสริมอาจต่างกันในแต่ละ Agent
+
+ตัวอย่าง:
+
+```text
+ใช้ $gridgeist ปรับดีไซน์ Interface นี้โดยรักษาพฤติกรรมและแบรนด์เดิม
+หลัง Implement ให้ใช้ Playwright ตรวจ Desktop และ Mobile viewport ที่สำคัญ
+การใช้งานด้วย Keyboard, Overflow และ Primary user flow
+```
+
+## ทำอย่างไรให้ผลลัพธ์ดีขึ้น
+
+- ให้ Agent ดู Repository และหน้าเว็บที่ Render แล้ว ไม่ใช่แค่คำอธิบาย
+- ระบุพฤติกรรมที่ห้ามเปลี่ยนเมื่อทำ Redesign
+- ใช้เนื้อหา ข้อมูล โค้ด หรือ Workflow ของผลิตภัณฑ์จริง
+- ให้ตรวจหลาย Viewport และสถานะ Interaction
+- บอกแบรนด์ที่ต้องรักษา เพื่อไม่ให้ Swiss aesthetic กลายเป็น Preset
+
+## กรณีศึกษา
+
+[Tracefield](https://ohmiler.github.io/tracefield/) คือ Developer Observability Dashboard ที่ใช้ Gridgeist กับโปรเจกต์จริง โดย [Repository](https://github.com/ohmiler/tracefield) เก็บ Baseline, Prompt ที่ใช้, Rubric ประเมินผล, ชุดทดสอบ และ Final interface ไว้ให้ตรวจสอบได้
+
+[Ledgerline](https://ohmiler.github.io/ledgerline/) ทดสอบ Skill เดียวกันกับเว็บไซต์เอกสาร Payment API ที่มีเนื้อหาหนาแน่น โดย [Repository](https://github.com/ohmiler/ledgerline) เก็บ Baseline, Prompt แบบตรงตัว, Rubric 6 ด้าน, เนื้อหา API ที่กำหนดตายตัว, การตรวจ 4 ขนาดหน้าจอ และ Final interface ไว้ครบ
+
+[Morrow](https://ohmiler.github.io/morrow-portfolio/) ทดสอบการปรับตัวตามแบรนด์ด้วย Creative Portfolio แบบ Image-led ที่เป็น Fictional โดย [Repository](https://github.com/ohmiler/morrow-portfolio) เก็บภาพ AI-generated ชุดเดียวกัน, Baseline, Prompt แบบตรงตัว, Rubric 6 ด้าน, การตรวจ 4 ขนาดหน้าจอ และ Final interface ที่ตั้งใจไม่ใช้ภาษาภาพแบบ Technical ของกรณีศึกษาก่อนหน้า
+
+[Doodlewood](https://ohmiler.github.io/doodlewood/) ทดสอบ Playful interaction design ด้วยสตูดิโอวาดรูปสำหรับเด็กแบบ Fictional ที่รักษาความเป็นส่วนตัว โดย [Repository](https://github.com/ohmiler/doodlewood) เก็บ Baseline, Prompt แบบตรงตัว, Rubric 6 ด้าน, Drawing engine ที่ทำงานในเครื่อง, การตรวจ 4 ขนาดหน้าจอ และข้อจำกัดด้านความปลอดภัยของเด็กกับหลักฐานจากผู้ใช้จริงไว้อย่างชัดเจน
+
+กรณีศึกษาที่ทีมสร้างเองทั้ง 4 ตัวจึงครอบคลุมพื้นผิวแบบ Data-heavy, Content-heavy, Image-led และ Playful interactive แล้ว ขั้นต่อไปควรเน้นการตรวจจากผู้ใช้ Agent และโปรเจกต์ภายนอก มากกว่าการเพิ่มหมวดภาพที่ทีมสร้างเองอีก
+
+## ข้อจำกัด
+
+- Gridgeist ให้ทิศทางและกระบวนการ แต่คุณภาพยังขึ้นกับ Context ที่ Agent ได้รับ
+- Automated checks ไม่สามารถแทนการตรวจหน้าเว็บจริงได้
+- ค่าเริ่มต้นด้าน Grid, Type และสีเป็นเพียงจุดเริ่มต้น ไม่ใช่กฎตายตัว
+- ผลลัพธ์จากโมเดลไม่แน่นอน ควรทดสอบซ้ำเมื่อเปลี่ยน Agent หรือแก้ Skill
+
+## การทดสอบ
+
+ชุด Prompt และเกณฑ์ประเมินภาษาไทยอยู่ที่ [`evals/prompts.th.md`](evals/prompts.th.md) ส่วนชุดภาษาอังกฤษอยู่ที่ [`evals/prompts.md`](evals/prompts.md)
+
+ตรวจโครงสร้าง Skill ที่ติดตั้งได้ โดยบังคับ Python ให้อ่าน UTF-8:
+
+```powershell
+python -X utf8 "$HOME\.codex\skills\.system\skill-creator\scripts\quick_validate.py" .\skills\gridgeist
+```
+
+ตรวจ Release metadata และเอกสารสองภาษาโดยไม่ต้องใช้ Dependency ภายนอก:
+
+```powershell
+python -X utf8 .\scripts\validate_release.py
+```
+
+ทดสอบ Clean install และ Update ผ่าน Codex Marketplace กับตัวติดตั้งแบบ Universal จริง คำสั่งนี้ต้องใช้ Codex, Node.js, npm, Git และ Network โดยจะใช้ Home ชั่วคราวและไม่แก้การติดตั้งเดิมของคุณ:
+
+```powershell
+python -X utf8 .\scripts\smoke_test_install.py
+```
+
+## License
+
+[MIT](LICENSE)

package/temp_gridgeist/skills/gridgeist/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: gridgeist
+description: Use when creating, redesigning, or reviewing web interfaces that need product-specific structure, clear hierarchy, responsive composition, accessible interaction, or relief from generic AI-generated SaaS aesthetics. Adapt grid, typography, imagery, motion, and product evidence to the established brand—including technical, editorial, image-led, warm, playful, and utilitarian directions—across React, Next.js, Tailwind CSS, HTML/CSS, landing pages, dashboards, documentation, portfolios, and interactive tools.
+---
+
+# Gridgeist
+
+## Overview
+
+Craft distinctive, product-native interfaces from audience, content, behavior, and brand intent. Use grid as structural logic; make it visible only when it serves the product.
+
+## Select a mode
+
+| Intent and authorization | Mode | Start with |
+|---|---|---|
+| Build an interface without an existing design | Create | Audience, primary task, content, and evidence |
+| Change an existing interface with permission to edit | Redesign | Preserved behavior, brand signals, and state inventory |
+| Diagnose without changing files | Review | Prioritized findings grounded in rendered evidence |
+
+Let user authorization determine whether files change. Permission to redesign does not authorize choosing among materially different visual theses. Derive direction from explicit user intent or established brand evidence; audience, task, product category, and content may inform hierarchy but do not alone confirm a visual thesis. Use the alignment gate below whenever thesis-level ambiguity remains.
+
+## Workflow
+
+1. **Inspect** — Understand the audience, primary tasks, brand signals, content, product evidence, routes, components, tokens, and rendered desktop/mobile UI. Inspect existing design-system sources, including `DESIGN.md` when present, and reconcile them with the implementation and rendered evidence rather than assuming they agree. Inventory important interaction states and constraints. Do not invent customers, metrics, outcomes, research, or compliance.
+   - **Align direction before editing** — Classify the direction as **user-confirmed**, **brand-derived**, or **provisional**. Treat a coherent user direction as confirmed even when it leaves implementation choices open; variations within the same thesis are not material ambiguity. Classify a direction as brand-derived only when existing visual implementation, assets, documented rules, or repeated brand conventions converge on one thesis; product subject matter or copy alone is not enough. When a broad Create or Redesign still supports materially different theses that would change core brand expression, hierarchy, imagery, color, or motion, offer two or three evidence-grounded directions with trade-offs and a recommendation, then ask the user to choose or authorize the recommendation. While the direction is provisional, do not define the replacement system or edit implementation files. Proceed without redundant questions when intent or coherent brand evidence is clear. Do not block Review or narrow repairs; label an unconfirmed Review replacement direction provisional.
+   - **Hard stop for provisional broad work** — A provisional direction is not an implementable direction. End the turn after the options, trade-offs, recommendation, and alignment question. Do not set a thesis, read the system contract, create tokens, edit files, start implementation, or verify a redesign until the user selects a direction or explicitly authorizes the recommendation.
+2. **Set a thesis** — Write one governing sentence combining audience, primary task, structural logic, brand expression, and a product-native motif. Read [design-language.md](references/design-language.md) before choosing the direction, especially for image-led, warm, playful, or otherwise nontechnical brands.
+3. **Define the system** — Read [system-contract.md](references/system-contract.md) before making new or changed system decisions. Establish the relevant color, typography, layout, spacing, shape, surface, component, state, media, motion, and responsive rules as one compact contract. Decide whether the grid should be visible, quiet, or invisible. Reuse semantic tokens and existing primitives; keep narrow repairs proportional and do not create a persistent design artifact unless authorized.
+4. **Compose** — Build hierarchy before detail. Make one area dominant, align related content, vary sections within shared logic, and let the most authentic material—product UI, data, prose, imagery, artwork, code, or the primary tool—carry visual weight.
+5. **Implement** — Preserve required behavior and states. Follow repository conventions, semantic HTML, keyboard and touch behavior, and existing primitives. Recompose mobile layouts rather than shrinking desktop. Avoid dependencies for simple CSS effects.
+6. **Verify** — Use [review-checklist.md](references/review-checklist.md). Render representative widths and exercise primary flows, states, focus behavior, reduced motion, overflow, and dynamic content. Fix clarity and hierarchy before polish. Report what was observed separately from what remains inferred or untested.
+
+For interactive products, inventory at least default, loading, empty, error, success, disabled, and destructive states when applicable. Preserve privacy, safety, data, and platform constraints as product behavior, not optional polish.
+
+## Coordinate companions
+
+- Keep Gridgeist as the sole owner of product and visual direction. Do not automatically combine it with another broad frontend-design or art-direction skill. If the user explicitly requests both, establish one direction owner before editing instead of silently blending their defaults.
+- **Explicit overlap gate** — When the user requests Gridgeist plus another broad visual-design skill, state the overlap and recommend one direction owner before selecting a thesis or editing; use Gridgeist by default for product-native, brand-adaptive work. Do not silently ignore the requested companion or run both visual theses. After ownership is clear, use only non-conflicting implementation or verification help from the other skill unless the user chooses it as owner.
+- Use context capabilities during Inspect, asset generation after the thesis, technical audits after implementation, and browser automation during Verify.
+- Treat companions as optional. Do not block work or add dependencies when they are unavailable.
+
+## Anti-slop contract
+
+- Use one thesis and one coherent system.
+- Preserve or deliberately evolve the brand instead of importing a house aesthetic.
+- Build hierarchy through scale, position, density, rhythm, and contrast.
+- Give grid visibility, borders, radii, shadows, gradients, and motion defined roles.
+- Prefer authentic product evidence; label sample or fictional material and never fabricate proof.
+- Give sections or workflows distinct compositions within shared structural logic.
+
+Repeated rounded cards, centered hero copy, gradient blobs, excessive pills, uniform sections, arbitrary icon boxes, generic claims, and technical chrome on nontechnical brands are diagnostic signals, not automatic violations. Replace weak structure with a stronger product-specific idea.
+
+## Decision reference
+
+| Dimension | Decide from |
+|---|---|
+| Structure | Information order, task flow, shared alignments, and the brand's degree of regularity |
+| Type | Brand voice, reading needs, and role hierarchy; reserve mono for genuinely technical content |
+| Visual lead | Product UI, data, prose, imagery, artwork, code, or a primary interactive surface |
+| Shape and surface | Brand geometry, containment, adjacency, state, and interaction—not fashion |
+| Color | Existing brand palette and semantic roles; do not assume neutral plus one accent |
+| Components | Product tasks, shared anatomy, variants, density, state behavior, and repository conventions |
+| Motion | Causality, feedback, spatial change, and tone, with reduced-motion support |
+| Responsive | Priority, order, density, input method, and content behavior at each range |
+
+## Output contract
+
+For user-confirmed or brand-derived Create or Redesign, provide **Direction** with the thesis and preserved constraints, complete responsive **Implementation**, and **Verification** evidence naming observed viewports, flows, states, and remaining gaps. When system decisions materially change, identify the relevant contract or where its tokens and component rules are implemented. For provisional broad Create or Redesign, output only the alignment options, trade-offs, recommendation, and question; do not include **Implementation** or redesign **Verification** claims. For Review, make no edits and provide a one-line **Verdict**, prioritized findings with location, evidence, impact, and the smallest coherent correction, plus one replacement **Direction**. Never claim verification without observation.
+
+## Common mistakes
+
+| Mistake | Correction |
+|---|---|
+| Treating Gridgeist as a visible-grid preset | Use grid as underlying logic and expose it only when the brand benefits |
+| Copying a reference literally | Extract principles and preserve the user's identity and content |
+| Styling before understanding behavior | Inventory tasks, constraints, and states before composing |
+| Making minimalism empty | Add useful evidence and controlled density |
+| Styling components one at a time | Define shared anatomy, tokens, variants, and states before polishing instances |
+| Improving the default state only | Design loading, empty, error, success, disabled, and destructive paths |
+| Stacking desktop UI on mobile | Redesign order, density, navigation, media, and interaction |
+| Reporting subjective taste alone | Tie findings to comprehension, usability, consistency, brand, or accessibility |
+| Reporting automated checks as user evidence | Separate technical verification from usability, safety, and research claims |
+
+## Contrasting examples
+
+> Redesign dense API documentation with a visible information grid, precise code states, and verified mobile navigation.
+
+> Redesign a warm image-led portfolio with an invisible alignment system, expressive type, artwork-led pacing, and accessible project narratives.

package/temp_gridgeist/skills/gridgeist/agents/openai.yaml

@@ -0,0 +1,9 @@
+interface:
+  display_name: "Gridgeist"
+  short_description: "Build product-native interfaces with clear structure"
+  icon_small: "./assets/gridgeist-small.svg"
+  icon_large: "./assets/gridgeist.png"
+  brand_color: "#1547FF"
+  default_prompt: "Use $gridgeist to design or refine this interface around its product, brand, and behavior, then verify responsive and accessible results."
+policy:
+  allow_implicit_invocation: true

package/temp_gridgeist/skills/gridgeist/assets/gridgeist-small.svg

@@ -0,0 +1,10 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="128" height="128" viewBox="0 0 128 128" role="img" aria-labelledby="title desc">
+  <title id="title">Gridgeist</title>
+  <desc id="desc">GG monogram on a cobalt grid.</desc>
+  <rect width="128" height="128" fill="#F2F0E9"/>
+  <path d="M32 0V128M64 0V128M96 0V128M0 32H128M0 64H128M0 96H128" stroke="#11120F" stroke-opacity="0.18"/>
+  <path d="M96 0V128M0 96H128" stroke="#1547FF" stroke-width="3"/>
+  <text x="10" y="82" fill="#11120F" font-family="Inter, Arial, Helvetica, sans-serif" font-size="61" font-weight="900" letter-spacing="-7">G</text>
+  <text x="58" y="82" fill="#1547FF" font-family="Inter, Arial, Helvetica, sans-serif" font-size="61" font-weight="900" letter-spacing="-7">G</text>
+  <circle cx="96" cy="96" r="4" fill="#1547FF"/>
+</svg>

package/temp_gridgeist/skills/gridgeist/assets/gridgeist.svg

@@ -0,0 +1,18 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1024" height="1024" viewBox="0 0 1024 1024" role="img" aria-labelledby="title desc">
+  <title id="title">Gridgeist</title>
+  <desc id="desc">Gridgeist typographic mark on a precise cobalt grid.</desc>
+  <defs><pattern id="grid" width="128" height="128" patternUnits="userSpaceOnUse"><path d="M128 0H0V128" fill="none" stroke="#11120F" stroke-opacity="0.16" stroke-width="2"/></pattern></defs>
+  <rect width="1024" height="1024" fill="#F2F0E9"/>
+  <rect x="1" y="1" width="1022" height="1022" fill="url(#grid)" stroke="#11120F" stroke-width="2"/>
+  <path d="M768 0V1024M0 768H1024" stroke="#1547FF" stroke-width="8"/>
+  <g font-family="Inter, Arial, Helvetica, sans-serif" font-weight="900" letter-spacing="-20">
+    <text x="56" y="477" font-size="326" fill="#11120F">GRID</text>
+    <text x="56" y="754" font-size="290" fill="#1547FF">GEIST.</text>
+  </g>
+  <g font-family="Consolas, monospace" font-size="22" font-weight="500" letter-spacing="2" fill="#11120F">
+    <text x="56" y="72">AGENT SKILL / WEB INTERFACE DIRECTION</text>
+    <text x="56" y="962">GG-01</text>
+    <text x="836" y="962">OPEN SOURCE</text>
+  </g>
+  <circle cx="768" cy="768" r="13" fill="#1547FF"/>
+</svg>

package/temp_gridgeist/skills/gridgeist/references/design-language.md

@@ -0,0 +1,88 @@
+# Gridgeist Design Language
+
+Use this reference before selecting or explaining a visual direction. Build from the product and brand rather than collecting fashionable labels.
+
+## Direction model
+
+Choose one structural influence, one expressive influence, and one product-native motif.
+
+- **Structural influence** defines order: rational grid, editorial sequence, task flow, spatial canvas, or another coherent logic.
+- **Expressive influence** defines tone: precise, warm, restrained, playful, tactile, image-led, or another brand-supported quality.
+- **Product-native motif** makes the result specific: traces, lesson progress, artwork, route status, drawing tools, documents, or another authentic artifact.
+
+Write the thesis as: **audience + primary task + structural logic + brand expression + product-native motif**.
+
+Examples:
+
+- “An operational workspace for SREs built on aligned trace relationships, compressed hierarchy, and live latency states.”
+- “A human portfolio for creative collaborators paced by asymmetric artwork, warm editorial type, and candid project evidence.”
+- “A touch-first drawing studio for children organized around the canvas, friendly tool groups, and immediate local feedback.”
+
+## Product-surface adaptation
+
+| Surface | Let this lead | Structural treatment | Avoid |
+|---|---|---|---|
+| Data or technical product | Real data, state, relationships, commands, product UI | Explicit tracks, dense alignment, quiet rules, precise labels | Fake metrics, decorative code, interchangeable dashboard cards |
+| Content or documentation | Reading order, navigation, examples, metadata | Controlled measure, editorial pacing, persistent orientation | Squeezed columns, repetitive content boxes, ornamental complexity |
+| Image-led portfolio or brand | Artwork, crop, scale, caption, narrative | Invisible or quiet grid, purposeful asymmetry, varied pacing | Technical chrome, equal project cards, art used as thumbnails only |
+| Playful or canvas-based tool | Primary canvas, direct manipulation, touch controls, feedback | Task-centered zones, friendly grouping, flexible geometry | Importing a technical grid, shrinking the main tool, tiny controls |
+| Transactional form or workflow | Progress, input, validation, confirmation, recovery | Clear sequence, stable control placement, explicit state changes | Styling only the happy path, hidden errors, disruptive reflow |
+
+This table guides decisions; it is not a set of templates. A product may combine surfaces, but one should dominate each viewport or workflow stage.
+
+## Brand adaptation gate
+
+Before importing any visual influence:
+
+1. Inventory existing voice, typography, palette, imagery, geometry, motion, and recognizable assets.
+2. Mark each signal as **preserve**, **evolve**, or **replace**, with a product reason for any replacement.
+3. Decide whether structure should be **visible**, **quiet**, or **invisible**.
+4. Test recognizability: if borders, mono type, and technical labels disappear, does the direction still belong to this product?
+5. Reject the direction if it gains Gridgeist mannerisms while losing the established brand.
+
+When no brand exists, derive expression from audience, task, content, and product character rather than defaulting to technical minimalism.
+
+## System heuristics
+
+### Grid and composition
+
+- Use consistent outer relationships and gutters across the interface.
+- Align major edges when alignment improves reading or task flow.
+- Break regularity only to create deliberate emphasis, narrative pace, or direct manipulation space.
+- On small screens, replace wide structures with a simpler priority order; do not preserve decorative empty tracks.
+
+### Typography
+
+- Define roles for display, heading, body, label, metadata, and code only when needed.
+- Keep body measure readable, commonly around 45–75 characters.
+- Use weight, spacing, family, and contrast before inventing many sizes.
+- Use mono for commands, code, IDs, timestamps, or technical labels—not as automatic Gridgeist branding.
+
+### Imagery and product material
+
+- Give authentic material enough scale and context to carry hierarchy.
+- Define crop, aspect ratio, caption, loading, empty, and small-screen behavior.
+- Preserve meaningful artwork and brand assets; mark decorative imagery appropriately.
+- Label sample or fictional content and avoid implying real customers, outcomes, or research.
+
+### Borders, shape, and surfaces
+
+- Use borders to explain containment, adjacency, sequence, or interaction.
+- Derive radius, shadow, texture, and surface contrast from brand and function.
+- Avoid combining heavy borders, strong shadows, gradients, and large radii without a product reason.
+
+### Color and motion
+
+- Start with brand and semantic roles rather than a preset palette.
+- Check default, hover, focus, disabled, selected, success, warning, and error states.
+- Animate feedback, causality, or spatial relationship; avoid ambient motion competing with the primary task.
+- Support `prefers-reduced-motion` without hiding essential state changes.
+
+## Reference use
+
+When a user supplies a reference site:
+
+1. Identify reusable principles: hierarchy, density, grid visibility, type, imagery, color, motion, and content strategy.
+2. Separate principles from protected brand assets and distinctive compositions.
+3. Translate the principles into the user's content, behavior, stack, and identity.
+4. State what was inspired by the reference without claiming an exact replica.