#GitHub Spec Kit: การใช้งานในการสร้างระบบด้วย Spec-Driven Development

การใช้ AI Coding Agent เช่น GitHub Copilot, Claude Code, Codex CLI หรือ Gemini CLI ช่วยให้การพัฒนาซอฟต์แวร์เร็วขึ้นอย่างมาก แต่หากเริ่มต้นด้วย Prompt เพียงไม่กี่บรรทัด เช่น

ช่วยสร้างระบบ Task Management ให้หน่อย

AI อาจสร้าง Code ได้ทันที แต่ยังมีคำถามสำคัญอีกจำนวนมาก เช่น

  • ระบบมีผู้ใช้งานกี่ Role
  • ใครสามารถสร้างหรือแก้ไข Task
  • Task มีสถานะอะไรบ้าง
  • Validation Rule เป็นอย่างไร
  • Authentication ใช้วิธีใด
  • Architecture ของระบบเป็นแบบใด
  • Acceptance Criteria คืออะไร
  • Test Case ครอบคลุม Requirement หรือไม่
  • เมื่อพัฒนาเสร็จแล้วจะรู้ได้อย่างไรว่าครบตาม Requirement

GitHub Spec Kit ถูกสร้างขึ้นมาเพื่อจัดการปัญหาเหล่านี้ด้วยแนวคิด Spec-Driven Development (SDD)

แทนที่จะเริ่มจาก

Prompt
  ↓
Code

เราจะเปลี่ยนเป็น

Intent
  ↓
Specification
  ↓
Clarification
  ↓
Technical Plan
  ↓
Tasks
  ↓
Implementation
  ↓
Verification
  ↓
Convergence

แนวทางนี้ทำให้ AI Coding Agent ทำงานจาก Requirement และ Engineering Artifact ที่ตรวจสอบได้ ไม่ได้พึ่งเฉพาะ Context ชั่วคราวใน Chat

#1. GitHub Spec Kit คืออะไร

GitHub Spec Kit เป็น Open Source Toolkit จาก GitHub สำหรับสนับสนุนกระบวนการ Spec-Driven Development

หน้าที่หลักของ Spec Kit คือช่วยจัด Workflow ระหว่าง

Developer
Product Requirement
Architecture
AI Coding Agent
Source Code
Testing

ให้อยู่ในกระบวนการที่มีโครงสร้าง

Spec Kit ไม่ใช่ Web Framework และไม่ได้บังคับว่าเราต้องใช้ Programming Language หรือ Technology ใดเป็นพิเศษ

จึงสามารถใช้กับระบบได้หลายรูปแบบ เช่น

  • React
  • Next.js
  • Laravel
  • Spring Boot
  • ASP.NET Core
  • FastAPI
  • Go
  • Node.js
  • Microservices
  • Mobile Backend
  • AI Application
  • Enterprise Application

แนวคิดสำคัญคือ

Specification ต้องมาก่อน Implementation

#2. Spec-Driven Development คืออะไร

Spec-Driven Development หรือ SDD เป็นแนวทางที่ใช้ Specification เป็น Source of Truth

แทนที่จะเก็บ Requirement ไว้ใน Chat หรือ Prompt เพียงอย่างเดียว เราจะสร้าง Artifact เช่น

spec.md
plan.md
tasks.md

แล้วใช้ Artifact เหล่านี้เป็น Context หลักของการพัฒนา

ตัวอย่าง Flow

Business Requirement
        │
        ▼
     spec.md
        │
        ▼
     plan.md
        │
        ▼
     tasks.md
        │
        ▼
    Source Code
        │
        ▼
       Tests
        │
        ▼
   Convergence

ข้อดีคือ Developer สามารถตรวจสอบย้อนหลังได้ว่า

Requirement ใด
      ↓
ถูกออกแบบอย่างไร
      ↓
แตกเป็น Task อะไร
      ↓
ถูก Implement ที่ส่วนใด

#3. ปัญหาของ Prompt-Driven Development

หากใช้ AI เขียน Code ด้วย Prompt เป็นหลัก มักพบปัญหาต่อไปนี้

#3.1 Requirement Drift

เริ่มต้น Requirement แบบหนึ่ง แต่เมื่อสนทนากับ AI หลายรอบ Requirement อาจเปลี่ยนไปโดยไม่รู้ตัว

ตัวอย่าง

