Every team eventually finds itself rebuilding the same foundational setup in every project. In many organizations, this is still a manual struggle. We write “how we work” docs, define naming conventions and establish review gates that live only in our wikis. For teams already leveraging AI, this setup often exists in isolated pockets like a collection of disconnected prompts telling an assistant to “act as a PM” or “design like an architect”.
In both cases, the expertise remains trapped in silos. For those working manually, the immediate opportunity is to use AI skills to jump-start their specific tasks. But once you do, you quickly reach a plateau – while individual skills and prompts have become portable, the lifecycle around them has not.
That gap is what the Lifecycle Agent Orchestrator (LAO) tries to close. It’s a plugin for Claude Code and Cursor that uses multi-agent orchestration to ship the development process itself as a versioned, overridable artifact. Not just the individual role skills. The stitching between them.
The Problem: Skills Are Portable, Process Is Not
Current AI tools offer impressive specialized skills – performing architecture reviews or enforcing testing conventions with high precision. However, these tools still operate in isolation.
Modern software delivery doesn’t happen in a vacuum. It flows through a series of high-stakes handoffs. This is where even the most advanced teams hit a wall. Despite the promise of automation, the broader lifecycle remains stubbornly manual:
- The Cognitive Load of Fragmentation: Engineers must still manually orchestrate which tools to run and when, creating a massive tax on context.
- Traceability Decay (Drift): We lose the “intent” of a feature as it travels from a product ticket to a design mock and finally into the codebase.
- Simulated Handoffs: We still rely on manual “persona-switching” – manually checking if a design works for a developer or if an architecture suits a product goal.
- The Proof Problem: At the point of release, we still rely on assumptions rather than programmatic proof that we’ve satisfied every original requirement.
LAO moves beyond single-prompt interactions by employing multi-agent orchestration to bridge the high-stakes handoffs between roles.
The skills are the actors. The lifecycle is the director.
Step 1: Jump-Start Your Work with AI Skills
The quickest way to see value isn’t by changing your entire workflow. It’s by using individual skills to improve the work you’re already doing.
Each role in the plugin is independently usable. You don’t need the full pipeline to get an immediate win:
- Engineers can use the Intake skill to turn a messy Jira ticket into a clean scope with real acceptance criteria.
- PMs can use the Product Management skill to draft a structured PRD.
- Architects can define a technical design running the Architecture skill against a requirement.
# Direct use of individual skills
Invoke code-review skill to review these changes
Invoke intake skill to extract scope from PROJ-5678
This “Step 1” approach pays back immediately.
You get a senior-level assistant for specific tasks without committing to a new workflow.
Step 2: The Orchestrator as the Director
Over time, this pattern exposes a critical bottleneck. We find ourselves questioning: Which skill comes next? Did we skip a step? Are we aligning roles or just checking boxes? Here, we hit the ceiling of isolated tools.
Once you trust the individual skills, the orchestrator stitches them together into a cohesive system.
# command inside a Claude Code or Cursor session
# Direct Jira story ingestion
/lao Work on PROJ-1234
# An ungrounded requirement
/lao Add a user notification preferences API endpoint
# a tire-kick before committing to anything
/lao-dry-run
Through multi-agent orchestration, LAO ensures that the PM, Designer and Architect personas actively review and challenge each other’s outputs.
The goal isn’t just automation – it’s coordination.
Core Internals
The following are a few key design decisions that power the LAO.
The Nine-Phase Engine
The pipeline is nine phases, structured into two halves with different personalities:
.
- Alignment (Phases 1–3): Product, Design and Architecture align early. They cross-review every output to catch gaps before engineers write a single line of code.
- Execution (Phases 4–9): Once the team establishes alignment, the system drives the project through scope, design, planning, implementation, validation and shipping.
The key shift is simple: Alignment happens once, upfront. Execution happens without rework.
Project-Specific Infrastructure
Overlays let you define how your specific system works – ensuring your project remains the domain authority. Under the hood, each phase composes up to three layers of knowledge:
| Layer | Lives in | Contains |
|---|---|---|
| Base | Plugin | Universal rules for the role |
| Overlay | Project | Project-specific patterns, stack, conventions |
| Domain | Project | Cross-cutting domain knowledge (auth, payments, compliance) |
A project looks like this once it’s connected:
If a project already has its architecture docs scattered across docs/, there’s no need to move anything. A lao.config.yaml at the project root maps existing files into the engine:
project_name: my-app
languages: [python, react]
overlays:
architecture: docs/architecture/standards.md
coding-standards: .cursor/rules/coding.md
domain:
- docs/domain/*.md
- src/payments/DESIGN.md
extra_roles:
compliance-review: tools/compliance/SKILL.md
There are two discovery paths – the convention directory or the config file. If both exist, the config file wins because project-specific overlays take priority.
This is the project respecting itself as the domain authority.
Preview, Then Execute
Every run begins in simulation – a preview of the nine-phase pipeline that writes no files, creates no branches and posts no Jira comments. The orchestrator walks through Phases 1–6, simulating execution to produce realistic PhaseOutput objects and checkpoints for your iteration. It then summarizes Phases 7–9 as projected outcomes, as these require real code execution.
When you’re ready, you say proceed and the pipeline replays – but with the preview’s decisions carried forward instead of regenerated:
The system eliminates both upfront cost and the risk of committing to a flawed plan.
Acceptance Criteria, Tracked Across Phases
The system captures acceptance criteria during Intake and tracks them through to Validation, where you must prove each one with recorded evidence to unlock the “Ship” gate. The CLI renders this data as text today, but a dashboard could render it visually tomorrow without requiring any changes to the engine. Every phase emits a PhaseOutput – a structured object with a defined schema.
--- Phase: Tech Design (Phase 5 of 9) ---
Status: Needs Approval
SUMMARY:
Add rate limiting middleware to API gateway.
No new dependencies, config-driven thresholds.
ARTIFACTS:
- [design_doc] docs/design/rate-limiting.md
ACCEPTANCE CRITERIA (tracked):
AC1: Rate limit of 100 req/min/user ...... pending
AC2: Returns 429 with retry header ....... pending
AC3: Configurable per environment ........ pending
→ Approve to proceed to Plan or request changes.
No claims without fresh proof – that’s the whole point of the validation gate.
Multi-Language, Without a Fork Per Language
Four skills need to know what language they’re looking at: coding-standards, testing-conventions, code-review and security. Each has a universal base and a language pack for the specifics:
Currently, plugin supports Python, Java, C# and React. Detection runs once at pipeline start: if lao.config.yaml lists languages, use them, otherwise scan for pyproject.toml, pom.xml, *.csproj, package.json with a React dep and collect every match. A full-stack repo auto-detects as [python, react] and both packs get loaded. The agent applies each to the right file types.
Adding a new language – Go, Rust, anything – means creating a references/<language>/directory in those four skills with the expected files, plus a couple of lines in detection and validation scripts.
No change to the universal base. That separation is worth preserving.
Role vs. Workflow Split
The design deliberately separates Phases 1–5 (Role-based) from Phases 6–9 (Execution-based).
Phases 1–5 (Roles): These phases use individual skill files (PM, XD, Architecture, Intake) through multi-agent orchestration because judgment varies by project. A fintech audit requires different logic than a game engine pipeline, so project overlays merge with these base skills to provide local context.
Phases 6–9 (Workflows): These phases power the orchestrator’s core engine (TDD, validation, shipping) and maintain tight coupling for continuity. Unlike roles, workflows use substitutions. If you override a workflow, such as swapping TDD for BDD, the new logic replaces the built-in engine entirely rather than layering on top of it.
# Override the workflow for a single phase
workflows:
# BDD instead of TDD
implement: docs/workflows/our-bdd-process.md
# custom release flow
ship: docs/workflows/our-release-process.md
Separate judgment from execution to protect flexible strategy without sacrificing delivery.
When to Use This and When Not
The Sweet Spot: Use this if you pair Claude Code or Cursor with Jira/PRD-driven intake. It excels for teams that front-load design and track ACs to the finish line. The engine treats multi-language and monorepos as first-class citizens, using config-based discovery to navigate complex structures.
The Breaking Point: Avoid this for ad-hoc work lacking tickets or defined ACs. The fit weakens if your “ship” phase involves unmodeled complexity – like mobile store submissions or if you require unattended, autonomous execution. The plugin is designed as a human-in-the-loop engine. It doesn’t chase full autonomy – yet.
What Changes When You Adopt This?
The most immediate change is practical: Your development process leaves the wiki and enters your repository as a versioned artifact.
But adoption doesn’t have to be a cliff. You start by using individual skills (single agent) to improve local tasks. As you build trust, you let the orchestrator (multi-agent) handle the parts that are hardest to do manually – the handoffs, the alignment and the validation.
Over time, the shift becomes structural:
- Handoffs become explicit gates
- Requirements become traceable
- Validation becomes evidence-driven
- The lifecycle becomes consistent
I expect the next iteration of the tool to automate this entire flow. For now, we must build it by hand – or, more precisely, install it.
Closing Thought
This isn’t about replacing how teams work. It’s about making how they work explicit and reliable.
The lifecycle stops being something you document. It becomes something you execute and once that happens, it’s no longer just process.
It’s part of the product.
.
Repository & Contribution
The Lifecycle Multi-Agent Orchestrator is available as an open-source project. I encourage you to explore the repository, use the individual skills to jump-start your own work and contribute to the evolution of portable development engine.
- GitHub: sandeep-mewara/lifecycle-agent-orchestrator
- Documentation: Detailed design specs and phase contracts are included in the repo.
In practice, this kind of artifact only gets better when it’s applied across different projects and constraints.
.