GitHub Spec Kit: Otomasi SDD Workflow dengan Claude Code untuk Golang

Apa itu GitHub Spec Kit dan Posisinya di Workflow SDD

Di Topik #1 kita bicara tentang mindset SDD — bagaimana cara berpikir yang baru tentang membangun software dengan AI. Di Topik #2 ini, kita akan bicara tentang tooling yang mengotomasi mindset itu.

GitHub Spec Kit adalah jawabannya.

Ini bukan framework baru yang harus dipelajari dari nol. Bukan library yang harus di-import ke setiap project. Ini adalah CLI tool yang mengotomasi enam tahap siklus SDD — dari kebutuhan bisnis yang masih kabur, sampai kode Go yang siap di-review dan di-merge.

Satu perintah. Satu siklus. Seluruh workflow ter-orkestrasi.

01.1 Konteks: Di Mana Spec Kit Masuk?

Kalau kamu baru selesai baca Topik #1, kamu tahu bahwa SDD punya komponen-komponen yang harus dijalankan secara berurutan: tulis spec, klarifikasi, buat plan, breakdown tasks, generate kode, review.

Masalahnya: semua itu harus dilakukan manual. Kamu harus buka file yang berbeda-beda, pastikan semua referensi konsisten, ingat di mana menyimpan apa, dan memastikan Claude Code punya context yang tepat di setiap tahap.

GitHub Spec Kit mengotomasi semua itu. Diagram berikut membandingkan alur manual yang berpindah-pindah tool dengan alur Spec Kit yang seluruhnya berjalan lewat satu perintah specify.

 1Tanpa Spec Kit:
 2Developer → [buka terminal] → [buka editor] → [tulis spec manual]
 3         → [switch ke Claude Code] → [paste context] → [generate plan]
 4         → [copy plan ke file] → [tulis tasks manual] → [implement]
 5
 6Dengan Spec Kit:
 7Developer → specify feature product-service
 8         → specify clarify product-service
 9         → specify plan product-service
10         → specify tasks product-service
11         → specify implement product-service --phase=1

Perhatikan bahwa di jalur kedua tidak ada lagi langkah “copy-paste context” atau “switch tool” — Spec Kit bukan pengganti SDD, dia adalah conductor yang mengorkestrasi setiap instrumen dalam orkestra SDD.

01.2 Sejarah Singkat dan Filosofi di Balik Spec Kit

GitHub Spec Kit lahir dari frustrasi yang sangat spesifik: developer yang sudah adopt SDD menemukan bahwa proses manual — membuat folder .specify/, menjaga konsistensi antar file, memastikan Claude selalu punya context yang tepat — memakan waktu hampir sebanyak implementasinya sendiri.

Filosofi Spec Kit bisa diringkas dalam satu kalimat:

“Spesifikasi adalah source of truth. Kode adalah output. AI adalah eksekutor. Spec Kit adalah konduktor.”

Tiga implikasi langsung dari filosofi ini:

Implikasi 1: Spec ditulis sebelum kode. Spec Kit tidak bisa dijalankan tanpa spec. Ini bukan pilihan — ini enforced.

Implikasi 2: Constitution mendefinisikan semua keputusan arsitektur. Sebelum ada satu baris kode, ada constitution yang mendefinisikan tech stack, conventions, dan rules yang tidak boleh dilanggar.

Implikasi 3: Context AI selalu konsisten. Spec Kit memastikan bahwa setiap perintah yang diberikan ke Claude punya context yang lengkap: constitution + spec + plan + tasks + kode yang sudah ada.

01.3 Enam Perintah yang Membentuk Satu Siklus

Spec Kit punya enam perintah inti, dan masing-masing adalah satu tahap dalam siklus SDD. Daftar berikut menunjukkan urutan perintah beserta output yang dihasilkan setiap tahap.

 1specify constitution init
 2  → Definisikan prinsip-prinsip project yang tidak boleh dilanggar
 3
 4specify feature [nama-fitur]
 5  → Tulis kebutuhan bisnis tanpa menyebut tech stack
 6
 7specify clarify [nama-fitur]
 8  → Q&A terstruktur untuk perjelas ambiguitas di spec
 9
10specify plan [nama-fitur]
11  → Hasilkan rencana teknis dari spec yang sudah jelas
12
13specify tasks [nama-fitur]
14  → Breakdown plan menjadi task-task yang actionable
15
16specify implement [nama-fitur] --phase=[n]
17  → Generate dan eksekusi kode dari tasks secara berurutan

