วิธีตั้งค่า Spec Kit ใน Claude Code ในปี 2026: ใช้ข้อกำหนดแทนพรอมป์ต์

เกิดอะไรขึ้นกับ vibe coding ในเดือนพฤษภาคม 2026?#

ในช่วงปีถัดมา “vibe coding” กลายเป็นคำพ้องความหมายกับการทำงานแบบไร้โครงสร้างกับเอเจนต์ AI

หนึ่งปีต่อมา ในวันที่ 4 กุมภาพันธ์ 2026 เขาเผยแพร่เธรดย้อนทบทวน:

ในการบรรยายที่ Sequoia Ascent 2026 เขาอธิบายได้แม่นยำยิ่งขึ้นว่า “Vibe coding ยกระดับขั้นต่ำ—เพิ่มสิ่งที่ทุกคนทำได้ในงานซอฟต์แวร์ ส่วน agentic engineering รักษาระดับสูงสุด—มาตรฐานคุณภาพของการพัฒนาซอฟต์แวร์ระดับมืออาชีพ” บนเวทีเดียวกัน เขากล่าวประโยคที่กลายเป็นคำติดปากในอุตสาหกรรมว่า “คุณจะสร้างช่องโหว่เพราะ vibe coding ไม่ได้ คุณยังคงรับผิดชอบต่อซอฟต์แวร์ของคุณเหมือนเดิม”

สองสิ่งเกิดขึ้นพร้อมกัน ในเดือนกันยายน 2025 GitHub เผยแพร่เครื่องมือ Spec Kit—ซึ่งได้ 107,000 ดาวใน 8 เดือน ในเดือนกุมภาพันธ์ 2026 AWS เผยแพร่ กรณีศึกษาการค้นพบยาฉบับละเอียด โดยรายงานว่า “สร้างตรรกะทางธุรกิจจากข้อกำหนดได้ 95% และประหยัดเวลาได้ 80+ ชั่วโมง”

ภายในสิ้นเดือนพฤษภาคม 2026 วงการข้อมูลภาษาอังกฤษเริ่มเห็นพ้องกันว่า vibe coding ในฐานะวิธีทำงานเป็นระดับเริ่มต้น ขั้นถัดไปคือ Spec-Driven Development คู่มือนี้อธิบายวิธีติดตั้งและนำแนวทางนี้ไปใช้

Spec Kit และ Spec-Driven Development คืออะไร?#

แนวคิดหลักของวิธีการนี้สรุปได้ในประโยคเดียวจากเอกสารทางการของ GitHub:

ในทางปฏิบัติ กระบวนการนี้มี 4 ขั้นตอน (Spec Kit เพิ่มอีกหนึ่งขั้นตอน เป็นขั้นศูนย์—constitution ซึ่งจะอธิบายด้านล่าง):

1. Specify - เขียนข้อกำหนดว่าต้องการอะไรด้วยภาษาธรรมชาติ ว่าจะทำอะไรและทำไปทำไม ไม่ใช่ทำอย่างไร
2. Plan - เอเจนต์นำข้อกำหนดไปจัดทำแผนทางเทคนิค: จะใช้เทคโนโลยีใด สถาปัตยกรรมเป็นอย่างไร และมีองค์ประกอบใดบ้าง
3. Tasks - เอเจนต์แบ่งแผนออกเป็นงานเฉพาะที่ตรวจสอบได้ พร้อมระบุการพึ่งพากัน
4. Implement - เอเจนต์ (หรือเอเจนต์ย่อย) ทำงานตามรายการและเขียนโค้ด

หลัง Implement แล้ว Spec Kit เวอร์ชันปัจจุบันมีขั้นตอนตรวจสอบชื่อ Converge: เอเจนต์เปรียบเทียบโค้ดที่เสร็จแล้วกับข้อกำหนด แผน และงาน จากนั้นเพิ่มสิ่งที่ตกหล่นลงใน tasks.md ให้รัน Implement และ Converge วนซ้ำจนกว่า Converge จะตอบว่า “Converged”

แต่ละขั้นตอนเป็นไฟล์ Markdown แยกกันใน repo และเป็นคำสั่ง slash แยกกันใน Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement ส่วนคำสั่งตรวจสอบคือ /speckit-converge เอกสาร Spec Kit เขียนคำสั่งชุดเดียวกันโดยใช้จุด (/speckit.specify) แต่ใน Claude Code Spec Kit ติดตั้งคำสั่งเหล่านี้เป็น skills และเรียกใช้ด้วยขีดกลาง หากมีสิ่งใดผิดพลาดในขั้นใด ให้แก้ไขไฟล์ Markdown แล้วเรียกขั้นตอนถัดไปอีกครั้ง

Spec Kit เป็นการนำ SDD ไปใช้รูปแบบหนึ่ง ในเดือนพฤษภาคม 2026 มีการผสานรวมกับเอเจนต์ AI ต่าง ๆ มากกว่า 30 ราย ภายใน repo เดียวกัน Spec Kit ทำงานในลักษณะเดียวกันกับ Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose และเครื่องมืออื่น ๆ อีกนับสิบ

