一键导入
systematic-multi-service-check
After finding one root cause service, systematically check all related services for additional faults before concluding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
After finding one root cause service, systematically check all related services for additional faults before concluding.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Structured procedure to locate the root cause of a confirmed bug. Uses keyword search → focused reading → call-graph tracing. Outputs a specific file + line + hypothesis.
Step-by-step procedure to reproduce a bug. Use this FIRST before trying to fix anything. Produces a minimal script that demonstrates the failure.
AgentM SDK development guide — manifest-as-agent-unit philosophy, SDK programmatic invocation, dynamic workflow orchestration, atom contract, Operations abstraction, event system, service communication, CLI conventions, scenario authoring, logging, structured output, and config resolution. Use whenever writing, editing, or reviewing code under src/agentm/ (atoms, core, gateway), contrib/scenarios/ (manifests), or contrib/extensions/ (workspace-member atoms). Also trigger when creating new atoms, modifying MANIFEST declarations, registering tools or events, touching FileOperations / BashOperations / ResourceWriter, writing CLI subcommands, configuring model profiles, spawning child sessions, building multi-agent orchestrators, writing workflow scripts, or when a code change looks like it might bypass the SDK's existing abstractions. If you catch yourself about to write raw os.stat / open() / subprocess.run in an atom, importing openai/anthropic directly instead of going through the provider layer, or shelling
Guide for adding new benchmarks to the agentm-eval framework and running experiments through the unified `agentm eval` CLI. Covers the adapter interface, experiment lifecycle, result schema, ClickHouse linking, and output conventions. Use whenever creating a new eval adapter, modifying an existing benchmark integration, writing code under contrib/evals/src/agentm_eval/, discussing experiment management, or when the user mentions "add a benchmark", "new eval", "接入评估", "新benchmark", "实验管理", "eval adapter". Also trigger when reviewing eval-related code or debugging experiment output structure.
How to write workflow scripts that orchestrate multiple agents in AgentM. Covers agent(), parallel(), pipeline(), phase(), return values, atom_config data passing, and the journal-based resume / invalidation / partial re-run mechanism (workflow_lineage, workflow_invalidate). Trigger when writing a workflow script, choosing an orchestration pattern, recovering from a wrong node result, or when the user says 编排 / workflow / 多 agent / 并行 / 扇出 / 调度 / 写个 workflow / 失效 / 部分重跑 / 重算. Also trigger when you catch yourself building prompts inside a workflow script — pass data via atom_config instead and let the agent build its own prompt.
Analyze agentm session traces using `agentm trace` atomic commands. Use when inspecting trajectories, token economics, tool calls, or aggregating stats across a trace tree (parent + child sessions). Compose atomic commands via shell pipes — never parse OTLP JSONL directly.
| name | systematic-multi-service-check |
| description | After finding one root cause service, systematically check all related services for additional faults before concluding. |
| tags | ["rca","insufficient_evidence","premature_conclusion","multi_service","fault_isolation"] |
| trigger_patterns | ["When investigating a microservice incident","After identifying one failing service","When multiple services are involved in a failure","When symptoms suggest cascading or co-occurring faults"] |
| type | skill |
| confidence | evolved |
| version | 1 |
| evidence | {"train_cases":6,"pattern_frequency":6} |
When investigating a microservice incident, never stop after finding the first failing service. Incidents frequently involve multiple services failing simultaneously from different fault types (e.g., JVMRuntimeMutator on one service, NetworkLoss/NetworkPartition on another).
Start with zero assumptions. Always query metrics, logs, and service topology before concluding anything. Never skip investigative tool calls.
When you find a failing service, ask: "What other services could also be failing?" Specifically:
For each candidate service, check for DIFFERENT fault types. The pattern across all cases is: Service A has a compute/memory fault (JVMRuntimeMutator, CPUStress, MemoryStress) while Service B has a network fault (NetworkLoss, NetworkPartition, NetworkCorrupt). These are independent — finding one does not rule out the other.
Produce a complete fault matrix. Before concluding, compile a list of all services with anomalies, noting the specific fault type for each. Only submit your conclusion when you have checked every service in the affected call chain.
If you have zero tool calls in your trajectory, you have failed. Every RCA must include at least 2-3 investigative queries to different data sources before a conclusion is valid.