Codex
Claude
GeminiWhat you do
- Describe the desired outcome, constraints, and authority boundary.
- Review material design choices or production-risk gates.
- Inspect verification, review findings, and residual risk before release.
Product and engineering teams delivering repository changes / engineering
Engineering Tracked Delivery
A delivered change with an explicit flow, truthful tracker state, proportionate verification, independent review, and release evidence.
From request to resultA complete plan you can follow.
Visible planThe problem
Engineering requests fail when requirements, dependencies, verification, and review live only in chat or are compressed into implementation.
AI can coordinate discovery, implementation, testing, and review across a long-running change while StackOS preserves dependencies and proof.
What the agent does
- Define requirements and affected flows before planning tickets.
- Discover the real code and system boundaries, then design the approach and proof plan.
- Deliver through dependency-linked tickets, run the planned verification, and adjudicate independent review.
- Audit tracker truth and close only when evidence matches the result.
When this workflow helps
A reusable method, adapted to the request.
- A user asks for engineering work that needs planning, implementation, review, and signoff.
- A user explicitly asks to use a workflow, engineering workflow, StackOS workflow, "the workflow", or to follow the SDLC for engineering delivery.
- A user asks for release-grade delivery or equivalent lifecycle language that implies requirements-to-release enforcement.
- Work should be visible as tracker tasks/tickets with dependencies, blockers, evidence, and release state.
- A project wants host-local agents configured from SDLC presets for a concrete delivery flow.
- The change touches contracts, tests, UI, data, provider behavior, MCP/REST/CLI operation surfaces, docs, or release risk.
Before it starts
Ready with project context
- Repository instructions and source access
- A desired outcome and acceptance boundary
- Authority for the requested file or system changes
What proves it worked
Evidence, not a success claim.
- Requirements and flow map
- Dependency-linked delivery tickets
- Automated and risk-appropriate manual verification
- Independent review adjudication
- Tracker and release closeout evidence
Workflow path
The reusable stages of the work.
A real run expands these stages around the request, context, selected tools, approvals, and dependencies.
- 01Passes to next stage
Scope Work
Restate the engineering goal, delivery mode, constraints, project setup, host-agent format, and missing context.
- 02Passes to next stage
Define Requirements And Flows
Convert user intent into explicit user, data, system, and business flows, acceptance criteria, non-goals, and evidence expectations.
- 03Passes to next stage
Discover Impact
Map affected scopes, real execution paths, ownership boundaries, downstream readers, tests, docs, and signoff fallout.
- 04Passes to next stage
Plan Tracker Tickets
Create or update tracker tasks/tickets with dependencies, sequencing, blockers, owned scopes, and definition of done.
- 05Passes to next stage
Design Approach
Identify canonical ownership, shared operations, data invariants, adapter surfaces, grants, docs, tests, rollout, and rollback implications.
- 06Passes to next stage
Review Design
Challenge the requirements, impact map, ticket plan, and design before implementation.
- 07Passes to next stage
Design Tests, TDD, And Manual Scenarios
Own the full proof plan before delivery: TDD/red-first automated tests, verification commands, agent-executed E2E/manual flow scenarios, expected…
- 08Passes to next stage
Deliver Tickets
Claim ready tracker tickets, implement one by one, update status, and record focused verification evidence.
- 09Passes to next stage
Verify Delivery
Run and report the mandatory verification stack for the actual diff and risk profile.
- 10Verified outcome
Review Delivery
Review completed delivery across behavior, QA, integration contracts, security boundaries, docs, tracker evidence, and release risk.
Safe stopping and recovery
Useful even when the whole path cannot run.
- Stop after a reviewed design or diagnosis when implementation authority was not granted.
- Record blockers in the run and tracker instead of hiding them in chat.
- Use run consistency and recovery operations to resume a blocked step without losing prior handoffs.
Specialists inside this workflow