ดังนั้น หลังจากรันแล้ว repo ของคุณจะมีทั้งโค้ด ข้อกำหนด แผน และงานต่าง ๆ อีกหนึ่งเดือนต่อมา คุณกลับมาที่โปรเจกต์ อ่าน spec.md และเข้าใจได้ว่าทำอะไรไปและทำไม นี่ไม่ใช่ “vibe coding ที่ลืมไปว่ามีโค้ดอยู่” อีกต่อไป แต่มันคือหน่วยความจำสำหรับการทำงานของโปรเจกต์

ทำไมคนที่ใช้ vibe coding และไม่เขียนโค้ดจึงต้องใช้สิ่งนี้?#

Spec Kit แบ่งการวางแผนออกเป็นขั้นตอนต่างหากด้วยคำสั่ง slash 4 คำสั่ง ตรรกะคือแยก “คิดให้รอบคอบ” ออกจาก “ลงมือทำ” เพื่อให้แต่ละขั้นเริ่มใน context window ที่สะอาด ไม่รกด้วยเนื้อหาจากขั้นก่อนหน้า

ประโยชน์ที่ชัดเจนสามข้อสำหรับคนที่ใช้ vibe coding:

• คาดการณ์ได้ เมื่อคุณบอกเอเจนต์ว่า “ทำฟอร์มลงทะเบียนพร้อมยืนยันอีเมล” เอเจนต์จะเดารายละเอียด 10 อย่างเอง—และเดาผิดจากสิ่งที่คุณคิดไว้ 3 อย่าง แต่เมื่อมี spec.md ที่ประกอบด้วย User Stories, Acceptance Scenarios และเครื่องหมาย [NEEDS CLARIFICATION] ในทุกจุดที่ยังไม่แน่ชัด ก็ไม่มีอะไรให้เดา
• ความทรงจำของโปรเจกต์ อีกหนึ่งเดือนต่อมา คุณจะจำไม่ได้ว่าคุยอะไรกับเอเจนต์ในแชต แต่ spec.md, plan.md และ tasks.md อยู่ใน repo ในโฟลเดอร์ specs/###-feature/ ข้าง ๆ โค้ด ไฟล์เหล่านี้บอกทั้งสิ่งที่ทำและเหตุผล
• รองรับงานขนาดใหญ่ สำหรับฟีเจอร์ที่เกี่ยวข้องกับ 1-2 ไฟล์ ความแตกต่างแทบสังเกตไม่ออก แต่สำหรับฟีเจอร์ที่มี 20 ไฟล์และเอนทิตีข้อมูล 5 รายการ ความแตกต่างคือระหว่าง “เขียนใหม่ทั้งหมดหลังผ่านไป 4 ชั่วโมง” กับ “ทุกอย่างเข้ามาอยู่ใน main branch หลังผ่านไป 4 ชั่วโมง” AWS Kiro แสดงให้เห็นการทำงานอัตโนมัติ 95% ของตรรกะทางธุรกิจจากข้อกำหนดในโปรเจกต์ TargetID

ภาพลวงตาหลักของ vibe coding คือดูเหมือนจะเร็วกว่าในตอนเริ่มต้น ผ่านไปครึ่งชั่วโมงก็มีต้นแบบแล้ว แต่เมื่อครบหนึ่งสัปดาห์ ต้นแบบก็พัง และการทิ้งแล้วเริ่มใหม่ง่ายกว่า Spec-Driven Development ใช้เวลาตอนเริ่มต้นนานขึ้นเล็กน้อย (หนึ่งชั่วโมงแทนครึ่งชั่วโมง) แต่หนึ่งสัปดาห์ต่อมา คุณยังทำงานอยู่ใน repo เดิม

วิธีติดตั้ง Spec Kit ใน Claude Code (4 ขั้นตอน)#

ขั้นตอนที่ 1. ติดตั้ง uv ทำเพียงครั้งเดียว แล้วจะอยู่ในระบบของคุณต่อไป

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

ตรวจสอบว่า uv ติดตั้งแล้ว:

uv --version

ขั้นตอนที่ 2. ติดตั้ง Spec Kit ใช้คำสั่งเดียว:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

ตรวจสอบ:

specify --version

ขั้นตอนที่ 3. เริ่มต้น repo ไปยังโฟลเดอร์โปรเจกต์ (หรือสร้างโฟลเดอร์ใหม่) แล้วรัน:

specify init --here --integration claude

แฟล็ก --integration claude เลือก Claude Code โดยตรง หากไม่ใส่ Spec Kit จะขอให้คุณเลือกเอเจนต์จากรายการแบบโต้ตอบ และอาจถามประเภทสคริปต์ด้วย (สำหรับ macOS และ Linux ให้คงเป็น sh) หากโฟลเดอร์ไม่ว่าง Spec Kit จะเตือนว่าจะรวมไฟล์เข้ากับไฟล์ที่มีอยู่ ให้ commit งานของคุณก่อน แล้วจึงรันคำสั่งอีกครั้งพร้อมแฟล็ก --force

หลังจากนั้น ไฟล์ต่อไปนี้จะปรากฏใน repo:

.specify/
  memory/
    constitution.md        # กฎของโปรเจกต์ เติมข้อมูลด้วย /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

