SpecKit AI Workflow
Relevant source files
The following files were used as context for generating this wiki page:
The SpecKit AI Workflow defines a structured, multi-phase process for developing and implementing features within the infrahub-ops-cli project. It ensures that features move from high-level requirements to technical specifications, implementation plans, and finally to executable tasks with clear quality gates and testing requirements.
This workflow enforces the "Split-Binary, Shared-Core" architecture, where specialized binaries like infrahub-backup, infrahub-taskmanager, and infrahub-collect share common internal logic located in src/internal/app.
Sources: AGENTS.md:144-150, specs/archive/003-collect-tool/plan.md:33-40
Workflow Lifecycle
The development lifecycle follows a strict progression of artifacts, ensuring technical alignment and constitution compliance before code implementation.
The diagram shows the progression from initial specification to final project archiving.
Sources: dev/README.md:5-10, specs/archive/003-collect-tool/plan.md:23-28
Phase 1: Specification (Specify)
The workflow starts with a spec.md that defines user stories, functional requirements, and success criteria without leaking implementation details. This stage focuses on user value and business needs.
Sources: specs/archive/003-collect-tool/checklists/requirements.md:10-15, specs/004-backup-retention-policy/checklists/requirements.md:10-15
Phase 2: Implementation Planning (Plan)
The planning phase produces a plan.md that maps requirements to technical architecture. This document identifies affected files, defines testing strategies, and performs a "Constitution Check" against the project's core principles.
Sources: specs/archive/003-collect-tool/plan.md:1-10, specs/004-backup-retention-policy/plan.md:1-10
Phase 3: Task Generation (Tasks)
The tasks.md file breaks down the plan into granular, trackable items. Each task is mapped to a specific user story (US1, US2, etc.) and priority.
Sources: specs/archive/003-collect-tool/tasks.md:1-10, specs/005-restore-latest-backup/tasks.md:1-10
Core Development Principles
The workflow adheres to five mandatory principles defined in the project constitution.
| Principle | Requirement |
|---|---|
| I. Split-Binary | Entry points in src/cmd/ must remain thin; logic must reside in src/internal/app. |
| II. Operational Safety | Destructive operations require explicit confirmation or --force flags. |
| III. Self-Contained | Binaries must be statically linked (CGO_ENABLED=0) and cross-platform. |
| IV. Quality Gates | All changes must pass make test, make vet, make lint, and make fmt. |
| V. Feedback | Commands must provide streaming progress feedback via standard logging. |
| Sources: specs/archive/003-collect-tool/plan.md:33-46, specs/004-backup-retention-policy/plan.md:35-48 |
Implementation and Verification
Implementation occurs in defined chunks, each ending with a verification checkpoint.
The sequence diagram illustrates the iterative implementation and testing loop for each feature chunk.
Sources: specs/archive/003-collect-tool/opsmill-implement-report.md:12-25, specs/archive/003-collect-tool/plan.md:20-22
Testing Strategy
- Unit Tests: Table-driven tests in Go located in
src/internal/app/*_test.gocover pure logic like manifest construction or secret masking. - End-to-End (E2E) Tests: Python-based tests using
pytestlocated intests/e2e/verify binary behavior against real Docker Compose or Kubernetes (vcluster) deployments.
Sources: specs/archive/003-collect-tool/plan.md:20-25, pyproject.toml:25-31
Artifact Archiving
Once a feature is implemented and verified, the documentation is moved to a durable format. ADRs (Architecture Decision Records) and knowledge base articles are extracted into the dev/ directory, while original specifications are archived in specs/archive/.
Sources: dev/README.md:1-10
The SpecKit AI Workflow ensures technical precision and maintains the project's architectural integrity throughout the software development lifecycle.