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 change checked against the original request, with test results, independent review and a recorded release status. The record shows what was completed and what still needs attention.
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
- Clarify the request, affected users and systems, constraints, and what will count as a successful result.
- Inspect the existing code, choose an approach and checks, then plan tasks in dependency order. Review the plan before implementation.
- Implement authorized tasks, running independent work in parallel when useful. Test and independently review each result before starting dependent work, then check that the pieces work together.
- Compare the finished change with the original request, record test and review results, and state whether it was released or what remains. Close the work only when the evidence supports that status.
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
Design Approach
Identify canonical ownership, shared operations, data invariants, adapter surfaces, grants, docs, tests, rollout, and rollback implications.
- 05Passes 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…
- 06Passes to next stage
Plan Tracker Tickets
Turn the completed design and proof plan into executable assignments with dependencies, exclusive ownership, acceptance criteria, review instructions,…
- 07Passes to next stage
Delivery Readiness Review
Review the complete requirements, design, proof plan, executable tickets, dependencies, and resources before implementation.
- 08Passes to next stage
Deliver Tickets
Delegate ready tickets, independently verify each candidate immediately, and accept integrated results before completing tickets and releasing dependents.
- 09Passes to next stage
Verify Delivery
Prove the assembled outcome, cross-ticket interactions, remaining requirements, and mandatory project checks using current ticket receipts plus the…
- 10Verified outcome
Review Delivery
Independently review the assembled outcome and remaining integration risks across behavior, contracts, security, docs, evidence, and release authority.
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.
- Before reopening an earlier gate, stop active assignments and their processes, preserve evidence, and reconcile affected child tickets explicitly. Existing runs retain their frozen step order.
Specialists inside this workflow