รอบแรก:
Task มี 3 Status

รอบต่อมา:
เพิ่ม Review

รอบถัดไป:
Agent Generate Code บางส่วนยังใช้ 3 Status

ถ้ามี spec.md เป็น Source of Truth ปัญหานี้จะลดลง

#3.2 AI รีบเขียน Code ก่อนเข้าใจ Requirement

ตัวอย่าง Prompt

สร้างระบบ Login

ยังมี Requirement ที่ไม่ได้ระบุอีกมาก เช่น

Login ด้วย Email หรือ Username?
Password Policy คืออะไร?
ต้อง Verify Email หรือไม่?
ใช้ Session หรือ JWT?
มี Refresh Token หรือไม่?
Account Lockout หรือไม่?
มี Role อะไรบ้าง?

Spec Kit จึงมีขั้นตอน Specify และ Clarify ก่อนเข้าสู่ Implementation

#3.3 Architecture ไม่สอดคล้องกัน

เมื่อใช้ AI Generate Code หลายรอบ อาจเกิด Pattern ที่ไม่เหมือนกัน

Controller A
   ↓
Service
   ↓
Repository

Controller B
   ↓
Database โดยตรง

Controller C
   ↓
ORM ใน Controller

Spec Kit จึงมี Constitution เพื่อกำหนดหลักการของ Project

#3.4 ไม่รู้ว่า Code ครบ Requirement หรือยัง

การที่ Build ผ่านหรือ Unit Test ผ่านไม่ได้หมายความว่าระบบครบทุก Requirement

Spec Kit จึงมีขั้นตอน Converge สำหรับตรวจ Implementation เทียบกับ

Specification
Technical Plan
Tasks

#4. Workflow หลักของ GitHub Spec Kit

Workflow สำหรับ Feature ขนาดเล็กสามารถใช้

Specify
   ↓
Plan
   ↓
Tasks
   ↓
Implement
   ↓
Converge

สำหรับ Production Feature ควรเพิ่ม Quality Gate

Constitution
      ↓
Specify
      ↓
Clarify
      ↓
Plan
      ↓
Checklist
      ↓
Tasks
      ↓
Analyze
      ↓
Implement
      ↓
Converge

หน้าที่ของแต่ละขั้นตอนคือ

ขั้นตอน หน้าที่
Constitution กำหนดหลักการและ Engineering Rules ของ Project
Specify ระบุว่าระบบต้องทำอะไรและทำไปเพื่ออะไร
Clarify ค้นหา Requirement ที่กำกวม
Plan กำหนด Architecture และ Technology
Checklist ตรวจคุณภาพและความครบถ้วนของ Requirement
Tasks แตก Plan เป็นงานที่ Implement ได้
Analyze ตรวจความสอดคล้องของ Spec, Plan และ Tasks
Implement ให้ Coding Agent ลงมือสร้างระบบ
Converge ตรวจว่า Code ครบตาม Artifact หรือไม่

#5. เตรียม Environment

เอกสารปัจจุบันของ Spec Kit รองรับ Python 3.11 ขึ้นไป

ตรวจสอบ Python

python --version

ตัวอย่าง

Python 3.12.7

เครื่องมือที่แนะนำสำหรับติดตั้ง Package คือ uv

#6. ติดตั้ง uv

#macOS

ใช้ Homebrew

brew install uv

ตรวจสอบ

uv --version

#Windows

ใช้ WinGet

winget install --id=astral-sh.uv -e

ตรวจสอบ

uv --version

#Linux/macOS ผ่าน Installer

สามารถใช้วิธีติดตั้งตามเอกสารของ uv

หลังติดตั้งให้ตรวจสอบ

uv --version

#7. ติดตั้ง GitHub Spec Kit

วิธีง่ายสำหรับติดตั้ง specify-cli

uv tool install specify-cli

ตรวจสอบ

specify version

อีกทางเลือกหนึ่งคือ

pipx install specify-cli

หรือ

pip install specify-cli

สำหรับ Team หรือ CI/CD ควรพิจารณา Pin Version ที่ผ่านการทดสอบแล้ว

ตัวอย่าง

uv tool install specify-cli==<VERSION>

หรือ Install จาก GitHub Release Tag ที่กำหนดแน่นอน

uv tool install specify-cli \
  --from git+https://github.com/github/spec-kit.git@vX.Y.Z

