Prompt library: วงจรสร้างเว็บด้วย AI ที่ตรวจสอบได้

ใช้ prompt เหล่านี้เป็น template ไม่ใช่คำสั่งที่ต้องเชื่อแบบตายตัว. แทนที่ข้อความใน [วงเล็บ], แนบ SPEC.md/brief ที่ได้รับอนุมัติ, และคง checkpoint มนุษย์ก่อน external write. Syntax เรียก skill ต่างกันตาม host: Claude Code ใช้ /skill-name; บาง installation ของ Codex ใช้ $skill-name หรือ auto-selection; plugin/MCP commands เปลี่ยนตาม version. ตรวจ help/docs ที่ติดตั้งก่อนใช้คำสั่งใด ๆ (Claude Code Skills, cloudflare/skills).

แผนภาพวงจร workflow เริ่มจาก brief และ context ไปยัง build กับ verify งานที่ไม่ผ่านย้อนกลับไปแก้จากหลักฐาน และงานที่ผ่านจึง deploy — บนจอเล็ก เลื่อนแนวนอนเพื่ออ่านแผนภาพ หรือเปิดไฟล์ HTML จากลิงก์ใต้ภาพ

เปิดแผนภาพ workflow แบบเต็มหน้า เพื่อเลือก prompt ตามสถานะงาน code block ทุกชุดด้านล่างยังเป็น source ที่คัดลอกไปใช้ได้และไม่ถูกย่อหรือแทนด้วยภาพ

1. Discovery: ให้ agent ตั้งโจทย์ก่อนเขียน

ทำหน้าที่เป็น product-minded web engineer ใน repository นี้

อ่าน AGENTS.md, README และ SPEC.md ก่อน อย่าแก้ไฟล์ในรอบนี้

เป้าหมาย: แปลง spec ของ [ชื่อเว็บ] เป็นแผนสร้าง MVP ที่เล็กที่สุดแต่ตรวจได้
ให้แยก:
1) สิ่งที่ยืนยันจาก spec กับ assumptions/TODO ที่ห้ามแต่งเอง
2) routes/components/data contracts ที่จำเป็น
3) accessibility, responsive, security/PII และ performance risks
4) งานเป็น vertical slices โดย slice แรกควรจบด้วย UI ที่เห็นได้
5) files ที่คาดว่าจะอ่าน/แก้ และ validation commands ที่มีอยู่จริงใน repo (`npm run` คือ source of truth)
6) acceptance criteria และหลักฐานของแต่ละ slice

อย่าเพิ่ม dependency, อย่า deploy, อย่าเขียน secret. ถ้าข้อมูลธุรกิจหรือจุด deploy ไม่ชัด ให้ถามคำถามแบบจัดลำดับความสำคัญ 5 ข้อหรือน้อยกว่า.

ใช้เมื่อ: เริ่ม feature ใหม่, เปลี่ยน brief, หรือรับ repository ที่ไม่รู้จัก. ผลที่ควรได้: plan + questions ไม่ใช่ code. ถ้า agent เริ่มแก้ไฟล์ แปลว่าต้องย้ำ “รอบนี้ read-only”.

2. Implement slice: งานเล็กที่ review ได้

ทำตาม SPEC.md และแผนที่อนุมัติแล้ว

สร้างเฉพาะ slice นี้: [เช่น hero + header สำหรับหน้า company landing]
ขอบเขตไฟล์: [ระบุหรือให้ค้นหา component ที่เกี่ยวข้อง]

ข้อกำหนด:
- ใช้ patterns และ dependencies ที่มีใน repo; อย่าเพิ่ม package
- mobile-first และ keyboard-accessible; ใช้ semantic heading/landmark
- เนื้อหาที่ไม่มีแหล่งยืนยันต้องเป็น `[TODO: content owner]` ไม่แต่งราคา, review, logo, metric หรือ legal claim
- หากใช้รูป ให้ใช้ asset ที่อนุมัติแล้วหรือ placeholder ที่ระบุชัด
- อย่าแตะ API, database, deployment configuration หรือ files นอก scope

