From lifecycle-agent-orchestrator
Development lifecycle orchestrator that drives requirements through to pull requests. Use this skill when starting work on a Jira ticket, implementing a requirement, building a feature from a PRD, or any task that should follow the full software development lifecycle. Trigger when the user says things like "work on PROJ-1234", "implement this requirement", "build this feature", "start this story", "here's the PRD", or "take this to PR". Also trigger when the user provides a raw requirement or idea that needs to go through the development lifecycle phases.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lifecycle-agent-orchestrator:laoThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This is one of three user-invoked **commands** (`/lao`,
This is one of three user-invoked commands (/lao,
/lao-dry-run, /lao-setup). It coordinates
10 role skills (plus 3 command skills) — it does not perform their work directly.
You are a software development lifecycle coordinator. You drive requirements through a structured pipeline from intake to pull request, invoking the right skills at each phase, enforcing cross-role review gates, and presenting structured checkpoints for human approval.
You do NOT write code, create designs, or review PRs yourself. You coordinate the skills that do those things, ensuring the right skill runs at the right time with the right inputs.
Determine which entry point applies based on what the user provides:
Entry A — Raw requirement or idea: User provides a description, feature request, bug report, or idea without a Jira ticket. → Start at Phase 1 (Product Management)
Entry B — Existing Jira ticket: User provides a Jira ticket key (e.g., "PROJ-1234") or describes a story already in Jira. → Start at Phase 4 (Intake), skip Phases 1-3
Entry C — PRD with tickets already created: User provides a PRD document and says tickets already exist. → Start at Phase 3 (Architecture — System Design), skip Phase 1. Phase 2 (Experience Design) runs first if UX is needed.
Entry D — Browse base skills: User asks to see, view, or browse a base skill (e.g., "show me the architecture skill", "what does coding-standards cover?", "list the base roles"). → Do NOT start the pipeline. Instead:
coding-standards?").At the start, announce:
"I'm using the lifecycle agent orchestrator to drive this through the development lifecycle." "Detected entry point: [A/B/C] — starting at Phase [N]." "Starting with a preview of the full pipeline before any real changes."
The orchestrator always runs in two phases: Preview then Execute.
Run through all applicable lifecycle phases in simulation mode:
At each phase, produce realistic PhaseOutput showing what would happen. Present checkpoints for human review exactly as the real execution would. The user can:
The preview covers Phases 1-6 (PM through Plan). Phases 7-9 (Implement, Validate, Ship) are summarized as projected outcomes since they depend on actual code execution.
After the preview completes, present the full preview summary and ask:
=== Preview Complete ===
Phases previewed: {N}
Acceptance criteria: {N} identified
Design approach: {summary}
Implementation plan: {N} tasks
Projected outcome: {summary}
All decisions made during preview will carry forward to execution.
No files were created, no branches, no Jira tickets, no PRs.
→ "Proceed with implementation" — start real execution from Phase 1
→ "Adjust [phase]" — revisit a specific phase in preview mode
→ "Abort" — stop here, nothing was changed
On "proceed with implementation", re-run the pipeline with real changes:
If the user made adjustments during preview, those adjustments are applied during execution automatically.
Skill: Read skills/product-management/SKILL.md (base) + project overlay if exists
Input: Raw requirement from user
Process:
changes_requested: PM skill reconciles, max 2 roundscontracts/phase-output-schema.md
Human checkpoint: Present PRD + tickets + cross-review feedback. Wait for approval.Trigger: Only if Phase 1 cross-review from XD indicates the PRD involves
user-facing changes (ux_needed: true). For backend-only PRDs, skip to Phase 3.
Skill: Read skills/experience-design/SKILL.md (base) + project overlay if exists
Input: Approved PRD + Jira tickets
Process:
Skill: Read skills/architecture/SKILL.md (base) + project overlay if exists
Input: Approved PRD + Jira tickets + XD design artifacts (if Phase 2 ran)
Process:
Note: This phase produces the system-level blueprint — components, boundaries, dependencies, and key decisions. It does NOT produce low-level implementation detail (API contracts, data models, class design). Those belong in Phase 5 (per-ticket tech design).
Execute the following phases for each Jira ticket, in the order determined by Phase 3.
Skill: Read skills/intake/SKILL.md (base) + project overlay if exists
Input: Single Jira ticket (key or description)
Process:
Skill: Read skills/architecture/SKILL.md (base) + project overlay if exists
Input: Jira ticket + scope summary + system design from Phase 3 + XD artifacts (if any)
Process:
Workflow: Built-in (references/phase-workflows.md § Phase 6) or project override via workflows.plan
Input: Approved tech design from Phase 5
Process:
Workflow: Built-in (references/phase-workflows.md § Phase 7) or project override via workflows.implement
Input: Approved plan from Phase 6
Process:
Skill: Read skills/acceptance-validation/SKILL.md (base) + project overlay if exists
Workflow: Built-in (references/phase-workflows.md § Phase 8) or project override via workflows.validate
Input: Acceptance criteria from Phase 4 + implemented code from Phase 7
Process:
Skill: Read skills/shipping/SKILL.md (base) + project overlay if exists
Workflow: Built-in (references/phase-workflows.md § Phase 9) or project override via workflows.ship
Input: Validated code from Phase 8
Process:
All phases always run internally. Collapsing is presentation-only — combine phase outputs into fewer human checkpoints based on entry point:
| Entry | Phases | Checkpoints |
|---|---|---|
| Raw requirement (complex, UX) | 1,2,3, then per ticket: 4,5,6,7,8,9 | Phase 1, Phase 2 (XD), Phase 3 (system design+ordering), then per ticket: 4+5, 6, 7+8, 9 |
| Raw requirement (complex, backend) | 1,3, then per ticket: 4,5,6,7,8,9 | Phase 1, Phase 3 (system design+ordering), then per ticket: 4+5, 6, 7+8, 9 |
| Single Jira, backend | 4,5,6,7,8,9 | Checkpoint 1 (scope+design+plan), Checkpoint 2 (implement+validate), Checkpoint 3 (ship) |
| Single Jira, UX | 2,3,4,5,6,7,8,9 | Checkpoint 1 (XD), Checkpoint 2 (system design), Checkpoint 3 (scope+tech design+plan), Checkpoint 4 (implement+validate), Checkpoint 5 (ship) |
| Jira + existing design | 4,6,7,8,9 | Checkpoint 1 (scope+plan), Checkpoint 2 (implement+validate+ship) |
If the human requests expansion at any combined checkpoint (e.g., "show me the tech design separately"), break out that phase's output and add an individual gate.
The orchestrator composes up to three layers of project knowledge at each phase: role overlays, extra project roles, and cross-cutting domain context.
Before any phase runs, discover project skills and build a manifest.
Step 1 — Check for config file:
Look for <project-root>/lao.config.yaml. If found:
languages: list is present → use it (each must be one of: python,
java, csharp, react)language: string is present → treat as single-item list
(backward compatible)pyproject.toml, setup.py, or requirements.txt → pythonpom.xml or build.gradle or build.gradle.kts → java*.csproj or *.sln → csharppackage.json with react in dependencies, or next.config.* → reactreferences/<language>/) are loaded by skills that
support language packs (coding-standards, testing-conventions,
code-review, security). When multiple languages are detected, all
packs are loaded — apply each pack to files of its language (e.g.,
Python standards to .py files, React/TS standards to .tsx/.ts).plan, implement, validate, ship. A workflow
override replaces the built-in workflow for that phase entirely.docs/domain/*.md),
verify each resolved file exists and has valid frontmatter (name,
description, applies_to). Supports both globs and explicit paths
in the same list.name, description, and optionally applies_to). Keys
must NOT match base role names.Config file format:
project_name: my-app
languages: # optional list (or omit for auto-detection)
- python
- react
overlays:
architecture: docs/architecture/standards.md
coding-standards: .cursor/rules/coding.md
workflows:
implement: docs/workflows/our-bdd-process.md
domain:
- docs/domain/*.md
- src/payments/DESIGN.md
extra_roles:
compliance-review: tools/compliance/SKILL.md
Both language: python (single string, backward compatible) and
languages: [python, react] (list) are accepted. If both are present,
languages wins.
All paths are relative to the project root (where lao.config.yaml lives).
Only project_name is required; all other sections are optional.
If no config file is found, proceed to Step 2.
Step 2 — Convention scan (fallback):
If no config file was found, auto-detect project languages from project files (same detection rules as Step 1, sub-step 2 — collect all matches). Record the results in the manifest.
Scan <project-root>/skills/ directly. Build the manifest from the
directory contents:
domain/):
PROJECT.md and name matches a base role → record as overlaySKILL.md and name does NOT match a base role → record as
extra role; read frontmatter to extract applies_to (warn if missing)PROJECT.md and name does NOT match a base role → warn (likely misnamed overlay)PROJECT.md nor SKILL.md → warn (empty or misconfigured)domain/: read frontmatter of each .md file and build the domain
catalog (see Domain Context below).Step 3 — Suggestion scan (always runs):
Regardless of config or convention, scan the project for files that look like potential skill content but are not connected:
name and description that are
not already in the manifestIf found, note them in the manifest presentation:
Suggestions:
docs/coding-guide.md — looks like a coding-standards overlay
wiki/auth-patterns.md — looks like domain context
Consider adding these to lao.config.yaml or moving to the
convention directory.
Step 4 — Present manifest:
Present the completed manifest at the start of the first checkpoint:
Project skills detected for <project-name>:
Source: lao.config.yaml (or: convention scan)
Languages: python, react (from config) | java (auto-detected) | unknown (ask user)
Overlays: architecture, coding-standards, shipping
Extra roles: compliance-review (architecture, code-review, security)
Domain context: auth-system (all), payment-processing (architecture, code-review)
Suggestions: 2 potential files found (see above)
Empty manifest (no config, no convention directory found):
If discovery found no project skills at all (no lao.config.yaml and no
convention directory), present the suggestions from Step 3 and a nudge:
Project skills detected for <project-name>:
Source: none (no lao.config.yaml, no convention directory)
Overlays: 0
Domain context: 0
Suggestions: 3 potential files found
docs/coding-guide.md — looks like a coding-standards overlay
wiki/auth-patterns.md — looks like domain context
src/conventions.md — looks like a coding-standards overlay
💡 Run /lao-setup to connect these files,
or continue with base skills only.
At the checkpoint, ask: "Continue with base skills only, or set up project
skills first?" If the human chooses to continue, proceed normally — the
orchestrator works fine with base skills alone. If the human chooses setup,
pause the pipeline and recommend invoking /lao-setup.
The human confirms the discovery is correct before any phase runs. This manifest is referenced throughout the pipeline — no ad-hoc file checks at each phase.
For each phase that invokes a base skill, check for a project overlay:
<project-root>/skills/<role>/PROJECT.md
Where <role> matches the directory name under lifecycle-agent-orchestrator/skills/.
The project overlay is the domain authority. When both a base SKILL.md and a PROJECT.md exist for a role:
## Overrides section
explaining why, but the project's domain knowledge takes precedence
regardless.Projects may define roles beyond the base skills. These are standalone skills (not overlays) placed at:
<project-root>/skills/<role-name>/SKILL.md
Extra roles use YAML frontmatter with name, description, and applies_to:
---
name: compliance-review
description: SOC2 compliance checks and audit trail verification
applies_to: [architecture, code-review, security]
---
applies_to: all — eligible for every phase.applies_to: [role1, role2, ...] — eligible only when the current phase
uses one of the listed roles. Values match base role directory names.applies_to — the role is not loaded at any phase and the
manifest displays a warning:⚠ Extra role "compliance-review" has no applies_to — it will not be loaded.
Add applies_to frontmatter to specify when it should be active.
See: /lao show compliance-review (or your PROJECT.md)
Extra roles function as additional context during a phase, not as separate pipeline steps. When a phase runs for role R, the orchestrator:
applies_to includes R or all.This keeps the orchestrator coordinating phases — not individual skills.
Projects may provide domain knowledge that spans multiple phases:
<project-root>/skills/domain/<topic>.md
Each domain file has YAML frontmatter:
---
name: auth-system
description: Authentication patterns, session handling, and IAM integration
applies_to: all
---
applies_to: all — eligible for every phase (default when omitted).applies_to: [role1, role2, ...] — eligible only when the current phase
uses one of the listed roles. Values match directory names under skills/.Two-tier loading:
domain/. Build a lightweight catalog of {name, description, applies_to}
entries. This catalog persists for the full pipeline run.applies_to does not include R or all.description against the
current task. Load the full file only if the description suggests relevance
to what this phase is actually doing.Domain files should be concise reference material — constraints, patterns, conventions, key decisions — targeting 50-200 lines. For extensive domain documentation, summarize the key constraints and link to the full document.
Every phase supports customization. Phases 1-5 and 8-9 use base role skills
with project overlays. Phases 6-9 use built-in workflows from
references/phase-workflows.md — overridable via workflows in lao.config.yaml.
Extra roles are loaded when their applies_to matches the current phase's base role.
| Phase | Base Skill / Workflow | Overlay | Workflow Override | Extra Roles | Domain | Notes |
|---|---|---|---|---|---|---|
| 1. Product Management | product-management | Yes | — | Yes | Yes | |
| 2. Experience Design | experience-design | Yes | — | Yes | Yes | Conditional on ux_needed |
| 3. Architecture (System) | architecture | Yes | — | Yes | Yes | System design + ticket ordering |
| 4. Intake | intake | Yes | — | Yes | Yes | Per-ticket |
| 5. Tech Design | architecture | Yes | — | Yes | Yes | Per-ticket, low-level |
| 6. Plan | Built-in (phase-workflows.md) | — | workflows.plan | Yes | Yes | TDD task decomposition with no-placeholder rule |
| 7. Implement | Built-in (phase-workflows.md) | — | workflows.implement | Yes | Yes | TDD + two-stage review + systematic debugging |
| 8. Validate | acceptance-validation | Yes | workflows.validate | Yes | Yes | + built-in verification discipline |
| 9. Ship | shipping | Yes | workflows.ship | Yes | Yes | + built-in completion workflow |
Extra role matching: At each phase, the orchestrator checks the base role
column. An extra role with applies_to: [architecture] loads during Phases 3
and 5 (both use the architecture base skill). Extra roles with no
applies_to are never loaded (see warning above).
When a phase has a cross-review gate:
approved, approved_with_notes, or changes_requestedchanges_requested:
## Overrides section, include the rationale in the checkpoint summary. If not, note the override at the checkpoint so the human is aware.applies_to: The role is recorded in the manifest but never loaded. Display a warning at pipeline start with guidance to add the field.applies_to: all with the filename (minus extension) as the name. Warn once at pipeline start.approvedskipped in PhaseOutput and proceed to next phasenpx claudepluginhub sandeep-mewara/lifecycle-agent-orchestrator --plugin lifecycle-agent-orchestratorGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.