Sdlc Orchestrator

SDLC orchestrator

Purpose

Choose the route, keep ownership clear, and stop a broad request from turning into an unbounded chain of skills.

Inputs

• Restate the desired outcome in one sentence.
• Read the repository state and relevant project memory.
• Classify the task as a new product, existing-product change, narrow change, release, incident, review, documentation update, or agent-system task.
• Identify the first decision that could invalidate later work.
• Check that the runtime can read, write, execute, validate, and request approval as the route requires.

Decision process

1. Select the smallest entrypoint in the installed route map. When no route map is exposed, use the phase and entrypoint guidance in the reference.
2. Record the route, why it fits, what it deliberately excludes, and when it must stop.
3. Run only the discovery and planning steps needed to resolve real uncertainty.
4. Freeze affected behavior, interfaces, platform constraints, and acceptance criteria before decomposition.
5. Give parallel workers disjoint ownership and define their merge order before delegation.
6. For production code, route through tdd-workflow, engineering-quality, and service-implementation as the task requires.
7. Match validation depth to the blast radius. Add security, compliance, performance, and release checks only when the affected surface calls for them.
8. Update the canonical documentation and project memory with decisions future work needs.

Decision boundaries

• A route defines ownership and order; it does not grant permission.
• Keep read-only analysis separate from write-authorized implementation.
• Verify current external behavior through primary documentation, preferably Context7 MCP where available.
• Ask for approval immediately before irreversible, production-facing, costly, or security-sensitive actions.
• Stop when missing user intent or unavailable evidence would materially change the result.

Decision record

• Selected route and rejected broader alternatives
• Decision, permission, and stop boundaries
• Artifact ownership and merge order for parallel work
• Validation, rollback, and completion evidence
• Final handoff with documentation links

Ready when

• Every skill in the route owns a necessary decision or deliverable.
• No implementation starts from unresolved behavior or scope.
• Missing runtime capabilities are reported and reflected in the plan.
• Parallel lanes do not share write ownership.
• Completion claims point to commands, artifacts, or reviewed evidence.

Handoff

Pass the goal, constraints, route, completed evidence, unresolved questions, and next decision to the skill that owns it.

References

• references/phase-gates.md: criteria for advancing, narrowing, or stopping a route.