ขั้นตอนที่ 4. เปิด Claude Code และตรวจสอบคำสั่ง slash รันคำสั่งนี้ในโฟลเดอร์เดิม:

claude

ในเซสชัน ให้พิมพ์ /speckit—คำสั่ง speckit-* ควรปรากฏในรายการแนะนำ หากไม่ปรากฏ ให้เริ่ม Claude Code ใหม่เพื่อให้อ่าน .claude/skills/ อีกครั้ง หากมี CLAUDE.md ที่ root ของโปรเจกต์อยู่แล้ว Spec Kit จะปล่อยไว้ตามเดิม โดยทำงานควบคู่กันผ่าน .specify/memory/constitution.md

Spec Kit ใช้งานได้โดยไม่ต้องมี Claude Code (รองรับเอเจนต์ 30+ ราย) แต่คู่มือนี้อธิบายการตั้งค่าโดยเฉพาะสำหรับ Claude หากต้องการติดตั้งเครื่องมือสองอย่างทันที ดูคู่มือแยกเรื่อง การตั้งค่า CLAUDE.md และ Plan Mode ใน Claude Code

Spec Kit เป็นองค์ประกอบแรกของ “สัญญาจ้างงานเอเจนต์” การตั้งค่าครบชุดประกอบด้วยทั้งสามส่วน: โคลน AI (วิธีการของคุณในรูปแบบ Skills และเอเจนต์ย่อย), Second Brain (โครงสร้าง business/ ที่เอเจนต์กลับไปหาในแต่ละครั้ง) และวิศวกรรมบริบท (Spec Kit, Plan Mode, /compact) นี่คือเสาหลักสามต้นที่ AI จะเกิดภาพหลอนหากขาดไป

วิธีเขียนข้อกำหนดแรกของคุณ (Specify)#

ใน Claude Code ให้พิมพ์:

/speckit-specify

จากนั้นเอเจนต์จะถามให้คุณอธิบายฟีเจอร์ ในขั้นนี้ให้ใช้ภาษาธรรมดา ไม่ต้องใช้ศัพท์เทคนิค:

ฉันต้องการฟอร์มลงทะเบียนในแอปของฉัน ผู้ใช้กรอกอีเมล
และรหัสผ่าน ได้รับอีเมลยืนยัน และหลังจากยืนยันแล้ว
จะไปยังแดชบอร์ด การยืนยันหมดอายุเมื่อครบ 48 ชั่วโมง หาก
ยังไม่ยืนยันอีเมล ให้ลบบัญชีภายใน 5 นาทีหลังเส้นตายนั้น
ห้ามลบบัญชีที่ยืนยันแล้ว

ในตัวอย่างนี้ชี้แจงช่วงยอมล่าช้าลบเป็น 5 นาทีหลังครบ 48 ชั่วโมง ผลิตภัณฑ์จริงต้องยืนยันช่วงนี้ก่อน Plan หากต้องตรง 48 ชั่วโมงพอดี ต้องออกแบบและทดสอบให้บังคับข้อกำหนดที่เข้มกว่านั้น เอเจนต์จะจัดทำ specs/001-registration/spec.md เปิดแล้วจะเห็นโครงสร้างประมาณนี้:

# ข้อกำหนดฟีเจอร์: การลงทะเบียนผู้ใช้

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "ฉันต้องการฟอร์มลงทะเบียน..."

## สถานการณ์ผู้ใช้และการทดสอบ *(ต้องมี)*

### เรื่องราวหลักของผู้ใช้
ในฐานะผู้ใช้ใหม่ ฉันต้องการลงทะเบียนบัญชีพร้อมการยืนยันอีเมล
เพื่อให้เข้าถึงแดชบอร์ดด้วยตัวตนที่ผ่านการยืนยันแล้วได้

### สถานการณ์การยอมรับ
1. **Given** ฉันอยู่บนหน้าลงทะเบียน
   **When** ฉันส่งอีเมลและรหัสผ่านที่ถูกต้อง
   **Then** ฉันได้รับอีเมลยืนยันภายใน 1 นาที
2. **Given** ฉันคลิกลิงก์ยืนยันภายใน 48 ชั่วโมง
   **When** ฉันไปถึงแดชบอร์ด
   **Then** ฉันเห็นว่าอีเมลได้รับการยืนยันแล้วในโปรไฟล์
3. **Given** ฉันยังไม่ยืนยันเมื่อครบเส้นตาย 48 ชั่วโมง
   **When** cleanup รันภายใน 5 นาทีถัดไป
   **Then** บัญชีถูกลบและอีเมลใช้ลงทะเบียนใหม่ได้
4. **Given** บัญชียังไม่ครบ 48 ชั่วโมงหรือยืนยันแล้ว
   **When** cleanup รัน
   **Then** บัญชีไม่ถูกลบ

## ข้อกำหนด *(ต้องมี)*

### ข้อกำหนดเชิงฟังก์ชัน
- **FR-001**: ระบบ MUST รับการลงทะเบียนด้วย [NEEDS CLARIFICATION:
  อีเมล/รหัสผ่านเท่านั้น หรือมี SSO/OAuth ด้วย?]