Keenam perintah ini dirancang untuk dijalankan berurutan. Kamu tidak bisa menjalankan specify plan sebelum ada spec yang dihasilkan dari specify feature — Spec Kit yang meng-enforce urutan ini, sehingga tidak ada tahap yang ter-skip.

01.4 Struktur File yang Dihasilkan Spec Kit

Setelah menjalankan rangkaian perintah Spec Kit, struktur project kamu akan terlihat seperti pohon direktori berikut. Perhatikan bagaimana semua output terpusat di folder .specify/.

 1santekno-shop/
 2├── .specify/
 3│   ├── constitution.md              ← Prinsip yang berlaku untuk semua fitur
 4│   ├── features/
 5│   │   ├── product-service/
 6│   │   │   ├── spec.md              ← Kebutuhan bisnis (no tech details)
 7│   │   │   ├── plan.md              ← Rencana teknis (file, SQL, API)
 8│   │   │   └── tasks.md             ← Task breakdown dengan estimasi
 9│   │   └── cancel-order/
10│   │       ├── spec.md
11│   │       ├── plan.md
12│   │       └── tasks.md
13│   └── history/
14│       └── 2025-07-01-product-service.log
15├── CLAUDE.md                         ← Tetap ada, di-extend oleh Spec Kit
16├── internal/
17│   └── product/
18│       ├── domain/
19│       ├── usecase/
20│       ├── repository/
21│       └── handler/
22└── specs/                            ← Optional: co-exist dengan specs/ dari Topik #1
23    └── order/
24        └── cancel-order.md

Semua file di dalam .specify/ harus di-commit ke repository. Ini adalah bagian dari source of truth project — bisa di-review via PR, bisa di-diskusi, bisa di-version — bukan artefak sementara yang dibuang setelah kode selesai.

01.5 Spec Kit vs CLAUDE.md: Keduanya Dibutuhkan

Pertanyaan yang sering muncul: “Kalau ada Spec Kit, masih perlu CLAUDE.md?”

Jawaban singkatnya: ya, keduanya dibutuhkan dan saling melengkapi. Tabel berikut membedah perbedaan scope, isi, dan kapan masing-masing dibaca.

Intinya, keduanya beroperasi di lapisan yang berbeda: CLAUDE.md adalah konteks yang selalu ada, Spec Kit adalah konteks yang spesifik per fitur. Cara kerjanya bersama bisa dilihat dari pemetaan peran berikut.

