القائمة
Orchestrate the full Liminal Spec pipeline with agent teams. Manages drafters and verifiers from orientation through technically enriched stories.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Write complete, traceable Epics using Liminal Spec methodology. Covers User Profile, Flows, Acceptance Criteria, Test Conditions, Data Contracts, and Story Breakdown.
Publish a detailed epic as two handoff-ready artifacts: a PO-friendly business epic with grouped ACs and a developer story file with full AC/TC detail and Jira section markers.
Explore product direction and produce a PRD before feature scoping. Use when requirements are unclear, scope spans multiple features, or stakeholder alignment is needed.
Orchestrate story-by-story implementation with agent teams. Manages teammates, routes verification, and makes judgment calls across the full implementation cycle.
Transform a Feature Spec into implementable Tech Design with architecture, interfaces, and test mapping. Validates the spec as downstream consumer.
Write a single functional story with epic-quality rigor. Story-sized epic for focused changes that don't warrant the full pipeline.
| name | ls-team-spec |
| description | Orchestrate the full Liminal Spec pipeline with agent teams. Manages drafters and verifiers from orientation through technically enriched stories. |
Purpose: Orchestrate the full Liminal Spec pipeline using agent teams — from orientation through technically enriched stories. You are the team lead — you gather context, spawn teammates for drafting and verification, manage revision loops, route human review, and move the pipeline forward.
You start with a human who wants to build something. You end with a published epic (business epic + developer stories) ready for implementation (via /ls-team-impl or direct handoff to developers).
If team mode is not available, use the individual phase skills directly (/ls-research, /ls-epic, /ls-tech-design, /ls-publish-epic).
You are not the drafter. You are not the verifier. You are the orchestrator — the agent who holds the full picture, directs the pipeline, and applies judgment at every transition.
Your job:
You should be able to handle routine decisions autonomously — review synthesis, severity assessment, revision routing, loop termination. The human is the final authority on product decisions and artifact acceptance, not a checkpoint for every orchestration call.
Create team-spec-log.md alongside where the spec artifacts will live. This is the orchestration log for the entire run — skill availability, lane decisions, phase transitions, verification findings, revision decisions, and process observations all go here. The first entry is the lane determination below.
Check which execution capabilities are available by locating skills by name:
Codex lane (primary): the codex-subagent or copilot-subagent skill is available. Either provides access to GPT-5x-codex models for verification. If available, load the skill with the Skill tool (Skill(codex-subagent) or Skill(copilot-subagent)). Also check for gpt53-codex-prompting — if available, load it with Skill(gpt53-codex-prompting). This skill improves prompt quality for Codex subagents but is not required.
Model selection default in Codex/Copilot lane:
gpt-5.3-codex for normal drafting verification and routine single-review passes.gpt-5.2 only when running parallel multi-verifier diversity passes.Sonnet-only fallback: Neither subagent skill is available. Verification will use Sonnet 4.6 directly rather than routing through a Codex subagent. This reduces multi-model verification diversity. Warn the human: verification quality is reduced without multi-model review. Recommend stopping and installing a subagent skill. If the human chooses to continue, proceed in Sonnet-only mode.
Declare the selected lane once before starting: "Running in Codex lane via codex-subagent" or "Running in Copilot lane via copilot-subagent" or "Running in Sonnet-only mode — reduced verification diversity."
Log the lane determination to team-spec-log.md: which skills were found, which were not, which lane was selected, and whether any fallbacks were applied.
Load ls-research and ls-epic with the Skill tool. These orient you on what the methodology expects at each phase — exit checklists, validation criteria, artifact structure. You'll load additional phase skills as the pipeline progresses.
Load required skills yourself before dispatching teammates. Do not instruct teammates to use a skill you have not loaded and verified in your own context first.
These three invariants are non-negotiable:
fixed, accepted-risk, or defer.Keep process flexibility without weakening the invariants:
low, medium, high) and scale verification depth accordingly.accepted-risk for explicitly reasoned, non-blocking issues.Before Phase 1 drafting starts, discover and lock the project's verification gates for this pipeline.
CLAUDE.md, AGENTS.md, README, package scripts, CI config) to identify required verification commands/checks.team-spec-log.md:
Do not assume document quality checks alone are sufficient. Use the complete gate required by project policy.
Before any teammates are spawned, the orchestrator works directly with the human to understand what's being built and what already exists.
If the human doesn't have sufficient context for epic drafting, you create the pre-epic documentation yourself. You have ls-research loaded — use it. This may include:
This is conversational work between you and the human. You don't spawn teammates for this — you're gathering, organizing, and clarifying until you have enough to direct an epic drafter.
You're ready to enter the epic phase when you can answer:
If you can direct an epic writer with clear, specific context, proceed. If not, keep working with the human.
This pattern repeats at every phase. It's described once here and referenced throughout.
Author self-review. The drafter critically reviews their own work against the phase skill's exit checklist. Fixes non-controversial issues. Reports what they found, what they fixed, and what remains open.
Dual verification. Spawn an Opus verifier teammate (fresh for this phase, persists across verification rounds within the phase). The verifier loads the relevant phase skills (specified per phase below) and reads the artifact plus all input artifacts. In the Codex/Copilot lane, the verifier also fires a Codex subagent async for a parallel review using gpt-5.3-codex by default. Two perspectives: Opus architectural/judgment review + Codex literal/detail review. In Sonnet-only mode, the verifier does a solo review.
Orchestrator synthesis. Read all verification findings. Categorize by severity (Critical, Major, Minor). Decide what needs fixing and what to dismiss. Codex grades conservatively — apply your own judgment, don't defer to model calibration.
Route fixes by default. Auto-dispatch clear must-fix and should-fix items to the original drafter (not a fresh agent — they have the full context of what they wrote and why). Ask the human before proceeding only when a fix changes product scope, requirement intent, or release risk profile.
Re-verify. Send the revised artifact back to the same Opus verifier, who fires a fresh Codex subagent. Review the changes.
Iterate. Repeat steps 3-5 until verifiers return minimal or no substantive findings, or the orchestrator rules remaining findings as non-issues.
Codex evidence gate. If Codex output is missing, incomplete, or unverifiable, mark the cycle degraded and treat it as incomplete. Retry/reassign/escalate before phase acceptance.
Run phase gate yourself. Execute the discovered phase acceptance gate commands/checks yourself before accepting the phase.
Log. At the end of each verification cycle, log to team-spec-log.md: what findings came back, what was fixed, what was dismissed and why, how many rounds it took.
The verification loop converges when:
Don't pursue perfection. Pursue readiness for the next phase's consumer.
Before any phase is accepted, write a short pre-acceptance receipt to the log or report:
fixed, accepted-risk, defer)none)On the first verification round, after verifiers deliver their report, ask: "What else did you notice but not report?" This reliably surfaces 20-30 additional observations, several significant. The exact wording matters — it deactivates the agent's self-censoring filter that suppresses findings they judge as "not important enough." Subsequent rounds are reviewing targeted fixes — the open-ended probe is for initial discovery.
Create a team at the start of the orchestration. The team persists across all phases. Teammates are created and shut down within each phase's cycle, but the team and its task list span the full run.
All teammates are spawned as general-purpose agents with bypassPermissions. Senior-engineer is reserved exclusively for the orchestrator's own quick fixes via subagent — never for teammates.
Shut down teammates after each phase completes. Don't leave idle teammates running across phase boundaries.
At each phase boundary:
team-spec-log.md (including pre-acceptance receipt fields) as the final action of the current phase.Everyone in this phase loads: ls-epic
ls-epic plus reads any pre-epic documentation (PRD, product brief, tech overview)ls-epic, reads the drafted epic plus all pre-epic documentationSpawn a general-purpose Opus teammate. Hand them:
ls-epic with Skill(ls-epic)The drafter produces a complete epic following the ls-epic skill's structure: User Profile, Feature Overview, Scope, Flows with ACs and TCs, Data Contracts, Tech Design Questions, Recommended Story Breakdown. Include a prominent instruction to report back to the orchestrator when complete or blocked.
Run the verification pattern. The verifier and Codex subagent both have ls-epic loaded and read the epic plus all input documentation.
The epic verification is the most important in the pipeline — errors here cascade through every downstream phase. Run verification rounds until findings converge to minimal.
After verification converges, present the epic to the human for review. The human reviews every line — this is the scrutiny gradient at work. The epic is the linchpin artifact.
If the human requests changes, route them to the drafter for revision. Re-verify if changes are substantive. The epic is accepted when the human says it's accepted.
Log the epic phase completion to team-spec-log.md: how many drafting rounds, how many verification rounds, what the human changed, final state. Include any process issues that came up — skill loading problems, context ceiling hits, drafter confusion, verification findings that were dismissed and why. Phase transitions are natural reflection points.
Everyone in this phase loads: ls-epic AND ls-tech-design
The drafter needs ls-epic to validate the epic before designing from it (the dual-role: validator then designer). The verifier needs both to check alignment between the epic and the design.
Spawn a general-purpose Opus teammate. Hand them:
ls-epic with Skill(ls-epic) and ls-tech-design with Skill(ls-tech-design)The drafter first validates the epic (can they design from it? are data contracts complete? any technical constraints the BA missed?). If issues found, they report back and the orchestrator resolves directly or spawns a fresh epic drafter to make revisions.
Once validated, the drafter produces the tech design following the ls-tech-design skill's structure: system context, module architecture, flow-by-flow design, interface definitions, TC-to-test mapping, chunk breakdown. Include a prominent instruction to report back to the orchestrator when complete or blocked.
Run the verification pattern. The verifier and Codex subagent both have ls-epic + ls-tech-design loaded and read the epic + tech design.
After verification converges, check in with the human: "Tech design is verified. Want to review it?" The human may review key sections, do a full review, or accept based on the verification results. This is not the mandatory every-line review that the epic gets — it's at the human's discretion per the scrutiny gradient.
Log the tech design phase completion to team-spec-log.md: verification rounds, human review scope, any issues encountered. If the tech design drafter surfaced epic validation issues, log how they were resolved. Phase transitions are natural reflection points.
Everyone in this phase loads: ls-epic AND ls-publish-epic
ls-epic + ls-publish-epic, reads the accepted epicls-epic + ls-publish-epic, reads the epic, the business epic, and the story fileSpawn a general-purpose Opus teammate. Hand them:
ls-epic with Skill(ls-epic) and ls-publish-epic with Skill(ls-publish-epic)The drafter produces two artifacts:
The ls-publish-epic skill requires stories first, then the business epic — bottom-up compression.
Include a prominent instruction to report back to the orchestrator when complete or blocked.
Run the verification pattern. The verifier and Codex subagent both have ls-epic + ls-publish-epic loaded and read the detailed epic, the business epic, and the story file.
Key verification targets for publish epic:
Check in with the human: "Business epic and stories are published and verified. Want to review?" The PO reviews the business epic. The Tech Lead or developers review the story file. Per the scrutiny gradient, the business epic gets shape-and-completeness review — is it clear enough to prioritize and accept from?
Log the publish epic phase completion to team-spec-log.md: coverage gate results, integration path trace gaps found and resolved, verification rounds, any issues encountered. Phase transitions are natural reflection points.
After publishing, the full artifact set gets a final coherence check. This is the final quality gate before handoff to implementation.
Spawn a dual verifier: an Opus teammate who fires a Codex subagent async (default model: gpt-5.3-codex). In Sonnet-only mode, the verifier does a solo review. Both read the detailed epic, the business epic, the story file, and the tech design (if available). They check:
If fixes are needed, the Opus verifier teammate makes them directly. This is the final signoff — when this pass comes back clean, the spec pipeline is complete.
Present the final state to the human: "All artifacts verified and coherence check passed. Spec pipeline is complete." The human may do a final spot-check or accept.
Log the final verification phase completion to team-spec-log.md: coherence check results, fixes made, any issues encountered and resolved. This is the final log entry for the spec pipeline.
After all phases complete, the pipeline output is a set of handoff-ready artifacts. The orchestrator presents the full artifact set to the human:
team-spec-log.md (orchestration log — useful context for implementation: patterns noticed, decisions made, deviations documented)From here, the human can proceed to implementation via /ls-team-impl (team orchestration) or direct handoff to developers with the story file and tech design.
Log the full pipeline completion to team-spec-log.md: total phases run, total verification rounds across all phases, significant process decisions, and any recommendations for future runs.
Before declaring full pipeline completion, run the discovered final handoff gate yourself and include command/check results in the final completion log entry.
When teammates escalate issues or problems arise during any phase:
If the human interrupts with process feedback (not artifact content feedback), enter PAUSED_PROCESS_REVIEW mode immediately:
In PAUSED_PROCESS_REVIEW, prioritize diagnosis over reassurance. Treat frustration as diagnostic signal.
These patterns apply across all phases and encode failure modes the skill needs to handle.
Teammates emit idle notifications between turns. These are noise during multi-step tasks — a drafter writing a tech design will fire multiple idle notifications while actively working. Do not interpret idle notifications as "the agent is done" or "the agent is stuck."
The reliable signal is the teammate's explicit message reporting results. Wait for that. If extended time passes with no message (calibrate based on task complexity), send a brief nudge: "Did you complete the work? Report your results." Don't assume failure from silence alone.
Drafters that read extensive input documentation (epic + codebase + tech overview) and then produce large artifacts (tech designs) can exhaust their context window. Symptoms: the agent goes idle without completing, or produces truncated/confused output.
Mitigation: the human configures model context size. If an agent hits context limits, the human may need to intervene to adjust model settings. The orchestrator cannot control context size at spawn time — flag the issue and let the human handle it.
After long drafting tasks (30+ minutes, extensive tool calls for codebase analysis), agents sometimes complete their work but forget to send the completion message back to the team lead. The reporting instruction decays over long execution chains.
Place the reporting instruction prominently in the handoff prompt. If two idle notifications pass after expected completion time with no message, send a nudge.
Do not launch verification before the drafter signals "done." Do not launch the next phase before the current phase is fully accepted. The teammate's explicit report is the trigger for the next step, not the orchestrator's independent observation of file state.
Codex models grade conservatively — they flag everything as Major. Claude models tend to grade more generously. The orchestrator applies their own judgment. Not every Major finding is actually Major. Some Minor findings at the epic level are actually Critical because they'll cascade. Calibrate based on the scrutiny gradient: upstream findings get more weight.
The workflow defined above is the default. The orchestrator has discretion to adjust within bounds.
What can be adjusted:
low, medium, high)accepted-risk dispositions for non-blocking itemsWhat cannot be adjusted:
Human override always wins. If the human directs a process change, apply it, log it, and continue.
If a phase's verification surfaces a pattern, flag it in subsequent phase handoffs.
team-spec-log.md is created during On Load and lives alongside the spec artifacts. It captures the full orchestration experience for this run.
What to log:
What not to log:
Write narrative entries, not bullet points. Each entry should tell the story of what happened, what was observed, and why it might matter. A future reader building or refining this skill needs to understand the shape of the work, not just the checkboxes.
team-spec-log.md is a first-class deliverable. A smooth orchestration with thin notes is less valuable than a rough orchestration with thorough documentation. Optimize for learning surface area.
Every line of code traces back through a chain:
AC (requirement) → TC (test condition) → Test (code) → Implementation
Validation rule: Can't write a TC? The AC is too vague. Can't write a test? The TC is too vague.
This chain is what makes the methodology traceable. When something breaks, you can trace from the failing test back to the TC, back to the AC, back to the requirement.
Upstream = more scrutiny. Errors compound downward.
The epic gets the most attention because if it's on track, everything else follows. If it's off, everything downstream is off.
Epic: #################### Every line
Tech Design: #############....... Detailed review
Stories: ########............ Key things + shape
Implementation:####................ Spot checks + tests
This is the linchpin. Read and verify EVERY LINE.
BA self-review -- Critical review of own work. Fresh eyes on what was just written.
Tech Lead validation -- Fresh context. The Tech Lead validates the spec is properly laid out for tech design work:
Additional model validation -- Another perspective (different model, different strengths):
Fix all issues, not just blockers -- Severity tiers (Critical/Major/Minor) set fix priority order, not skip criteria. Address all issues before handoff. Minors at the spec level compound downstream -- zero debt before code exists.
Validation rounds -- Run validation until no substantive changes are introduced, typically 1-3 rounds. The Tech Lead also validates before designing -- a built-in final gate. Number of rounds is at the user's discretion.
Human review (CRITICAL) -- Read and parse EVERY LINE:
Still detailed review, but less line-by-line than epic.
Stories go through a two-phase validation reflecting their two-phase authoring.
Less line-by-line, more shape and completeness:
Story contract compliance check:
Consumer gate: could an engineer implement from this story alone, without reading the full tech design?
Spot checks + automated tests.
Liminal Spec uses this pattern throughout:
| Artifact | Author Reviews | Consumer Reviews |
|---|---|---|
| Epic | BA self-review | Tech Lead (needs it for design) |
| Tech Design | Tech Lead self-review | BA/SM (needs it for story derivation) + Tech Lead (needs it for technical sections) |
| Published Stories | BA/SM self-review | Engineer (needs them for implementation) |
If the Tech Lead can't build a design from the epic -> spec isn't ready. If the BA/SM can't derive stories from the epic -> epic isn't ready. If the Engineer can't implement from published stories + tech design -> artifacts aren't ready.
The downstream consumer is the ultimate validator.
How to run validation passes is left to the practitioner. This skill describes:
Leaves flexible: