Git Workflow Spec Kit Golang: Auto-Commit and Automated PRs

Git Workflow: Auto-Commit and PR from Spec Kit

Setting up a solid git workflow with Spec Kit for Golang auto-commit removes two of the biggest daily frictions in software development: writing informative commit messages and assembling comprehensive PR descriptions. speckit.implement solves both at once — every task produces a structured, spec-traceable commit, while specify pr generates a complete PR description in seconds. The result is a git history that reads like documentation and pull requests that answer a reviewer’s questions before they are asked.

In this article we walk through the commit anatomy Spec Kit emits, how to configure it, and how the generated artifacts plug into CHANGELOG tooling, pre-commit hooks, and CI.

13.1 The Anatomy of a Spec Kit Commit

The value of auto-commit starts with the shape of the message itself. Every commit speckit.implement produces follows a fixed template that ties the change back to a specific acceptance criterion and task. The example below shows a real commit for a CreateReview usecase.

 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% ✓
11- Error code 'PURCHASE_REQUIRED' verified ✓

The takeaway: each commit carries its own audit trail — which spec version it implements, which ACs it satisfies, and which Definition-of-Done checks passed. Months later, git log alone can tell you exactly why a line of code exists.

13.2 Configuring the Commit Message

The commit template is not hard-coded; you steer it from .speckit-config.yaml. The configuration below maps task types to Conventional Commit prefixes and controls what extra metadata lands in the commit body.

 1# .speckit-config.yaml
 2git:
 3  # Map task type → Conventional Commit type
 4  commit_types:
 5    domain: "feat"
 6    usecase: "feat"
 7    repository: "feat"
 8    handler: "feat"
 9    migration: "feat"
10    test: "test"
11    config: "chore"
12    docs: "docs"
13
14  auto_scope: true              # scope inferred from the modified domain
15  include_dod_summary: true     # DoD verification summary in the body
16  include_token_usage: false    # set true to track API cost per commit
17  sign_commits: false           # requires GPG setup
18  auto_issue_ref: true          # pull ticket from branch: feature/SHOP-789-*
19  issue_prefix: "SHOP"

The key point: with auto_scope and auto_issue_ref enabled, the scope and ticket reference are derived from the domain and branch name automatically — you never type them by hand, and they never drift out of sync.

13.3 The Generated Commit History

Because one task produces one commit, the git log for a finished feature becomes a readable roadmap of the implementation. The log below shows all fourteen commits for the product-review feature.

 1git log --oneline feature/SHOP-789-product-review
 2
 3abc1234 feat(review): e2e smoke test verified — product review COMPLETE
 4bcd2345 feat(router): register review endpoints under /products/:id/reviews
 5cde3456 feat(review): add handler tests (12 tests covering all error paths)
 6def4567 feat(review): implement HTTP handlers CreateReview, ListReviews, DeleteReview
 7efg5678 feat(review): implement DeleteReview usecase with admin authorization
 8fgh6789 feat(review): implement ListReviews usecase with pagination and sorting
 9ghi7890 test(review): add CreateReview usecase tests (8 test cases)
10hij8901 feat(review): implement CreateReview usecase with purchase verification
11ijk9012 feat(db): add average_rating and total_review_count to products table
12jkl0123 feat(review): implement review repository with atomic operations
13klm1234 feat(review): add ReviewRepository interface with 5 methods
14lmn2345 feat(db): create reviews table with unique constraint
15mno3456 feat(product): add AverageRating and TotalReviewCount fields
16nop4567 feat(review): add Review domain entity with status and validation

What to notice: each commit has a single, clear purpose and is traceable to a task. Reviewers can walk the history top to bottom and understand the feature without opening a single design document.

13.4 Generating the PR Description

Once the commits are in place, specify pr assembles the pull request. It can print to the terminal for review or create the PR directly through the GitHub CLI. The commands below cover both paths.

1# Print the PR description to the terminal
2specify pr --feature product-review
3
4# Create the PR directly via GitHub CLI
5specify pr --feature product-review --create

The generated PR body is not a one-line summary — it is a full compliance report. The excerpt below shows the AC compliance table that anchors every Spec Kit PR.

 1## feat(review): implement product review feature [SHOP-789]
 2
 3### Spec Reference
 4| Item             | Value                                       |
 5|------------------|---------------------------------------------|
 6| Spec             | `.specify/features/product-review/spec.md`  |
 7| Spec approved by | @budi on 2025-07-02                         |
 8| Implementation   | @citra                                      |
 9
10### Acceptance Criteria
11| AC   | Description                                  | Status |
12|------|----------------------------------------------|--------|
13| AC1  | POST /products/:id/reviews accepts rating    | ✅     |
14| AC2  | Verify customer purchased product (DELIVERED)| ✅     |
15| AC13 | Not purchased → 422 PURCHASE_REQUIRED        | ✅     |
16| AC14 | Already reviewed → 422 ALREADY_REVIEWED      | ✅     |
17
18### Implementation Stats
19- Commits: 14 (one per task) · Lines: +1,247 / -23
20- API token usage: 67,234 tokens (~$0.21)
21- Estimated time savings: 5-8 hours vs manual

The takeaway: the reviewer receives the full picture — who approved the spec, every AC and its status, the files touched, coverage, and cost — without ever asking the developer for context. Review time drops because the evidence is already in front of them.

13.5 Configuring PR Generation