- **FR-002**: ระบบ MUST ส่งอีเมลยืนยันภายใน 60 วินาที
- **FR-003**: การยืนยัน MUST หมดอายุที่ 48 ชั่วโมง ระบบ MUST
  ลบบัญชียังไม่ยืนยันภายในไม่เกิน 5 นาทีหลังเส้นตาย และ
  MUST NOT ลบบัญชีที่ยืนยันแล้ว
- **FR-004**: ระบบ MUST บันทึกความพยายามลงทะเบียนทั้งหมดเป็นเวลา [NEEDS
  CLARIFICATION: เราจะเก็บ log นานเท่าไร - 30 วัน, 90 วัน, ตลอดไป?]

### เอนทิตีหลัก
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## เกณฑ์ความสำเร็จ *(ต้องมี)*
- **SC-001**: ส่งอีเมลยืนยันได้ภายใน 60 วินาที (p95) อย่างน้อย 95%
- **SC-002**: การลบบัญชีที่ยืนยันแล้วโดยผิดพลาด 0 ครั้ง
- **SC-004**: ไม่ลบก่อน 48 ชั่วโมง ทุกบัญชียังไม่ยืนยันที่เข้าเกณฑ์
  ถูกลบเมื่ออายุไม่เกิน 48 ชั่วโมง 5 นาทีภายใต้โหลดที่ทดสอบ
- **SC-003**: อัตราการลงทะเบียนสำเร็จ > 60% (ตั้งแต่เปิดฟอร์มจนถึงแดชบอร์ด)

โปรดสังเกตเครื่องหมาย [NEEDS CLARIFICATION: ...] Spec Kit ใส่เครื่องหมายเหล่านี้โดยตั้งใจในทุกจุดที่เอเจนต์ไม่ได้รับคำตอบที่ชัดเจนจากข้อความของคุณ ก่อนจะไปยังขั้นตอน Plan คุณต้องตอบคำถามเหล่านี้ใน spec.md ด้วยตนเอง หรือรัน /speckit-clarify แล้วเอเจนต์จะไล่ตรวจประเด็นที่ยังไม่ชัดเจนและถามคุณในบทสนทนา

ใน Spec Kit คำสั่ง /speckit-clarify ที่มีมาให้ใช้แทนคำพูดว่า “ถามคำถามผม” ผลลัพธ์เหมือนกัน: อย่าไปต่อยัง Plan จนกว่าเครื่องหมาย [NEEDS CLARIFICATION] จะหมดไปจาก spec.md

ไม่ควรใส่เทคโนโลยีลงใน spec.md ห้ามกล่าวถึง React, Postgres, Prisma หรือ Redis ข้อกำหนดอธิบายว่าระบบทำอะไรจากมุมมองของผู้ใช้และธุรกิจ ส่วนเทคโนโลยีที่จะใช้จะอยู่ในขั้นตอนถัดไป

Claude ทำอะไรในขั้น Plan?#

เมื่อ spec.md พร้อมแล้ว ให้รัน:

/speckit-plan

คุณจะส่งคำใบ้เกี่ยวกับเทคโนโลยีไปในคำสั่งโดยตรงก็ได้:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude อ่านข้อมูลจากสามแหล่ง: spec.md, CLAUDE.md (หรือ memory/constitution.md) และโค้ดที่มีอยู่ใน repo ผลลัพธ์คือ plan.md ที่มีโครงสร้างประมาณนี้:

# แผนการนำไปใช้: การลงทะเบียนผู้ใช้

## บริบททางเทคนิค
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## การตัดสินใจด้านสถาปัตยกรรม

### 1. การจัดเก็บโทเคน
จัดเก็บโทเคนใน DB (ตาราง ConfirmationToken) ไม่ใช่ใน JWT
เหตุผล: ต้องเพิกถอนโทเคนฝั่งเซิร์ฟเวอร์ได้เมื่อมีการลงทะเบียนอีเมลใหม่

### 2. การส่งอีเมล
ส่งแบบอะซิงโครนัสผ่าน cron `/api/cron/send-confirmation` ซึ่งทำงานทันที
หลังลงทะเบียน Resend จัดการการลองใหม่

### 3. cron ลบอัตโนมัติ
รัน `/api/cron/cleanup-unconfirmed` ทุกนาที ลบเฉพาะแถวที่
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
ตัวอย่างที่ชี้แจงแล้วอนุญาตให้ลบล่าช้าสูงสุด 5 นาที
ตรวจ scheduler lag กับเวลาจบรันเทียบเพดานนี้ หากเกินต้องรายงาน
ว่าล้มเหลว ไม่ใช่ว่า cleanup รายวันสำเร็จ

## โมเดลข้อมูล
ดู data-model.md

## สัญญา API
ดู contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## ระยะการนำไปใช้
1. การย้ายฐานข้อมูล (สคีมา Prisma + ไฟล์ migration)
2. เส้นทาง API (3 endpoints)
3. UI: ฟอร์มลงทะเบียน + หน้ายืนยันสำเร็จ
4. งาน cron (ส่ง + ล้างข้อมูล)
5. เทมเพลตอีเมล
6. การทดสอบ integration

