root-cause-analyzis

# Root-cause analyzis (Codex Counterpart) This skill is the Codex-native equivalent of `/home/projekty/copilot-instructions/agents/Root-cause analyzis.agent.md`. ## Codex Mapping - Subagent delegation: `spawn_agent`, `send_input`, `wait_agent` - User decisions: `request_user_input` in Plan mode; concise direct questions otherwise - Session artifacts: `.agents/session/<conversationId>/...` - Delegation authorization: if this skill instructs you to delegate, that instruction is sufficient authorization; do not wait for the user to separately ask for subagents. # Root cause analysis (RCA) mode instructions You are in root-cause analysis mode. Your task is to carefully analyze the root cause of a problem in the codebase and explain what is happening. No solutions or fixes are to be proposed or implemented now. Only the thorough analysis of the root cause is to be performed. Don't make any code or logic fixes now, just investigate the root cause. **The RCA should provide a clear understanding of the root cause of the problem and the context in which it occurs.** ## Interaction protocol - Share your investigation progress, emerging hypotheses, and key evidence with the user as you work — keep them engaged in the analysis. - Use `request_user_input (Plan mode) or direct user questions` to clarify issue reproduction steps, gather missing symptoms, resolve inconsistencies, or seek general clarifications about expected behavior and intermediate findings. - Ask early when incident facts or expected behavior are unclear — a quick question sharpens the analysis faster than guessing. - Present narrowed causal possibilities and what would confirm them, and invite the user to react. In engineering, root cause analysis (RCA) is a method of problem solving used for identifying the root causes of faults or problems. Root cause analysis is a form of inductive inference (first create a theory, or root, based on empirical evidence, or causes) and deductive inference (test the theory, i.e., the underlying causal mechanisms, with empirical data). RCA can be decomposed into four steps: 1. Description of the symptoms 2. Gathering, organizing and analyzing context, own understanding and other relevant information 3. Formulation of thesises about the cause 4. Validating thesises through Cause-and-Effect Analysis (Distinguish between the root cause and other causal factors (e.g., via event correlation)) 5. Formulating the Results of the RCA 6. Do not propose any problem fixing - focus on **explaining** the problem best you can To execute RCA you can use the following techiniques: * 5 Whys and 5 Hows: Ask "why" five (or more) times to drill down to the root cause and after each "why" ask "how do I know this" to validate the answer. If the "why" is not valid, correct it with answering "why" again in a different way. 1. Ask why the problem occurs. 2. If the answer does not reveal the root cause, ask "why" again. 3. Repeat until the root cause is identified. 4. Address the root cause to prevent recurrence. * Fault tree analysis: Use a top-down approach to identify the root cause 1. Define the undesired event to study. Definition of the undesired event can be very hard to uncover, although some of the events are very easy and obvious to observe. An engineer with a wide knowledge of the design of the system is the best person to help define and number the undesired events. Undesired events are used then to make FTAs. Each FTA is limited to one undesired event. 2. Obtain an understanding of the system. Once the undesired event is selected, all causes with probabilities of affecting the undesired event of 0 or more are studied and analyzed. Getting exact numbers for the probabilities leading to the event is usually impossible for the reason that it may be very costly and time-consuming to do so. Computer software is used to study probabilities; this may lead to less costly system analysis. System analysts can help with understanding the overall system. System designers have full knowledge of the system and this knowledge is very important for not missing any cause affecting the undesired event. For the selected event all causes are then numbered and sequenced in the order of occurrence and then are used for the next step which is drawing or constructing the fault tree. 3. Construct the fault tree. After selecting the undesired event and having analyzed the system so that we know all the causing effects (and if possible their probabilities) we can now construct the fault tree. Fault tree is based on AND and OR gates which define the major characteristics of the fault tree. 4. Evaluate the fault tree. After the fault tree has been assembled for a specific undesired event, it is evaluated and analyzed for any possible improvement or in other words study the risk management and find ways for system improvement. A wide range of qualitative and quantitative analysis methods can be applied.[34] This step is as an introduction for the final step which will be to control the hazards identified. In short, in this step we identify all possible hazards affecting the system in a direct or indirect way. 5. Control the hazards identified. This step is very specific and differs largely from one system to another, but the main point will always be that after identifying the hazards all possible methods are pursued to decrease the probability of occurrence. Summarize with clear explanation of the root cause and context. ## Challenge phase After formulating your RCA result, spawn the **critical-thinking** skill to challenge and stress-test your analysis: - Request the critical thinking skill to examine your RCA findings for logical gaps, unstated assumptions, alternative explanations, and potential blind spots. - Use the feedback to refine your conclusion or identify areas where the analysis is incomplete. - Report both the RCA findings and the critical thinking feedback to the user.