✅ REINSTATED 2026-05-24T21:20 BST — Path E (Spec-Kit per-repo + TT-native coordination) restored as canonical after Phase D” execution-attempt 2026-05-24T20:54→21:20 BST surfaced the substrate-correcting findings collapsing Path D’s 96% scorecard to ~78-82%. See feedback-adopt-bmad-plus-openspec-hybrid (superseded; audit-only) and the 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.mdfor the 6 empirical findings + scorecard re-run. Content below is the original 2026-05-23T18:00 BST framing; reinforced by 2026-05-24 empirical evidence (see SCF §2). When a future session authors the Path E launch-prompt, START from this memory + SCF, NOT from the Path D launch-prompt v1.5 (superseded).
Rich-directive 2026-05-23T~18:00 BST: “i am convinced that adopting GitHub Spec Kit is a good move” — after the second SOTA research pass surfaced Spec Kit as the canonical SDD framework that:
- Maps cleanly to TT’s existing discipline (constitution.md ≈ CLAUDE.md/arch-state.md; spec.md ≈ cascade-Q file per decision; plan.md ≈ BUILD-PLAN.md; tasks.md ≈ Native Tasks + Linear Issues)
- Ships 6 slash commands as Agent Skills:
/speckit.constitution+/speckit.specify+/speckit.plan+/speckit.tasks+/speckit.taskstoissues+/speckit.implement - Supports brownfield adoption explicitly (TT’s case — 7 in-scope repos with existing structure)
- Cross-tool portable across Claude Code + Codex CLI + Cursor + GitHub Copilot + Gemini CLI + 20+ other AI agents
- Includes
/speckit.taskstoissueswhich auto-creates GitHub Issues from tasks → Linear’s GitHub integration auto-mirrors to Linear Issues (may simplify Phase C scope)
Strategic implications:
- Phase D’ scope grows from “AGENTS.md + SKILL.md alignment” to “Spec Kit adoption” — Spec Kit is a complete framework that incorporates AGENTS.md + SKILL.md + EARS-notation acceptance criteria + cross-tool config + CLI tooling. Phase D’ becomes Phase D”.
- Steven-readiness: Spec Kit gives Codex native compatibility. When Steven onboards on his preferred Codex CLI, he’ll find
.specify/+memory/constitution.md+specs/already populated in TT repos. No re-authoring; he works in his tool of choice immediately. - Phase C interaction:
/speckit.taskstoissues+ Linear’s native GitHub integration may cover what Phase C’s Linear MCP scope was going to build. Worth re-evaluating Phase C scope after Spec Kit adoption lands. - Phase B is COMPATIBLE: Phase B is migrating BUILD-PLAN.md to Shape A (step-N + depends_on + exit_criteria + checkbox). Shape A maps directly to Spec Kit’s plan.md shape. Post-Phase-B BUILD-PLAN.md files can be renamed to plan.md (or symlinked) with minimal additional work.
Spec Kit specifics to honour during adoption:
- CLI is Python-based —
uvrecommended for installation (clean + reproducible per the project’s own guidance) - Multi-repo support is community-preset (
sakitA/spec-kit-preset-multi-repo-branching), not first-class. TT has 7 in-scope repos under~/testatetech/parent → needs the preset OR per-repo Spec Kit installs --no-gitflag for monorepo cases or projects with existing git setup; Spec Kit is moving Git functionality to opt-in starting 1.0.0- Brownfield discipline: per EPAM’s adoption guidance — provide architectural context upfront; share API contracts; well-defined acceptance criteria (“endpoint returns 200” not “endpoint works”); spec quality drives task + implementation quality
- Core principles in constitution.md (per EPAM example): “Code duplication is prohibited”; “Search for existing functions before creating a new one”; per-layer reuse rules. These match TT’s existing CLAUDE.md disciplines.
- AGENTS.md stewardship: now under the Agentic AI Foundation (Linux Foundation) — stable open standard, not vendor-controlled
File-mapping decisions deferred to Phase D” authoring (Rich-lock per question at launch-prompt review):
| TT artefact | Spec Kit equivalent | Open question |
|---|---|---|
| arch-state.md (cross-repo Tier-1) | memory/constitution.md (per repo) | Cross-repo Tier-1 vs per-repo: how to bridge? |
| CLAUDE.md per repo | AGENTS.md + CLAUDE.md symlink | Symlink pattern; Claude-specific bits go to .claude/ overlay |
| cascade-Q files | specs/Q-NNN/spec.md | Rename / symlink / leave-as-is — Rich-lock |
| BUILD-PLAN.md (post-Phase-B Shape A) | specs/ | Rename after Phase B lands |
| Native Tasks (tt-inherit-v2) | specs/ | Coexistence pattern |
| frontmatter-conventions.md | Spec Kit metadata schema | Align TT-specific extensions with Spec Kit conventions explicitly |
Tactical decisions Rich locks at Phase D” launch-prompt review (knock-on sequence):
- Spec Kit scope: per-repo vs root + multi-repo preset (highest knock-on; determines all paths)
- arch-state.md vs memory/constitution.md mapping (cross-repo Tier-1 bridge pattern)
- CLI install (
pip/uv) vs convention-only adoption (determines tooling footprint) - Spec Kit’s
/speckit.taskstoissuesimpact on Phase C Linear MCP scope (overlap re-evaluation) - AGENTS.md content split (tool-agnostic vs Claude-specific overlay)
- EARS notation timing (Phase D” or Phase B trailing or separate)
/speckit.implementautonomous-execution discipline (currently interactive per TT; adoption affects this)
Related: feedback-build-plan-hybrid-shape-a-narrative-plus-native-tasks (Shape A is already Spec-Kit-compatible; just needs filename alignment); feedback-prompts-comprehensive-and-fully-detailed (Phase D” launch-prompt will be comprehensive per the recent flip).