data-model.md จะอธิบายเอนทิตีและความสัมพันธ์ระหว่างกัน ส่วน contracts/ จะมีโครงร่างสัญญา API (อาจเป็น OpenAPI YAML หรือชนิด request/response ของ TypeScript) นี่ไม่ใช่โค้ด แต่เป็นสิ่งที่ตั้งใจให้ Claude แปลงเป็น route จริงในภายหลัง

ข้อดีหลักของขั้น Plan คือการมีบริบทที่สะอาด Claude ไม่พยายามจำทั้งข้อกำหนดและการนำไปใช้พร้อมกัน แต่มันจะคิดให้รอบคอบก่อน บันทึกการตัดสินใจลงในไฟล์ แล้วจึงไปต่อ

ถัดไปคือคำสั่ง /speckit-analyze ซึ่งเป็นตัวเลือก โดยจะรันหลังขั้น Tasks และก่อน Implement: คำสั่งนี้ตรวจชุด spec.md + plan.md + tasks.md เพื่อหาความขัดแย้ง และตรวจว่าข้อกำหนดทุกข้อมีแผนและงานรองรับหรือไม่ คำสั่งนี้ไม่แก้ไขไฟล์ แต่สร้างรายงานเท่านั้น โดยพื้นฐานแล้วนี่คือการตรวจความสมเหตุสมผลอย่างเป็นทางการก่อนเริ่มลงมือ

วิธีแบ่งงานเป็นงานย่อย (Tasks)#

เมื่อมี spec.md และ plan.md แล้ว ให้รัน:

/speckit-tasks

Claude จะขยายแผนเป็น tasks.md:

# งาน: การลงทะเบียนผู้ใช้

## ระยะที่ 1: ฐานข้อมูล (ไม่มีการพึ่งพา)
- [ ] T-001: เพิ่มโมเดล User ใน prisma/schema.prisma (ทำงานพร้อมกันได้อย่างปลอดภัย)
- [ ] T-002: เพิ่มโมเดล ConfirmationToken ใน prisma/schema.prisma (หลัง T-001)
- [ ] T-003: สร้าง migration `add-user-registration` (หลัง T-002)

## ระยะที่ 2: สัญญา API (ไม่มีการพึ่งพา)
- [ ] T-004: สร้าง Zod schemas ใน shared/validation/auth.ts
- [ ] T-005: กำหนด TypeScript types ใน shared/types/auth.ts (หลัง T-004)

## ระยะที่ 3: Routes (ขึ้นกับระยะ 1+2)
- [ ] T-006: ทำ POST /api/auth/register
- [ ] T-007: ทำ POST /api/auth/confirm
- [ ] T-008: ทำ GET /api/auth/resend-confirmation

## ระยะที่ 4: UI (ทำพร้อมกับระยะ 3 ได้)
- [ ] T-009: สร้างหน้า /register พร้อมฟอร์ม
- [ ] T-010: สร้างหน้า /register/confirm/[token]
- [ ] T-011: สร้างหน้า /register/success

## ระยะที่ 5: cron + integration (ขึ้นกับระยะ 3+4)
- [ ] T-012: cron /api/cron/send-confirmation
- [ ] T-013: cron /api/cron/cleanup-unconfirmed
- [ ] T-014: เทมเพลตอีเมล registration-confirmation.tsx
- [ ] T-015: การทดสอบ integration (Playwright) รวม cleanup ก่อนครบ
  48h พอดีที่ 48h ลบภายใน 48h 5m งานล่าช้าที่ต้องล้มเหลว
  และการป้องกันบัญชีที่ยืนยันแล้ว

## หมายเหตุ
- T-001, T-004, T-009-T-011 ทำงานพร้อมกันได้อย่างปลอดภัย (ไฟล์คนละไฟล์)
- T-002 ขัดแย้งกับ T-001 (ไฟล์เดียวกัน: schema.prisma) - ให้ทำตามลำดับ
- T-006 ต้องใช้ T-003 (นำ migration ไปใช้แล้ว) และ T-005 (types)

สังเกตเครื่องหมาย parallel-safe และ after T-NNN นี่คือกราฟการพึ่งพาที่ช่วยให้รันหลายขั้นตอนไปพร้อมกันได้ในภายหลัง แนวทางเร่งงานทั้งหมดของ Spec Kit อาศัยกลไกนี้: งานบางอย่างส่งให้ Claude Code ห้าเซสชันที่ต่างกันทำพร้อมกันได้ แต่งานอื่นต้องทำตามลำดับอย่างเคร่งครัด

Spec Kit ทำสิ่งนี้ให้อัตโนมัติด้วยคำสั่งเดียว ตั้งแต่เริ่มใช้งาน

คำสั่ง /speckit-taskstoissues ซึ่งเป็นตัวเลือก จะรับ tasks.md แล้วสร้าง GitHub Issues จากรายการ แต่ละ issue มีลิงก์กลับไปยัง spec.md เหมาะสำหรับทำงานเป็นทีมหรือติดตามความคืบหน้าผ่าน GitHub Projects

วิธีนำไปใช้ด้วยเอเจนต์ย่อย (Implement)#

/speckit-implement

