เครื่องมือร่างแบบจำลองเอชทีเอ็มแอล

สเก็ตช์

ใช้สกิลนี้เมื่อผู้ใช้ต้องการ เห็นแนวทางการออกแบบก่อนตัดสินใจเลือก — สำรวจไอเดีย UI/UX ในรูปแบบ HTML mockup แบบใช้แล้วทิ้ง จุดประสงค์คือการสร้างตัวแปรแบบโต้ตอบ 2-3 แบบเพื่อให้ผู้ใช้เปรียบเทียบแนวทางภาพเคียงข้างกัน ไม่ใช่เพื่อสร้างโค้ดที่พร้อมส่งมอบ

โหลดสกิลนี้เมื่อผู้ใช้พูดประมาณว่า "สเก็ตช์หน้าจอนี้", "แสดงให้ฉันดูว่า X อาจมีลักษณะอย่างไร", "เปรียบเทียบเลย์เอาต์ A กับ B", "ขอ 2-3 แนวทางสำหรับ UI นี้", "ให้ฉันดูตัวแปรบางตัว", "ทำ mockup ก่อนที่ฉันจะสร้าง"

เมื่อไม่ควรใช้สกิลนี้

• ผู้ใช้ต้องการคอมโพเนนต์แบบพร้อมผลิต — ใช้ claude-design หรือสร้างอย่างถูกต้อง
• ผู้ใช้ต้องการอาร์ติแฟกต์ HTML แบบ polished ครั้งเดียว (landing page, deck) — claude-design
• ผู้ใช้ต้องการไดอะแกรม — excalidraw, architecture-diagram
• การออกแบบล็อกแล้ว — แค่สร้างมัน

หากผู้ใช้มีระบบ GSD เต็มรูปแบบติดตั้งอยู่

หาก gsd-sketch ปรากฏเป็นสกิลพี่น้อง (ติดตั้งผ่าน npx get-shit-done-cc --hermes) ให้เลือกใช้ gsd-sketch สำหรับเวิร์กโฟลว์เต็มรูปแบบ: .planning/sketches/ ถาวรพร้อม MANIFEST, การวิเคราะห์โหมด frontier, การตรวจสอบความสอดคล้องกับสเก็ตช์ก่อนหน้า และการผสานกับ GSD ส่วนที่เหลือ สกิลนี้เป็นเวอร์ชันสแตนด์อโลนแบบเบา — การสเก็ตช์ครั้งเดียวโดยไม่มีเครื่องจักรสถานะ

วิธีการหลัก

intake  →  variants  →  head-to-head  →  pick winner (or iterate)

1. การรับข้อมูล (ข้ามได้หากผู้ใช้ให้ข้อมูลเพียงพอแล้ว)

ก่อนสร้างตัวแปร ให้ถามสามสิ่ง — ทีละคำถาม ไม่ใช่ทั้งหมดในครั้งเดียว:

1. ความรู้สึก "มันควรให้ความรู้สึกอย่างไร? คำคุณศัพท์, อารมณ์, ไวบ์" — "สงบ, บรรณาธิการ, เหมือน Linear" บอกได้มากกว่า "มินิมอล".
2. การอ้างอิง "แอป, ไซต์, หรือผลิตภัณฑ์อะไรที่จับความรู้สึกที่คุณจินตนาการไว้?" — การอ้างอิงจริงดีกว่าคำบรรยายนามธรรม
3. การกระทำหลัก "สิ่งที่สำคัญที่สุดอย่างเดียวที่ผู้ใช้ทำบนหน้าจอนี้คืออะไร?" — ตัวแปรทั้งหมดควรตอบสนองสิ่งนี้ได้ดี หากไม่เช่นนั้น มันก็เป็นแค่การตกแต่ง

สะท้อนแต่ละคำตอบสั้นๆ ก่อนคำถามต่อไป หากผู้ใช้ให้ทั้งสามอย่างมาล่วงหน้าแล้ว ข้ามไปยังตัวแปรได้เลย

2. ตัวแปร (2-3, ไม่เคย 1, นานๆ ครั้ง 4+)

