Git Workflow Spec Kit Golang: Auto-Commit dan PR Otomatis
Cara menggunakan fitur auto-commit dan PR generation dari GitHub Spec Kit di proyek Golang. Commit message yang terstruktur, PR description otomatis, dan git history yang clean.
Git Workflow: Auto-Commit dan PR dari Spec Kit
Salah satu friction terbesar dalam git workflow sehari-hari di proyek Golang adalah membuat commit message yang informatif dan PR description yang lengkap. Dengan auto-commit dari Spec Kit, setiap task dari speckit.implement menghasilkan commit yang terstruktur dan traceable ke spec, sementara specify pr menghasilkan PR description yang komprehensif dalam hitungan detik. Di artikel ini kita bedah bagaimana kedua fitur ini menghilangkan pekerjaan manual sekaligus membentuk git history yang clean dan audit-friendly.
13.1 Anatomy Commit dari Spec Kit
Sebelum bisa memanfaatkan auto-commit, penting memahami struktur commit yang dihasilkan. Template berikut memperlihatkan bagian-bagian wajib dari setiap commit message yang dibuat speckit.implement.
1{type}({scope}): {short description}
2
3Implements: {spec file} {version}
4Spec reference: {AC/EC identifiers}
5Task: {task number} from {tasks file}
6
7DoD verified:
8{list of verified DoD items}
9
10Token usage: {input}/{output} tokensFormat ini memastikan setiap commit menjawab tiga pertanyaan sekaligus: apa yang berubah, spec mana yang di-implement, dan bukti DoD apa yang sudah diverifikasi. Agar terasa konkret, berikut contoh nyata dari implementasi fitur review.
1feat(review): implement CreateReview usecase with purchase verification
2
3Implements: .specify/features/product-review/spec.md v1.0
4Spec reference: AC1-AC5, AC13, AC14
5Task: 07 from .specify/features/product-review/tasks.md
6
7DoD verified:
8- go build ./... ✓
9- go test -race ./internal/usecase/review/... ✓ (8 passed)
10- Coverage: 89.4% ✓ (target: 85%)
11- Error code 'PURCHASE_REQUIRED' verified ✓
12- Error code 'ALREADY_REVIEWED' verified ✓
13
14Token usage: 2,847/1,203 tokensDengan struktur seperti ini, membaca satu commit saja sudah cukup untuk memahami konteks penuh perubahan — spec mana, task nomor berapa, dan verifikasi apa yang lulus — tanpa perlu membuka file lain.
13.2 Konfigurasi Commit Message
Perilaku commit generator bisa disesuaikan lewat file konfigurasi proyek. Konfigurasi YAML berikut mengatur mapping type commit berdasarkan task type, scope otomatis, hingga penyisipan issue reference.
1# .speckit-config.yaml
2
3git:
4 # Format commit type berdasarkan task type
5 commit_types:
6 domain: "feat"
7 usecase: "feat"
8 repository: "feat"
9 handler: "feat"
10 migration: "feat"
11 test: "test"
12 config: "chore"
13 docs: "docs"
14
15 # Scope diambil dari domain yang dimodifikasi
16 auto_scope: true
17
18 # Include DoD verification summary di commit body
19 include_dod_summary: true
20
21 # Include token usage di commit body
22 include_token_usage: false # set true untuk tracking cost
23
24 # Sign commits secara otomatis (butuh GPG setup)
25 sign_commits: false
26
27 # Tambahkan issue/ticket reference otomatis
28 # Diambil dari branch name: feature/SHOP-789-*
29 auto_issue_ref: true
30 issue_prefix: "SHOP"Dengan auto_scope dan auto_issue_ref, kamu tidak perlu mengingat konvensi penamaan — Spec Kit menurunkannya otomatis dari task type dan nama branch, sehingga seluruh tim menghasilkan commit dengan gaya yang seragam.
13.3 Commit History yang Dihasilkan
Hasil akhir dari auto-commit paling jelas terlihat di git log. Setelah keempat belas task fitur product-review selesai, riwayat commit terbentuk rapi seperti berikut.
1git log --oneline feature/SHOP-789-product-review
2
3# 14 commits, satu per task:
4abc1234 feat(review): e2e smoke test verified — product review COMPLETE
5bcd2345 feat(router): register review endpoints under /products/:id/reviews
6cde3456 feat(review): add handler tests (12 tests covering all error paths)
7def4567 feat(review): implement HTTP handlers CreateReview, ListReviews, DeleteReview
8efg5678 feat(review): implement DeleteReview usecase with admin authorization
9fgh6789 feat(review): implement ListReviews usecase with pagination and sorting
10ghi7890 test(review): add CreateReview usecase tests (8 test cases)
11hij8901 feat(review): implement CreateReview usecase with purchase verification
12ijk9012 feat(db): add average_rating and total_review_count to products table
13jkl0123 feat(review): implement review repository with atomic operations
14klm1234 feat(review): add ReviewRepository interface with 5 methods
15lmn2345 feat(db): create reviews table with unique constraint
16mno3456 feat(product): add AverageRating and TotalReviewCount fields
17nop4567 feat(review): add Review domain entity with status and validationGit log ini adalah roadmap lengkap dari implementasi — satu commit per task, masing-masing punya tujuan yang jelas dan traceable ke spec. Riwayat semacam ini membuat proses git revert atau git bisect jadi presisi karena setiap perubahan terisolasi.
13.4 Generate PR Description
Setelah semua task ter-commit, langkah berikutnya adalah membuat PR. Perintah berikut menampilkan PR description di terminal atau langsung membuatnya via GitHub CLI.
1# Generate PR description (tampilkan di terminal)
2specify pr --feature product-review
3
4# Buat PR langsung via GitHub CLI
5specify pr --feature product-review --create
6
7# Output PR yang di-create:Cukup satu flag --create, PR langsung terbuat di GitHub lengkap dengan description — menghilangkan ritual copy-paste manual yang biasanya memakan waktu. Isi PR description yang di-generate terlihat seperti berikut.
1## feat(review): implement product review feature [SHOP-789]
2
3### Overview
4Implementasi sistem review dan rating produk untuk customer Santekno Shop.
5Customer yang sudah membeli produk (status DELIVERED) bisa memberikan rating (1-5)
6dan ulasan teks. Admin bisa menghapus review yang tidak sesuai.
7
8### Spec Reference
9| Item | Value |
10|------|-------|
11| Spec | `.specify/features/product-review/spec.md v1.0` |
12| Plan | `.specify/features/product-review/plan.md` |
13| Tasks | `.specify/features/product-review/tasks.md` |
14| Spec approved by | @budi on 2025-07-02 |
15| Implementation by | @citra |
16
17### Spec Compliance
18
19#### Acceptance Criteria
20| AC | Description | Status |
21|----|-------------|--------|
22| AC1 | POST /products/:id/reviews menerima rating dan content | ✅ |
23| AC2 | Validasi customer sudah beli produk (DELIVERED) | ✅ |
24| AC3 | Review disimpan dengan status PUBLISHED | ✅ |
25| AC4 | Rata-rata rating di-update atomic dalam satu TX | ✅ |
26| AC5 | Response 201 Created dengan review data | ✅ |
27| AC6 | GET /products/:id/reviews dengan pagination | ✅ |
28| AC7 | Response menyertakan avg rating dan total count | ✅ |
29| AC8 | DELETE hanya bisa dilakukan admin | ✅ |
30| AC9 | Soft delete (tidak dihapus permanent) | ✅ |
31| AC10 | Rating di-recalculate setelah delete | ✅ |
32| AC11 | Rating di luar 1-5 → 400 | ✅ |
33| AC12 | Content terlalu panjang → 400 | ✅ |
34| AC13 | Belum beli → 422 PURCHASE_REQUIRED | ✅ |
35| AC14 | Sudah review → 422 ALREADY_REVIEWED | ✅ |
36| AC15 | Review tidak ditemukan → 404 | ✅ |
37| AC16 | Non-admin delete → 403 FORBIDDEN | ✅ |
38
39#### Edge Cases
40| EC | Description | Status |
41|----|-------------|--------|
42| EC1 | Concurrent review — race condition | ✅ UNIQUE INDEX |
43| EC2 | Rating update atomicity | ✅ Transaction |
44| EC3 | Product deleted cascade | ✅ Documented |
45
46### What Changed
47
48#### New Files
49- `internal/domain/review/entity.go` — Review entity
50- `internal/usecase/review/create_review.go` — Create usecase
51- `internal/usecase/review/list_reviews.go` — List usecase
52- `internal/usecase/review/delete_review.go` — Delete usecase
53- `internal/repository/postgres/review_repository.go` — Repository
54- `internal/delivery/http/handler/review_handler.go` — HTTP handlers
55- `migrations/20250702001_create_reviews.sql`
56- `migrations/20250702002_add_product_rating_columns.sql`
57
58#### Modified Files
59- `internal/domain/product/entity.go` — Added rating fields
60- `internal/delivery/http/router/router.go` — New routes
61
62### Test Coverage
63internal/domain/review/... 91.2%
64internal/usecase/review/... 89.4%
65internal/repository/postgres/... 85.1%
66internal/delivery/http/handler/... 88.7%
67Overall: 88.7% (target: 85%) ✅
68
69### Implementation Stats
70- Duration: 3h 45m
71- Commits: 14 (one per task)
72- Lines added: 1,247 / Lines deleted: 23
73- API token usage: 67,234 tokens (~$0.21)
74- Spec Kit time savings estimate: 5-8 hours vs manual
75
76### Checklist
77- [x] All ACs implemented and verified
78- [x] All ECs handled
79- [x] Test coverage ≥ 85%
80- [x] No race conditions (go test -race)
81- [x] Golangci-lint clean
82- [x] Migration files created
83- [x] Spec files committedPerhatikan tabel AC compliance dan bagian stats: reviewer langsung tahu apa yang berubah, seberapa lengkap coverage-nya, dan berapa cost token yang dihabiskan — semua konteks yang biasanya harus ditanyakan manual ke developer sudah tersaji sejak awal.
13.5 Konfigurasi PR Generation
Sama seperti commit, format PR juga dapat dikustomisasi. Konfigurasi berikut menentukan section mana yang disertakan, level detail perubahan, hingga reviewer default.
1# .speckit-config.yaml
2
3pr:
4 # Template file untuk PR description
5 template: .github/pull_request_template_speckit.md
6
7 # Section yang di-include di PR
8 include_sections:
9 - overview
10 - spec_reference
11 - spec_compliance
12 - what_changed
13 - test_coverage
14 - stats
15 - checklist
16
17 # Level detail untuk what_changed
18 detail_level: "file" # file | function | line
19
20 # GitHub labels yang di-apply ke PR
21 labels:
22 - "ready-for-review"
23 - "spec-driven"
24
25 # Reviewers yang di-request otomatis
26 default_reviewers:
27 - "tech-lead"
28 - "qa-team"
29
30 # Draft PR sampai semua tasks selesai
31 create_as_draft: true
32 convert_to_ready_when_done: trueDengan create_as_draft dan convert_to_ready_when_done, PR otomatis berstatus draft selama implementasi berjalan dan baru berubah menjadi ready saat semua task tuntas — mencegah reviewer masuk terlalu dini ke pekerjaan yang belum selesai.
13.6 Commit Signing dan Verification
Untuk proyek yang butuh verified commits, Spec Kit bisa menandatangani commit otomatis. Langkah berikut menyiapkan GPG key dan mengaktifkan signing di konfigurasi.
1# Setup GPG key
2gpg --gen-key
3git config --global user.signingkey YOUR_KEY_ID
4
5# .speckit-config.yaml
6git:
7 sign_commits: true
8
9# Setiap commit dari speckit.implement akan di-sign:
10# ✓ feat(review): implement CreateReview usecase (signed by @citra)Dengan signing aktif, setiap commit auto-generate tetap membawa badge “Verified” di GitHub — penting untuk repo yang menerapkan branch protection dengan syarat signed commits.
13.7 Gitflow Hook untuk Spec Validation
Auto-commit dari Spec Kit sudah pasti membawa spec reference, tapi commit manual bisa saja lolos tanpa referensi. Pre-commit hook berikut menegakkan aturan bahwa setiap commit di feature branch harus menyertakan spec reference.
1# .git/hooks/pre-commit (otomatis jika auto_install_hooks: true di config)
2
3#!/bin/bash
4# Check: setiap commit di feature branch harus ada spec reference
5
6BRANCH=$(git rev-parse --abbrev-ref HEAD)
7COMMIT_MSG=$(cat "$1")
8
9if [[ "$BRANCH" == feature/* ]]; then
10 if ! echo "$COMMIT_MSG" | grep -q "Implements:"; then
11 # Cek apakah ini commit manual atau dari speckit
12 if ! echo "$COMMIT_MSG" | grep -q "\[skip-spec\]"; then
13 echo "❌ Feature branch commits must reference spec"
14 echo " Add 'Implements: .specify/features/...' to commit message"
15 echo " Or use speckit.implement to auto-generate the commit"
16 echo " For manual commits, add '[skip-spec]' to skip this check"
17 exit 1
18 fi
19 fi
20fiHook ini menjadikan spec reference sebagai default yang ditegakkan tooling, bukan sekadar konvensi yang bergantung pada disiplin manual — dengan pintu keluar [skip-spec] untuk commit yang memang bukan spec-driven.
13.8 Viewing Spec-Referenced Commit History
Setelah git history penuh dengan spec reference, kamu bisa menambang informasi darinya. Perintah git log --grep berikut menyaring commit berdasarkan spec, fitur, hingga menghasilkan laporan audit.
1# Lihat semua commit yang reference spec
2git log --grep="Implements:" --oneline
3
4# Lihat commit untuk feature tertentu
5git log --grep="product-review" --oneline
6
7# Lihat spec compliance rate di git log
8git log --grep="Implements:" --format="%ai %s" | head -20
9
10# Generate report: fitur apa saja yang sudah di-implement
11specify audit --git-history
12# Output:
13# Products reviewed by AC count:
14# cancel-order: 10 ACs (complete, merged 2025-06-15)
15# product-review: 16 ACs (complete, merged 2025-07-02)
16# flash-sale: 8 ACs (in progress, branch: feature/SHOP-800-*)Karena setiap commit membawa penanda Implements:, git log berubah menjadi database yang bisa di-query — kamu bisa menjawab “fitur apa saja yang sudah selesai” hanya dengan satu perintah, bukan menelusuri board manual.
13.9 Amending Commits dari speckit.implement
Kadang commit auto dari Spec Kit perlu disesuaikan setelah dibuat. Perintah berikut menunjukkan cara amend perubahan spesifik maupun mengubah commit message tanpa kehilangan format spec reference.
1# Jika perlu amend commit terakhir
2git add -p # pilih perubahan spesifik
3git commit --amend --no-edit # amend tanpa ubah message
4
5# Jika perlu ubah commit message
6git commit --amend -m "feat(review): implement CreateReview usecase
7
8Implements: .specify/features/product-review/spec.md v1.0
9Spec reference: AC1-AC5, AC13, AC14
10Task: 07 from .specify/features/product-review/tasks.md
11
12DoD verified: all passed
13Note: Added additional validation for unicode content (not in original spec)"Saat mengamend, pastikan tetap mempertahankan blok Implements: agar hook validasi dan audit tetap mengenali commit tersebut sebagai spec-driven — bagian Note: adalah tempat ideal untuk mencatat deviation kecil dari spec.
13.10 PR di GitHub: Navigasi yang Lebih Baik
PR description yang di-generate Spec Kit mengubah cara reviewer bekerja. Alur berikut menggambarkan bagaimana reviewer bisa menelusuri dari spec ke kode dalam satu PR.
1# Di PR: click "Files changed"
2# Reviewer bisa lihat .specify/features/product-review/spec.md
3# Dan langsung compare: apakah implementasi sesuai spec?
4
5# GitHub memperlihatkan diff dari spec files:
6# + AC13: Customer belum beli produk → 422 PURCHASE_REQUIRED
7# (ini dari spec.md, dan reviewer bisa verify di handler test)
8
9# Review experience:
10# 1. Baca spec.md → pahami requirements
11# 2. Baca plan.md → pahami design decisions
12# 3. Review actual code → verify implementation
13# Semua dalam satu PRKarena spec ikut ter-commit bersama kode, reviewer tidak perlu berpindah antar tool — pertanyaan “apakah implementasi sesuai spec?” bisa dijawab langsung dari tab “Files changed” di PR yang sama.
13.11 Conventional Commits + Spec Kit
Commit yang dihasilkan Spec Kit sudah compatible dengan Conventional Commits, sehingga bisa langsung dipakai untuk otomasi rilis. Contoh berikut men-generate CHANGELOG dari riwayat commit.
1# Generate CHANGELOG dari commit history
2npx conventional-changelog -p angular -i CHANGELOG.md -s
3
4# CHANGELOG yang dihasilkan:
5# ## [1.2.0] — 2025-07-02
6#
7# ### Features
8# * **review**: implement product review feature (SHOP-789) (abc1234)
9# * **review**: add Review domain entity with validation (nop4567)
10# * **product**: add AverageRating and TotalReviewCount fields (mno3456)
11#
12# ## [1.1.0] — 2025-06-15
13#
14# ### Features
15# * **order**: implement cancel order (SHOP-456) (xyz9876)Karena type(scope) sudah konsisten sejak commit dibuat, CHANGELOG tergenerate rapi tanpa perlu menyunting satu baris pun — dokumentasi rilis menjadi produk sampingan gratis dari disiplin commit.
13.12 Auto-Tag setelah Merge
Spec Kit juga bisa diintegrasikan dengan proses rilis untuk menandai versi otomatis. Konfigurasi berikut mengatur auto-tag dan pembuatan release note setelah merge ke main.
1# .speckit-config.yaml — release integration
2
3release:
4 # Auto-tag setelah merge ke main (butuh semantic-release)
5 auto_tag: false
6
7 # Jika true: generate release note dari semua spec yang di-merge
8 generate_release_notes: true
9
10 # Release note format
11 release_notes_include:
12 - feature_name
13 - ac_count
14 - commit_linkDengan generate_release_notes, setiap rilis membawa ringkasan fitur beserta jumlah AC yang diselesaikan — memberi stakeholder gambaran cakupan rilis tanpa perlu membaca kode.
13.13 Audit Commit Compliance
Untuk memastikan disiplin spec reference dipatuhi, Spec Kit menyediakan audit compliance. Perintah berikut menghitung persentase commit di branch yang membawa spec reference.
1# Cek: berapa persen commit di feature branch yang punya spec reference
2specify audit --compliance --feature product-review
3
4# Output:
5# Commit compliance check — feature/SHOP-789-product-review
6#
7# Total commits: 15
8# With spec reference: 14 (93.3%)
9# Without spec reference:
10# - "Initial commit: project setup" (expected — not spec-driven)
11#
12# Compliance rate: 93.3% ✅Angka compliance ini bisa dijadikan quality gate objektif: alih-alih berdebat soal “apakah tim disiplin”, kamu punya metrik konkret yang bisa dipantau per branch.
13.14 Multi-Author Commits dalam Tim
Saat beberapa developer berkolaborasi di satu branch, atribusi tetap penting. Perintah berikut menunjukkan cara menandai author dan reviewer di dalam commit spec-driven.
1# Task 07 di-implement oleh @citra
2# Task 08 di-implement oleh @andi (peer programming)
3
4git commit --author="Citra <citra@santekno.com>" \
5 -m "feat(review): implement CreateReview usecase
6
7Implements: .specify/features/product-review/spec.md v1.0
8Task: 07 — implemented by @citra, reviewed by @andi"Dengan mencantumkan author dan reviewer di commit body, kontribusi tiap anggota tetap terlacak meski pekerjaan dilakukan berpasangan — berguna saat menelusuri siapa yang paham konteks sebuah task di kemudian hari.
13.15 Tips untuk Commit Message yang Lebih Baik
Meski commit message di-generate otomatis, kamu bisa menambahkan konteks “why” yang tidak ada di spec. Perintah berikut menyisipkan catatan keputusan teknis ke dalam commit.
1# Tambahkan "why" yang tidak ada di spec:
2specify implement --feature product-review --task 06 \
3 --commit-note "Used pgx advisory lock instead of SELECT FOR UPDATE for better performance at scale"
4
5# Commit message yang dihasilkan:
6# feat(review): implement review repository with atomic operations
7#
8# Implements: ...
9# Note: Used pgx advisory lock instead of SELECT FOR UPDATE
10# for better performance at scale (load test showed 40% improvement)Spec menjelaskan “apa” yang harus dibangun, tapi flag --commit-note mengabadikan “mengapa” sebuah keputusan teknis diambil — konteks yang paling sering hilang dan paling dibutuhkan saat regresi muncul berbulan-bulan kemudian.
13.16 Git Bisect dengan Spec References
Ketika bug muncul di production, spec reference mempercepat pencarian akar masalah. Alur berikut menggabungkan git bisect dengan pencarian commit berbasis AC.
1# Git bisect untuk cari commit yang introduce bug
2git bisect start
3git bisect bad HEAD
4git bisect good v1.1.0
5
6# Spec Kit membantu: cari commit yang implement AC yang relevan
7git log --grep="Implements.*product-review.*AC4" --oneline
8# → abc1234: feat(review): implement CreateReview usecase
9
10# Isolasi bug ke task level:
11git checkout abc1234
12specify audit --feature product-review --task 07
13# Cek apakah DoD masih lulus di commit lama iniKarena setiap commit menyimpan AC yang diimplementasikannya, kamu bisa langsung melompat ke commit yang menyentuh perilaku bermasalah — mempersempit ruang pencarian bug dari puluhan commit menjadi satu task saja.
13.17 PR Review Best Practices dengan Spec
Reviewer butuh pendekatan yang berbeda saat mereview PR hasil Spec Kit. Checklist berikut memandu reviewer untuk memeriksa spec lebih dulu, baru kode.
1## Checklist untuk Reviewer
2
3### Spec Review (sebelum lihat kode)
4- [ ] Baca spec.md — apakah spec masuk akal dari perspektif bisnis?
5- [ ] Baca clarifications.md — apakah semua pertanyaan kritis sudah dijawab?
6- [ ] Lihat spec compliance table di PR description — ada yang missing?
7
8### Plan Review
9- [ ] Baca plan.md — apakah design decisions sound?
10- [ ] Risk analysis — apakah ada risk yang terlewat?
11- [ ] Open questions — semua sudah di-resolve?
12
13### Code Review
14- [ ] Verify: kode sesuai spec (bukan spec sesuai kode)
15- [ ] Verify: error codes match exact AC requirement
16- [ ] Verify: test coverage mencakup semua ACs dan edge cases
17- [ ] Verify: tidak ada kode yang tidak ada di tasks tapi di-implement
18 (scope creep dari AI — perlu dicek)Urutan review “spec dulu, kode belakangan” memastikan reviewer menilai apakah kode mengikuti spec — bukan sebaliknya menerima kode apa adanya lalu merasionalisasi spec agar cocok.
13.18 Auto-PR dan Draft PR
Spec Kit mendukung siklus PR dari draft awal hingga ready. Perintah berikut membuat draft PR sejak tahap spec, lalu memperbaruinya seiring implementasi selesai.
1# Buat draft PR dari awal (setelah specify + clarify)
2specify pr --feature product-review --draft --create
3# → Draft PR dengan spec saja, belum ada kode
4
5# Update PR setelah implementasi selesai
6specify pr --feature product-review --update
7
8# Convert draft ke ready
9specify pr --feature product-review --readyDengan membuka draft PR sejak spec disetujui, tim mendapat ruang diskusi lebih awal tentang arah desain — jauh sebelum satu baris kode ditulis, saat perubahan masih murah dilakukan.
13.19 Integration dengan GitHub Actions
Enforcement paling kuat datang dari CI. Workflow GitHub Actions berikut menjalankan spec compliance check dan memverifikasi commit message di setiap PR.
1# .github/workflows/spec-pr-check.yml
2
3name: Spec PR Check
4
5on:
6 pull_request:
7 types: [opened, synchronize, reopened]
8
9jobs:
10 spec-compliance:
11 runs-on: ubuntu-latest
12 steps:
13 - uses: actions/checkout@v4
14 with:
15 fetch-depth: 0 # full history needed
16
17 - name: Install Spec Kit
18 run: npm install -g @github/spec-kit
19
20 - name: Extract feature name from branch
21 run: |
22 BRANCH="${GITHUB_HEAD_REF}"
23 FEATURE=$(echo "$BRANCH" | sed 's/feature\/[A-Z0-9-]*-//')
24 echo "FEATURE=$FEATURE" >> $GITHUB_ENV
25
26 - name: Check spec compliance
27 env:
28 ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
29 run: |
30 if [ -d ".specify/features/$FEATURE" ]; then
31 specify audit --feature $FEATURE --output github-checks
32 else
33 echo "⚠️ No spec found for feature: $FEATURE"
34 echo "This PR may not be spec-driven. Proceed with caution."
35 fi
36
37 - name: Verify commit message compliance
38 run: |
39 # Check that all non-initial commits have spec references
40 COMMITS=$(git log origin/main..HEAD --oneline | wc -l)
41 SPEC_COMMITS=$(git log origin/main..HEAD --grep="Implements:" --oneline | wc -l)
42 echo "Spec-referenced commits: $SPEC_COMMITS / $COMMITS"Dengan check ini berjalan di setiap PR, spec compliance menjadi syarat merge yang otomatis — deviation tidak bisa lolos ke main tanpa ketahuan, tanpa perlu reviewer mengingat untuk memeriksanya manual.
13.20 Ringkasan
Auto-commit dari speckit.implement dan PR generation dari specify pr menghilangkan dua pain point terbesar dalam Git workflow: commit message yang informatif dan PR description yang lengkap.
Commit messages yang di-generate mengikuti Conventional Commits, traceable ke spec dan task, dan menyertakan DoD verification summary — git history menjadi dokumentasi yang bisa dibaca manusia.
PR description yang di-generate menyertakan AC compliance table, what changed, coverage report, dan implementation stats — reviewer mendapat semua konteks yang diperlukan tanpa perlu bertanya ke developer.
CI integration memastikan semua commit di feature branch punya spec reference — enforcement otomatis tanpa friction manual.
Di artikel berikutnya, kita bahas update CLAUDE.md otomatis — bagaimana Spec Kit membantu menjaga konteks AI tetap akurat seiring proyek berkembang.