Claude เริ่มจากงานแรกใน tasks.md แต่ละงานผ่านวงจรสั้น ๆ: อ่านไฟล์ที่เกี่ยวข้อง เขียน diff รันการทดสอบ แล้วทำเครื่องหมาย [x] ระบบจะเรียกเอเจนต์ย่อยโดยอัตโนมัติเมื่อจำเป็น: ตัวหนึ่งแยกสำหรับตรวจโค้ด อีกตัวรัน linter และอีกตัวตรวจ regression

และกล่าวถึงกฎแยกต่างหากว่า:

ใน Spec Kit วงจรนี้เป็นระบบ คุณมี spec.md เป็นแหล่งข้อมูลหลัก, plan.md สำหรับการตัดสินใจทางเทคนิค และ tasks.md เป็นเช็กลิสต์ หาก Claude ออกนอกเส้นทางในขั้นใด ให้กลับไปที่ข้อกำหนดแล้วบอกว่า “สิ่งนี้ไม่ตรงกับ FR-003 ทำใหม่” ไม่ต้องเขียนพรอมป์ต์ยาว ๆ ว่า “จำสิ่งที่เราคุยกัน...” เพราะประวัติทั้งหมดอยู่ในไฟล์

ถ้าคุณเชื่อมต่อ Dynamic Workflows ใน Opus 4.8 ก็สามารถให้ Spec Kit ทำงานอัตโนมัติเต็มรูปแบบได้: ใช้คำสั่ง /speckit-implement เพียงครั้งเดียว แล้ว Claude จะกระจายงานไปทำพร้อมกัน รวมผลลัพธ์ และตรวจสอบงาน ขีดจำกัดคือเอเจนต์ย่อยพร้อมกัน 1000 ตัว ฟีเจอร์ส่วนใหญ่ใช้ 10-30 ตัวก็เพียงพอ

เมื่อทำเครื่องหมาย [x] ครบทุกช่อง และการตรวจสอบในส่วนถัดไปตอบว่า “Converged” ให้ตรวจ PR (หรือชุด PR หากมีหลายงาน) แล้ว merge ชิ้นงาน—spec.md, plan.md, tasks.md—ยังคงอยู่ใน repo เป็นเอกสารประกอบฟีเจอร์ อีกหนึ่งปีต่อมา คุณจะไม่ต้องย้อนแกะตรรกะจากโค้ด

วิธีตรวจว่าเอเจนต์ไม่ได้พลาดอะไร (Converge)#

/speckit-converge

ก่อนอื่นเอเจนต์จะสรุปสิ่งที่พบพร้อมระดับความรุนแรง จากนั้นจะมีผลลัพธ์หนึ่งในสองแบบ “Converged” หมายความว่าไม่มีสิ่งตกหล่น tasks.md ไม่เปลี่ยนแปลงแม้แต่ไบต์เดียว และคุณไปตรวจสอบต่อได้ “Tasks appended” หมายความว่าพบสิ่งที่ตกหล่นและเพิ่มไว้ในส่วน Convergence ของ tasks.md พร้อมแจ้งจำนวนรายการ

Converge ไม่แก้ไขหรือลบโค้ด การเขียนเพียงอย่างเดียวคือเพิ่มงานใหม่ลงใน tasks.md ดังนั้นรันได้โดยไม่ต้องกังวล แต่ต้องรันหลังจาก /speckit-implement ทำงานผ่าน tasks.md ฉบับปัจจุบันแล้วเท่านั้น การตรวจแต่ละรอบจะพบสิ่งตกหล่นน้อยลง

Spec Kit แตกต่างจาก CLAUDE.md และ Plan Mode อย่างไร?#

เปรียบเทียบทั้งสองกับ Spec Kit ตามคุณลักษณะ 5 ข้อ:

ในคำศัพท์ของ Spec Kit สิ่งนี้คือ .specify/memory/constitution.md ระหว่างการเริ่มต้น Spec Kit จะใช้ CLAUDE.md ที่มีอยู่เป็นพื้นฐานของ constitution หรือสร้างไฟล์แยกไว้ข้าง ๆ ก็ได้ ปกติฉันคง CLAUDE.md ไว้เป็น “สัญญา” ระดับสากล (สแต็ก อภิธานศัพท์ โปรโตคอลการ deploy) และใช้ constitution ของ Spec Kit สำหรับกฎเฉพาะเวิร์กโฟลว์นี้ เช่น “ตรวจสอบฟอร์มทั้งหมดผ่าน Zod; ห้ามตรวจสอบด้วยตนเอง”

การเชื่อมต่อกับ Plan Mode ง่ายกว่า Plan Mode เป็นโหมด “วางแผนก่อนเขียนโค้ด” แบบรวดเร็วภายในเซสชันเดียว เหมาะกับการเปลี่ยนแปลงเล็ก ๆ (แก้บั๊ก ปรับโครงสร้างฟังก์ชัน) แต่สำหรับฟีเจอร์ใหญ่ Plan Mode ทำได้ไม่ดีเท่า เพราะ context window ของเซสชันเดียวเล็กเกินไปสำหรับแผนยาว 3000 บรรทัด—อย่างที่ฉันอธิบายตรง ๆ ในเซสชันสด:

Spec Kit เป็นเครื่องมือวิศวกรรมบริบทที่จับต้องได้ โดยย้าย “ผ้าปูโต๊ะของสถาปัตยกรรม” จากแชตไปไว้ในไฟล์ Spec.md อยู่ใน repo และ Claude ทุกเซสชันใหม่จะอ่านไฟล์นี้อีกครั้ง—คุณไม่ต้องพูดซ้ำ

การตั้งค่าสำหรับโปรเจกต์ขนาดใหญ่:

1. CLAUDE.md - สแต็ก อภิธานศัพท์ และสิ่งที่ห้ามทำ อยู่ที่ root
2. .specify/memory/constitution.md สำหรับ Spec Kit—กฎเฉพาะของเวิร์กโฟลว์นี้
3. specs/001-feature-A/spec.md, plan.md, tasks.md - ฟีเจอร์แรก
4. specs/002-feature-B/spec.md, plan.md, tasks.md - ฟีเจอร์ที่สอง
5. สำหรับงานประจำวัน ใช้ /speckit-implement (สำหรับงานที่เตรียมไว้แล้ว) หรือ /plan (ตรวจทานอย่างรวดเร็วก่อนเปลี่ยนแปลง)

กรณีใช้งานจริงใดบ้างที่ได้ผล?#

กรณีที่เจาะจง:

• AWS Kiro - เอเจนต์ค้นพบยา ในโพสต์บล็อก AWS Industries ลงวันที่ 18 กุมภาพันธ์ 2026 ทีมงานอธิบายโครงการ TargetID นักพัฒนาสามคน สามสัปดาห์ และเอเจนต์ค้นพบยา ตัวเลขในบทความ: Kiro สร้างโค้ดตรรกะทางธุรกิจมากกว่า 95% และประหยัดเวลาพัฒนาได้มากกว่า 80 ชั่วโมง นอกจากนี้ยังระบุว่า “เอกสาร README ที่ Kiro เขียนช่วยประหยัดเวลาได้ประมาณ 8 ชั่วโมง” และ “ลดรอบพรอมป์ต์แล้วแก้ซ้ำลง 40%”
• Rackspace Technology ในบล็อก AWS เดียวกัน Rackspace รายงานว่า “ทำงานที่ประเมินไว้ 52 สัปดาห์เสร็จในเวลาเพียง 3 สัปดาห์” และ “ประสิทธิภาพเพิ่มขึ้น 90%” นี่ไม่ใช่ฟีเจอร์ขนาดเล็กอีกต่อไป แต่เป็นโปรเจกต์ Enterprise เต็มรูปแบบ
• การเติบโตของ GitHub Spec Kit ณ วันที่ 7 พฤษภาคม 2026 repo มี 93,000 ดาว; ภายในวันที่ 31 พฤษภาคม มี 107,000 ดาว นั่นคือเพิ่มขึ้น +14,000 ดาวในสามสัปดาห์ อัตราการเติบโตนี้เป็นสัญญาณชัดเจนว่าแนวทางดังกล่าวกำลังมีส่วนแบ่งตลาดเพิ่มขึ้น

สำหรับผู้อ่าน นี่หมายความว่าแนวทางนี้ไม่ใช่แค่ทฤษฎี ทีมจริงจังนำไปใช้ในระบบ production แล้ว

เมื่อใดที่ Spec Kit ไม่เหมาะ?#

ไม่เหมาะ #1 - การแก้ไขเล็ก ๆ หากงานคือ “เปลี่ยนชื่อตัวแปร” “แก้คำพิมพ์ผิดในข้อความ” หรือ “เพิ่ม log” การผ่าน Specify → Plan → Tasks จะใช้เวลามากกว่าการแก้เอง สำหรับการแก้เล็ก ๆ Plan Mode หรือพรอมป์ต์ตรง ๆ ใน Claude Code เร็วกว่า

ไม่เหมาะ #2 - การทดลองแบบสด เมื่อคุณยังไม่รู้ว่าต้องการอะไร และต้อง “ลองเล่น” กับอินเทอร์เฟซหรือประกอบต้นแบบอย่างรวดเร็วเพื่อดูว่า “เข้าท่าหรือเปล่า” การเขียนข้อกำหนดก็ไม่มีประโยชน์ คุณค่าของงานอยู่ที่การด้นสดนั่นเอง ในระดับของการ “ลองเล่นกับไอเดีย” vibe คือสิ่งที่ใช้ได้ผล ไม่ใช่ข้อกำหนด

ไม่เหมาะ #3 - โค้ดเก่าที่มีสถานะซับซ้อน ความเป็นจริงเปลี่ยนแปลงเร็วกว่าข้อกำหนด ลองพิจารณาการเรียกเก็บเงินค่าสมาชิก: ทีมอธิบายรอบบิลและกฎภาษี จากนั้นหนึ่งสัปดาห์ต่อมา ฝ่ายการเงินขอเพิ่ม VAT สำหรับยุโรป—ข้อกำหนดก็ล้าสมัยก่อนปล่อยใช้งาน เมื่อกฎธุรกิจเปลี่ยนเร็ว การดูแลข้อกำหนดกลายเป็นภาระ