สร้าง 2-3 ตัวแปร ในครั้งเดียว แต่ละตัวแปรเป็นไฟล์ HTML ที่สมบูรณ์และสแตนด์อโลน อย่าบรรยายตัวแปร — สร้างมันเลย จุดประสงค์คือการเปรียบเทียบ

แต่ละตัวแปรควรมี จุดยืนในการออกแบบที่แตกต่าง ไม่ใช่แค่ค่าพิกเซลที่ต่าง สามแกนที่ดีสำหรับตัวแปรคือ:

• ความหนาแน่น: กะทัดรัด / โปร่ง / หนาแน่นมาก (เลือกสองขั้วที่ตรงข้าม)
• การเน้น: เนื้อหาก่อน / การกระทำก่อน / เครื่องมือก่อน
• สุนทรียศาสตร์: แนวบรรณาธิการ / ประโยชน์ใช้สอย / ขี้เล่น
• เลย์เอาต์: คอลัมน์เดียว / ไซด์บาร์ / แผงแยก
• การลงกราวด์: แบบการ์ด / เนื้อหาเปล่า / แบบเอกสาร

เลือกหนึ่งแกนแล้วดึงความแตกต่างออกมา ตัวแปรสองตัวที่ต่างกันแค่สีเสริมนั้นเปล่าประโยชน์ — ผู้ใช้แยกไม่ออก

การตั้งชื่อตัวแปร: อธิบายจุดยืน ไม่ใช่หมายเลข

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. ทำให้เป็น HTML จริง

แต่ละตัวแปรเป็น ไฟล์ HTML แบบ self-contained เดียว:

• <style> แบบอินไลน์ — ไม่มีขั้นตอน build, ไม่มี CSS ภายนอก
• ฟอนต์ระบบ หรือ Google Font หนึ่งตัวผ่าน <link>
• Tailwind ผ่าน CDN (<script src="https://cdn.tailwindcss.com"></script>) ก็ใช้ได้
• เนื้อหาปลอมที่สมจริง — ประโยคจริง ชื่อจริง ไม่ใช่ "Lorem ipsum"
• แบบโต้ตอบได้: ลิงก์คลิกได้, hover จริง, มีการเปลี่ยนสถานะอย่างน้อยหนึ่งอย่าง (เปิด/ปิด, กรอง, สลับ) ภาพนิ่งแช่แข็งเป็น spike ที่แย่กว่าภาพเคลื่อนไหวที่เลอะเทอะ

เปิดในเบราว์เซอร์ หากดูเสีย ให้แก้ไขก่อนนำเสนอผู้ใช้

ตรวจสอบตัวแปรด้วยสายตา — ใช้เครื่องมือเบราว์เซอร์ของ Hermes อย่าแค่เขียน HTML และหวังว่ามันจะเรนเดอร์; โหลดแต่ละตัวแปรและดูมัน:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")

browser_vision ส่งคืนคำอธิบาย AI เกี่ยวกับสิ่งที่อยู่บนหน้าจริง พร้อมเส้นทางสกรีนช็อต — จับข้อบกพร่องด้านเลย์เอาต์ที่การตรวจสอบซอร์สล้วนๆ อาจพลาด (เช่น การนำเข้าฟอนต์ที่ล้มเหลวอย่างเงียบๆ, คอนเทนเนอร์ flex ที่ยุบ) แก้ไขและนำทางใหม่จนกว่าแต่ละตัวแปรจะดูดี

Default CSS reset + system font stack สำหรับการเริ่มต้นอย่างรวดเร็ว:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README ของตัวแปร

README.md ของแต่ละตัวแปรตอบคำถาม:

## Variant: {stance name}

### Design stance
One sentence on the principle driving this variant.

### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...

### Trade-offs
- Strong at: ...
- Weak at: ...

### Best for
- The kind of user or use case this variant actually serves

5. การเทียบเคียงกัน

หลังจากสร้างตัวแปรทั้งหมดแล้ว ให้นำเสนอในรูปแบบการเปรียบเทียบ อย่าแค่ลิสต์ — แสดงความเห็น:

## Three takes on the home screen

| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density   | Low            | High              | Medium        |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |

**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.

ให้ผู้ใช้เลือกตัวชนะ หรือรวมสองตัวเป็นไฮบริด หรือขออีกหนึ่งรอบ

