VSA + SOLID · .NET/Blazor · Next.js · Claude Code + Cursor
You are the orchestrator
The skills are your instruments. You don't write the boilerplate — you point the skills, decide at the forks, and keep the board honest. Everything reports into one shared state: the GitHub Projects board. Click a flow to light its path, or click any node to see what that skill does.
Every skill reads its repo/project/label values from that repo's GITHUB-PROJECTS.md config block — one file per repo, skills stay generic.
Everything. All flows at once — the full orchestration surface. Pick one to isolate it.
control / hand-off conditional branch▸ pulsing = active flowclick a node for detail ↓
The orchestrator
You point, the skills execute
Pick any node in the map to see what that skill does, when you invoke it, and what it reads from the repo config. The whole ecosystem is designed so that you make the decisions and the skills carry the mechanics.
The linear spine
/start-feature → implement in the slice → crucible review → /finish-feature → Done.
Everything writes status to the board — that's your single source of truth.
The engine: review ↔ refactor
The review no longer passes/fails — it returns ranked refactors + a readiness signal.
You loop review → apply top refactors → re-review until it reads Ready, then hand to finish.
How you multitask
Orchestrator modes
SerialOne issue = one branch = one worktree. The default clean unit of work.
Parallel (fan-out)An Epic splits into sub-issues; each is an isolated slice in its own worktree. You context-switch between independent streams with no collisions.
Loopedreview → refactor → re-review runs until Ready, then auto-hands to /finish-feature. The inner loop you can automate.
Parallel lensesOne review fans out into VSA · SOLID · stack · Simplify passes at once, then merges findings — faster than a single sweep.
The words you actually say to drive each skill. Fill the <placeholders>and paste. Every prompt also shows up in its node's detail panel above — click Copy on any of them.
Standing orders — paste once per session
Session kickoffYou're my implementation partner on this .NET / Blazor repo. House rules: vertical-slice architecture, outcome-oriented SOLID, one issue = one branch = one worktree. Track all new work as GitHub issues on the board — never markdown trackers. At any real design fork, stop and give me 2–3 options with costs before implementing. Hold the crucible review bar and report progress honestly.
/start-feature
New briefStart on: <brief>. Create the issue, add it to the board, branch feat/<n>-slug, and give me the verify plan before you build. Consult me at any fork.
Existing issuePick up issue #<N> — set up the worktree and read the owning slice before you touch anything.
Just goWork the next thing on the board — tell me which issue you're taking and why.
Consult at a fork
Force the forkBefore implementing, surface 2–3 viable mechanisms with their costs and silent breakages, recommend one, and wait for my call.
Implement in the slice
GuardrailsBuild it in the owning slice only — shared kernel stays contracts/ports, no ProjectReference into a sibling product. Flag it if this wants to push a file past ~1k lines.
crucible review
Full reviewCrucible review of the current branch. Refactor-oriented: severity-tagged findings each with the fix, then close with the top 1–3 refactors by leverage and a merge-readiness signal.
Parallel lensesRun VSA, SOLID, Blazor, and simplification as separate lenses over this diff, then merge the findings into one ranked list.
Just the gateIs this Ready to merge, Ready after blockers, or Needs rework? Give me only the blockers first.
Refactor loop
Turn the crankApply the top refactors from that review, then re-review. Loop until the signal reads Ready, then stop and show me the diff.
/update-docs
Route itWhere does this go? <thing>
Capture a bugCapture this as its own linked bug and keep going on the current branch: <desc>.
Log a decisionLog this design decision and reference it from the issue: <decision>.
/finish-feature
Ship itFinish the feature — run the suites and report exact counts, rebase onto the default branch, write the changelog fragment, and open the PR that Closes #<N>.
Live retest owedWrap it up, but a live retest is owed: open the PR with Refs #<N> and move it to Verifying instead of Done.
Verifying → Done
Confirm liveLive retest passed on #<N> — move it to Done and close it out.
Blocked
Mark blockedThis is blocked on <external dep>. Mark it Blocked on the board with a one-line note, and tell me what unblocks it.
Epic fan-out (parallel)
Split it upThis is multi-stream: create an Epic with sub-issues for <A>, <B>, <C>, then start the first sub-issue.
Fan out moreSpin up the next sub-issues under epic #<N> and give me a one-line status for each.
🌙 Night shift (manual runner)
1 · Mark an issue safe for unattended workLabel issue #<N> auto:ready — it's specified well enough to run overnight without me.
2 · Fire tonight's run (shell command, not a prompt)gh workflow run night-shift --repo <owner>/<repo>
3 · Morning triageShow me last night's night-shift report: which PRs are open and Ready, what needs my decision, and what got stuck.
Reference — the standing prompt baked into the workflowRun the night-shift skill on <owner>/<repo>. Take up to 3 auto:ready issues; run each through implement → crucible review → refactor-until-Ready → tests → open a PR. Stop at any real design fork and leave me a recommendation. Never merge. Post a morning report of PRs opened, decisions needed, and anything stuck.
history (read-only recall)
Catch up on an issueHistory of #<N> — what have we tried, in order, and what happened each time.
Catch up on a topicCatch me up on <area/topic>: find the related issues across open and closed, and give me the chronological what-we-tried.
Before restarting workBefore I pick this back up — what did we do last on <topic>, and did any approach get reverted or superseded?
Autonomous · your runbook
🌙 Night shift — how you actually run it
Wired as a GitHub Actions workflow (.github/workflows/night-shift.yml) on a self-hosted runner on your always-on dev box. Manual-only by default — nothing fires until you say so, and a run only ever touches thisrepo's board.
1 · Before bed — pick the workLabel well-specified issues auto:ready. That label is the only opt-in the loop honors — epics and needs:decision issues are skipped. No label, no work.
2 · Fire the runActions → night-shift → Run workflow, or gh workflow run night-shift. It takes up to 3 eligible issues, highest priority first — then walk away.
3 · While you sleep — the guaranteesSame loop as daytime: build in the slice, crucible until Ready, tests green. At a real design fork it never guesses — it comments its recommendation, labels needs:decision, moves the issue to Blocked. Opens PRs, never merges.
4 · Morning — triage the reportOne digest: ✅ PRs opened (review & merge) · 🟡 needs your call (answer the fork, relabel) · 🔴 stuck (WIP branch pushed) · ⏭️ skipped (and why). You wake to a review queue, not a mystery.
Plug in another repo: copy the template at docs/project-tracking/templates/night-shift-dotnet-cygnet.yml (or adapt this repo's workflow) into that repo, register the self-hosted runner there, and add its ANTHROPIC_API_KEY secret. Each copy works only its own board. Want it truly nightly? Uncomment the schedule:block — that's the deliberate opt-in to autopilot.
Skills read every repo-specific value (owner · project # · ids · stack · test command · area:*labels) from that repo's GITHUB-PROJECTS.md. Drop the process skills + the matching crucible-<stack>into any repo and the whole loop works. · Instruments: /start-feature · crucible-{blazor,nextjs} · /finish-feature · /update-docs · /history · /night-shift over the GitHub Projects board.