qa

name	qa
description	QA session แบบ interactive ที่ผู้ใช้เล่าบั๊กหรือปัญหาแบบคุยกันธรรมดา แล้ว agent เปิด GitHub issue ให้ พร้อมสำรวจ codebase เบื้องหลังเพื่อเก็บ context และภาษา domain ใช้เมื่อผู้ใช้อยากรายงานบั๊ก ทำ QA เปิด issue แบบคุยกัน หรือพูดถึง "QA session"

QA Session

รัน QA session แบบ interactive ผู้ใช้เล่าปัญหาที่เจอ คุณช่วยถามให้ชัด สำรวจ codebase เพื่อเก็บ context แล้วเปิด GitHub issue ที่คงทน เน้นมุมมองผู้ใช้ และใช้ภาษา domain ของโปรเจกต์

สำหรับแต่ละ issue ที่ผู้ใช้ยกขึ้นมา

1. ฟังก่อน แล้วถามให้ชัดแบบพอดี ๆ

ให้ผู้ใช้เล่าปัญหาด้วยคำพูดของเขาเอง ถามคำถามสั้น ๆ ไม่เกิน 2-3 ข้อ โฟกัสที่:

• เขาคาดหวังอะไร vs เกิดอะไรขึ้นจริง
• ขั้นตอน reproduce (ถ้ายังไม่ชัด)
• เกิดทุกครั้งหรือเป็น ๆ หาย ๆ

อย่าสัมภาษณ์ยืดเยื้อ ถ้าคำอธิบายชัดพอจะเปิด issue ได้แล้ว ไปต่อเลย

2. สำรวจ codebase เบื้องหลัง

ระหว่างคุยกับผู้ใช้ ให้ยิง Agent (subagent_type=Explore) ทำงานเบื้องหลังเพื่อทำความเข้าใจบริเวณที่เกี่ยวข้อง เป้าหมายไม่ใช่การหาวิธีแก้ — แต่เพื่อ:

• เรียนรู้ภาษา domain ที่ใช้ในบริเวณนั้น (เช็ก UBIQUITOUS_LANGUAGE.md)
• เข้าใจว่า feature นั้นควรทำอะไร
• ระบุขอบเขตพฤติกรรมฝั่งที่ผู้ใช้มองเห็น

context นี้ช่วยให้เขียน issue ได้ดีขึ้น — แต่ตัว issue เองต้องไม่อ้างถึงไฟล์ เลขบรรทัด หรือรายละเอียด implementation ภายใน

3. ประเมิน scope: issue เดียวหรือต้องแตกย่อย?

ก่อนเปิด issue ตัดสินใจว่านี่คือ issue เดียว หรือควร แตกย่อย เป็นหลาย issue

แตกย่อยเมื่อ:

• การแก้กินพื้นที่หลายบริเวณที่เป็นอิสระต่อกัน (เช่น "validation ของ form ผิด แล้วก็ไม่มี success message แล้วก็ redirect พัง")
• มีประเด็นที่แยกจากกันชัดเจนจนคนละคนหยิบไปทำขนานกันได้
• ผู้ใช้เล่าอะไรที่มี failure mode หรืออาการหลายแบบที่แยกจากกัน

คงเป็น issue เดียวเมื่อ:

• เป็นพฤติกรรมเดียวที่ผิดในที่เดียว
• อาการทั้งหมดมาจากพฤติกรรมต้นตอเดียวกัน

4. เปิด GitHub issue

สร้าง issue ด้วย gh issue create ไม่ต้องให้ผู้ใช้ review ก่อน — เปิดเลยแล้วแชร์ URL

issue ต้อง คงทน — อ่านแล้วยังเข้าใจได้แม้ผ่าน refactor ใหญ่ ๆ เขียนจากมุมมองของผู้ใช้

สำหรับ issue เดียว

ใช้ template นี้:

## What happened

[Describe the actual behavior the user experienced, in plain language]

## What I expected

[Describe the expected behavior]

## Steps to reproduce

1. [Concrete, numbered steps a developer can follow]
2. [Use domain terms from the codebase, not internal module names]
3. [Include relevant inputs, flags, or configuration]

## Additional context

[Any extra observations from the user or from codebase exploration that help frame the issue — e.g. "this only happens when using the Docker layer, not the filesystem layer" — use domain language but don't cite files]

สำหรับการแตกย่อย (หลาย issue)

สร้าง issue ตามลำดับ dependency (ตัวที่ block คนอื่นก่อน) เพื่อให้อ้างเลข issue จริงได้

ใช้ template นี้กับ sub-issue แต่ละตัว:

## Parent issue

#<parent-issue-number> (if you created a tracking issue) or "Reported during QA session"

## What's wrong

[Describe this specific behavior problem — just this slice, not the whole report]

## What I expected

[Expected behavior for this specific slice]

## Steps to reproduce

1. [Steps specific to THIS issue]

## Blocked by

- #<issue-number> (if this issue can't be fixed until another is resolved)

Or "None — can start immediately" if no blockers.

## Additional context

[Any extra observations relevant to this slice]

เวลาแตกย่อย:

• เลือก issue บาง ๆ หลายอันดีกว่า issue หนา ๆ ไม่กี่อัน — แต่ละอันต้องแก้และตรวจได้อย่างอิสระ
• ระบุความสัมพันธ์แบบ block กันตามจริง — ถ้า issue B test ไม่ได้จริง ๆ จนกว่า issue A จะถูกแก้ ก็บอกไปตรง ๆ ถ้าเป็นอิสระต่อกัน ให้ระบุทั้งคู่ว่า "None — can start immediately"
• สร้าง issue ตามลำดับ dependency เพื่อให้อ้างเลข issue จริงในช่อง "Blocked by" ได้
• เน้นให้ขนานกันได้มากที่สุด — เป้าหมายคือให้หลายคน (หรือหลาย agent) หยิบคนละ issue ไปทำพร้อมกันได้

กติกาสำหรับเนื้อหา issue ทุกอัน

• ห้ามใส่ file path หรือเลขบรรทัด — พวกนี้ล้าสมัยเร็ว
• ใช้ภาษา domain ของโปรเจกต์ (เช็ก UBIQUITOUS_LANGUAGE.md ถ้ามี)
• อธิบายพฤติกรรม ไม่ใช่ code — "sync service apply patch ไม่สำเร็จ" ไม่ใช่ "applyPatch() throws on line 42"
• ขั้นตอน reproduce เป็นสิ่งบังคับ — ถ้าหาไม่ได้ ให้ถามผู้ใช้
• กระชับเข้าไว้ — dev ควรอ่าน issue จบได้ใน 30 วินาที

หลังเปิด issue เสร็จ ให้พิมพ์ URL ของ issue ทั้งหมด (พร้อมสรุปความสัมพันธ์ว่าอันไหน block อันไหน) แล้วถามว่า: "issue ถัดไป หรือพอแค่นี้?"

5. คุยต่อจนจบ session

ทำต่อไปเรื่อย ๆ จนผู้ใช้บอกว่าพอ issue แต่ละอันเป็นอิสระต่อกัน — อย่ารวบไปทำเป็น batch