Workflow ที่ทำให้ AI Agent ทำงานเหมือนมี Memory

เวลาทำโปรเจกต์ขนาดเล็ก​ หรือ poc อะไรสักอย่าง ปัญหาที่เจอจริงมักไม่ใช่เรื่องโค้ดเลย แต่เป็นเรื่อง “ทำยังไงให้ทุกคน — รวมถึง AI ที่ช่วยทำงาน — เข้าใจตรงกันตั้งแต่ต้น”

เพราะถ้า context หลุดตั้งแต่ต้น มันจะพาทุกอย่างหลุดตาม ขอบเขตไม่ชัด คำศัพท์ปน implementation ค่อย ๆ เถไปจากที่ตั้งใจ แล้วสุดท้ายก็ต้องย้อนกลับมาแก้ใหม่ทั้งแผง ซึ่งเสียเวลามากกว่าที่คิด

เลยอยากเล่า workflow ที่ผมใช้อยู่ตอนนี้ด้วย 3 skills ที่ต่อกันเป็นลำดับ คือ grill-with-docs, to-prd, และ to-issues

ของพวกนี้เป็น skill ของ Matt Pocock ดูต้นฉบับได้ที่ https://github.com/mattpocock/skills/tree/main/skills/engineering

เริ่มจากปัญหาจริงก่อน

ลองนึกภาพเคสนี้ เช่นผมอยากได้ “simple app” สักตัว ใช้ Next.js + shadcn/ui + App Router + Prisma + PostgreSQL แล้วก็อยากโชว์ SSR, CSR, SSG, ISR, Server Actions, API Routes, Server Components, Client Components ครบ

ฟังดูโอเค แต่ถ้าส่ง requirement แบบนี้ให้ ai agent แล้วรีบ scaffold เลย สิ่งที่ได้มักจะเป็นแบบนี้

• route เยอะแต่ไม่มีเรื่องเล่าเดียวกัน
• มีครบทุก rendering strategy แต่ไม่ชัดเลยว่าทำไมหน้านี้ถึงต้องเป็น SSR
• Server Action กับ API Route ซ้อนบทบาทกันมั่ว
• Prisma schema มีแต่ domain ของมันคืออะไรกันแน่

สรุปคือ “มีครบ” แต่พอไล่ implement ต่อก็เริ่มสะดุดตลอด นี่คือ step ที่ผมใช้ในช่วงนี้

Step 1: grill-with-docs — อย่าเพิ่งรีบ ให้บีบ requirement ก่อน

skill นี้ไม่ได้ช่วยตอบเร็ว แต่ช่วยไม่ให้เราคิดลัด มันถามทีละประเด็น และทุกครั้งที่ข้อสรุปเริ่มนิ่ง ก็จดลง CONTEXT.md ทันที

ผลที่ได้จากการ grill ที่ดีคือภาษากลางของโปรเจกต์ จาก “simple app” เราค่อย ๆ บีบจนได้ว่า ใช้ Product Catalog เป็น domain หลักไม่ใช่ todo, มี Category, Product, Review, มี Admin สำหรับฝั่งจัดการ, เน้นเป็น feature showcase ไม่ใช่ e-commerce เต็มรูป

แค่นี้ทุกอย่างหลังจากนี้จะเข้าใจตรงกัน เพราะมีคำที่ตกลงกันแล้วว่าหมายถึงอะไร

คำถามที่ควรไล่ให้จบในช่วง grill มีประมาณนี้: domain ที่เหมาะที่สุดคืออะไร, ใครมีสิทธิ์แก้ข้อมูล, route ไหนใช้ rendering strategy อะไรและทำไม, Server Action กับ API Route แบ่ง boundary กันตรงไหน, scope อะไรตัดทิ้งก่อน

อันที่สำคัญมากคืออัปเดต CONTEXT.md ระหว่างคุย ไม่ใช่สรุปทีหลัง เพราะถ้าปล่อยให้ข้อตกลงอยู่แค่ใน chat มันหายเร็วมาก โดยเฉพาะตอนเริ่ม implement จริง

Step 2: to-prd — เปลี่ยน context ที่นิ่งแล้วให้จับต้องได้

หลัง grill จนเริ่มนิ่ง หลายคนชอบข้ามตรงนี้แล้วรีบเข้า implementation เลย แต่ปัญหาคือความเข้าใจยังอยู่ในหัว หรือกระจายใน chat log

