bert.hausmans
c9e417690c
Adds crewli-architect, backend/frontend-implementer, test-writer subagents, the /build-module orchestrator command, the PR merge-gate template, and a permissions allow-list in settings.json. Documents the layer as CLAUDE_CODE_TOOLING.md section 10. Implementer Edit/Write is allow-listed; git push deliberately omitted so merge/push stay human. Co-Authored-By: Claude <noreply@anthropic.com>
73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
---
|
|
description: >
|
|
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).
|
|
argument-hint: <task-name-or-gitea-issue-#>
|
|
allowed-tools: 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.
|