twig-sdlc
Run the end-to-end SDLC workflow for twig development. Takes an ADO work item or natural language prompt through planning, implementation, PR lifecycle, and close-out via Conductor multi-agent orchestration. Activate when asked to implement a feature end-to-end, run the full SDLC pipeline, or orches
Install
mkdir -p .claude/skills/twig-sdlc && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15071" && unzip -o skill.zip -d .claude/skills/twig-sdlc && rm skill.zipInstalls to .claude/skills/twig-sdlc
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Run the end-to-end SDLC workflow for twig development. Takes an ADO work item or natural language prompt through planning, implementation, PR lifecycle, and close-out via Conductor multi-agent orchestration. Activate when asked to implement a feature end-to-end, run the full SDLC pipeline, or orchestrate planning through delivery.About this skill
End-to-End SDLC Workflow
Orchestrated SDLC pipeline powered by the conductor skill. Takes an ADO work item (Epic or Issue) or a natural language prompt and drives it through planning, implementation, code review, PR management, and close-out — all via multi-agent orchestration.
This workflow is long-running — typically 30-120+ minutes depending on scope. Always launch with
conductor run ... --web(no--silent) in a hidden window — this captures full agent output in logs for post-mortem analysis while the web dashboard provides real-time monitoring. Do NOT use--web-bg— it does not work correctly; always use--web.
Always launch detached — use
Start-Process -WindowStyle Hiddenso conductor survives if the parent session drops and doesn't clutter the terminal. Non-detached async shells die when the Copilot CLI session reconnects or terminates.
Workflows
All workflows are registered in the twig conductor registry. Use short names — no absolute paths needed.
Workflow source: PolyphonyRequiem/twig-conductor-workflows Install:
conductor registry add twig --source github://PolyphonyRequiem/twig-conductor-workflowsUpdate:conductor registry update twig
| Workflow | Registry Name | Purpose | Key Inputs |
|---|---|---|---|
| Planning only | twig-sdlc-planning@twig | Recursive planner: architect + review + seed + per-issue task planning | work_item_id or prompt, intent |
| Implementation only | twig-sdlc-implement@twig | Coding, review, PR lifecycle | work_item_id, intent |
| Full (composite) | twig-sdlc-full@twig | Planning → implementation → close-out → retrospective | work_item_id or prompt, intent |
Workflow Inputs
| Input | Type | Required | Default | Description |
|---|---|---|---|---|
work_item_id | string | conditional | — | ADO work item ID (Epic, Issue, or Task). Required for resume and redo. |
prompt | string | conditional | "" | Natural language description. Creates a new Epic. Forces intent=new. |
intent | string | no | resume | User intent: new (fresh start), redo (delete and redo), resume (pick up where left off). |
pr_owner | string | yes | — | GitHub owner (org or user) of the PR target repository. For twig: PolyphonyRequiem. |
pr_repo_name | string | yes | — | GitHub repository name (without owner) of the PR target. For twig: twig. |
gh_user | string | no | "" | Explicit gh CLI user identity. Pinned via $env:GH_CONDUCTOR_USER. Empty = use active gh account. |
pr_ownerandpr_repo_nameare required. They tell the workflow which GitHub repository to target for PR creation, review, and merge. Omitting them causes the workflow to fail at the PR lifecycle stage. For twig, always passpr_owner=PolyphonyRequiemandpr_repo_name=twig.
skip_plan_reviewis removed — useintent=resumeinstead (default behavior). For new runs from a prompt,intent=newis inferred automatically.
Workflow Metadata
All metadata is passed dynamically via --metadata / -m flags at invocation time.
The workflow YAMLs contain no metadata — the invoking agent resolves all values.
| Field | Example | Description |
|---|---|---|
tracker | ado | Work item tracking system |
project_url | https://dev.azure.com/dangreen-msft/Twig | ADO project URL |
git_repo | C:\Users\dangreen\projects\twig2 | Originating git repo path |
workitem_id | 1842 | Target work item ID (numeric) |
worktree_name | twig2-1842 | Git worktree directory name |
cwd | C:\Users\dangreen\projects\twig2-1842 | Worktree working directory |
All values must be resolved — templates with
{braces}are skipped by the dashboard.
Quick Reference
Always run in a dedicated worktree — never on main or your working tree. Name the
worktree twig2-<ID> based on the work item ID.
# 1. Create a worktree for the work item
git worktree add -b sdlc/<ID> ../twig2-<ID> main
cd ../twig2-<ID>
# 2. Restore dependencies (worktrees don't share NuGet packages)
dotnet restore
# 3. Copy .twig workspace and set context to the target work item
Copy-Item -Recurse ../twig2/.twig .twig
twig set <ID>
twig sync
# 4. Run the full SDLC — default intent is "resume"
conductor run twig-sdlc-full@twig --input work_item_id=<ID> --input pr_owner=PolyphonyRequiem --input pr_repo_name=twig -m tracker=ado -m project_url=https://dev.azure.com/dangreen-msft/Twig -m git_repo=C:\Users\dangreen\projects\twig2 -m workitem_id=<ID> -m worktree_name=twig2-<ID> -m cwd=C:\Users\dangreen\projects\twig2-<ID> --web
# For a brand new work item (no prior work):
conductor run twig-sdlc-full@twig --input work_item_id=<ID> --input intent=new --input pr_owner=PolyphonyRequiem --input pr_repo_name=twig -m tracker=ado -m project_url=https://dev.azure.com/dangreen-msft/Twig -m git_repo=C:\Users\dangreen\projects\twig2 -m workitem_id=<ID> -m worktree_name=twig2-<ID> -m cwd=C:\Users\dangreen\projects\twig2-<ID> --web
# To redo from scratch (deletes existing children/branches):
conductor run twig-sdlc-full@twig --input work_item_id=<ID> --input intent=redo --input pr_owner=PolyphonyRequiem --input pr_repo_name=twig -m tracker=ado -m project_url=https://dev.azure.com/dangreen-msft/Twig -m git_repo=C:\Users\dangreen\projects\twig2 -m workitem_id=<ID> -m worktree_name=twig2-<ID> -m cwd=C:\Users\dangreen\projects\twig2-<ID> --web
Launching Multiple Runs
When running multiple work items, use discrete worktrees and launch 10 seconds apart.
Option A: Direct launch with logging (recommended)
Simpler approach — launches conductor directly with Tee-Object for log capture.
Dashboard URLs are written to conductor.log in each worktree.
# Create worktrees (NEVER on main — always a dedicated branch)
git worktree add -b sdlc/1673 ../twig2-1673 main
git worktree add -b sdlc/1782 ../twig2-1782 main
# Launch 10s apart with log capture
$ids = 1673, 1782
foreach ($id in $ids) {
$wt = "C:\Users\dangreen\projects\twig2-$id"
Start-Process -FilePath "pwsh" -ArgumentList "-NoProfile", "-Command",
"cd $wt; conductor run twig-sdlc-full@twig --input work_item_id=$id --input pr_owner=PolyphonyRequiem --input pr_repo_name=twig -m tracker=ado -m project_url=https://dev.azure.com/dangreen-msft/Twig -m git_repo=C:\Users\dangreen\projects\twig2 -m workitem_id=$id -m worktree_name=twig2-$id -m cwd=$wt --web 2>&1 | Tee-Object -FilePath $wt\conductor.log" `
-WindowStyle Hidden -PassThru | ForEach-Object { "Launched #$id — PID $($_.Id)" }
if ($id -ne $ids[-1]) { Start-Sleep -Seconds 10 }
}
# Retrieve dashboard URLs after ~15s
Start-Sleep -Seconds 15
foreach ($id in $ids) {
Get-Content "C:\Users\dangreen\projects\twig2-$id\conductor.log" |
Select-String "Dashboard:" | Select-Object -First 1
}
Option B: Job Object wrapper (orphan cleanup)
Use tools/run-conductor.ps1 when orphaned processes are a concern (MCP servers, test
runners surviving after conductor exits). The wrapper creates a Windows Job Object that
kills all child processes when conductor exits.
⚠️ Argument quoting is critical — the
-Argumentsvalue must be wrapped in escaped quotes soStart-Processpasses it as a single token to the script parameter.
$ids = 1673, 1782
foreach ($id in $ids) {
$wt = "C:\Users\dangreen\projects\twig2-$id"
$args = "run twig-sdlc-full@twig --input work_item_id=$id --input pr_owner=PolyphonyRequiem --input pr_repo_name=twig -m tracker=ado -m project_url=https://dev.azure.com/dangreen-msft/Twig -m git_repo=C:\Users\dangreen\projects\twig2 -m workitem_id=$id -m worktree_name=twig2-$id -m cwd=$wt --web"
Start-Process -FilePath "pwsh" -ArgumentList "-NoProfile", "-File",
"tools\run-conductor.ps1",
"-WorkingDirectory", "`"$wt`"",
"-Arguments", "`"$args`"" `
-WindowStyle Hidden
if ($id -ne $ids[-1]) { Start-Sleep -Seconds 10 }
}
The 10-second stagger avoids MCP server port collisions and rate-limit spikes.
Always share the dashboard URL — after launching, provide the user the web dashboard URL from terminal output.
Worktree Cleanup
After runs complete, clean up worktrees:
# Remove worktrees and branches
git worktree remove --force ../twig2-1673
git branch -D sdlc/1673
# If directories are locked, kill lingering processes first:
dotnet build-server shutdown
Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'twig2-\d+' } |
ForEach-Object { Stop-Process -Id $_.ProcessId -Force }
Phases
Phase 0: Preflight Validation
Validates external dependencies before expensive LLM planning begins. Catches broken auth, missing tooling, and connectivity failures early — saving minutes of wasted Opus inference that would otherwise fail opaquely in a downstream agent.
Entry Points
| Script | Workflow | Purpose | Budget |
|---|---|---|---|
preflight-check.ps1 | twig-sdlc-full.yaml | Full validation (12 checks) for apex SDLC entry | ≤10 seconds |
preflight-lite.ps1 | twig-sdlc-planning.yaml, twig-sdlc-implement.yaml | Lightweight validation (3 checks) for sub-workflow re-entry | ≤5 seconds |
Full preflight runs as the preflight_check script node in twig-sdlc-full.yaml.
On failure, it routes to the preflight_gate human gate where the user can retry,
proceed anyway (advisory-only failures), or abort.
Lite preflight runs as the preflight_lite script node in sub-workflows. This
catches the most common failures (gh auth, git repo, ADO connectivity) without
repeating the full 12-check suite. On failure, it routes to preflight_lite_gate.
Required vs. Advisory Checks
Checks are classified into two categories:
- **Required
Content truncated.