feedback_adopt_spec_kit_git_extensions_for_standardisation

Rich-directive verbatim 2026-05-24T~21:50 BST: “i would like to use Spec-Kit’s git extensions such as auto-commit.sh, create-new-feature.sh, git-common.sh and git-common.sh as well as any others. i want to adopt standardised code from spec-kit rather than maintain our own functionality”.

Decision

Adopt Spec-Kit’s git extension across all 7 TT repos when Path E launch-prompt executes. Includes:

• .specify/extensions/git/scripts/bash/: auto-commit.sh, create-new-feature.sh, git-common.sh, initialize-repo.sh
• .specify/extensions/git/scripts/powershell/ siblings
• .specify/extensions/git/git-config.yml (per-repo config; auto_commit.default: false is safe default)
• 5 SKILL.md files in .claude/skills/: speckit-git-commit, speckit-git-feature, speckit-git-initialize, speckit-git-remote, speckit-git-validate

Safety analysis (smoke-test 2026-05-24T~21:40 BST)

• auto_commit.default: false in shipped git-config.yml — DISABLED for all 17 events by default. Each event must be explicitly opted-in per-repo. No surprise commits.
• 2 mandatory hooks (not opt-out-able): before_constitution → speckit.git.initialize (one-shot; gracefully skips if .git/ exists); before_specify → speckit.git.feature (creates feature branch).
• auto-commit.sh runs git add . && git commit WITHOUT --no-verify — TT’s pre-commit hooks (frontmatter-pin-drift + lock-cascade-completeness + BUILD-PLAN-sync) STILL FIRE. Spec-Kit auto-commits FAIL if TT’s hooks block. Correct behavior; no --no-verify conflict with feedback-methodology-migration-cascade-q-pairing-mandatory.
• initialize-repo.sh checks for existing .git/ — gracefully skips. TT repos already have git; this hook is a no-op for TT.

What TT loses (replaced by Spec-Kit’s standardisation)

Honestly examined: TT didn’t have a create-new-feature.sh or auto-commit.sh to replace. What gets STANDARDISED:

• TT’s commit-message conventions (currently informal) → Spec-Kit’s [Spec Kit] <event> prefix templates
• TT’s manual feature-branch creation when needed → automated via create-new-feature.sh
• TT’s git-utility wrappers (if any drift in scripts) → Spec-Kit’s git-common.sh (has_git, check_feature_branch, spec_kit_effective_branch_name)
• The DISCIPLINE of running migrations/audits as numbered work units → encoded in Spec-Kit’s feature-branch numbering

What stays TT-native (complementary, not overlapping):

• All TT pre-commit hooks (substrate validation gates — different layer from automation)
• arch-state amendment registry (TT-specific Tier-1 substrate)
• Cascade-Q file discipline
• companion_files pin-drift validation
• Active-work-log (parent-workspace coordination layer)

Workflow lock — Rich-locked 2026-05-24T~21:55 BST

PE-4 = Mode B (Hybrid). Verbatim Rich-selection: “Mode B — Hybrid (Recommended for migration)”.

Operative meaning:

• Spec-Kit git extension INSTALLED across all 7 TT repos (PE-2)
• /speckit-specify slash command available; creates feature branches when invoked
• Phase D” Stage 3.5 migration work (existing BUILD-PLAN.md → spec.md+plan.md+tasks.md): write files BY HAND, commit to main directly (NOT via /speckit-specify)
• Post-Path-E NEW feature work: invoke /speckit-specify properly → triggers before_specify hook → creates feature branch → spec authored on branch → PR cycle
• Boundary between “migration” and “new work” is the Path E launch-prompt landing (commit timestamp / arch-state A-290)

Mode A (full feature-branch-per-spec from day 1) was REJECTED. Reasoning Rich preserved: avoid the 5-PR overhead during Stage 3.5; minimal disruption to migration; full workflow kicks in for clean new-feature work.

Path E sub-decisions this directive cascades into

Sub-decision	Options	Recommendation
PE-2 (revised)	git extension INCLUDED vs EXCLUDED	INCLUDED (per this directive)
PE-4 (new)	Mode A (full feature-branch) vs Mode B (hybrid)	Mode B for Phase D” migration; Mode A for post-landing new features
PE-5 (new)	Branch numbering: sequential 001- vs timestamp YYYYMMDD-HHMMSS-	Timestamp — matches TT’s existing date-prefix conventions in non-markdown files; survives parallel-session concurrency better
PE-6 (new)	Auto-commit defaults: keep default: false vs enable subset	Keep default: false initially; review after first 5 specs land via Mode A

When to read this memory

• Authoring Path E launch-prompt (task #66) — load-bearing for PE-2..PE-6 decisions
• When future framework-evaluation surfaces “should we use upstream tooling vs maintain our own?” — Rich-directive precedent for choosing standardisation
• When TT’s commit conventions feel ad-hoc — Spec-Kit’s [Spec Kit] <event> templates are the upstream pattern

Related

• feedback-adopt-github-spec-kit (Path E lock; this directive operationalises the git portion)
• feedback-methodology-migration-cascade-q-pairing-mandatory (no --no-verify discipline preserved under Spec-Kit’s auto-commit because Spec-Kit runs git commit without bypass flags)
• feedback-no-sdd-framework-solves-multi-repo-for-tt (parent-workspace coordination layer stays; git extension only standardises per-repo automation)
• Path E pivot SCF at docs/superpowers/specs/2026-04-29-multi-phase-audit/batch-imp-24-phase-d-double-prime-path-e-pivot-research-findings-v1.0.md