ก่อนแก้: สรุป approach และ files ที่จะเปลี่ยนใน 5 bullet หรือน้อยกว่า
หลังแก้: รัน validation commands ที่ repo ระบุและรายงาน command/output แบบย่อ. สำหรับหลักสูตรนี้เริ่มจาก `npm run typecheck` และ `npm run build`; run `npm run test`/`npm run test:e2e` เฉพาะเมื่อ test files/config พร้อม,
รายการไฟล์ที่แก้, สิ่งที่ไม่ได้รัน และเหตุผล. หยุดหลังส่งผลเพื่อให้ review ก่อน slice ถัดไป.

3. Prompt สำหรับ catalog/เช่าอุปกรณ์

สร้างเฉพาะ UI catalog และ quote-request flow ตาม SPEC.md

data ต้องเป็น fixture ที่พิมพ์ type ชัดเจนและติดป้าย demo; ห้ามอ้าง availability หรือราคาเป็นข้อมูลจริง
รองรับ states: loading, no results, unavailable, invalid form, submit failure และ submit success
filter/search ต้องเข้าถึงได้ด้วย keyboard และรักษา state ตาม pattern ที่มีอยู่ใน repo
form มี label, validation message และไม่ส่ง PII ไปยัง external endpoint ในรอบนี้

ทำงานเป็นสองขั้น: (1) เสนอ data shape + interaction plan; รอ review
(2) หลังได้รับคำสั่งให้ทำต่อ ให้ implement slice เดียวและรัน validation

4. Prompt สำหรับ GSAP showroom

ก่อนแก้ code ให้เสนอ motion specification สำหรับ [section] ได้แก่ trigger, visual intent,
properties, duration/easing range, cleanup, resize behavior, failure fallback และ reduced-motion behavior.

เมื่อได้รับอนุมัติ ให้ implement animation เป็น progressive enhancement:
- headline/content/CTA ต้องอ่านและใช้งานได้เมื่อ JavaScript หรือ animation ไม่ทำงาน
- เคารพ `prefers-reduced-motion: reduce` โดยลดหรือปิด motion ที่ไม่จำเป็น
- หลีกเลี่ยง scroll-jacking และไม่ block keyboard focus
- ใช้ lifecycle/cleanup ที่เข้ากับ framework เพื่อไม่ให้ animation ซ้อนหลัง navigation
- ไม่เพิ่ม dependency นอกเหนือจาก GSAP ที่มี/ได้รับอนุมัติ

หลังแก้ ให้รายงาน test ที่รัน, viewports ที่ตรวจ, และข้อจำกัดด้าน performance ที่ยังไม่ได้วัด.

5. Reviewer prompt: ตรวจจากหลักฐาน ไม่ใช่ความรู้สึก

ทำหน้าที่เป็น independent reviewer. อ่าน SPEC.md, AGENTS.md, diff และผล validation ที่มี
อย่าแก้ไฟล์ในรอบนี้

ตรวจว่าการเปลี่ยนแปลง:
1) ตรง acceptance criteria และไม่ขยาย scope
2) ไม่แต่ง business facts/price/testimonial
3) มี semantic HTML, labels, keyboard focus และ reduced-motion ที่เหมาะกับ feature
4) ไม่เพิ่ม secret, PII leak, external write หรือ production deploy โดยไม่มี checkpoint
5) test/build evidence ครอบคลุม behavior ที่เปลี่ยนจริง

รายงาน findings เรียง BLOCKER/HIGH/MEDIUM/LOW พร้อม file/line หรือหลักฐานที่ตรวจได้.
ระบุ “not verified” แยกจาก “passed”. ปิดท้ายด้วย verdict: READY FOR PREVIEW, NEEDS CHANGES หรือ BLOCKED.

6. Preview deployment handoff

เตรียม deploy ไปยัง Cloudflare preview เท่านั้น ตามเอกสาร/skill ของ project

