GRIDGEIST
เมนู
ENGitHub ↗

คู่มือภาคสนาม / v1.2

จากสัญญาณ
สู่ระบบ.

คู่มือที่เริ่มจากการตัดสินใจ เพื่อสร้าง ปรับดีไซน์ หรือรีวิว Interface ที่เป็นของผลิตภัณฑ์นั้นจริง ๆ ไม่ใช่ของสไตล์สำเร็จรูป

เวอร์ชัน
1.2.0
รูปแบบงาน
03
สัญญาอนุญาต
MIT

01 / เริ่มต้นใช้งาน

สร้างพื้นผิว
สำหรับการตัดสินใจ.

เรียกใช้ $gridgeist ระบุผลิตภัณฑ์และผู้ใช้ เลือกงาน รักษาสิ่งสำคัญ และกำหนดหลักฐานที่ต้องมีก่อนบอกว่างานเสร็จ

  1. 01เปิดของจริง

    Repository หน้าเว็บที่ Render แล้ว Route เนื้อหา และแบรนด์เดิม

  2. 02ระบุการตัดสินใจ

    Create, Redesign หรือ Review พร้อมผลลัพธ์ที่ควรเป็นจริง

  3. 03ผูกกับหลักฐาน

    Viewport, Interaction, Keyboard path, Project checks และข้อจำกัด

PROMPT / CREATE
ใช้ $gridgeist ออกแบบ Landing Page สำหรับแพลตฟอร์มเรียน SQL
ให้บทเรียน Query editor และผลลัพธ์เป็นหลักฐานสำคัญของงานภาพ
หลีกเลี่ยงกริดการ์ด SaaS แบบทั่วไป
ตรวจทั้ง Desktop, Mobile, Keyboard และ Accessibility

Context ที่ดีทำให้งานดีขึ้นต่อเนื่อง ให้ Agent ตรวจ Repository และหน้าเว็บที่ Render แล้วเมื่อเป็นไปได้

02 / ติดตั้ง + อัปเดต

เลือกเส้นทาง
ที่คุณดูแลต่อได้.

01

Codex Plugin

แนะนำ

เพิ่ม Marketplace ติดตั้ง Plugin แล้วเริ่ม Codex session ใหม่

codex plugin marketplace add ohmiler/gridgeist
codex plugin add gridgeist@gridgeist
02

Agent ที่รองรับ

UNIVERSAL

ใช้ Agent Skills CLI สำหรับ Claude Code, Cursor, Gemini CLI, Copilot, OpenCode และ Agent อื่นที่รองรับ

npx skills add ohmiler/gridgeist -g
03

ติดตั้งด้วยตนเอง

PORTABLE

คัดลอก skills/gridgeist/ ไปยัง Skills directory ของ Agent ที่รองรับมาตรฐาน Agent Skills แบบ SKILL.md

04

อัปเดตของเดิม

สั่งอัปเดต

Gridgeist จะไม่อัปเดตแบบเงียบ ให้ Refresh และติดตั้ง Codex Plugin ซ้ำ หรือใช้คำสั่ง Update ของ Skills CLI แล้วเริ่ม Agent session ใหม่ ส่วนการคัดลอกเองต้องแทนที่จาก Release tag

codex plugin marketplace upgrade gridgeist
codex plugin add gridgeist@gridgeist

npx skills update gridgeist -g -y

03 / เลือกรูปแบบงาน

ระบบเดียว.
สามทางเข้า.

รูปแบบใช้เมื่อเริ่มจาก
Createสร้าง Interface ใหม่ผู้ใช้ + งานหลัก + หลักฐานจริง
Redesignเปลี่ยนดีไซน์ผลิตภัณฑ์เดิมรักษา Behavior + สัญญาณแบรนด์ + State inventory
Reviewวิเคราะห์ Draft ก่อนแก้ไขปัญหาตามลำดับความสำคัญ + หลักฐาน

04 / ปรับระบบ

เผยโครงสร้างเท่าที่
ผลิตภัณฑ์ต้องการ.

เลือกระดับการมองเห็นจากผู้ใช้ งาน เนื้อหา และแบรนด์ Gridgeist คือวิธีตัดสินใจ ไม่ใช่หน้าตาที่ต้องมองเห็นเสมอ

มองเห็นข้อมูล + ระบบเทคนิค

ใช้แนวจัดวางชัดเจนกับความสัมพันธ์ คำสั่ง สถานะ และหลักฐานเชิงปฏิบัติการ

เงียบเนื้อหา + บทบรรณาธิการ

ควบคุมความกว้างการอ่านและตำแหน่งอ้างอิง โดยให้ข้อความหรือภาพเป็นผู้นำ

มองไม่เห็นCanvas + การควบคุมตรง

ให้เครื่องมือหลักครองพื้นที่ และเก็บโครงสร้างไว้ในตำแหน่งคำสั่งกับ Behavior

สถานะนำขั้นตอนธุรกรรม

ใช้ตำแหน่งคำสั่งที่คงที่ Validation, Confirmation และ Recovery สร้างลำดับ

ทดสอบความเป็นแบรนด์ถ้าเอาเส้น Mono label และกริดที่มองเห็นออก ผลลัพธ์ยังต้องเป็นของผลิตภัณฑ์นั้น

05 / กำหนด Contract

เชื่อมระบบ
ก่อนเก็บรายละเอียด.

ใช้ Contract ที่เล็กที่สุดแต่ครอบคลุมงาน และตรวจ Implementation กับหลักฐานของแบรนด์เดิมก่อนเปลี่ยนค่า

01 / Foundationสี · ตัวอักษร · Rhythm
02 / SemanticCanvas · Text · State
03 / Componentโครง · Variant · Behavior
สี + Themeจับคู่บทบาท.