ข้อดีคือ Environment ของสมาชิกในทีมจะมี Version ที่สอดคล้องกัน

#8. สร้าง Project ใหม่

สมมติเราต้องการสร้างระบบ

task-management-system

และใช้ GitHub Copilot

specify init task-management-system --integration copilot

จากนั้น

cd task-management-system

ถ้าใช้ Claude

specify init task-management-system --integration claude

ถ้าใช้ Gemini

specify init task-management-system --integration gemini

Integration ที่รองรับสามารถตรวจสอบได้จาก

specify integration list

#9. Terminal Command กับ Agent Command ต่างกันอย่างไร

จุดนี้สำคัญมาก

คำสั่ง

specify init
specify version
specify integration list

คือ CLI Command ที่รันใน Terminal

แต่คำสั่งกระบวนการ เช่น

/speckit-specify
/speckit-plan
/speckit-tasks

ต้องเรียกจาก AI Coding Agent

ตัวอย่าง

Terminal
   │
   ├── specify init
   └── specify version

AI Coding Agent Chat
   │
   ├── /speckit-specify
   ├── /speckit-plan
   ├── /speckit-tasks
   └── /speckit-implement

รูปแบบ Command อาจแตกต่างตาม Integration

ตัวอย่าง

GitHub Copilot
/speckit-specify

Codex Skill
$speckit-specify

Reference notation
/speckit.specify

ดังนั้นควรใช้รูปแบบที่ Integration ของ Agent นั้นสร้างให้

#10. ขั้นตอนที่ 1: Constitution

Constitution คือชุดหลักการที่ Project ต้องปฏิบัติตาม

สามารถมองว่าเป็น

Engineering Constitution
Coding Principles
Architecture Rules
Testing Policy
Security Rules
Definition of Quality

ตัวอย่างสำหรับ Task Management System

/speckit-constitution

Project principles:

1. All user input must be validated.
2. Controllers must not contain business logic.
3. Business logic must be placed in service components.
4. Sensitive credentials must never be committed.
5. Authentication and authorization follow least privilege.
6. Database schema changes require migrations.
7. Every business-critical rule requires automated tests.
8. API responses must follow a consistent error format.
9. Every feature requires testable acceptance criteria.
10. Critical workflows require integration tests.

โดยทั่วไป Constitution เป็นกติกาที่ใช้ในระดับ Project และขั้นตอนอื่นต้องสอดคล้องกับหลักการนี้

#11. ขั้นตอนที่ 2: Specify

ขั้นตอนนี้ตอบคำถามว่า

ระบบต้องทำอะไร และทำไปเพื่ออะไร

ยังไม่ควรรีบกำหนด Technology Stack

ตัวอย่าง

/speckit-specify

สร้างระบบ Task Management สำหรับทีมพัฒนาซอฟต์แวร์

ผู้ใช้สามารถ:
- สร้าง Project
- เชิญสมาชิกเข้า Project
- สร้าง Task
- Assign Task
- กำหนด Priority
- กำหนด Due Date
- เปลี่ยนสถานะ Task
- Comment ใน Task
- ดู Activity History

Task มีสถานะ:
- TODO
- IN_PROGRESS
- REVIEW
- DONE

Project Owner สามารถจัดการสมาชิกได้

ระบบรองรับทีมขนาด 5-50 คน

ผลลัพธ์สำคัญจะถูกเก็บเป็น Specification เช่น

specs/
└── <feature>/
    └── spec.md

#12. Specification ที่ดีควรมีอะไร

Specification ที่ดีควรระบุ

Objective
User Stories
Functional Requirements
Acceptance Criteria
Edge Cases
Success Criteria
Constraints

ตัวอย่าง User Story

As a project member
I want to create a task
so that the team can track work.

Acceptance Criteria

Given a user is a project member
When the user creates a task with valid data
Then the task is stored
And the project relationship is recorded
And the creator is recorded

กรณี Error

Given a user is not a project member
When the user attempts to create a task
Then the system denies the request

ข้อดีคือ Acceptance Criteria สามารถนำไปสร้าง Test Case ได้โดยตรง

#13. ขั้นตอนที่ 3: Clarify

ใช้เมื่อ Requirement ยังมีความกำกวม

/speckit-clarify

หรือระบุ Focus

/speckit-clarify

Focus on:
- task assignment
- permissions
- task status transitions
- activity history