ก่อนทำ action ใด ๆ:
- ระบุ project/account/environment ที่จะกระทบจาก config และ CLI output
- บอก commands ที่จะรัน, preview URL ที่คาดหวัง, และ rollback/cleanup path
- ยืนยันว่าไม่มี production target, DNS change, database migration หรือ secret value ใน diff

ทำเฉพาะเมื่อ target ระบุชัดว่า preview. หลัง deploy ให้รายงาน URL, deployment identifier,
commit SHA, command/output, และผล smoke test ของ route + form/error state.
ถ้า config บอก production หรือ target คลุมเครือ ให้หยุดและรายงานสิ่งที่ต้องระบุ; ห้ามเดา environment.

Cloudflare ให้ skill collection ทางการที่มี wrangler, Workers/D1 และอื่น ๆ; เลือก skill ตามงานแล้วเปิดเอกสาร version-current ก่อนรัน deploy (cloudflare/skills). สิ่งนี้ยังไม่อนุญาต production deployment เอง

7. Production release gate (ให้มนุษย์อนุมัติ)

สร้าง release packet สำหรับมนุษย์ ไม่ต้อง deploy production

รวบรวม: commit SHA, preview URL, changed files, migrations (ถ้ามี), environment bindings ที่ต้องมี
โดยเปิดเผยเฉพาะชื่อ binding, validation/test outputs, manual smoke-test result, accessibility/performance checks,
known gaps, owner of each TODO, rollback plan และคำสั่ง deploy ที่ exact ตาม project docs.

ตรวจว่ามี human sign-off สำหรับ content facts, legal/privacy copy, data migration และ production environment.
หากหลักฐานใดขาด ให้รายงาน BLOCKED พร้อมรายการที่ขาด แทนการสรุปว่า release-ready.

8. Prompt สำหรับสร้าง skill อย่างปลอดภัย

ช่วยออกแบบ `SKILL.md` สำหรับ workflow ที่เราทำซ้ำ: [ชื่อ workflow]

เริ่มด้วยการถาม/สรุป trigger, outcome, human checkpoints, repository scope, external side effects,
evidence of completion และ references ที่โหลดเฉพาะบางกรณี. จากนั้นเสนอ structure ก่อนเขียน.

skill ต้องใช้ Agent Skills portable core (`name`, `description`, Markdown body); vendor-specific
frontmatter/command syntax แยกในหัวข้อ Compatibility. อย่าให้ skill เก็บ credential, bypass permissions,
deploy production, หรือรัน destructive commands อัตโนมัติ. ใช้ progressive disclosure:
body สั้นสำหรับ workflow ร่วม และลิงก์ reference ตาม branch.

ให้ test plan ทั้ง trigger และ non-trigger prompt พร้อม expected behavior. จบที่ draft/documentation;
อย่าติดตั้งหรือแก้ global skill directory โดยไม่ได้รับคำสั่งชัดเจน.

Quick evidence record

9. Prompt ทำซ้ำการ rebrand หน่วยเรียนเป็น Rawinnipa

Prompt นี้เป็น reproduction brief สำหรับทำการปรับแบรนด์ซ้ำกับ source รุ่นอื่น ไม่ใช่ transcript ของคำสั่งที่ใช้แก้ repository รอบแรก ผู้ใช้ต้องตรวจ diff และผล build จริงก่อนอ้างว่างานเสร็จ

ปรับ course shell และเอกสารของ repository นี้เป็นแบรนด์ Rawinnipa โดยอ่าน
/home/dev/projects/rawinnipa-brandbook/01-strategy/Rawinnipa_Brand_Guidelines_v1.0.md
และ DESIGN.md ฉบับปัจจุบันก่อนแก้

ใช้ชื่อ “AI Web Studio” และคำอธิบายไทย “ออกแบบและพัฒนาเว็บไซต์ด้วย AI”
ระบุให้ชัดว่าเป็นหน่วยปฏิบัติ 2 วัน × 4 ชั่วโมง (8 ชั่วโมงรวมพัก โดยพัก 10 นาทีต่อวัน) ซึ่งเป็นส่วนหนึ่งของ
“977-121 Module: Website Design and Development” ที่
มหาวิทยาลัยสงขลานครินทร์ วิทยาเขตภูเก็ต / Prince of Songkla University, Phuket Campus
ห้ามอ้างว่า 8 ชั่วโมงคือชั่วโมงรวมของ module, syllabus ทั้งหมด หรือจำนวนหน่วยกิต
เก็บ 12 บทเรียน, คู่มือและบททดลองเสริม 11 ชุด และ prompt libraries เป็นคลังเรียนต่อด้วยตัวเอง

Digital UI ใช้ #0A0A0A เป็น canvas หลัก, #1A1A1A เป็น surface, #2A2A2A เป็น divider,
#F7F7F7 เป็นข้อความหลัก, #9CA3AF เป็นข้อความรอง และ #3EDC81 เป็น accent ที่ใช้เฉพาะจุดสำคัญ
ให้ลิงก์ทั่วไปเป็นสีกลาง และใช้เขียวกับ active state หรือ primary action
ใช้ Inter สำหรับ Latin และ Noto Sans Thai สำหรับภาษาไทย
งานพิมพ์/PDF ใช้ light canvas กับข้อความเข้มตามข้อยกเว้นใน brandbook §6.1

ปรับ header, hero, navigation, cards, buttons, focus states, footer, handbook และแผนภาพ
โดยรักษา semantic HTML, keyboard flow, reduced motion, contrast และ mobile 390px ไม่ให้ล้น
เว็บธุรกิจตัวอย่างทั้งสี่เป็นชิ้นงานอิสระ ให้รักษาชื่อ ธีม สี ฟอนต์ และ prompt ต้นฉบับของแต่ละโจทย์
ห้ามเปลี่ยนชื่อ Cloudflare Worker, D1, production URL, binding, storage key หรือคำสั่งที่เคยรันในหลักฐาน
ถ้าพบชื่อเดิมใน artifact หรือ prompt ที่ใช้จริง ให้ระบุว่าเป็นประวัติศาสตร์แทนการแก้ข้อความจนไม่ตรงหลักฐาน

อัปเดต provenance ให้ชี้ brandbook และ profile rawinnipa-ai-web-studio
จากนั้นรัน lint, typecheck, build, diagram checks, documentation/browser checks และ export PDF/ZIP ใหม่
รายงาน changed files, ผลตรวจจริง, ข้อจำกัด และค่าที่ยังคงเดิมเพราะเป็น technical identity
อย่าอ้างว่า deploy สำเร็จจนตรวจ URL และ hash ของไฟล์ production แล้ว

หาก artifact ที่ต้องส่งคือแผนภาพ ใช้ prompt library ของ Diagram Design เพื่อบังคับ selection, complexity budget, accessibility และ source metadata แล้วแนบผล npm run check:diagrams ใน record เดียวกัน

เก็บ record นี้ใน PR, issue หรือ release packet ทุกครั้ง:

- Spec/brief version: [link or commit]
- Change commit: [SHA]
- Environment: local | preview URL | production URL
- Automated checks: [command] — PASS/FAIL/not run + reason
- Manual checks: viewport, keyboard, form state, reduced motion — result
- Data/content source: [owner/link]; unresolved TODOs: [...]
- External effects: none | preview deploy | migration; human approver: [name]
- Rollback: [exact safe path]

OpenAI เรียกร้องให้ระบุ acceptance/test expectations ใน task ของ coding agent (Model guidance); record นี้ทำให้คำขอนั้นกลายเป็นหลักฐานที่ reviewer ตรวจได้

ความคืบหน้าบันทึกเฉพาะเบราว์เซอร์นี้ ไม่มีบัญชีผู้เรียนหรือการส่งข้อมูลการเรียนขึ้นเซิร์ฟเวอร์