to-spec

Files (1)

• SKILL.md

SKILL.md (first lines)

skill นี้เอา context ของบทสนทนาปัจจุบันและความเข้าใจใน codebase มาผลิตเป็น spec (บางคนอาจรู้จักเอกสารแบบนี้ในชื่อ PRD) ห้ามสัมภาษณ์ user — แค่สังเคราะห์จากสิ่งที่รู้อยู่แล้ว

ข้อมูล issue tracker และชุดคำศัพท์ของ triage label ควรถูกเตรียมมาให้แล้ว — ถ้ายังไม่มีให้รัน `/setup-matt-pocock-skills`

## ขั้นตอน

1. สำรวจ repo เพื่อทำความเข้าใจสถานะปัจจุบันของ codebase ถ้ายังไม่ได้ทำ ใช้คำศัพท์จาก domain glossary ของโปรเจกต์ให้สม่ำเสมอตลอดทั้ง spec และเคารพ ADR ที่มีอยู่ในบริเวณของ codebase ที่กำลังแตะ

2. ร่างว่าจะ test feature นี้ที่ seam (จุดต่อสาธารณะที่เราใช้ test พฤติกรรม) ไหนบ้าง ควรเลือกใช้ seam ที่มีอยู่แล้วก่อนสร้างใหม่ ใช้ seam ที่อยู่สูงที่สุดเท่าที่เป็นไปได้ ถ้าจำเป็นต้องมี seam ใหม่ ให้เสนอไว้ที่จุดสูงสุดเท่าที่ทำได้ ยิ่งทั้ง codebase มี seam น้อยยิ่งดี — จำนวนในอุดมคติคือหนึ่งเดียว

เช็คกับ user ว่า seam เหล่านี้ตรงกับที่เขาคาดหวังไว้

3. เขียน spec ตาม template ด้านล่าง แล้ว publish ขึ้น issue tracker ของโปรเจกต์ ติด triage label `ready-for-agent` — ไม่ต้อง triage เพิ่มอีก

<spec-template>

## โจทย์ปัญหา

ปัญหาที่ user กำลังเจอ เล่าจากมุมมองของ user

## แนวทางแก้

วิธีแก้ปัญหา จากมุมมองของ user

## User Stories

รายการ user story แบบมีเลขกำกับ ยาว ๆ แต่ละ user story ต้องอยู่ในรูปแบบ:

1. ในฐานะ <actor> ฉันต้องการ <feature> เพื่อ <benefit>

<user-story-example>
1. ในฐานะลูกค้าธนาคารบนมือถือ ฉันต้องการเห็นยอดเงินในบัญชีของฉัน เพื่อให้ตัดสินใจเรื่องการใช้จ่ายได้อย่างมีข้อมูลมากขึ้น
</user-story-example>

รายการ user story นี้ต้องละเอียดครอบคลุมสุด ๆ และแตะทุกแง่มุมของ feature

## ข้อตัดสินใจด้าน implementation

รายการการตัดสินใจด้าน implementation ที่เกิดขึ้น ซึ่งอาจรวมถึง:

- module ที่จะสร้าง/แก้ไข
- interface ของ module เหล่านั้นที่จะถูกแก้ไข
- ข้อชี้แจงเชิงเทคนิคจาก developer
- การตัดสินใจเชิงสถาปัตยกรรม
- การเปลี่ยน schema
- API contract
- interaction เฉพาะจุด

ห้ามใส่ file path หรือ code snippet แบบเจาะจง เพราะพวกมันอาจล้าสมัยเร็วมาก

ข้อยกเว้น: ถ้า prototype ให้ snippet ที่บันทึกการตัดสินใจได้แม่นยำกว่าคำบรรยาย (state machine, reducer, schema, รูปร่างของ type) ให้แทรกมันไว้ในข้อตัดสินใจที่เกี่ยวข้อง พร้อมโน้ตสั้น ๆ ว่ามาจาก prototype ตัดให้เหลือเฉพาะส่วนที่อัดแน่นด้วยการตัดสินใจ — ไม่ใช่ demo ที่รันได้ เอาแค่ส่วนสำคัญ

## ข้อตัดสินใจด้านการ test

รายการการตัดสินใจด้านการ test ที่เกิดขึ้น ให้ใส่:

- คำอธิบายว่า test ที่ดีเป็นอย่างไร (test เฉพาะพฤติกรรมภายนอก ไม่ใช่รายละเอียดของ implementation)
- module ไหนบ้างที่จะถูก test
- ตัวอย่างที่มีอยู่ก่อนแล้วสำหรับ test พวกนี้ (เช่น test แนวเดียวกันที่มีอยู่ใน codebase)

## นอกขอบเขต

คำอธิบายสิ่งที่อยู่นอกขอบเขตของ spec นี้

## โน้ตเพิ่มเติม

โน้ตอื่น ๆ เกี่ยวกับ feature นี้

</spec-template>

From Boom-Vitt/skills-thai, MIT.

More from Boom-Vitt/skills-thai