Agent อาจพบคำถาม เช่น

User หนึ่งคนอยู่ได้หลาย Project หรือไม่?
Task มี Assignee ได้หลายคนหรือไม่?
ใครเปลี่ยน Task เป็น DONE ได้?
Owner สามารถลบ Activity History ได้หรือไม่?
Due Date ใช้ Timezone ใด?

ตัวอย่าง Decision

- User อยู่ได้หลาย Project
- Version แรก Task มี Assignee คนเดียว
- Owner และ Assignee เปลี่ยน Status ได้
- Activity History ลบไม่ได้
- Database เก็บเวลาเป็น UTC

หลัง Clarify แล้ว Specification ควรมี Requirement ที่ชัดขึ้น

#14. ขั้นตอนที่ 4: Plan

เมื่อเรารู้แล้วว่า จะสร้างอะไร จึงกำหนดว่า จะสร้างอย่างไร

ตัวอย่าง

/speckit-plan

Frontend:
- React
- TypeScript
- Vite
- React Router

Backend:
- FastAPI
- Python 3.12

Database:
- PostgreSQL

Authentication:
- JWT access token
- refresh token

Testing:
- pytest
- Playwright

Development:
- Docker Compose

CI:
- GitHub Actions

ตัวอย่าง Architecture

┌─────────────────────┐
│   React Frontend    │
└──────────┬──────────┘
           │
           │ HTTPS / JSON
           ▼
┌─────────────────────┐
│     FastAPI API     │
├─────────────────────┤
│ Authentication      │
│ Project Service     │
│ Task Service        │
│ Activity Service    │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│     PostgreSQL      │
└─────────────────────┘

#15. Plan ควรตอบอะไรให้ได้

Technical Plan ควรตอบเรื่องสำคัญ เช่น

Technology Stack
System Architecture
Database Design
API Design
Authentication
Authorization
Validation
Error Handling
Testing Strategy
Deployment
Observability
Security

ตัวอย่าง Entity

User
Project
ProjectMember
Task
Comment
ActivityLog

ตัวอย่าง Relationship

User
  │
  └── ProjectMember
          │
          ▼
       Project
          │
          └── Task
               │
               ├── Comment
               └── ActivityLog

#16. ขั้นตอนที่ 5: Checklist

ใช้

/speckit-checklist

Checklist เป็น Quality Gate สำหรับตรวจ Requirement

ตัวอย่าง

[ ] User Role ระบุครบหรือไม่
[ ] Permission ระบุชัดหรือไม่
[ ] Validation Rule ครบหรือไม่
[ ] Error Case ครบหรือไม่
[ ] Acceptance Criteria Testable หรือไม่
[ ] Security Requirement ชัดหรือไม่
[ ] Performance Constraint ระบุหรือไม่

Checklist ไม่ใช่ Unit Test ของ Code

แต่เป็นเสมือน

Unit Test ของ Requirement

#17. ขั้นตอนที่ 6: Tasks

เมื่อ Spec และ Plan พร้อมแล้ว ใช้

/speckit-tasks

Agent จะสร้าง tasks.md ที่มีลำดับ Dependency

ตัวอย่าง

T001 Create backend project structure
T002 Configure PostgreSQL
T003 Create User model
T004 Create Project model
T005 Create ProjectMember model
T006 Create Task model
T007 Implement JWT authentication
T008 Implement project API
T009 Implement member management
T010 Implement task CRUD
T011 Implement task authorization
T012 Implement activity logging
T013 Add unit tests
T014 Add API integration tests
T015 Create React frontend
T016 Implement login page
T017 Implement dashboard
T018 Implement Kanban board
T019 Add Playwright E2E tests
T020 Configure GitHub Actions

แนวคิดคือเปลี่ยน

Architecture

ให้กลายเป็น

Executable Work Breakdown

#18. ขั้นตอนที่ 7: Analyze

ก่อน Implement Feature สำคัญ ควรใช้

/speckit-analyze

หน้าที่คือหาความไม่สอดคล้องระหว่าง

spec.md
plan.md
tasks.md

ตัวอย่าง

Specification:
ต้องมี Activity History

Plan:
มี Activity Service

Tasks:
ไม่มี Task สำหรับ Activity Log

กรณีนี้ควรแก้ Task ก่อน Implement

Flow คือ

spec.md
   │
   ├─────────────┐
   ▼             ▼