อีกความเสี่ยงหนึ่งคือความรู้สึกว่าควบคุมได้ทั้งที่ไม่จริง: โครงสร้างดูเรียบร้อย แต่เอเจนต์มักเพิกเฉยต่อคำสั่ง หรือกลับทำตามเทมเพลตอย่างตรงตัวเกินไป ผลที่ได้คือโค้ดที่ถูกต้องเชิงโครงสร้างแต่ไม่เหมาะกับ repo ของคุณโดยเฉพาะ—ข้อกำหนดไม่ได้รับประกันว่าเอเจนต์เข้าใจตามที่คุณตั้งใจ

นักวิเคราะห์ในอุตสาหกรรมเตือนถึง waterfall: การเขียนข้อกำหนดขนาดใหญ่ก่อนเริ่มเขียนโค้ดเป็นเส้นทางที่เคยทำให้อุตสาหกรรมล้มเหลวมาแล้วครั้งหนึ่ง ในยุคที่มีข้อกำหนดยาว 200 หน้า วิศวกรระมัดระวังแนวทางนี้เรื่อยมา และความระมัดระวังนั้นก็มีเหตุผล

ควรทำอย่างไร ฉันขอเสนอกฎง่าย ๆ: เปรียบเทียบขนาดฟีเจอร์กับเวลาที่ใช้เขียนข้อกำหนด หากใช้เวลาน้อยกว่า 2 ชั่วโมงในการทำฟีเจอร์ อย่าเขียน spec—Plan Mode เร็วกว่า หากฟีเจอร์ใช้เวลาหนึ่งสัปดาห์ ให้ใช้ Spec Kit อย่างแน่นอน เวลาที่ประหยัดได้จะชดเชยเวลาหนึ่งชั่วโมงที่ใช้เขียนข้อกำหนดได้ถึงห้าเท่า หากอยู่ระหว่าง 2 ชั่วโมงกับหนึ่งสัปดาห์ ให้ใช้วิจารณญาณของคุณ แม้โดยส่วนตัวฉันเขียน spec แม้แต่ฟีเจอร์ที่ใช้เวลาครึ่งวัน เพราะชิ้นงานใน repo มีค่ามากกว่าเวลาครึ่งชั่วโมงที่ประหยัดได้

ต่อไปทำอะไร: จะผสาน Spec Kit เข้ากับโปรเจกต์อย่างไร?#

แผนที่ทำได้จริงสำหรับ 7 วันข้างหน้า:

• วันที่ 1 ติดตั้ง uv และ Spec Kit (5-10 นาที) ตรวจสอบว่าคำสั่ง /speckit-* ปรากฏใน Claude Code แล้ว อย่าลองใช้กับโปรเจกต์เดิม—เริ่มจากโปรเจกต์ใหม่
• วันที่ 2 เลือกฟีเจอร์จริงที่คุณวางแผนจะสร้าง รัน /speckit-specify พร้อมคำอธิบายแบบอิสระ เปิด spec.md อ่าน แล้วตอบ [NEEDS CLARIFICATION] ให้ครบ อย่ารีบไป Plan
• วันที่ 3 รัน /speckit-plan พร้อมคำใบ้เกี่ยวกับสแต็กของคุณ อ่าน plan.md โดยเฉพาะส่วน Architecture Decisions หากมีอะไรไม่เหมาะ ให้แก้ไขด้วยตนเอง
• วันที่ 4-5 รัน /speckit-tasks แล้วรัน /speckit-analyze เพื่อตรวจชุด spec, plan และ tasks อีกครั้ง จากนั้นรัน /speckit-implement ดูว่า Claude ทำเครื่องหมาย [x] ใน tasks.md อย่างไร บางจุดอาจติดขัด—เป็นเรื่องปกติ กลับไปที่ spec.md ชี้แจงข้อกำหนด แล้วเริ่ม /speckit-implement ใหม่โดยระบุงานเฉพาะ เมื่อปิดงานครบแล้ว ให้รัน /speckit-converge และทำซ้ำขั้นตอน Implement กับ Converge จนกว่าจะได้คำตอบ “Converged”
• วันที่ 6-7 ตรวจ PR (หรือชุด PR) แล้ว merge อ่าน spec.md และ plan.md—นี่คือเอกสารฟีเจอร์ของคุณสำหรับปีที่จะมาถึง

สิ่งที่แนะนำให้อ่านควบคู่กัน:

• วิธีตั้งค่า CLAUDE.md ในปี 2026 - พื้นฐานสำหรับ constitution ของ Spec Kit
• Plan Mode ใน Claude Code - ทางเลือกด่วนสำหรับงานเล็ก ๆ
• วิศวกรรมบริบทในปี 2026 - เหตุผลที่ Spec Kit ใช้ได้ผล
• Skills, Subagents, MCP หรือ Plugins - สิ่งที่เพิ่มให้ Spec Kit เพื่อปรับเวิร์กโฟลว์ของคุณได้
• Dynamic Workflows ใน Claude Code - วิธีเปิดเอเจนต์ย่อยหลายตัวพร้อมกันในขั้น Implement

เวิร์กโฟลว์บริบทครบชุด: โคลน AI + Second Brain + วิศวกรรมบริบท

อ่านเนื้อหาเพิ่มเติมได้ที่ Ailoot.