# Dstack Investigate

> Anomaly root cause analysis. Use when a metric looks wrong or surprising. Runs a structured 4-phase investigation over a single Upsolve thread: confirm → narrow → hypothesize → validate. Findings use numbered codes (1A CONFIRMED, 1B CANDIDATE, 2A RULED_OUT). Trigger phrases: "revenue dropped", "metric is spiking", "why did X change?", "something looks wrong", "root cause", "debug this metric".

- Skill: `upsolve-labs/dstack-investigate` (Agent Skill)
- Install (CLI): `npx skillmds@latest add upsolve-labs/dstack-investigate`
- Raw SKILL.md: https://api.skillmd.com/api/skills/upsolve-labs/dstack-investigate/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Finance & Business
- License: MIT
- Author: Upsolve-Labs (https://skillmd.com/u/upsolve-labs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/upsolve-labs/dstack-investigate

---


## Update Check (run first)

```bash
_UPD=$(~/.claude/skills/data-stack/bin/data-stack-update-check 2>/dev/null || .claude/skills/data-stack/bin/data-stack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
```

If output shows `UPGRADE_AVAILABLE <old> <new>`: read `~/.claude/skills/data-stack/skills/dstack-upgrade/SKILL.md` and follow the "Inline upgrade flow". If `JUST_UPGRADED <from> <to>`: tell user "Running data-stack v{to} (just updated!)" and continue.

# /investigate

You are helping the user find the root cause of a data anomaly.

## Before Starting

AskUserQuestion: "What anomaly are you investigating? Describe the symptom (e.g. 'revenue dropped 20% on Tuesday', 'DAU spiked 3x this morning', 'conversion rate is at 0')."

## Phase 1: Confirm the Anomaly

Open an Upsolve thread. Run:

```
analyze_data("Show me <metric> for the last 30 days broken down by day. Highlight any days that are more than 2 standard deviations from the mean.")
```

**Gate:** If the anomaly is confirmed in data, proceed. If the data looks normal, tell the user what you found and ask if they want to check a different time range or metric.

## Phase 2: Narrow by Dimension

Run 2–3 follow-up queries in the same thread to slice the anomaly:

```
analyze_data("Break down <metric> for <anomaly period> by: [geography, product, channel, device, user type — use the most relevant dimensions]. Which segments show the sharpest change?", thread_id=<id>)
```

Identify the 2–3 segments that explain the most variance.

## Phase 3: Form & Test Hypotheses

Based on the narrowing, generate 3–5 candidate causes. For each, run a targeted query:

```
analyze_data("Test hypothesis: <hypothesis>. Show the relevant data to confirm or rule it out.", thread_id=<id>)
```

## Phase 4: Present Findings

Use numbered codes:
- **1A [CONFIRMED]** — Directly supported by data
- **1B [CANDIDATE]** — Partial evidence, plausible
- **2A [RULED OUT]** — Data contradicts this
- **3A [UNKNOWN]** — Can't confirm without additional data

Format:

```
INVESTIGATION: <metric> anomaly on <date>
Confirmed: <X>% change vs prior period

FINDINGS:
  1A [CONFIRMED] <finding> — <evidence>
  1B [CANDIDATE] <finding> — <evidence>
  2A [RULED OUT] <finding> — <why>

ROOT CAUSE (most likely):
  <1–2 sentence summary>

NEXT STEPS:
  - <action 1>
  - <action 2>
```

## Rules

- One thread for the entire investigation.
- Never skip Phase 1 confirmation — don't assume the anomaly exists.
- If root cause is clear after Phase 2, skip directly to findings.
- Maximum 8 Upsolve queries per investigation. Prioritize the most diagnostic ones.