plan.md       tasks.md
   │             │
   └──────┬──────┘
          ▼
       Analyze
          │
          ▼
Conflict / Gap / Ambiguity

analyze เป็นขั้นตอนตรวจ ไม่ควรใช้แทนการแก้ Artifact ต้นทาง

#19. ขั้นตอนที่ 8: Implement

เมื่อ Artifact พร้อมแล้วจึงใช้

/speckit-implement

AI Coding Agent จะมี Context หลักคือ

Constitution
Specification
Technical Plan
Checklist
Task Breakdown

จึงดีกว่าการสั่ง

ช่วยเขียนระบบทั้งหมดให้หน่อย

เพราะ Agent มีรายละเอียดของ Requirement และ Architecture ที่เป็นระบบ

#20. Human Review ยังจำเป็น

Spec Kit ไม่ได้หมายความว่า Developer สามารถปล่อยให้ Agent ทำทุกอย่างโดยไม่ตรวจ

ควร Review อย่างน้อย

Architecture
Security
Authentication
Authorization
Input Validation
Database Migration
API Contract
Error Handling
Dependency
Secrets
Testing
Generated Code

Workflow ที่เหมาะสม

AI Generate
    ↓
Developer Review
    ↓
Run Tests
    ↓
Static Analysis
    ↓
Security Scan
    ↓
Commit

#21. ขั้นตอนที่ 9: Converge

หลัง Implement ใช้

/speckit-converge

ขั้นตอนนี้ตรวจ Codebase เทียบกับ

spec.md
plan.md
tasks.md

ถ้าพบ Gap จะมีงานที่ต้องทำเพิ่มเติม

Workflow

Implement
   ↓
Converge
   ↓
พบ Gap?
 ┌─┴───────────────┐
 │                 │
Yes               No
 │                 │
 ▼                 ▼
New Tasks       Converged
 │
 ▼
Implement
 │
 └──────────→ Converge

ดังนั้น /speckit-implement ไม่ใช่จุดจบของ Feature

เป้าหมายคือ

Converged

ก่อนเข้าสู่ Code Review หรือ Pull Request

#22. ตัวอย่าง Workflow แบบเต็ม

สำหรับ Production Feature

/speckit-constitution
        ↓
/speckit-specify
        ↓
/speckit-clarify
        ↓
/speckit-plan
        ↓
/speckit-checklist
        ↓
/speckit-tasks
        ↓
/speckit-analyze
        ↓
/speckit-implement
        ↓
/speckit-converge

ถ้า Converge พบ Gap

/speckit-converge
        ↓
   New Tasks
        ↓
/speckit-implement
        ↓
/speckit-converge

วนซ้ำจน Artifact กับ Implementation สอดคล้องกัน

#23. โครงสร้าง Project โดยประมาณ

โครงสร้างจริงขึ้นกับ Version และ Integration แต่แนวคิดโดยทั่วไปจะมี

task-management-system/
│
├── .specify/
│   ├── memory/
│   │   └── constitution.md
│   └── ...
│
├── specs/
│   └── <feature>/
│       ├── spec.md
│       ├── plan.md
│       ├── tasks.md
│       └── ...
│
├── frontend/
│
├── backend/
│
└── README.md

ถ้าใช้ GitHub Copilot ใน Skills Mode Integration จะติดตั้ง Skill ที่เกี่ยวข้องไว้ในพื้นที่ของ Copilot ภายใน Repository

#24. ใช้ Spec Kit กับ Existing Project

ถ้ามี Source Code อยู่แล้ว สามารถ Initialize ใน Directory ปัจจุบันได้

ก่อนทำควร

Commit หรือ Stash
      ↓
สร้าง Branch
      ↓
Initialize Spec Kit
      ↓
Review Diff

คำสั่ง

specify init --here --force --integration copilot

หรือ

specify init --here --force --integration claude

--force มีผลกับ Repository ที่มีไฟล์อยู่แล้ว จึงควร Review Diff ก่อน Commit

#25. Existing Project ไม่จำเป็นต้อง Spec ทุกอย่างย้อนหลัง

วิธีที่เหมาะสมกว่าคือเริ่มจาก Feature ใหม่

ตัวอย่างระบบเดิมมี Task Management อยู่แล้ว และต้องเพิ่ม

Task Attachment

ใช้

/speckit-specify

