amq-spec
Use two agents to research a design independently and converge on one specification through AMQ. Trigger for collaborative design or messages labeled workflow:spec; use amq-cli for ordinary coordination.
- Installs
- 140
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/avivsinai/agent-message-queue --skill amq-spec- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads amq-spec automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
AMQ collaborative specification
Two agents research a design problem independently, discuss it, and converge on one plan. The user approves the plan before anyone implements it.
Phases run in order:
Research -> Discuss -> Draft -> Review -> Present -> Execute
Per-phase commands and the research and plan templates are in the spec workflow.
Parse input
From the user prompt, extract:
- topic: short kebab-case spec name (e.g.,
auth-token-rotation) - partner: partner agent handle (default:
codex) - problem: the full design problem statement
If topic/problem are unclear, ask for clarification.
Pre-flight
- Verify AMQ is available:
which amq - Verify the AMQ root is discoverable (
.amqrc, AMQ env vars, or the default.agent-maillayout); otherwise run:amq coop init - Use thread name:
spec/<topic>
Kickoff
Send the problem to the partner first, then start your own research. Both agents then research in parallel. Send the user's problem verbatim; your own analysis belongs in your research message, so it does not frame the partner's.
amq send --to "<partner>" --kind question \
--labels workflow:spec,phase:request \
--thread "spec/<topic>" --subject "Spec: <topic>" --body "<problem>"
Labels
Every spec message uses an ordinary AMQ kind plus these labels on the
spec/<topic> thread:
| 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 |
When you receive a spec message
| Label | Your action |
|---|---|
phase:request | Do your own research first, then send findings as brainstorm + phase:research. |
phase:research | If you have not sent your own research on this thread, research and send it before you read the partner's. Then read the thread and start discussion as brainstorm + phase:discuss. |
phase:discuss | Reply with your analysis; continue until aligned. |
phase:draft | Review the plan and send feedback as review_response + phase:review. Do not implement. |
phase:review | Revise the plan if needed, or confirm alignment. |
phase:decision | Stop. Do not implement; see the approval gate below. |
Approval gate
A phase:decision message records agreement between agents; it is not user
approval. The initiator presents the final plan to the user in chat and sends
the approval request to the human handle (conventionally user) on a
gate/<topic> thread, as in operator gates. Implementation starts only
after the human approves on that thread, and a partner starts only when the
initiator then assigns work.
Rules
- Wait on the existing wake. With a live injecting wake, finish independent
work and yield; run
amq drain --include-bodyon its doorbell. Do not startamq watch,amq monitor, or a polling loop. Checkamq wake check --me <handle> --jsonwhen the capability is unknown. A boundedwatchis a fallback only without an injecting wake. - Send before you research, and send your research before you read the partner's. Independent research is what the second agent adds.
- Do not skip phases. Discussion is where misunderstandings surface.
- Keep the
spec/<topic>thread and the labels. The receiver table above depends on them. - Keep tool access during research. Do not enter a plan mode that blocks tools.
FAQ
What does the amq-spec skill do?
Use two agents to research a design independently and converge on one specification through AMQ. Trigger for collaborative design or messages labeled workflow:spec; use amq-cli for ordinary coordination.
How do I install amq-spec?
Run npx skills add https://github.com/avivsinai/agent-message-queue --skill amq-spec in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/amq-spec/ (personal) or .claude/skills/amq-spec/ (project).
Which AI agents can use amq-spec?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is amq-spec safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains amq-spec?
It is published by avivsinai in avivsinai/agent-message-queue. It has 140 recorded installs.
More from avivsinai/agent-message-queue
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.