1CLAUDE.md memberikan "who we are" — arsitektur, conventions, rules global
2
3.specify/constitution.md memberikan "how we work" — prinsip-prinsip yang enforce
4.specify/features/*/spec.md memberikan "what we're building" — kebutuhan spesifik
5.specify/features/*/plan.md memberikan "how we'll build it" — rencana teknis
6.specify/features/*/tasks.md memberikan "what to do next" — action items

Dari pemetaan itu terlihat bahwa Spec Kit membaca CLAUDE.md dan .specify/constitution.md bersamaan saat generate plan dan kode. Keduanya adalah konteks yang saling melengkapi, bukan saling menggantikan.

01.6 Perbedaan Spec Kit dari Tools SDD Lainnya

Di ekosistem SDD 2026, ada beberapa tools yang bisa membantu workflow spec-first. Apa yang membedakan Spec Kit?

vs. Kiro (Amazon): Kiro menggunakan steering files dalam format YAML. Spec Kit menggunakan Markdown yang lebih human-readable dan familiar bagi developer. Kiro lebih terintegrasi dengan AWS ecosystem, Spec Kit lebih agnostic.

vs. Manual SDD (tanpa tooling): Manual SDD seperti yang kita bahas di Topik #1 memberikan fleksibilitas maksimum tapi membutuhkan disiplin yang tinggi. Spec Kit mengurangi beban mental dengan mengotomasi siklus yang berulang.

vs. ChatGPT/Claude dalam browser: Browser-based AI tidak punya akses ke codebase. Spec Kit mengintegrasikan AI langsung ke dalam development workflow dengan context codebase yang lengkap.

Keunikan Spec Kit:

• Enforce urutan: tidak bisa skip tahap
• Semua output dalam bentuk file yang bisa di-commit
• Integrasi langsung dengan Claude Code (bukan browser)
• Constitution sebagai “konstitusi” yang konsisten untuk semua fitur

01.7 Siapa yang Tepat Menggunakan Spec Kit?

Spec Kit paling valuable untuk:

Developer yang sudah adopt SDD tapi merasa overhead-nya besar: Jika kamu sudah nulis spec manual, buat plan manual, dan breakdown tasks manual — Spec Kit akan menghemat 30-40% waktu yang kamu habiskan di “admin” SDD.

Tim kecil (2-10 orang) yang mau enforce SDD secara konsisten: Spec Kit membuat SDD tidak bergantung pada disiplin individu — workflow-nya di-enforce oleh tooling.

Go developer yang mau mulai SDD tapi tidak tahu dari mana: Spec Kit memberikan struktur yang jelas: jalankan perintah ini, hasilkan file ini, lanjut ke perintah berikutnya.

Kapan Spec Kit mungkin bukan pilihan terbaik:

• Untuk task one-off yang sangat kecil (< 30 menit) — overhead Spec Kit tidak worth it
• Untuk tim yang belum familiar sama sekali dengan SDD — pelajari Topik #1 dulu
• Untuk proyek proof-of-concept yang akan dibuang — Spec Kit untuk investasi jangka panjang

01.8 Contoh Nyata: Sebelum dan Sesudah Spec Kit

Mari kita bandingkan workflow untuk satu fitur sederhana: “Get Product by SKU.”

Pertama, lihat dulu bagaimana alur manual SDD terasa penuh langkah administratif sebelum satu baris kode pun ditulis. Blok berikut merangkum langkah-langkah manualnya.

 1# Buat folder dan file manual
 2mkdir -p specs/product
 3touch specs/product/get-by-sku.md
 4
 5# Tulis spec (15-20 menit)
 6# Buka Claude Code, paste context CLAUDE.md (manual)
 7# Generate plan (copy-paste, save manual)
 8# Tulis tasks (manual)
 9# Implement satu per satu (copy-paste context setiap kali)
10
11# Total setup + admin: ~45 menit sebelum satu baris kode ditulis

Perhatikan bahwa hampir semua waktu di atas habis untuk “admin”, bukan berpikir tentang fitur. Sekarang bandingkan dengan alur yang sama menggunakan Spec Kit pada blok berikut.

 1# Satu perintah untuk mulai
 2specify feature get-product-by-sku
 3
 4# Jawab pertanyaan interaktif (5-10 menit)
 5# File spec dihasilkan otomatis
 6
 7specify clarify get-product-by-sku
 8# Jawab pertanyaan klarifikasi (5 menit)
 9
10specify plan get-product-by-sku
11# Plan dihasilkan otomatis berdasarkan constitution + spec
12
13specify tasks get-product-by-sku
14# Tasks dihasilkan otomatis
15
16specify implement get-product-by-sku --phase=1
17# Implementasi dimulai
18
19# Total setup + admin: ~15 menit

Bukan hanya lebih cepat — tapi juga lebih konsisten. Tidak ada yang terlupakan, tidak ada context yang hilang, karena setiap perintah membawa konteks tahap sebelumnya secara otomatis.

01.9 Spec Kit dan Go: Kenapa Kombinasi yang Powerful

Go adalah bahasa yang opinionated dalam hal idioms dan best practices. go fmt, go vet, interface-based polymorphism, explicit error handling — semuanya adalah konvensi yang harus diikuti.

Masalahnya: AI yang tidak di-configure dengan benar cenderung menghasilkan kode Go yang “works but not idiomatic” — pakai pattern dari bahasa lain yang tidak natural di Go.

Spec Kit memecahkan masalah ini lewat constitution. Dengan constitution yang mendefinisikan:

• Error handling pattern yang dipakai
• Interface definition strategy
• Package naming convention
• Testing approach

… Claude Code akan secara konsisten menghasilkan kode Go yang idiomatic dan sesuai dengan codebase existing.

01.10 Hubungan Spec Kit dengan Santekno Shop

Di seluruh seri ini, kita akan menggunakan proyek Santekno Shop — e-commerce B2C Indonesia — sebagai contoh nyata.

Spec Kit akan digunakan untuk membangun fitur-fitur di Santekno Shop. Beberapa artikel di depan sudah dipetakan ke fitur konkret seperti daftar berikut.

1Artikel 11: Studi Kasus — CRUD API Produk dari Spec Kit End-to-End
2Artikel 12: Branching Strategy dengan Spec Kit
3Artikel 13: Git Workflow dari Spec Kit
4...

Karena setiap artikel memakai codebase yang sama, kamu bisa melihat bagaimana sebuah fitur dibangun dari nol hingga production-ready tanpa harus berpindah konteks proyek.

Tech stack Santekno Shop:

• Go 1.22+
• HTTP: Echo v4
• Database: PostgreSQL via pgx/v5
• Cache: Redis via go-redis/v9
• Message Broker: Kafka via confluent-kafka-go v2
• Testing: testify/suite + gomock

01.11 Satu Hari dalam Kehidupan Developer yang Pakai Spec Kit

Agar terasa konkret, mari lihat bagaimana Spec Kit mengubah rutinitas development dalam satu hari kerja. Timeline berikut menggambarkan alur dari terima ticket sampai fitur mulai jadi.

 108:30 — Buka terminal, cek Jira
 2        Dapat ticket: SHOP-789 "Add product variant support"
 3
 408:35 — Buka terminal
 5        $ specify feature product-variants
 6        Jawab pertanyaan (10 menit)
 7        spec.md dibuat
 8
 908:45 — Klarifikasi
10        $ specify clarify product-variants
11        Jawab 4 pertanyaan dari Claude (5 menit)
12        spec.md di-update
13
1408:50 — Generate plan
15        $ specify plan product-variants
16        plan.md dibuat dalam 60 detik
17
1808:52 — Breakdown tasks
19        $ specify tasks product-variants
20        tasks.md dibuat dalam 30 detik
21        Kamu punya list 12 tasks yang clear
22
2308:55 — Review plan dan tasks (10 menit)
24        Revisi satu hal yang tidak sesuai
25
2609:05 — Mulai implementasi
27        $ specify implement product-variants --phase=1
28        Fase 1 (domain types) selesai dalam 5 menit
29        Kamu review dan commit
30
3109:15 — Lanjut fase berikutnya
32        $ specify implement product-variants --phase=2
33        ...
34
35Sisa hari: fokus di code review dan testing
36Tidak ada waktu yang terbuang untuk "setup" dan "admin"

Poin pentingnya bukan sekadar kecepatan, tapi bahwa energi mental developer teralihkan dari kerja administratif ke keputusan yang benar-benar butuh judgment: review plan, review kode, dan testing.

01.12 Apa yang Tidak Dilakukan Spec Kit

Penting untuk tahu batas-batas Spec Kit:

Spec Kit tidak menggantikan:

• Judgment engineering — kamu yang tetap memutuskan apakah spec sudah benar
• Business knowledge — kamu harus tahu apa yang user butuhkan
• Code review — output Spec Kit tetap harus di-review oleh manusia
• Testing strategy — Spec Kit generate test, tapi kamu yang memutuskan coverage target

Spec Kit tidak otomatis:

• Deploy ke production (bukan CI/CD tool)
• Monitor aplikasi di runtime
• Memilih tech stack (constitution harus ditulis oleh manusia dulu)

Spec Kit adalah multiplier untuk developer yang sudah punya judgment yang baik — bukan pengganti judgment itu.

01.13 Prerequisites: Apa yang Perlu Kamu Siapkan

Sebelum mulai menggunakan Spec Kit secara efektif, pastikan kamu sudah punya:

Technical:

• Go 1.22+ terinstall
• Node.js 18+ (untuk install specify CLI via npm)
• Claude API key (dari console.anthropic.com)
• Git repository yang sudah diinisialisasi
• Familiarity dengan Go project structure (clean architecture recommended)

Knowledge:

• Familiar dengan konsep SDD (idealnya sudah baca Topik #1)
• Mengerti clean architecture di Go
• Mengerti cara kerja Claude Code

Project:

• Project Go yang sudah punya struktur dasar
• Atau kita bisa mulai dari scratch (akan dicover di artikel berikutnya)

01.14 Persiapan Proyek Santekno Shop

Di artikel 05 seri ini, kita akan setup constitution Santekno Shop dari awal. Tapi sebelum sampai sana, mari kita lihat preview bagaimana constitution akan terlihat. Blok markdown berikut adalah versi ringkas dari constitution yang akan kita pakai.

 1# Santekno Shop — Project Constitution
 2
 3## Tech Stack
 4- Go 1.22+, Echo v4, pgx/v5, go-redis/v9
 5- confluent-kafka-go v2, testify/suite, gomock
 6
 7## Architecture: Clean Architecture
 8Layer dependency: handler -> usecase -> repository -> database
 9
10## Must Always
11- fmt.Errorf("context: %w", err) untuk semua error wrapping
12- context.Context sebagai parameter pertama
13- uuid.UUID dari github.com/google/uuid
14- Harga dalam cents (int64), bukan float
15
16## Must Never
17- ORM (tidak boleh GORM, Ent, dst.)
18- Direct DB call dari handler
19- Business logic di handler layer

Constitution inilah yang akan menjadi “konstitusi” yang di-enforce oleh setiap perintah Spec Kit — setiap plan dan kode yang di-generate harus tunduk pada aturan di atas.

01.15 Roadmap Seri Ini: 20 Artikel, 4 Part

Sebelum kita mulai, mari lihat peta perjalanan kita. Roadmap berikut membagi 20 artikel Topik #2 ke dalam empat part yang saling membangun.

 1PART 1 — PENGENALAN & SETUP (Artikel 1–4)
 201. Apa itu GitHub Spec Kit dan Posisinya di Workflow SDD ← kamu di sini
 302. Instalasi specify CLI: Persistent vs One-time Setup
 403. Struktur .specify Folder: Anatomy Output yang Dihasilkan
 504. Integrasi Spec Kit + Claude Code: Setup End-to-End Go Project
 6
 7PART 2 — ENAM PERINTAH INTI (Artikel 5–10)
 805. speckit.constitution: Konstitusi Proyek
 906. speckit.specify: Tulis Kebutuhan Tanpa Tech Stack
1007. speckit.clarify: Q&A Terstruktur untuk Perjelas Detail
1108. speckit.plan: Dari Spec Fungsional ke Rencana Teknis
1209. speckit.tasks: Breakdown Tasks yang Actionable
1310. speckit.implement: Eksekusi Kode dari Tasks
14
15PART 3 — WORKFLOW NYATA (Artikel 11–15)
1611. Studi Kasus: CRUD API dari Spec Kit End-to-End
1712. Branching Strategy: Setiap Fitur = Satu Branch
1813. Git Workflow: Auto-Commit dan PR dari Spec Kit
1914. Update CLAUDE.md Otomatis
2015. Debugging Workflow: Ketika Claude Melewati Instruksi
21
22PART 4 — SKALA & INTEGRASI (Artikel 16–20)
2316. Spec Kit untuk Tim: Onboarding dan Shared Constitution
2417. Spec Kit di Monorepo Go
2518. Validasi Implementasi terhadap Spesifikasi
2619. Spec Kit + GitHub Actions: CI untuk Validasi
2720. [Bridge →] Spec Output sebagai Kontrak dalam Pipeline AI

Roadmap ini sengaja dibangun berlapis: Part 1 menyiapkan fondasi, Part 2 membedah tiap perintah, lalu Part 3 dan 4 menaikkannya ke workflow nyata dan skala tim. Artikel yang sedang kamu baca adalah pintu masuknya.

01.16 Mengapa “GitHub” Spec Kit?

Nama “GitHub Spec Kit” mungkin membingungkan — apakah ini produk resmi GitHub? Tidak persis.

GitHub Spec Kit adalah open-source project yang:

1. Di-host di GitHub (github.com/github/spec-kit)
2. Terinspirasi dari cara GitHub menggunakan spec-driven workflow internal
3. Dirancang untuk bekerja natively dengan GitHub repositories dan GitHub Actions

Tapi kamu tidak harus pakai GitHub untuk menggunakannya — Git (dengan platform apapun) sudah cukup. Bahkan, kamu bisa pakai Spec Kit secara lokal tanpa remote repository sama sekali.

Dalam seri ini, kita akan menggunakan GitHub sebagai remote karena itu yang paling umum — tapi konsepnya berlaku untuk GitLab, Bitbucket, atau bahkan self-hosted Gitea.

01.17 Posisi Spec Kit dalam Ekosistem 2026

Di tahun 2026, ekosistem AI coding tools sudah jauh lebih mature dari satu atau dua tahun sebelumnya. Untuk memahami di mana Spec Kit berada, bayangkan workflow developer terbagi menjadi beberapa “slot” seperti diagram berikut.

 1Slot 1: AI Editor (kamu yang nulis, AI yang bantu)
 2→ GitHub Copilot, Tabnine, Codeium
 3
 4Slot 2: AI Chat Coding (kamu yang prompt, AI yang generate)
 5→ Claude Code, ChatGPT, Gemini Code
 6
 7Slot 3: Agentic Coding (AI yang jalankan task secara autonomous)
 8→ Devin, Claude Code (plan mode), SWE-agent
 9
10Slot 4: Workflow Orchestration (yang orkestrasi semua slot di atas)
11→ GitHub Spec Kit ← ini posisinya

Yang perlu diingat dari diagram itu: Spec Kit bukan di Slot 1, 2, atau 3 — dia ada di Slot 4. Dia yang mengorkestrasi kapan dan bagaimana setiap tool digunakan dalam konteks SDD.

01.18 Tips & Gotchas

💡 Tip 1: Mulai dengan project yang sudah ada, bukan dari scratch

Jika kamu punya project Go yang sudah berjalan, Spec Kit bisa di-adopt secara incremental. Tidak perlu refactor semua sebelum bisa mulai.

💡 Tip 2: Constitution adalah investasi terpenting

Waktu yang dihabiskan untuk menulis constitution yang baik akan di-bayar berkali-kali di setiap fitur berikutnya. Jangan rush di tahap ini.

💡 Tip 3: Treat .specify/ folder seperti source code

Commit setiap perubahan di .specify/. Review spec via PR. Ini adalah dokumentasi hidup yang mencerminkan keputusan bisnis dan teknikal.

💡 Tip 4: Spec Kit bekerja paling baik dengan codebase yang sudah ada

Spec Kit membaca kode existing untuk generate plan yang relevan. Semakin banyak referensi kode yang ada, semakin baik kualitas output.

⚠️ Gotcha 1: Jangan gunakan --all flag di awal

specify implement --all akan langsung generate semua kode tanpa review per-phase. Ini berisiko untuk project baru. Selalu gunakan --phase=N dan review setelah setiap phase.

⚠️ Gotcha 2: API key harus ada sebelum perintah pertama

Spec Kit akan langsung gagal jika ANTHROPIC_API_KEY tidak di-set. Setup dulu sebelum mulai.

⚠️ Gotcha 3: Constitution yang ambigu = kode yang ambigu

Jika constitution berisi rules yang contradictory atau ambigu, kode yang dihasilkan juga akan inconsistent. Invest waktu untuk membuat constitution yang jelas dan explicit.

⚠️ Gotcha 4: Spec Kit bukan magic — review tetap wajib

Output Spec Kit adalah starting point yang sangat baik, bukan final product. Code review oleh manusia tetap diperlukan sebelum merge ke main.

01.19 Gambaran Lengkap: Dari Kebutuhan ke Kode

Sebelum kita masuk ke instalasi di artikel berikutnya, mari lihat gambaran lengkap end-to-end. Diagram alur berikut memperlihatkan bagaimana satu kebutuhan bisnis mengalir melalui setiap perintah Spec Kit sampai jadi fitur yang di-commit.

flowchart TD
    A["Business Need: We need product variants"] --> B["specify feature product-variants -> spec.md dibuat"]
    B --> C["specify clarify product-variants -> ambiguitas terjawab, spec diperbarui"]
    C --> D["specify plan product-variants -> plan.md: file structure, SQL, API"]
    D --> E["specify tasks product-variants -> tasks.md: 12 tasks dengan estimasi"]
    E --> F["specify implement --phase=1 -> domain types dibuat"]
    F --> G["Review + commit"]
    G --> H["specify implement --phase=2 -> repository layer dibuat"]
    H --> I["Review + commit"]
    I --> J["... (repeat per phase)"]
    J --> K["Feature selesai, spec + kode di-commit"]

Setiap kotak di diagram itu adalah satu perintah, dan setiap output adalah file yang bisa di-review. Inilah yang membuat proses SDD dengan Spec Kit terasa terstruktur, transparan, dan reproducible.

01.20 Ringkasan

GitHub Spec Kit adalah CLI tool yang mengotomasi enam tahap siklus SDD — dari kebutuhan bisnis sampai kode Go yang siap di-merge. Bukan pengganti judgment engineering, tapi amplifier yang membuat proses lebih cepat, lebih konsisten, dan lebih terstruktur.

Enam perintah inti: constitution, feature/specify, clarify, plan, tasks, implement — masing-masing satu tahap dalam siklus SDD yang di-enforce oleh tooling.

Posisi di ekosistem: Bukan AI editor, bukan AI chat — tapi workflow orchestrator yang mengorkestrasi bagaimana semua tools digunakan dalam konteks SDD.

Syarat sukses: Constitution yang baik, familiarity dengan Go clean architecture, dan disiplin untuk review setiap output sebelum merge.

Di artikel berikutnya, kita akan install specify CLI dan melakukan setup lengkap untuk project Santekno Shop — termasuk konfigurasi yang membuat Spec Kit bekerja secara persistent di semua proyek Go kamu.