เพิ่มความสามารถแนบไฟล์ใน Task

Requirements:
- สมาชิก Project Upload Attachment ได้
- รองรับ PDF, PNG, JPG
- ขนาดไม่เกิน 10 MB
- Task หนึ่งมีได้ไม่เกิน 20 Attachments
- ผู้ Upload และ Project Owner ลบไฟล์ได้
- การลบไฟล์ต้องบันทึก Activity History

จากนั้น

/speckit-clarify
/speckit-plan
/speckit-checklist
/speckit-tasks
/speckit-analyze
/speckit-implement
/speckit-converge

ทำให้ Adoption เกิดแบบ Incremental

#26. การใช้กับ GitHub Copilot

Initialize

specify init my-project --integration copilot

จากนั้นเปิด Project ด้วย Environment ที่รองรับ GitHub Copilot Agent

ตัวอย่าง Flow

/speckit-constitution
/speckit-specify
/speckit-clarify
/speckit-plan
/speckit-checklist
/speckit-tasks
/speckit-analyze
/speckit-implement
/speckit-converge

GitHub Copilot Integration ปัจจุบันใช้ Skills Mode เป็นแนวทางหลัก

#27. การใช้กับ Codex

Initialize

specify init my-project --integration codex

รูปแบบ Skill ของ Codex อาจใช้

$speckit-specify
$speckit-plan
$speckit-tasks
$speckit-implement
$speckit-converge

ดังนั้นไม่ควรสมมติว่า Agent ทุกตัวใช้ Syntax แบบเดียวกัน

#28. การใช้กับ Claude Code

Initialize

specify init my-project --integration claude

จากนั้นเรียก Process Step ตาม Skill หรือ Command ที่ Integration สร้างไว้

ประโยชน์คือทีมสามารถใช้ Process เดียวกัน แม้ Developer แต่ละคนใช้ Coding Agent ต่างกัน

#29. การใช้ Spec Kit ร่วมกับ Git

เอกสารปัจจุบันระบุว่า Git Workflow ถูกแยกเป็น Extension และไม่ได้เปิดใช้งานโดยอัตโนมัติทุกกรณี

หากต้องการ Git Extension สามารถติดตั้งหลัง Initialize

specify extension add git

แนวทางนี้เหมาะกับทีมที่ต้องการ Workflow เช่น

Feature
   ↓
Branch
   ↓
Specification
   ↓
Implementation
   ↓
Pull Request

#30. Spec Kit กับ Agile

Spec Kit ไม่จำเป็นต้องแทน Scrum หรือ Kanban

สามารถใช้ร่วมกันได้

Product Backlog
      ↓
Feature
      ↓
Specification
      ↓
Technical Plan
      ↓
Tasks
      ↓
Sprint / Kanban
      ↓
Implementation
      ↓
Convergence
      ↓
Pull Request

ตัวอย่าง

Epic
└── User Management
    ├── Registration
    ├── Login
    ├── Password Reset
    └── Role Management

แต่ละ Feature สามารถมี Spec ของตัวเองได้

#31. Spec Kit กับ Test-Driven Development

SDD และ TDD ทำงานร่วมกันได้ดี

Specification
      ↓
Acceptance Criteria
      ↓
Test Case
      ↓
Failing Test
      ↓
Implementation
      ↓
Passing Test
      ↓
Convergence

ตัวอย่าง Acceptance Criteria

Given a non-member
When requesting project tasks
Then the API returns 403

สามารถสร้าง Integration Test เช่น

def test_non_member_cannot_access_project_tasks():
    response = client.get(
        "/api/projects/1/tasks",
        headers=non_member_headers
    )

    assert response.status_code == 403

Specification ที่เขียนให้ Testable จึงช่วยให้ Test Design มีคุณภาพขึ้น

#32. Spec Kit กับ CI/CD

Spec Kit ช่วยควบคุม Development Intent แต่ไม่ได้แทน CI/CD

หลัง Agent Generate Code ควรมี Pipeline เช่น

Push / Pull Request
        │
        ▼
Install Dependencies
        │
        ▼
Lint
        │
        ▼
Unit Test
        │
        ▼
Integration Test
        │
        ▼
Security Scan
        │
        ▼
Build
        │
        ▼
Deploy

ตัวอย่าง Quality Gate

Specification
      ↓
Implementation
      ↓
