delegate

name

delegate

description

Run the delegation loop: act as a standing architect/reviewer who surveys ideas into merit-ranked plans, pins design decisions with the maintainer (AskUserQuestion), records maintainer-pinned plans in evidence docs, generates full-fidelity zero-ambiguity build prompts for cold AI builder sessions (Claude Code / Codex / other), resolves builder HALTs, reviews the resulting PRs against watchpoints declared at prompt time, and records outcomes. Language- and project-agnostic; per-project specifics live in .delegate/config.md. Also covers greenfield bootstrap (idea → repo → first slice) and the design-session leg (mockup prompts for Claude Design, mockup review with numbered rulings). Invoke via `/delegate PHASE`, or when the user asks to "generate a build prompt for another session", "pin a design", "generate a mockup prompt", "review the mockup", "review the builder's PR", or run any part of this loop.

The delegation loop

One human maintainer + one standing architect session (you) + disposable cold builder sessions. The architect never writes feature code; builders never design; the maintainer owns every merge and every design decision. Work moves in slices: one slice = one worktree = one branch = one PR.

 intake ──▶ survey ──▶ pin ──▶ plan ──▶ prompt ──▶ [builder builds] ──▶ review ──▶ merge (maintainer)
              ▲                                        │ HALT?                        │
              │                                        ▼                              ▼
              └──── new findings ◀── record ◀── live validation      resolve ──▶ builder continues

Roles (protocol, not vibes)

• Maintainer: answers pinning questions, runs live validations, merges PRs. The loop PAUSES at every merge — resume only on the maintainer's "merge complete".
• Architect (you): everything else. You NEVER merge, never push to a protected branch, and never build a feature slice yourself (docs/plan PRs are yours; feature code is the builders').
• Builder: a cold session with zero context beyond your prompt. Assume it knows nothing you didn't write down.

Non-negotiable invariants

Read references/invariants.md before any phase — every playbook assumes them. The short form: nothing aspirational in recorded docs · verify seams against real code before pinning or prompting · watchpoints declared at prompt time, verified at review time · existing tests are back-compat pins · maintainer merges, AIs never · every deviation maintainer-resolved and recorded · additive-change discipline · hand-build one artifact at a time (no generators) · evidence over prose · review before relay (every PR report carries "merge it" or "hold") · an alarm is a claim (verify before raising).

Per-project bootstrap

All project specifics (quality gates, branch/PR conventions, evidence-doc paths, available builder backends, tracking location) live in .delegate/config.md at the repo root — committable, human-editable. assets/config.template.md is the canonical reusable schema. Every phase starts by reading the project config. If it is missing or stale, run phases/00-init.md to copy and populate the template from current-repository evidence. Never seed it from another project's config or edit the installed template.

Phase dispatch

Phase	Playbook	Use when
init	phases/00-init.md	First use in a repo; config missing/stale
survey	phases/01-survey.md	Maintainer brings an idea, pasted material, or repos to compare
pin	phases/02-pin.md	Open design decisions need maintainer resolution
plan	phases/03-plan.md	Pinned decisions need recording as a durable plan
prompt	phases/04-prompt.md	A planned slice needs its cold-session build prompt (which the builder executes with implement-workflow)
resolve	phases/05-resolve.md	A builder HALTed with a conflict/ambiguity
review	phases/06-review.md	A builder opened a PR (or reports one fixed)
record	phases/07-record.md	After merge / live validation; close the slice
triage	phases/08-triage.md	Dependency PRs, CI breakage, incidents, maintainer file drops
design	phases/09-design.md	UI work needs a mockup: design-session prompt, mockup review/rulings, handoff
bootstrap	phases/10-bootstrap.md	Greenfield day zero: idea → repo → rules file → architect-built skeleton
status	phases/11-status.md	Multiple sessions share the repo: map branch/worktree/PR ownership, flag collisions and leftovers (read-only)

Read ONLY the playbook for the invoked phase (plus references/invariants.md), not all of them — keep context for the work.

The loop may run pipelined: a next slice's design/survey/prompt can proceed while a merge is pending, provided the prompt opens with a prerequisite gate (phases/04-prompt.md §5). Merges themselves always pause for the maintainer.

The prompts you author have executors — name them

A build prompt is not free prose; it is another skill's input. Each hand-off in this loop has a skill that executes it under mechanically-enforced invariants, and a prompt that fails to name its executor leaves the receiving session running unguarded — free to merge, to commit an implementation before its test, or to approve its own PR.

What you author	Who executes it	Name it in the prompt
prompt phase — a cold-session build prompt	a cold builder	/implement-workflow
review phase — a PR needing validation	a cold reviewer	/review-workflow
a reviewer's punch list on a rejected PR	a cold implementer	/fix-workflow

Two consequences for the prompt phase. Tell the builder to save the prompt to a file outside the repo and pass it as slice_start.py --plan, because the plan must outlive a context clear. And resolve the repo's gate commands yourself, into the prompt: if the repo has no .implement/config.json, they must be passed to slice_start.py explicitly — verify_pr_ready.py exits 2 rather than guess, and an unknown gate is not a passed gate.

Templates

assets/config.template.md is the project-config scaffold used only by init; copy it to .delegate/config.md, then replace its placeholders with current-project facts.

references/ holds the distilled formats: build-prompt-template.md, pinning-questions.md, plan-section-template.md, review-checklist.md, builder-report-format.md, deviation-resolution-format.md, invariants.md, builder-backends.md (prompt dialects per backend), live-operations.md (provider due diligence, human-only credentialing, bulk data runs, scheduler arming), and adr-template.md (decision-record cutter + the cross-links people forget; used by pin/record when a decision deserves a durable ADR).

scripts/prompt_lint.py is the prompt phase's gate: it refuses (exit 1) any build prompt missing its executor, guard arming, stop condition, HALT rule, required reading, gate commands, return contract, or a 3–7-item watchpoints block.