Just like commits, the PR output is configurable. The block below controls which sections appear, which labels and reviewers are attached, and whether the PR opens as a draft until the feature is complete.

 1# .speckit-config.yaml
 2pr:
 3  template: .github/pull_request_template_speckit.md
 4  include_sections:
 5    - overview
 6    - spec_reference
 7    - spec_compliance
 8    - what_changed
 9    - test_coverage
10    - stats
11    - checklist
12  detail_level: "file"          # file | function | line
13  labels: ["ready-for-review", "spec-driven"]
14  default_reviewers: ["tech-lead", "qa-team"]
15  create_as_draft: false
16  convert_to_ready_when_done: true

The practical benefit: create_as_draft plus convert_to_ready_when_done lets you open a draft PR right after specify and clarify — spec first, code later — and have it flip to ready automatically once every task passes.

13.6 Commit Signing and Verification

For projects that mandate verified commits, Spec Kit can sign each auto-generated commit with your GPG key. The setup below wires GPG into the workflow.

 1# One-time GPG setup
 2gpg --gen-key
 3git config --global user.signingkey YOUR_KEY_ID
 4
 5# .speckit-config.yaml
 6git:
 7  sign_commits: true
 8
 9# Every commit from speckit.implement is now signed:
10# ✓ feat(review): implement CreateReview usecase (signed)

The point to remember: signing is a single config flag away, so you get verified provenance on machine-generated commits without changing how you run speckit.implement.

13.7 A Pre-Commit Hook for Spec Validation

To keep the workflow honest, a pre-commit hook can reject any feature-branch commit that lacks a spec reference. The script below enforces that rule while allowing a deliberate [skip-spec] escape hatch.

 1# .git/hooks/pre-commit
 2#!/bin/bash
 3BRANCH=$(git rev-parse --abbrev-ref HEAD)
 4COMMIT_MSG=$(cat "$1")
 5
 6if [[ "$BRANCH" == feature/* ]]; then
 7    if ! echo "$COMMIT_MSG" | grep -q "Implements:"; then
 8        if ! echo "$COMMIT_MSG" | grep -q "\[skip-spec\]"; then
 9            echo "❌ Feature branch commits must reference a spec"
10            echo "   Add 'Implements: .specify/features/...' or use speckit.implement"
11            echo "   For legitimate manual commits, add '[skip-spec]'"
12            exit 1
13        fi
14    fi
15fi

The takeaway: enforcement happens locally, before code ever leaves the machine — spec traceability becomes a property of the branch rather than a habit you have to remember.

13.8 Conventional Commits and Automatic CHANGELOG

Because the commit types follow Conventional Commits, the history feeds straight into changelog tooling with no manual editing. The commands below generate a CHANGELOG from the same commits Spec Kit produced.

1# Generate a CHANGELOG from commit history
2npx conventional-changelog -p angular -i CHANGELOG.md -s
3
4# ## [1.2.0] — 2025-07-02
5# ### Features
6# * **review**: implement product review feature (SHOP-789) (abc1234)
7# * **review**: add Review domain entity with validation (nop4567)
8# * **product**: add AverageRating and TotalReviewCount fields (mno3456)

The lesson here: release notes stop being a manual chore. Every feature you ship with Spec Kit is already formatted for automatic release documentation.

13.9 CI Integration for Commit Compliance

The final guardrail lives in CI, where every PR is checked for spec compliance and commit-message discipline. The workflow below verifies AC coverage and confirms that feature-branch commits reference a spec.

 1# .github/workflows/spec-pr-check.yml
 2name: Spec PR Check
 3on:
 4  pull_request:
 5    types: [opened, synchronize, reopened]
 6jobs:
 7  spec-compliance:
 8    runs-on: ubuntu-latest
 9    steps:
10      - uses: actions/checkout@v4
11        with:
12          fetch-depth: 0
13      - name: Install Spec Kit
14        run: npm install -g @github/spec-kit
15      - name: Verify commit message compliance
16        run: |
17          COMMITS=$(git log origin/main..HEAD --oneline | wc -l)
18          SPEC_COMMITS=$(git log origin/main..HEAD --grep="Implements:" --oneline | wc -l)
19          echo "Spec-referenced commits: $SPEC_COMMITS / $COMMITS"

The takeaway: what the pre-commit hook enforces locally, CI enforces for the whole team — deviation cannot slip into main unnoticed, and there is zero manual friction to keep it that way.

13.10 Git Bisect with Spec References

Spec-referenced commits pay off again when hunting regressions. Because each commit names the AC it implements, git bisect and git log --grep narrow a production bug to a single task fast. The snippet below shows the flow.

1git bisect start
2git bisect bad HEAD
3git bisect good v1.1.0
4
5# Jump straight to the commit implementing the suspect AC:
6git log --grep="Implements.*product-review.*AC4" --oneline
7# → abc1234: feat(review): implement CreateReview usecase

The point: spec references turn a blind binary search into a targeted lookup — you find the offending task, not just the offending commit, and you know which acceptance criterion to re-verify.

13.11 Summary

Auto-commit from speckit.implement and PR generation from specify pr eliminate the two biggest pain points in a git workflow:

• Commit messages follow Conventional Commits, trace to a spec and task, and include a DoD summary — the git history becomes human-readable documentation.
• PR descriptions ship with an AC compliance table, a change list, a coverage report, and implementation stats — reviewers get every piece of context without asking the developer.
• CI and pre-commit enforcement guarantee that feature-branch commits reference a spec — automatic discipline without manual overhead.

In the next article, we tackle automatic CLAUDE.md updates — how Spec Kit keeps your AI’s project context accurate as the codebase evolves, so Claude never generates code against stale conventions.