Automated Tests
      ↓
SonarQube / Static Analysis
      ↓
Dependency Scan
      ↓
Pull Request Review

#33. Spec Kit กับ Code Review

Pull Request สามารถ Review ได้มากกว่าแค่ Diff

Reviewer สามารถตรวจ

spec.md
plan.md
tasks.md
Source Code
Tests

ทำให้คำถามของ Code Review เปลี่ยนจาก

Code นี้เขียนดีหรือไม่?

ไปเป็น

Code นี้ทำตาม Requirement หรือไม่?
Architecture ตรงกับ Plan หรือไม่?
Task ทุกข้อ Implement ครบหรือไม่?
Acceptance Criteria มี Test หรือไม่?

นี่เป็นประโยชน์สำคัญของ Spec-Driven Development

#34. Best Practice: อย่าใส่ Technology ใน Specify เร็วเกินไป

ไม่ควรเริ่มด้วย

สร้างด้วย React + FastAPI + PostgreSQL

แต่ควรเริ่มด้วย

ผู้ใช้สามารถสร้าง Project
เพิ่มสมาชิก
สร้าง Task
Assign Task
และติดตามสถานะงานของทีมได้

จากนั้น Technology ค่อยอยู่ใน plan

หลักการคือ

Specify = What + Why

Plan = How

#35. Best Practice: Requirement ต้อง Testable

ไม่ดี

ระบบต้องเร็ว

ดีกว่า

95% ของการเรียก Task List
ต้องตอบกลับภายใน 500 ms
ภายใต้ Load ที่กำหนด

ไม่ดี

ระบบต้องใช้งานง่าย

ดีกว่า

ผู้ใช้ใหม่สามารถสร้าง Project
และ Task แรกได้โดยไม่ต้องตั้งค่าเพิ่มเติม

#36. Best Practice: Feature ต้องเล็กพอ

ไม่ควรเริ่มด้วย

สร้าง ERP ทั้งระบบ

ควรแบ่งเป็น

Authentication
Customer Management
Product Management
Inventory
Purchase Order
Sales Order
Billing
Reporting

จากนั้นสร้าง Spec แยกตาม Feature

#37. Best Practice: ใช้ Clarify กับ Business Rule ที่ซับซ้อน

เหมาะมากกับระบบที่มี

Permission
Payment
Approval Workflow
Financial Calculation
Healthcare Workflow
Access Control
Subscription
Inventory Reservation

Requirement แบบนี้มักมี Edge Case มาก จึงไม่ควรข้าม Clarification

#38. Best Practice: Analyze ก่อน Implement

แก้ Requirement ก่อนเขียน Code มีต้นทุนต่ำกว่าแก้ Code หลังสร้างไปแล้วจำนวนมาก

Flow ที่แนะนำ

Spec
 ↓
Plan
 ↓
Tasks
 ↓
Analyze
 ↓
แก้ Gap
 ↓
Implement

#39. Best Practice: Converge หลัง Implement

อย่ามองว่า

/speckit-implement

คือขั้นตอนสุดท้าย

ควรใช้

Implement
   ↓
Run Tests
   ↓
Converge
   ↓
Fix Remaining Tasks
   ↓
Implement
   ↓
Converge

จน Feature พร้อม Review

#40. Best Practice: Human-in-the-Loop

แม้ AI จะช่วยสร้าง

Specification
Plan
Tasks
Code
Tests

Developer ยังต้องรับผิดชอบ

Correctness
Security
Privacy
Architecture
Business Rules
Compliance
Operational Risk

Spec Kit ช่วยเพิ่มโครงสร้าง แต่ไม่ได้แทน Engineering Judgment

#41. Prompt ตัวอย่างสำหรับสร้างระบบ

#Constitution

/speckit-constitution

This project follows these principles:

- Security first
- Input validation is mandatory
- Business logic stays outside controllers
- Database changes use migrations
- Critical business rules require tests
- APIs use consistent error responses
- Secrets never enter source control

#Specify

/speckit-specify

Build a team task management system.

Users can:
- create projects
- invite project members
- create tasks
- assign tasks
- set due dates
- set priorities
- move tasks across workflow states
- add comments
- view activity history

Task statuses:
TODO, IN_PROGRESS, REVIEW, DONE.

#Clarify

/speckit-clarify

Focus on:
- project membership
- task assignment
- task status transition
- deletion rules
- activity history

