agents: PM-orchestrated flow — @pm hub, @qa reviews, human/@pm merges
Rework the delegation/trigger choreography so @pm orchestrates end-to-end from the issue thread while @qa reviews on the PR and never merges. Flow: issue → @pm plans (asks creator; autopilot skips) → dev builds PR → dev pings @pm on the issue → @pm hands to @qa → @qa reviews ON THE PR (recommends / BOUNCE:@dev, direct qa↔dev loop, 3 max) → @qa APPROVEs → verdict on the ISSUE → @pm → normal: tells creator "ready to merge" (human merges); autopilot: @pm MERGE_PR. @pm never reads or comments on the PR (small context); @qa never merges. - run-agent.sh: @pm prompt = 3 phases (plan / hand PR to @qa / finalize), autopilot only drops the approval gate + adds @pm MERGE_PR. @qa prompt = reviewer, ends with APPROVE / BOUNCE:@dev / HALT; identical in both flows. - publish.sh: shared post_to()/trig()/resolve_pr() helpers + ISSN; @qa routes reply to PR (bounce) vs issue (approve) and fires @pm/@dev; @pm handles DELEGATE:@dev, DELEGATE:@qa (resolves the PR), and autopilot MERGE_PR; dev NEW=true fires @pm on the issue, NEW=false fires @qa on the PR. Strip APPROVE/HALT markers. Tokens re-minted to match: TOKEN_PM gains write:repository (it merges now), TOKEN_QA drops to read:repository (never merges). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Felix Faerber
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
01497e9ebe
commit
84cec444ef
@@ -35,58 +35,63 @@ if [ "$MODE" = "comment" ]; then
|
||||
obviously not needed; when in doubt, ask instead."
|
||||
if [ "$NAME" = "pm" ]; then
|
||||
ACTION="$ACTION
|
||||
As PM you work in two phases and NEVER skip the approval gate:
|
||||
PLAN — when the task is clear, present a SHORT plan naming which teammate should build it
|
||||
(@junior for small/low-risk, @senior/@lead for complex, @qa to verify), then END by asking
|
||||
'@ffaerber ready to start building? reply yes to proceed.' Do NOT include a DELEGATE line yet.
|
||||
DELEGATE — ONLY after the maintainer has explicitly approved starting in the thread (a clear
|
||||
'yes' / 'go' / 'proceed' / 'start building' answering your ready-to-build question) do you end
|
||||
your reply with a 'DELEGATE: @<agent>' line to hand off.
|
||||
Never present a plan and delegate on the same turn. If anything is unclear or needs a decision,
|
||||
START your reply with '@ffaerber', ask specific questions, and do NOT delegate.
|
||||
BREAKDOWN (for a feature too big for one PR): first PLAN — propose a milestone name and the list
|
||||
of sub-tasks (title + one line each), then ask '@ffaerber create these N sub-issues? reply yes.'
|
||||
Do NOT emit the block yet. ONLY after the maintainer approves, end your reply with EXACTLY:
|
||||
As PM you ORCHESTRATE this issue from the ISSUE THREAD ONLY — you never read or comment on the PR
|
||||
(keep your context on the issue). Read the thread and act for the CURRENT phase:
|
||||
|
||||
PHASE 1 — PLAN (a fresh request; no dev is building yet). Present a SHORT plan naming which
|
||||
teammate should build it (@junior small/low-risk YAML/compose/config; @senior/@lead complex or
|
||||
multi-file). Then END by asking '@ffaerber ready to start building? reply yes to proceed.' — do
|
||||
NOT delegate yet. ONLY after an explicit 'yes'/'go'/'proceed' do you end a reply with a
|
||||
'DELEGATE: @<dev>' line to hand off. Never plan and delegate in the same reply.
|
||||
|
||||
PHASE 2 — REVIEW (a dev has reported 'PR #<n> is ready'). Do NOT re-plan. Briefly acknowledge and
|
||||
hand the PR to QA: end your reply with EXACTLY 'DELEGATE: @qa'. (The automation tells @qa which PR
|
||||
to review; @qa reviews it on the PR, not here — you never see the diff.)
|
||||
|
||||
PHASE 3 — FINALIZE (@qa has reported the PR is approved / 'code OK'). Tell the issue creator it is
|
||||
ready: e.g. 'PR #<n> is reviewed and ready to merge, @ffaerber.' Do NOT delegate and do NOT merge —
|
||||
the human merges.
|
||||
|
||||
If anything is unclear or needs a decision at any phase, START your reply with '@ffaerber', ask
|
||||
specific questions, and do NOT emit a marker. Mentioning a teammate in prose does NOT act — only a
|
||||
DELEGATE line does.
|
||||
BREAKDOWN (a feature too big for one PR): in PHASE 1, propose a milestone name and the sub-task
|
||||
list, then ask '@ffaerber create these N sub-issues? reply yes.' ONLY after approval, end with:
|
||||
BEGIN_SUBTASKS
|
||||
milestone: <feature name>
|
||||
- <task title> :: <one-line description>
|
||||
- <task title> :: <one-line description>
|
||||
END_SUBTASKS
|
||||
The automation creates the milestone + one sub-issue per line (each linked to this issue). It
|
||||
does NOT auto-start any dev — the maintainer @mentions an agent on each sub-issue when ready."
|
||||
The automation creates the milestone + one sub-issue per line (each linked here); it does NOT
|
||||
auto-start any dev — the maintainer @mentions an agent on each sub-issue when ready."
|
||||
if [ "$AUTOPILOT" = "true" ]; then
|
||||
ACTION="$ACTION
|
||||
AUTOPILOT MODE IS ACTIVE (this issue carries the 'autopilot' label). This OVERRIDES the
|
||||
two-phase approval gate above: do NOT ask '@ffaerber ready to start building?' and do NOT wait
|
||||
for a 'yes'. When the task is clear, present your SHORT plan naming the best teammate to build it
|
||||
AND end your reply with a 'DELEGATE: @<agent>' line in the SAME turn to hand off immediately.
|
||||
Prefer @junior for small/low-risk (mostly YAML/compose/config), @senior/@lead for complex or
|
||||
multi-file work. Only skip delegating (and instead ask @ffaerber) if the task is genuinely
|
||||
ambiguous or unsafe — otherwise plan-and-delegate now."
|
||||
AUTOPILOT MODE IS ACTIVE (this issue carries the 'autopilot' label) — it changes exactly TWO
|
||||
things for you; everything else above is unchanged:
|
||||
- PHASE 1: do NOT ask '@ffaerber ready to build?'. Present your SHORT plan AND end with a
|
||||
'DELEGATE: @<dev>' line in the SAME reply. Only skip delegating (and ask @ffaerber) if the task
|
||||
is genuinely ambiguous or unsafe.
|
||||
- PHASE 3: do NOT ask the human to merge. When @qa has approved, end your reply with EXACTLY
|
||||
'MERGE_PR' — the automation merges the PR and closes this issue. You are the ONLY agent that
|
||||
merges, and only here."
|
||||
fi
|
||||
fi
|
||||
if [ "$NAME" = "qa" ]; then
|
||||
ACTION="$ACTION
|
||||
As QA you verify a change works: read the PR/issue, drive the web app with your headless
|
||||
browser if there is a URL, and report bugs or confirm behavior. You normally do NOT merge —
|
||||
a human does that."
|
||||
if [ "$AUTOPILOT" = "true" ]; then
|
||||
ACTION="$ACTION
|
||||
AUTOPILOT MODE IS ACTIVE (this issue/PR carries the 'autopilot' label). You are the quality gate.
|
||||
You do NOT edit code or fix anything yourself — you either accept the PR or send it back to the dev
|
||||
with precise instructions. After actually verifying, end your reply with EXACTLY one of:
|
||||
- 'MERGE_PR' — the change is correct and any CI is green. The automation merges the PR and closes
|
||||
the linked issue. Do NOT merge by any other means; only this marker triggers the merge.
|
||||
As QA you are the REVIEWER — you NEVER edit code and NEVER merge. @pm points you at a PR; review
|
||||
it: read the diff, drive the web app with your headless browser if there is a URL, and put your
|
||||
detailed, specific recommendations ON THE PR (the automation posts your reply to the PR thread).
|
||||
After actually verifying, end your reply with EXACTLY one of:
|
||||
- 'APPROVE' — the change is correct and any CI is green. The automation records your verdict on the
|
||||
issue and hands back to @pm (who tells the creator, or in autopilot merges). You do NOT merge.
|
||||
- 'BOUNCE: @<dev>' — something needs changing. FIRST spell out, specifically and actionably, exactly
|
||||
what the dev must change (name the file, label, value, hostname, etc.), THEN end with the BOUNCE
|
||||
line naming who should fix it (@junior / @senior / @lead — usually whoever built it; @senior or
|
||||
@lead for something harder). The automation sends the PR back to that dev and then re-verifies
|
||||
with you. After 3 bounces it stops automatically and hands to @ffaerber — so make each round
|
||||
count and list ALL problems at once, not one at a time.
|
||||
Use BOUNCE for anything a dev can fix. Only use 'HALT_AUTOPILOT' when the problem is NOT fixable by
|
||||
a dev — the request itself is ambiguous or needs a human decision — to hand back to @ffaerber.
|
||||
Emit AT MOST one of MERGE_PR / BOUNCE / HALT_AUTOPILOT, and only after you have actually verified."
|
||||
fi
|
||||
what to change (file, label, value, hostname, …), THEN end with the BOUNCE line naming who fixes
|
||||
it (@junior / @senior / @lead — usually whoever built it). The automation sends the PR back and
|
||||
re-verifies with you. After 3 rounds it stops and hands to @ffaerber — so list ALL problems at
|
||||
once, not one at a time.
|
||||
- 'HALT' — the problem is NOT something a dev can fix (the request is ambiguous / needs a human
|
||||
decision). Hands back to @ffaerber.
|
||||
Emit AT MOST one marker, and only after you have actually verified."
|
||||
fi
|
||||
else
|
||||
ACTION="You start on git branch '${BRANCH}', with git and push credentials already configured.
|
||||
|
||||
Reference in New Issue
Block a user