From amq-cli
Orchestrates parallel-research-then-converge workflow for two agents to independently explore design problems before aligning on specs via phased messaging.
npx claudepluginhub avivsinai/skills-marketplace --plugin amq-cliThis skill uses the workspace's default tool permissions.
This skill defines a structured two-agent specification flow.
Coordinates AI agents with AMQ CLI for file-based messaging: send to claude/codex/handles, check inbox, drain queues, setup co-op/swarm modes, route projects, diagnose issues.
Performs adversarial pre-coding planning: host and peer agents independently investigate codebase, diff specs, and validate plan with execution drill. Use for 'plan this', 'design approach', or scoping before coding.
Routes tasks to appropriate spec skills like spec-research or spec-plan based on type, orchestrates workflow phases from research to finish. Use when starting conversations or tasks.
Share bugs, ideas, or general feedback.
This skill defines a structured two-agent specification flow.
Use canonical phases in order:
Research -> Discuss -> Draft -> Review -> Present -> Execute
Detailed step-by-step protocol lives in references/spec-workflow.md.
This file is the concise operational entrypoint.
From the user prompt, extract:
auth-token-rotation)codex)If topic/problem are unclear, ask for clarification.
which amq.amqrc, AMQ env vars, or the default .agent-mail layout); otherwise run: amq coop initspec/<topic>The entire point of the spec workflow is parallel research — both agents exploring the problem independently, then comparing notes. Every second you spend researching before sending is a second your partner sits idle waiting for the problem statement. That's why the send comes first, even though your instinct might be to "research first to give better context."
amq send --to <partner> --kind question \
--labels workflow:spec,phase:request \
--thread spec/<topic> --subject "Spec: <topic>" --body "<problem>"
Send the user's problem description verbatim — your own analysis goes in the research phase, not the kickoff. If you pre-analyze, you bias the partner's independent research, which defeats the purpose of having two perspectives.
Labels are how both agents and the receiver-side protocol table know which phase the conversation is in. Use existing AMQ kinds plus labels to express spec workflow semantics:
| Phase | Kind | Labels |
|---|---|---|
| Problem statement | question | workflow:spec,phase:request |
| Research findings | brainstorm | workflow:spec,phase:research |
| Discussion | brainstorm | workflow:spec,phase:discuss |
| Plan draft | review_request | workflow:spec,phase:draft |
| Plan feedback | review_response | workflow:spec,phase:review |
| Final decision | decision | workflow:spec,phase:decision |
| Progress/ETA | status | workflow:spec |
# Initiate spec with problem statement
amq send --to <partner> --kind question \
--labels workflow:spec,phase:request \
--thread spec/<topic> --subject "Spec: <topic>" --body "<problem>"
# Submit independent research
amq send --to <partner> --kind brainstorm \
--labels workflow:spec,phase:research \
--thread spec/<topic> --subject "Research: <topic>" --body "<findings>"
# Discuss and align
amq send --to <partner> --kind brainstorm \
--labels workflow:spec,phase:discuss \
--thread spec/<topic> --subject "Discussion: <topic>" --body "<analysis>"
# Draft plan
amq send --to <partner> --kind review_request \
--labels workflow:spec,phase:draft \
--thread spec/<topic> --subject "Plan: <topic>" --body "<plan>"
# Review plan
amq send --to <partner> --kind review_response \
--labels workflow:spec,phase:review \
--thread spec/<topic> --subject "Review: <topic>" --body "<feedback>"
# Optional final decision message
amq send --to <partner> --kind decision \
--labels workflow:spec,phase:decision \
--thread spec/<topic> --subject "Final: <topic>" --body "<final plan>"
If you receive a message labeled workflow:spec, your action depends on the phase:
| Label | Your action |
|---|---|
phase:request | Read the problem statement, do your own independent research first, then submit findings as brainstorm + phase:research |
phase:research | Before reading: check if you've already submitted your own research on this thread. If not, do your own research and submit it first. This preserves research independence — reading the partner's findings before forming your own view contaminates your perspective. Once your research is submitted, read the thread and start discussion as brainstorm + phase:discuss. |
phase:discuss | Reply with your analysis, continue discussion until aligned |
phase:draft | Review the plan and send feedback as review_response + phase:review. Your job here is review, not implementation — the plan needs to survive scrutiny before anyone builds it. |
phase:review | Revise plan if needed, or confirm alignment |
phase:decision | Stop. Only the user can authorize implementation. The initiator presents the plan to the user; you wait until the initiator confirms approval and assigns you work. |
Why the partner doesn't implement: The spec workflow is a design process. The initiator owns the relationship with the user and presents the final plan. If the partner implements without approval, the user loses control over what gets built. Implementation starts only after the initiator explicitly tells you the user approved and assigns work.
These rules exist because violations silently break the workflow's value proposition:
spec/<topic> threads and the label convention — this is how both agents (and the tooling) know which phase the conversation is in. Without consistent labels, the receiver-side protocol table above breaks.For full protocol details, templates, and phase gates, see: