メニュー
Multi-agent collaboration patterns — how to build on others' work, ask questions, share knowledge, and work as a team.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | squad-collaboration |
| description | Multi-agent collaboration patterns — how to build on others' work, ask questions, share knowledge, and work as a team. |
Read what your dependencies produced. Reference their output explicitly. "Based on the schema from the db-schema task, the users table has id, email, password_hash, created_at. I'll add the JWT validation column and refresh_token table..."
When you @mention someone, ask something specific that needs an answer. Don't send FYI messages that waste their context window.
Good: "@backend what's the token expiry? I need it for the refresh logic" Good: "@frontend are you using React Router or Next.js routing? Affects how I set up the auth middleware" Bad: "@backend FYI I'm working on the frontend" (no question, wastes their time)
Don't just post conclusions. Explain why you made a choice, so others can course-correct early. "I chose RS256 over HS256 because the frontend needs to verify tokens without the signing secret"
If you're not sure about something, say so and ask. "I'm not sure if this migration is backwards-compatible — @backend can you verify?"
When required information is missing from your task or dependency outputs, flag the gap and ask — don't invent values, endpoints, or formats to fill it. A wrong guess propagates to every dependent task; a question costs one message.
Better to ask than to silently introduce a breaking change.
If another agent @mentions you, always respond — even briefly. The requesting agent may be blocked waiting for your answer. "Got it, the payload is {sub, email, role}. Using 1h expiry."
If you learn something about the project that other agents should know, state it clearly. "The project uses Drizzle ORM with PostgreSQL, not Prisma as I initially assumed." The squad system captures these as shared knowledge.
Author valid pi-squad plans — inline task arrays and strict v1 file specifications. Use when creating a squad plan, writing a squad spec JSON, choosing between inline tasks and specFile, computing specSha256, or debugging squad validation errors (must be array, SPEC_MALFORMED, SPEC_HASH_MISMATCH, Plan rejected).
Manage multi-agent squads — monitor progress, respond to escalations, relay human instructions, and summarize results. Use when a squad is running or when the user asks about squad status, agents, or task progress.
Code review methodology — two-pass review (correctness/scope, then over-engineering), surgical-change discipline, complexity findings with delete/stdlib/native/yagni/shrink tags, machine-parsed verdicts. Use when reviewing diffs, implementations, or pull requests.
Debugging and rework discipline — reproduce-first workflow, hypothesis testing, minimal fixes, regression tests. Use when fixing bugs, handling QA feedback, working on rework/fix tasks, or investigating failures.
Core communication protocol for multi-agent squad collaboration. Defines how agents talk to each other, signal status, and coordinate work.
QA and testing practices — test strategy, checklist, evidence requirements, verdict format, and rework flow. Use when verifying, testing, or reviewing implementations.
