crewli/.claude/commands/build-module.md

description, argument-hint, allowed-tools

description	argument-hint	allowed-tools
Orchestrate a full module build from an approved decision brief: dispatch backend/frontend/test subagents per the plan, run the reviewer gate, and assemble the PR merge-gate. Stops at the two human gates (decomposition approval, merge).	<task-name-or-gitea-issue-#>	Read, Grep, Glob, Bash, Agent, Edit, Write

Orchestrate the build for: $ARGUMENTS

You are the orchestrator running in the MAIN session (subagents cannot spawn subagents, so the sequencing logic lives here, not in an agent). You dispatch the specialist subagents via the Agent tool.

Phase 0 — Branch

Confirm a clean working tree first (git status). Create feat/<task> off main. Branch creation is ALWAYS Phase 0 (Crewli prompt discipline — never operate on main directly).

Phase 1 — Architect (HUMAN GATE 1)

Dispatch the crewli-architect subagent on $ARGUMENTS. It will drift-check, audit filesystem state, decompose, and emit a DECISION BRIEF ending in READY FOR DISPATCH. -> STOP. Present the brief verbatim. Wait for the human to reply approve / adjust / reject. Do NOT proceed without explicit approval. If adjust, relay the changes back to the architect and re-present. If reject, halt.

Phase 2 — Dispatch (after approval only)

Walk the approved subtask table in dependency order:

• Sequential subtasks: dispatch the assigned implementer subagent, wait, verify the commit landed (git log -1), then proceed.
• Parallel-safe subtasks: dispatch as background subagents. The implementer agents carry isolation: worktree, so parallel-safe subtasks are file-isolated automatically — no manual worktree juggling. Merge each worktree branch back as it completes. After each backend/frontend subtask commits, dispatch test-writer for its tests BEFORE moving to the next dependent subtask.

If any implementer or test-writer STOPS and reports a deviation from the approved plan, surface it to the human — do not improvise a fix around an approved decomposition.

Phase 3 — Review gate

Dispatch crewli-reviewer on the changes since the branch point. Read its final REVIEW VERDICT: line.

• BLOCK -> route the MUST FIX findings back to the relevant implementer subagent, re-run, re-review. Loop until PASS. The human is NOT bothered during this loop.
• PASS -> proceed to Phase 4.

Phase 4 — Assemble merge gate (HUMAN GATE 2)

Fill .claude/templates/pr-merge-gate.md with REAL signals: test counts, the reviewer verdict, Larastan result, the multi-tenancy 403 test status, the Gitea compare URL, the commit table, and the merge commit message. Verify EVERY gate signal is green. If ANY signal is red, return to Phase 2/3 — never present a red gate to the human. -> Present the completed merge gate. Wait for the human to reply merge. (You do NOT execute the merge or any push — the human performs the --no-ff merge into local main at their discretion.)

Phase 5 — Post-merge reminders (after the human confirms merge)

• If dev-docs changed: remind to run /sync-docs and re-upload .claude-sync/ (including SYNC_MANIFEST.md) to Project Knowledge. Without the upload, the next drift-check is blind.
• Delete the feature branch locally and remotely ONLY after confirming the merge actually landed on main (git log main --oneline | grep the merge). This is the pre-merge verification gate — the D1 near-miss rule. Never delete a branch whose merge you haven't verified.