CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

investigate

Use when the user asks to diagnose a bug, find the root cause of a failing behavior, or run a hypothesis-by-hypothesis investigation with experiments and evidence. Produces a diagnostic report with a recommended fix, but does not apply the fix.

70

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Investigate Issue

Overview

Diagnose the root cause of an issue autonomously. Propose candidate hypotheses, pick the most promising one, run discrete-outcome experiments, update probabilities with evidence, iterate. No user checkpoints. Final report recommends a fix; it does not apply one.

Context

Used for debugging and root cause analysis. The agent navigates the hypothesis space without HITL (human-in-the-loop) pauses. The user audits the trail through the printed Hypothesis Board and the final report.

Rules & Constraints

1. **No Production Changes**: Diagnostic edits (logging, probes, patches) must be reverted before the next step. The recommended fix is reported, NOT applied. 2. **Clean Baseline**: The tree you experiment in must be clean between experiments (verify via version-control status). When the current working tree holds changes you did not make — the user's work in progress — or when the request names a commit to diagnose (a CI failure for a pushed SHA), do NOT stash, reset, restore or commit those changes and do NOT refuse: create a temporary worktree of that commit (`git worktree add `; `HEAD` when no commit is named), run every experiment there, and remove it with `git worktree remove ` before the Final Report. The worktree carries tracked files only: when an experiment needs a gitignored file (`.env`, installed dependencies), install the dependencies there or name the missing file as the experiment's blocker; never copy secrets in. 3. **Autonomous Flow**: Do NOT pause for user selection of hypotheses or approval of experiments. Pick the highest-probability untested hypothesis and proceed. 4. **Transparency**: Print the "Hypothesis Board" (probabilities + evidence) before each experiment and in the final report so the reasoning trail is auditable. 5. **Termination**: Stop when one hypothesis reaches ≥80% probability, when three consecutive experiments fail to shift probabilities, or after 5 iterations — whichever comes first. 6. **Task tracking**: Use a task management tool (e.g., todo write, todowrite) to record iteration state and steps.

Instructions

<step_by_step>

  1. Initialize
    • Create a task list covering the steps below.
    • Gather initial data: error messages, logs, relevant source files, reproduction steps.
    • Choose the experiment tree (rule 2): the current working tree when it is clean and no other commit is named; otherwise a temporary worktree of the named commit (or HEAD). State the choice and the path.
  2. Hypotheses Generation
    • Propose 3-7 candidate root causes with initial probabilities (sum ≈ 100%) and one-line reasoning each.
    • Print the initial "Hypothesis Board".
  3. Experiment Loop (autonomous; no user checkpoints)
    • Pick the highest-probability untested hypothesis.
    • Design a discrete-outcome experiment; state what "Success" and "Failure" imply for the hypothesis.
    • Execute it (read code, run commands, inspect outputs). Keep any diagnostic edits isolated and revert them afterwards.
    • Record the outcome, adjust probabilities, append evidence to the Board.
    • Verify baseline is restored and print the updated Board.
    • Evaluate the termination condition (rule 5). If not met, repeat.
  4. Final Report
    • Print the final Hypothesis Board with the winning hypothesis highlighted.
    • Summarize each experiment: what was tested, what was observed, what it proved.
    • Recommend a concrete fix (file, line, proposed change) — do NOT apply it. </step_by_step>

Verification

[ ] 3-7 hypotheses generated with initial probabilities. [ ] Hypothesis Board printed before and after each experiment. [ ] Agent proceeded autonomously — no user approval checkpoints. [ ] Diagnostic changes reverted; baseline clean between experiments. [ ] A dirty working tree was neither cleaned nor treated as a blocker: experiments ran in a temporary worktree, removed before the report. [ ] Final report names a single root cause with evidence and recommends a fix without applying it.
Repository

korchasa/flowai-plugins

Path

plugins/flowai/skills/investigate/SKILL.md

Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.