การกำหนดธีม (เมื่อโปรเจกต์มีเอกลักษณ์ทางภาพ)

หากผู้ใช้มีธีมอยู่แล้ว (สี, ฟอนต์, tokens) ให้นำ tokens ที่ใช้ร่วมกันใส่ใน sketches/themes/tokens.css และทำการ @import ในแต่ละตัวแปร ทำให้ tokens น้อยที่สุด:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

อย่าทำ tokens มากเกินไปกับสเก็ตช์แบบใช้แล้วทิ้ง — สามสีและหนึ่งฟอนต์โดยปกติก็เพียงพอ

แถบความโต้ตอบ

สเก็ตช์มีความโต้ตอบเพียงพอเมื่อผู้ใช้สามารถ:

1. คลิกการกระทำหลัก แล้วมีบางอย่างที่มองเห็นได้เกิดขึ้น (การเปลี่ยนสถานะ, modal, toast, การนำทาง feint)
2. เห็นการเปลี่ยนสถานะที่มีความหมายอย่างหนึ่ง (กรองรายการ, สลับโหมด, เปิด/ปิดแผง)
3. hover ส่วนที่สังเกตได้ชัด (ปุ่ม, แถว, แท็บ)

มากกว่านั้นคือ over-engineering สำหรับของใช้แล้วทิ้ง น้อยกว่านั้นคือภาพหน้าจอ

โหมด Frontier (เลือกว่าจะสเก็ตช์อะไรต่อไป)

หากมีสเก็ตช์อยู่แล้วและผู้ใช้ถามว่า "ฉันควรสเก็ตช์อะไรต่อไป?":

• ช่องว่างความสอดคล้อง — ตัวแปรที่ชนะสองตัวจากสเก็ตช์ต่างกันทำการเลือกอิสระที่ยังไม่ได้ประกอบเข้าด้วยกัน
• หน้าจอที่ยังไม่ได้สเก็ตช์ — อ้างถึงแต่ยังไม่เคยสำรวจ
• ความครอบคลุมสถานะ — สเก็ตช์สถานะปกติ (happy path) แต่ยังไม่รวมสถานะว่าง / กำลังโหลด / ข้อผิดพลาด / 1000 รายการ
• ช่องว่าง Responsive — ตรวจสอบที่ viewport หนึ่ง; มันยังดีอยู่ไหมที่มือถือ / จอกว้างพิเศษ?
• รูปแบบปฏิสัมพันธ์ — มีเลย์เอาต์แบบคงที่; แต่ไม่มีการเปลี่ยนผ่าน, ลาก, หรือพฤติกรรมการเลื่อน

เสนอผู้สมัครที่มีชื่อ 2-4 รายการ ให้ผู้ใช้เลือก

ผลลัพธ์

• สร้าง sketches/ (หรือ .planning/sketches/ หากผู้ใช้ใช้แบบแผนของ GSD) ใน root ของ repo
• หนึ่ง subdir ต่อหนึ่งตัวแปร: NNN-stance-name/index.html + README.md
• บอกผู้ใช้ถึงวิธีเปิด: open sketches/001-calm-editorial/index.html บน macOS, xdg-open บน Linux, start บน Windows
• ทำให้ตัวแปรเป็นแบบใช้แล้วทิ้ง — สเก็ตช์ที่คุณรู้สึกว่าจำเป็นต้องเก็บรักษาควรถูกเลื่อนขั้นเป็นโค้ดโปรเจกต์จริง ไม่ใช่เก็บเป็นทรัพย์สิน

ลำดับเครื่องมือทั่วไปสำหรับหนึ่งตัวแปร:

terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")

ทำซ้ำสำหรับแต่ละตัวแปร จากนั้นนำเสนอตารางเปรียบเทียบ

การให้เครดิต

ดัดแปลงจากเวิร์กโฟลว์ /gsd-sketch ของโปรเจกต์ GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). ระบบ GSD เต็มรูปแบบมีสถานะสเก็ตช์ถาวร, การอ้างอิงรูปแบบธีม/ตัวแปร, และเวิร์กโฟลว์การตรวจสอบความสอดคล้อง; ติดตั้งด้วย npx get-shit-done-cc --hermes --global.