#Plan

/speckit-plan

Use:

Frontend:
React + TypeScript

Backend:
FastAPI

Database:
PostgreSQL

Authentication:
JWT access and refresh tokens

Testing:
pytest + Playwright

Development:
Docker Compose

CI:
GitHub Actions

#Tasks

/speckit-tasks

#Analyze

/speckit-analyze

#Implement

/speckit-implement

#Converge

/speckit-converge

#42. Workflow สำหรับทีม Software Engineering

ตัวอย่าง Workflow ที่นำไปใช้ในทีมได้จริง

Product Owner
     │
     ▼
Business Requirement
     │
     ▼
Developer + AI Agent
     │
     ▼
Specify
     │
     ▼
Requirement Review
     │
     ▼
Clarify
     │
     ▼
Plan
     │
     ▼
Architecture Review
     │
     ▼
Checklist
     │
     ▼
Tasks
     │
     ▼
Analyze
     │
     ▼
Implement
     │
     ▼
Automated Test
     │
     ▼
Converge
     │
     ▼
Pull Request
     │
     ▼
Code Review
     │
     ▼
CI/CD

#43. เปรียบเทียบ Prompt-Driven กับ Spec-Driven

Prompt-Driven Spec-Driven
Prompt เป็น Context ชั่วคราว Specification เป็น Artifact
Requirement กระจายใน Chat Requirement มี Source of Truth
AI อาจเริ่ม Code ทันที มี Planning ก่อน Coding
Traceability ต่ำ Trace ได้จาก Spec → Plan → Tasks
Review ยาก Review Artifact ได้
เปลี่ยน Agent แล้ว Context อาจหาย Artifact อยู่ใน Repository
เหมาะกับงานสั้น เหมาะกับ Feature และระบบที่จริงจัง

#44. Spec Kit เหมาะกับงานแบบใด

เหมาะมากกับ

  • Full-stack Application
  • REST API
  • Backend Service
  • Microservices
  • Enterprise Application
  • Internal Business System
  • AI Application
  • Feature ที่มี Business Rule ซับซ้อน
  • ระบบที่ต้องการ Traceability
  • Team ที่ใช้ AI Coding Agent
  • Existing Project ที่ต้องเพิ่ม Feature อย่างเป็นระบบ

อาจไม่จำเป็นต้องใช้ Workflow เต็มกับ

  • Script เล็ก ๆ
  • Proof of Concept สั้น ๆ
  • Throwaway Prototype

แต่แม้งานเล็ก การกำหนด Requirement ให้ชัดก็ยังช่วยลด Rework

#45. สรุป

GitHub Spec Kit ทำให้การใช้ AI Coding Agent เปลี่ยนจาก

Prompt
  ↓
Code

ไปเป็น

Constitution
      ↓
Specification
      ↓
Clarification
      ↓
Technical Plan
      ↓
Checklist
      ↓
Tasks
      ↓
Analysis
      ↓
Implementation
      ↓
Convergence

ประโยชน์สำคัญคือ

  1. Requirement ชัดก่อนเขียน Code
  2. Architecture ถูกกำหนดก่อน Implementation
  3. Work Breakdown เชื่อมกับ Specification
  4. AI Coding Agent มี Context ที่เป็นระบบ
  5. ลด Requirement Drift
  6. เพิ่ม Traceability
  7. Review Artifact ได้ด้วย Git
  8. ใช้ร่วมกับ TDD, Agile และ CI/CD ได้
  9. รองรับการทำงานกับ AI Coding Agent หลายชนิด
  10. ตรวจ Gap หลัง Implementation ด้วย Convergence ได้

แนวคิดที่ควรจำคือ

Spec ก่อน Code

และ

ให้ AI ทำงานจาก Specification ที่ตรวจสอบได้ แทนการพึ่ง Prompt ชั่วคราวเพียงอย่างเดียว

#References

เอกสารอ้างอิงตรวจสอบ ณ วันที่ 22 กันยายน 2026

หมายเหตุ: GitHub Spec Kit มีการพัฒนาอย่างต่อเนื่อง ชื่อ Command, Integration, Extension และ Workflow อาจเปลี่ยนใน Version ถัดไป ควรตรวจสอบเอกสาร Official ก่อนนำไปใช้ในระบบ Production หรือจัดทำเอกสารอบรมระยะยาว