菜单
Orchestrate full SDLC workflow chains (feature, chore, bug) end-to-end by sequencing sub-skill invocations, managing state across pause points, and isolating per-step context via Agent tool forking.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | orchestrating-workflows |
| description | Orchestrate full SDLC workflow chains (feature, chore, bug) end-to-end by sequencing sub-skill invocations, managing state across pause points, and isolating per-step context via Agent tool forking. |
| argument-hint | <title-or-issue> or <ID> |
| compatibility | Requires jq and a bash-compatible shell |
| hooks | {"Stop":[{"hooks":[{"type":"command","command":"${CLAUDE_PLUGIN_ROOT}/skills/orchestrating-workflows/scripts/stop-hook.sh"}]}]} |
Drive an SDLC workflow chain through a single skill invocation. The orchestrator sequences sub-skill calls, manages persistent state across pause points, and isolates per-step context by forking sub-skills into subagents.
FEAT-NNN, CHORE-NNN, BUG-NNN), check for an existing state file at .sdlc/workflows/{ID}.json and resume if found. A FEAT-NNN ID resumes a feature chain; CHORE-NNN resumes a chore chain; BUG-NNN resumes a bug chain. A #N GitHub issue reference starts a new feature workflow from that issue. Otherwise treat the argument as a free-text title and start a new workflow (feature by default; ask if ambiguous). Branch-name fallback for resume: when the user says "resume" or "continue" without an explicit ID, classify the current branch name with bash "${CLAUDE_PLUGIN_ROOT}/scripts/branch-id-parse.sh" "$(git rev-parse --abbrev-ref HEAD)" — the script applies the three regexes (^feat/(FEAT-[0-9]+)-, ^chore/(CHORE-[0-9]+)-, ^fix/(BUG-[0-9]+)-) and emits JSON {"id": "...", "type": "...", "dir": "..."} on stdout. Exit 0 means the branch carries an ID — resume that workflow via the state file. Exit 1 means no match — ask the user for an explicit ID. Exit 2 on missing arg.#N), or workflow ID to resume.documenting-chores (step 1) assigns the CHORE-NNN ID. The user may indicate a chore by saying "chore", "maintenance task", or similar.documenting-bugs (step 1) assigns the BUG-NNN ID. The user may indicate a bug by saying "bug", "fix", "defect", "regression", or similar.Three additive, positional-independent flags tune per-workflow model selection. They may appear before or after the ID / #N / title argument and do not change the existing argument shapes.
--model <tier> — hard blanket override. Replaces every non-locked fork's tier with <tier> (haiku, sonnet, or opus). May downgrade below baseline; the orchestrator emits a one-line baseline-bypass warning when it does (Edge Case 11). Baseline-locked forks are still pushed by a hard override.--complexity <tier> — soft blanket override. Treated as a low|medium|high (or equivalent tier string) floor for work-item complexity. Upgrade-only; respects baseline locks.--model-for <step>:<tier> — hard per-step override. Replaces the tier for a single named step (e.g. --model-for reviewing-requirements:opus). Per-step hard beats blanket hard (FR-5 #1 > #2). May be repeated.Parsing: run bash "${CLAUDE_PLUGIN_ROOT}/skills/orchestrating-workflows/scripts/parse-model-flags.sh" "$@" — emits {cliModel, cliComplexity, cliModelFor, positional} on stdout; exit 2 on unknown flag, malformed tier, or =-form. Pass cliModel and cliComplexity as scalar tier strings into every ${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh resolve-tier call. cliModelFor is a JSON map ({"<step>":"<tier>", ...} or null) — convert it to repeated --cli-model-for <step>:<tier> flag-value pairs before forwarding to prepare-fork.sh; see step-execution-details.md "Preparing fork flags" for the conversion pattern.
managing-work-itemsThe orchestrator integrates with issue trackers (GitHub Issues, Jira) through the managing-work-items skill. Issue tracking is additive and executed inline from main context — existing workflow steps remain unchanged. When no issue reference is found, tracking is skipped with an info-level message; mechanism failures emit a warning-level message.
For the full issue tracking protocol — extraction, invocation pattern, runnable examples, rejected alternatives, and mechanism-failure logging — see references/issue-tracking.md.
Confirmation gates require a fresh .sdlc/approvals/.approval-<gate>-<ID> marker, written by Hook A only on real UserPromptSubmit events. For canonical input shapes — approve <gate-type> <ID>, proceed <ID>, merge <ID> — marker-name resolution rules, the proceed fallback caveat, and copy-paste examples, see references/approval-marker-grammar.md.
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh check-claude-version 2.1.72 once at the entry point. The subcommand exits 0 silently when current ≥ required (or when the version cannot be determined), and exits 1 with a one-line warning on stderr when the installed Claude Code is older than the minimum. Treat the warning as advisory — continue the workflow; the per-fork NFR-6 fallback wrapper (see "Forked Steps") will catch any Agent-tool model-parameter rejection and retry without the parameter.documenting-features) in main context; then bash "${CLAUDE_PLUGIN_ROOT}/skills/orchestrating-workflows/scripts/init-workflow.sh" feature <artifact-path> (emits {id, type, complexity, issueRef}).documenting-chores); then init-workflow.sh chore <artifact-path> (same JSON shape).documenting-bugs); then init-workflow.sh bug <artifact-path> (same JSON shape).The orchestrator and its forked subagents must follow the lite-narration rules below. These rules minimize output tokens without discarding load-bearing signals. Load-bearing carve-outs (listed below) MUST be emitted as specified; they are not narration.
git status).->) and punctuation over Unicode alternatives in orchestrator-authored prose. Existing Unicode em dashes in tables and reference docs are retained. Script-emitted structured logs are out of scope for this rule — FR-14 echoes, [model] complexity-upgrade notices, and other prepare-fork.sh / workflow-state.sh output use Unicode → as their documented format (see carve-out below); do not normalize them.The following MUST always be emitted even when they resemble narration:
fail calls — users need the reason the workflow halted.reviewing-requirements — the full findings list must be shown to the user before any findings-decision prompt. Do not truncate.[model] step {N} ({skill}) → {tier} (...) audit-trail lines emitted by prepare-fork.sh. The Unicode → is the documented emitter format (matches prepare-fork.bats assertions and references/step-execution-details.md); do not rewrite to ASCII.[info], [warn], or [model] is a structured log, not narration. Emit verbatim.plan-approval, pr-review, findings-decision, review-findings, and merge-approval always require explicit user confirmation (a UserPromptSubmit event or a Hook A-recorded approval marker), regardless of any "work without stopping" instruction in the context. Do not interpret that reminder as authorization to self-resume, self-clear-gate, or self-approve at any of these five gates. See references/step-execution-details.md#pause-steps for the halt-and-surface procedure at the plan-approval / pr-review pause sites and references/step-execution-details.md Finalize fork-step blocks for the merge-approval gate procedure.Subagents forked from this orchestrator MUST return a contract line as the final line of their response. The orchestrator parses the last matching line. Three canonical shapes are defined:
done | artifact=<path> | <note-of-at-most-10-words> — success. <path> is the artifact the fork produced; the note is optional context.failed | <one-sentence reason> — failure. The orchestrator's FR-11 classifier treats an empty artifact or tool-loop exhaustion as failure; failed | is the explicit token a subagent emits to declare failure itself.Found **N errors**, **N warnings**, **N info** — retained shape for reviewing-requirements forks only. This is the pre-existing findings shape; the orchestrator's Decision Flow (see Reviewing-Requirements Findings Handling) parses error/warning/info counts from it. reviewing-requirements does not emit the done | ... shape.Precedence: the return contract takes precedence over the lite rules when the two conflict. Subagents MUST emit the contract shape even if it reads like narration. For reviewing-requirements, the full findings block (which the orchestrator displays to the user) still precedes the Found **N errors** ... summary line.
All three chains share a common shape, parameterized by chain type. The table below consolidates the Feature, Chore, and Bug step sequences; per-chain deltas follow. The Feature, Chore, and Bug section headings above all index into this one table.
| # | Applies to | Step | Skill | Context |
|---|---|---|---|---|
| 1 | feature / chore / bug | Document requirements / chore / bug | documenting-features / documenting-chores / documenting-bugs | main |
| 2 | feature / chore / bug | Review requirements (standard) | reviewing-requirements | fork (chore / bug: skip if complexity == low) |
| 3 | feature only | Create implementation plan | creating-implementation-plans | fork |
| 4 | feature only | PAUSE: Plan approval | — | pause |
| 5 | feature | Document QA test plan | documenting-qa | main |
| 3 | chore / bug | Document QA test plan | documenting-qa | main |
| 6…5+N | feature only | Implement phases 1…N | implementing-plan-phases | fork |
| 4 | chore | Execute chore | executing-chores | fork |
| 4 | bug | Execute bug fix | executing-bug-fixes | fork |
| 5+N+1 | feature only | Create PR | orchestrator | fork |
| 5+N+2 | feature | PAUSE: PR review | — | pause |
| 5 | chore / bug | PAUSE: PR review | — | pause |
| 5+N+3 | feature | Execute QA | executing-qa | main |
| 6 | chore / bug | Execute QA | executing-qa | main |
| 5+N+4 | feature | Finalize | finalizing-workflow | fork |
| 7 | chore / bug | Finalize | finalizing-workflow | fork |
Per-chain deltas (every difference the three original tables conveyed):
5 + N + 4 steps (N = phase count). Steps 3–4 (plan + plan-approval pause) and the step 6…5+N phase loop are feature-only. PR creation is a separate fork step (5+N+1) before the PR-review pause. Post-plan re-classification runs immediately after step 3.7 steps — no implementation plan, no plan-approval pause, no phase loop. PR creation is handled inside the step 4 executing-chores fork (not a separate orchestrator fork).7 steps mirroring the chore chain with bug-specific skills. PR creation is handled inside the step 4 executing-bug-fixes fork.complexity == low skip: chore and bug step 2 (reviewing-requirements) is skipped when persisted complexity is low — call advance with no fork (see references/step-execution-details.md). Feature chains always run step 2.Step-by-step procedures for starting new feature, chore, and bug workflows (active-marker creation, step 1 execution, ID allocation, issue-reference extraction, state initialization, complexity classification) and the resume procedure for paused or failed workflows live in the chain-procedures reference.
See references/chain-procedures.md for the full New Feature, New Chore, New Bug, and Resume procedures.
For each step, determine the context from the Chain Step Sequence table above and execute accordingly. The forked-step and main-context-step patterns are shared across all chains.
These steps run directly in the orchestrator's conversation because they rely on Stop hooks or interactive prompts that don't work when forked.
Step 1 — documenting-features: See New Feature Workflow Procedure in references/chain-procedures.md.
Step 5 — documenting-qa: Read the SKILL.md content from ${CLAUDE_PLUGIN_ROOT}/skills/documenting-qa/SKILL.md. Follow its instructions directly in this conversation, passing the workflow ID as argument. Expected artifact: qa/test-plans/QA-plan-{ID}.md. On completion:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh advance {ID} "qa/test-plans/QA-plan-{ID}.md"
Step 5+N+3 — executing-qa: Read the SKILL.md content from ${CLAUDE_PLUGIN_ROOT}/skills/executing-qa/SKILL.md. Follow its instructions directly in this conversation, passing the workflow ID as argument. Expected artifact: qa/test-results/QA-results-{ID}.md.
Immediately after the skill returns and before calling advance, parse the return contract line and persist findings:
qa_parsed=$(echo "$qa_response" | bash "${CLAUDE_SKILL_DIR}/scripts/parse-qa-return.sh" --stdin --artifact "qa/test-results/QA-results-{ID}.md")
On parse success, persist via:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh record-findings --type qa {ID} {stepIndex} \
"$(echo "$qa_parsed" | jq -r .verdict)" \
"$(echo "$qa_parsed" | jq -r .passed)" \
"$(echo "$qa_parsed" | jq -r .failed)" \
"$(echo "$qa_parsed" | jq -r .errored)" \
"$(echo "$qa_parsed" | jq -r .summary)"
Also persist the verdict to the QA-loop field:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh set-qa-verdict {ID} "$(echo "$qa_parsed" | jq -r .verdict)"
On parse mismatch (non-zero exit from parse-qa-return.sh), halt the workflow:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh fail {ID} "<contract-mismatch error from parse-qa-return.sh stderr>"
Surface the contract-mismatch error verbatim — this is a load-bearing carve-out, not narration.
After persisting findings, run the QA dispatch and branch on the result (FR-7). After QA, advance behavior is verdict-gated per qa-dispatch.sh. See references/qa-loop.md for the dispatch table.
dispatch=$(bash "${CLAUDE_SKILL_DIR}/scripts/qa-dispatch.sh" {ID})
Branch on $dispatch:
advance: call workflow-state.sh advance {ID} "qa/test-results/QA-results-{ID}.md" and continue to the next step.adopt-phase: fork addressing-qa-findings (the skill auto-detects adopt phase from state per FR-4). On its done | phase=adopted return, call workflow-state.sh advance {ID} "qa/test-results/QA-results-{ID}.md" and continue.fix-phase: increment qaFixAttempts and record a state event; fork addressing-qa-findings (auto-detects fix phase); on its done | phase=fix-committed return, re-invoke executing-qa (which auto-detects re-QA mode per FR-3). After re-QA completes, persist findings, set-qa-verdict, then re-run qa-dispatch.sh and loop.
new_count=$(bash "${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh" inc-qa-fix-attempts {ID})
# [info] qa-loop: fix attempt ${new_count} of ${qaLoopCap} for {ID}
# fork addressing-qa-findings, then re-invoke executing-qa
pause:qa-loop-exhausted: pause the workflow and surface the resume options to the user (load-bearing carve-out):
QA loop exhausted after {qaFixAttempts} fix attempt(s). Issues remain unresolved.
Resume options:
--approve-advance advance past QA with issues unresolved (counter preserved)
--qa-loop-cap <N> raise the cap to N and retry (resets counter to 0)
To abandon: close this workflow and address the issues manually.
workflow-state.sh pause {ID} qa-loop-exhaustedpause:qa-error: surface the QA ERROR reason; workflow-state.sh pause {ID} qa-error. User resolves manually then re-invokes.pause:fix-suite-failed: surface the FR-4 failure reason; workflow-state.sh pause {ID} fix-suite-failed. User resolves manually then re-invokes.pause:adoption-failed: surface the FR-5 partial-success reason (adoptedTests is preserved per FR-4); workflow-state.sh pause {ID} adoption-failed. User resolves manually then re-invokes.Step 1 — documenting-chores: See New Chore Workflow Procedure in references/chain-procedures.md.
Step 3 — documenting-qa: Same pattern as feature chain step 5. Read ${CLAUDE_PLUGIN_ROOT}/skills/documenting-qa/SKILL.md, follow its instructions in this conversation, passing the workflow ID as argument. Expected artifact: qa/test-plans/QA-plan-{ID}.md. On completion:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh advance {ID} "qa/test-plans/QA-plan-{ID}.md"
Step 6 — executing-qa: Same pattern as feature chain step 5+N+3. Read ${CLAUDE_PLUGIN_ROOT}/skills/executing-qa/SKILL.md, follow its instructions in this conversation, passing the workflow ID as argument. Expected artifact: qa/test-results/QA-results-{ID}.md.
Immediately after the skill returns and before calling advance, parse the return contract line and persist findings:
qa_parsed=$(echo "$qa_response" | bash "${CLAUDE_SKILL_DIR}/scripts/parse-qa-return.sh" --stdin --artifact "qa/test-results/QA-results-{ID}.md")
On parse success, persist via:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh record-findings --type qa {ID} {stepIndex} \
"$(echo "$qa_parsed" | jq -r .verdict)" \
"$(echo "$qa_parsed" | jq -r .passed)" \
"$(echo "$qa_parsed" | jq -r .failed)" \
"$(echo "$qa_parsed" | jq -r .errored)" \
"$(echo "$qa_parsed" | jq -r .summary)"
Also persist the verdict:
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh set-qa-verdict {ID} "$(echo "$qa_parsed" | jq -r .verdict)"
On parse mismatch, halt with fail and surface the contract-mismatch error verbatim (load-bearing carve-out).
After persisting findings, run the QA dispatch and branch on the result — same logic as feature chain step 5+N+3. After QA, advance behavior is verdict-gated per qa-dispatch.sh. See references/qa-loop.md for the dispatch table.
Forked steps use the Agent tool with the FEAT-014 pre-fork ceremony composed into prepare-fork.sh (FEAT-021 FR-1). Cross-cutting skills like managing-work-items are executed inline from main context (see Issue Tracking) — they do not follow the forked-step recipe.
See references/forked-steps.md for the full seven-step fork recipe (pre-fork ceremony, Agent-tool spawn with model parameter, NFR-6 fallback, FR-11 retry classifier, artifact validation, advance) and the Fork Step-Name Map.
After each reviewing-requirements fork (feature step 2; chore/bug step 2) the orchestrator parses the subagent's return text for the Found **N errors**, **N warnings**, **N info** summary line, runs the Decision Flow (zero-findings auto-advance; warnings-only gate by chain type and complexity; errors block and prompt for apply-fixes vs pause), applies any auto-fixes in main context, persists findings via record-findings before every advance or pause, and re-runs the fork at most once.
See references/reviewing-requirements-flow.md for the full parsing rules, Decision Flow, Applying Auto-Fixes sequence, Decision-to-Call mapping table, and individual-findings parsing procedure for auto-advanced decisions.
Chain-specific fork instructions for feature, chore, and bug chains (skip conditions, issue-tracking invocations, post-step-3 re-classification), pause step procedures, the phase loop for feature chains, and PR creation are documented in the step execution details reference.
See references/step-execution-details.md for the full chain-specific fork instructions, pause steps, phase loop, and PR creation.
This section summarizes the FEAT-014 adaptive model selection policy that every fork in this skill obeys. For the full algorithm pseudocode, tuning guidance, audit-trail field reference, known limitations, and migration guidance, read references/model-selection.md — that file is the canonical reference and this section is a concise summary.
Per-fork model selection is a two-axis lookup combined with an override chain. The orchestrator runs the resolve-tier subcommand of ${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh before every fork; the return value is passed verbatim as the Agent tool's model parameter.
final_tier = walk_override_chain(
base = max(step_baseline, work_item_complexity),
overrides = [cli_model_for, cli_model, cli_complexity, state_model_override]
)
Tiers are ordered haiku < sonnet < opus. Complexity labels map to tiers via low → haiku, medium → sonnet, high → opus.
Each forked step has a baseline tier floor (most are sonnet; finalizing-workflow and PR creation are haiku and baseline-locked). See references/model-selection.md for the full step baseline table and rationale.
Complexity is computed at workflow init from requirement-document signals (acceptance criteria count, severity, FR count, etc.) and persisted to state; features may upgrade post-plan via phase count. See references/model-selection.md for the full signal matrix and fallback rules.
Walked in strict precedence order; the first non-null entry wins. Hard overrides replace the tier entirely; soft overrides are upgrade-only and respect baseline locks.
| Order | Override | Kind | Behavior |
|---|---|---|---|
| 1 | CLI --model-for <step>:<tier> | hard | Replaces tier for the matching step. Bypasses baseline lock for that step. |
| 2 | CLI --model <tier> | hard | Replaces tier for every fork, including baseline-locked steps. Can downgrade below baseline. |
| 3 | CLI --complexity <tier> | soft | max(current, override) applied via the work-item complexity axis. Respects baseline lock and baseline floor. |
| 4 | State file modelOverride: <tier> | soft | Upgrade-only. Respects baseline lock. Editable between pause and resume via ${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh set-complexity. |
| 5 | Computed tier | — | Lowest precedence. Derived from step baseline and work-item complexity. |
Hard vs soft in one line: hard overrides answer "I know exactly what I want; do it"; soft overrides answer "I think this work is at least this complex".
finalizing-workflow and the inline PR-creation fork are baseline-locked:
--complexity, state modelOverride) are ignored — they cannot push baseline-locked steps off their baseline.--model, --model-for) bypass the lock and apply normally — --model opus on a feature chain forces finalizing-workflow and PR creation to opus.Rationale: these are mechanical gh / git operations with no reasoning component, regardless of how complex the overall feature is. Upgrading them to a higher tier costs tokens with zero quality benefit. A hard override is the explicit escape hatch for users who want to force them anyway.
${CLAUDE_SKILL_DIR}/scripts/workflow-state.sh fail {ID} "{error message}". Display the error clearly. Halt execution. The user can re-invoke to retry.fail with the phase error.executing-qa handles retries internally via its own loop. If ultimately unfixable, the orchestrator records the failure.${CLAUDE_PLUGIN_ROOT}/skills/{skill-name}/SKILL.md. Check that the lwndev-sdlc plugin is installed." Call fail./orchestrating-workflows "feature title"."Verification checklists for all chain types (common, feature, chore, bug), managing-work-items checks, issue-tracking verification (Cases A/B/C), and the full relationship-to-other-skills diagram with per-chain skill tables are documented in the verification reference.
See references/verification-and-relationships.md for the full verification checklists and skill relationship tables.
Developer-persona skill that consumes QA findings (verdict ISSUES-FOUND), reproduces failing QA tests, writes production fixes, re-validates, and adopts QA tests into *.qa.* siblings next to peer tests once re-QA passes. Use when the orchestrator branches from executing-qa with a non-PASS verdict, or when re-running addressing-qa-findings to drive the QA loop forward.
Merges the current PR, checks out main, fetches, and pulls — reducing the repetitive end-of-workflow sequence to a single slash command. Use when the user says "finalize", "merge and reset", "finalize workflow", or after QA passes.
Executes adversarial QA against a feature branch by writing and running real tests (or producing a structured exploratory review when no test framework is detected). Emits a version-2 results artifact with verdict, execution results, findings, and reconciliation delta.
Centralizes git and pull-request operations into a single delegatable skill. Dispatches between GitHub (gh CLI) and Azure DevOps (az CLI) backends based on origin URL or SDLC_SCM_BACKEND env override. Use when the orchestrator or a consumer skill needs to create, view, list, merge, or diff pull requests, or perform branch/commit/push work backed by either SCM provider.
Executes bug fix workflows from branch creation through pull request with root cause driven execution. Use when the user says "execute bug fix", "fix this bug", "run the bug fix workflow", or references bug documents in requirements/bugs/.
Executes chore task workflows including branch creation, implementation, and pull request creation. Use when the user says "execute chore", "implement this chore", "run the chore workflow", or references chore documents in requirements/chores/.