to-prd เป็น skill ที่ช่วยเราเขียน prd ออกมาเป็นสิ่งที่ตกลงกันให้อยู่ในรูปที่คนอื่นอ่านต่อได้ง่าย และที่สำคัญกว่า มันบังคับให้ตอบคำถามพวกนี้แบบเป็นระบบ เช่น

• หน้านี้มีไว้เพื่อใคร
• route นี้โชว์ feature ไหนของ framework และทำไมถึงเลือกแบบนั้น
• action ไหนควรเป็น Server Action, endpoint ไหนควรเป็น API Route

PRD ที่ได้ไม่ใช่เอกสารยาว ๆ แต่เป็นที่เก็บว่า ทำไมถึงตัดสินใจแบบนั้น เช่น landing page เป็น SSG เพราะเนื้อหาคงที่, catalog เป็น ISR เพราะข้อมูลเปลี่ยนเป็นช่วง ๆ ไม่ต้อง refresh ทุก request, admin dashboard เป็น server-rendered shell ที่มี CSR table ข้างใน เพราะตรงกับ App Router จริงมากกว่า

พอมี PRD แบบนี้ เวลาจะแตกงานต่อไม่ต้องย้อนไปไล่อ่านบทสนทนายาว ๆ ใหม่ทั้งหมด

Step 3: to-issues — แตกงานแบบ vertical slices ไม่ใช่แบบ layer

วิธีที่เจอบ่อยคือแตกตาม layer กล่าวคือ issue นึงทำ database, อีกอันทำ UI, อีกอันทำ API ดูเป็นระเบียบแต่ปิด issue แล้วไม่มีอะไรให้เปิดดูได้จริง ๆ แถมยังต้องจำไว้ตลอดว่าชิ้นที่เหลืออยู่ที่ไหน

โดย skill ที่ชื่อ to-issues เลยแตกให้แต่ละก้อนพาของไปจบได้เองในตัว มี schema ที่ใช้ได้, route ที่เปิดดูได้, UI ที่ลองได้ ปิด issue นึงแล้วมีของจริงให้เห็น

to-issues ใช้แตกเป็น vertical slices แทน แต่ละ issue ควรจบเส้นทางของตัวเองได้ มี schema ที่ใช้ได้, route ที่เปิดดูได้, UI ที่ลองได้

สำหรับโปรเจกต์ Product Catalog แตกออกมาได้ประมาณนี้:

1. bootstrap platform: Postgres + Prisma + seed + app framing
2. static explainer shell: landing/about + explanation UI
3. shopper catalog with ISR
4. product detail with SSR and reviews
5. review submission with Server Action
6. admin dashboard shell with CSR table
7. admin create product flow
8. admin edit/delete/feature flow
9. API Route playground
10. polish + README

สังเกตว่าแต่ละ issue พูดด้วยภาษาของ product ไม่ใช่ภาษาของ layer แทนที่จะพูดว่า “เพิ่ม Prisma schema” ก็พูดว่า “bootstrap Product Catalog platform” มันฟังดูต่างกันนิดเดียว แต่มันกำหนดว่าคนหยิบงานจะมองงานนั้นเป็น feature หรือแค่ task ย่อยทางเทคนิค

โดยก่อนใช้ skill “to-issues” อย่าลืมย้ำไปว่าให้อ่านไฟล์ prd จาก step 2 ด้วยนะ

หลังจากจบ to-issues แล้วเราสามารถเริ่ม implement ได้เลย เริ่มจาก ทีละ issue และ แต่ละ issue ก็สามารถ “new”​ หรือ “clear” prompt เดิมได้เลย แค่เปลี่ยน task ไปเรื่อยๆจนกว่าจะครบ

สรุปสั้น ๆ

grill-with-docs = ทำให้รู้ว่าจะสร้างอะไร to-prd = เก็บเป็นเอกสารว่าทำไมถึงตัดสินใจแบบนั้น to-issues = แตกออกมาเป็นชิ้นที่หยิบไปทำได้เลย

งานที่ดีไม่ได้เริ่มจาก generate code ให้เร็วที่สุด แต่เริ่มจากการนิยามให้ชัดก่อนว่าเรากำลังสร้างอะไรอยู่จริง ๆ

ถ้ามีเวลาจะมาเขียนต่อเรื่อง skill handoff ซึ่งเป็นอีก pattern นึงที่ช่วยประหยัด context ได้อีกมาก โดยเฉพาะตอนต้องส่งงานข้ามหลาย agent หรือหลายรอบสนทนาโดยไม่เสีย context ระหว่างทาง