เชื่อม Foreground/Background, Border, Action, Focus, Success, Warning และ Destructive

Type + Spacingตั้งชื่อตามหน้าที่.

กำหนดเฉพาะ Display, Heading, Body, Label, Metadata และ Spacing ที่พื้นผิวต้องใช้

Componentsทดสอบ Grammar.

ครอบคลุม Variant, State, ภาษา, Dynamic content, Overflow และ Container แคบ

Motion + หลักฐานผูกคำกล่าวอ้าง.

ใช้ Motion เพื่อ Feedback หรือ Causality รองรับ Reduced motion และรายงานเฉพาะสิ่งที่ตรวจจริง

FocusErrorReduced

06 / เขียน Brief

ข้อมูลสี่อย่าง
ลดความคลุมเครือ.

  1. 01

    ผลิตภัณฑ์ + ผู้ใช้

    กำลังออกแบบอะไร และใครเป็นคนใช้งาน?

  2. 02

    รูปแบบงาน + ผลลัพธ์

    Create, Redesign หรือ Review และเมื่อเสร็จแล้วอะไรควรเป็นจริง?

  3. 03

    ข้อจำกัด

    ระบุ Behavior, Route, เนื้อหา, Brand asset และเทคโนโลยีที่ต้องรักษา

  4. 04

    การตรวจสอบ

    ระบุ Viewport, Interaction, Keyboard path, Accessibility และ Project checks

รูปแบบ Prompt / Redesign +
ใช้ $gridgeist ปรับดีไซน์ Dashboard นี้ใหม่
รักษา Route, Function, เนื้อหา และสีแบรนด์เดิมทั้งหมด
สร้างลำดับข้อมูลใหม่ตาม Investigation path หลักของผู้ใช้
ตรวจ Narrow mobile, Tablet, Laptop และ Wide desktop
รูปแบบ Prompt / Review +
รีวิว Interface นี้ด้วย $gridgeist โดยยังไม่ต้องแก้โค้ด
สรุปคำตัดสินหนึ่งบรรทัด ตามด้วยปัญหาที่เรียงตามความสำคัญ
หลักฐาน และทิศทางใหม่หนึ่งทิศทางที่สอดคล้องกัน

07 / ขั้นตอนทำงาน

สำรวจก่อน
จัดองค์ประกอบ.

  1. 01Inspect

    ทำความเข้าใจผลิตภัณฑ์ ผู้ใช้ Route, Component, Token และ UI ที่ Render แล้ว หากยังมีทิศทางระดับ Thesis ที่สมเหตุผลหลายแบบ ให้แนะนำ 2–3 ทางเลือกและยืนยันหนึ่งทางก่อนแก้ไฟล์

  2. 02Set a thesis

    เขียนหนึ่งประโยคที่กำกับลำดับ โครงสร้าง การแสดงออก และหลักฐานจากผลิตภัณฑ์

  3. 03Define the system

    เชื่อม Foundation values กับ Semantic roles และ Component anatomy, Variant, State, Content stress, Motion และ Responsive transformation

  4. 04Compose

    สร้างลำดับก่อนรายละเอียด ให้ Code, Data, Workflow หรือภาพจริงทำหน้าที่สื่อสาร

  5. 05Implement

    ทำตาม Convention ของ Repository, Semantic HTML, Keyboard behavior และ Primitive เดิม

  6. 06Verify

    Render หลายขนาด ทดลอง State และ Input แก้ปัญหาที่พบ และรายงานสิ่งที่ยังไม่ได้ตรวจ

08 / ตรวจผลลัพธ์

ใช้หลักฐาน
ก่อนตัดสิน.

A

ความชัดเจน

ผลิตภัณฑ์ ผู้ใช้ งานหลัก และสิ่งที่ต้องทำต่อเข้าใจได้ทันที

B

ลำดับ

แต่ละ Viewport มีจุดเด่นหลักหนึ่งจุดและลำดับการอ่านที่ชัดเจน

C

การตอบสนอง

Mobile ถูกจัดใหม่ตามความสำคัญ และ Code กับ Table ไม่ล้นจอ

D

สถานะ

ตรวจ Default, Loading, Empty, Error, Success, Disabled และ Destructive เมื่อเกี่ยวข้อง

E

การเข้าถึง

สังเกต Landmark, Focus, ชื่อ, Contrast, Motion และ Keyboard path

F

ความซื่อตรง

ระบุคำสั่ง Viewport, Flow, ข้อจำกัด และหลักฐานที่ตรวจจริง

6 / 6

รอบ SYSTEM-CONTRACT ใหม่ของ v1.2Implementation ของ Scenario 19 ผ่านทั้งภาษาไทยและอังกฤษ พร้อมการตรวจ Responsive ด้วย Browser แบบอิสระ Guardrail ได้รับการซ่อมแล้ว ส่วนหลักฐานจากผู้ใช้จริงยังเป็นงานต่อไป

09 / ข้อจำกัด

เป็นวิธีคิด.
ไม่ใช่ Preset.

  • ค่าเริ่มต้นด้าน Grid, Type และสีเป็นเพียงจุดเริ่ม ไม่ใช่กฎตายตัว
  • คุณภาพผลลัพธ์ขึ้นอยู่กับ Context ของผลิตภัณฑ์ที่ Agent ได้รับ
  • Automated checks ไม่สามารถแทนการตรวจหน้าเว็บที่ Render จริงได้
  • ผลลัพธ์จากโมเดลอาจเปลี่ยน ควรทดสอบซ้ำเมื่อเปลี่ยน Agent หรือแก้ Skill

พร้อมดูวิธีนี้ในงานจริงหรือยัง?

ดูกรณีศึกษาทั้งหมด