multi-agent-testing

Multi-Agent Collaboration Testing (Chinese Version)

When to Use

Need to carry out evidence-based analysis, design, or verification preparation around delegation, coordination, shared state, conflicts, ownership, termination, and traceability.
Need to review Agent, RAG, or LLM solutions, results, or evidence, and form actionable improvement items.
The input is incomplete, but a bounded initial version with assumptions, information gaps, and human decision boundaries still needs to be delivered.

The default output is Markdown, organized by domain risk, evidence status, priority, and boundaries.
When the user requests table, CSV, JSON, or ticket format, retain the same finding fields, evidence, and decision boundaries.
Before the output enters an automated process, first confirm the schema, enumeration values, required fields, and evidence sources.

First read and follow prompts/multi-agent-testing.md, including input audit, domain coverage, and output order.
Extract scope, environment, version, time window, constraints, success criteria, and available evidence, focusing on task delegation, coordination protocols, shared state, conflict handling, termination, and tracing.
First distinguish confirmed facts, evidence-supported inferences, candidate recommendations, and Human decisions, then sort by risk and evidence strength.
Convert high-risk items into preconditions, steps, expected results or judgment criteria, required evidence, and verification methods.
When information is insufficient, deliver a bounded initial version, clarify which conclusions cannot hold, and do not present static materials as execution results.

When calibrating domain results, correct controls, or evidence gaps, read references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recalculation basis.
Each execution must read prompts/multi-agent-testing.md; it is the complete execution specification of this Skill.
When evaluation is needed, read evals/eval.yaml and the matching cases under evals/cases/ .
Only when the directory actually exists and the task requires it, read references/、examples/、scripts/ or output-formats.md, and do not assume assets that do not exist.

Establish handoff traces using task/message/correlation ID, sender/receiver, parent delegation, scope, owner, shared state version, and ACK; specify accept/reject/terminate conditions according to the actual protocol.
Claim/commit must be based on the project's atomic ownership or fencing protocol; stale messages and duplicate messages must not reacquire ownership or write repeatedly; do not assume exactly-once exists if no protocol is given.
For partial failures, separately record completed, incomplete, and uncertain side effects, and verify committed state before reassignment; a task must not be silently lost because one subtask failed or timed out.
Termination propagation verifies stop ACK, terminal state, and remaining responsibilities; a lease holder that has lost validity must not continue to commit; compare against normal single-claim and effective handoff, and avoid treating message redelivery itself as a fault.

Only analyze delegation, coordination, shared state, conflicts, ownership, termination, and traceability; do not replace the business owner or Human risk acceptance, exception approval, and security decisions.
Do not fabricate system behavior, fields, model outputs, data, thresholds, root causes, execution records, or passing conclusions.
Static design, plans, file existence, or dry-run can only retain the original evidence status and cannot be upgraded to proof of actual execution.
When evidence is insufficient, use pending confirmation, blocked, unassessed, or NOT_SCORED, and provide a minimal verification method.
When user data, production, or security is involved, use least privilege, desensitized data, mocks, dry-run, or an isolated environment.

Task delegation, coordination protocols, shared state, conflict handling, termination, and tracing are covered, and the source, evidence status, and verification method are recorded for each item.
Facts, inferences, candidate recommendations, information gaps, and Human decisions are separated.
High-risk items have P0/P1/P2/P3 or equivalent priority, responsible roles, and closure conditions.
Plans, static checks, or dry-runs are not written as test execution, all passed, or security approval.
Residual risks, stop/escalation conditions, and next steps are stated.

Listing only checkpoints without explaining trigger conditions, expected focus points, responsible roles, closure conditions, and evidence.
Treating test or model tool names from adjacent domains as a complete judgment of multi-Agent collaboration.
Using unexplained numbers to create false precision, or writing correlation as causation.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause user harm, business loss, or decision blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record conditions, versions, sources, and evidence.
Enable another engineer to independently install, execute, and review the output of this Skill.