Skip to main content

investigation-notes

Structured scratch tracking document for investigation state during bug hunts - prevents re-reading code, losing context, and rabbit holes; maintains external memory so you don't re-derive conclusions Use when this capability is needed.

Ir a la instalación

Datos de origen

Repositorio
tomevault-io/tomes
Última actividad en el origen
23 de julio de 2026 a las 21:48
Idioma detectado de SKILL.md
inglés
Estrellas
1
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
investigation-notes
description
Structured scratch tracking document for investigation state during bug hunts - prevents re-reading code, losing context, and rabbit holes; maintains external memory so you don't re-derive conclusions Use when this capability is needed.
metadata
{"author":"cloudflare"}
# Investigation Notes ## Overview During bug investigations, maintain a lightweight scratch document as external memory. This prevents re-reading code you've already analyzed, losing track of which hypothesis you're testing, and silently drifting into rabbit holes. **Core principle:** Write it down once, refer to it later. Re-reading your one-line note is faster than re-reading 200 lines of source. **Always** keep the document up to date with your current focus, hypotheses, and learnings from code reads and tests. **Always** refer to the document before re-reading code or forming a new hypothesis. If the information is there, use it. If it's not sufficient, read the code, then write a better note. **The document never takes priority over writing or running a test.** If you're choosing between updating notes and writing a test, write the test. Update the notes after. ## The Document Create `~/tmp/investigate-<short-name>.md` during orientation (step 2 of `/investigate`). The short name should be descriptive enough to identify the investigation (e.g., `investigate-concurrent-write.md`, `investigate-pipe-zombie-state.md`). Once created, notify the user and provide the file path so they can open it in their editor. ### Format ```markdown # Investigation: <one-line bug description> ## Error <assertion/crash message, file:line — written once, never changes> ## Current Focus <single sentence: what you are doing RIGHT NOW> ## Hypotheses 1. [TESTING] <one sentence> — test: <test name or "not yet written"> 2. [REJECTED] <one sentence> — disproved by: <one sentence> 3. [CONFIRMED] <one sentence> — evidence: <test name + result> ## Code Read - `file:line-range` — <what you learned, short paragraph or bullet> ## Tests - `file:line` "test name" — <result + what it means, one sentence> ## Ruled Out - <thing you investigated and eliminated, one sentence why> ## Next 1. <concrete next action> 2. <fallback> ``` ## Creation **Create the document when:** - You have more than one hypothesis to track - You've read more than 3 files/functions - You're about to re-read code you already read - The investigation is going to span multiple iterations of test-write-run When created, populate Error, Current Focus, your current hypotheses, and anything you've already learned (backfill "Code Read" and "Tests" from what you've done so far). ## Rules - **Always** update "Current Focus" before starting any new thread of work - **Always** Add a hypothesis for what you're doing - **Always** update the document after each significant action: - After reading a function or file section → add to "Code Read" - After forming or rejecting a hypothesis → update "Hypotheses" - **After running a test → update BEFORE doing anything else.** Record: what test ran, what the result was, what it means for the active hypothesis. This is non-negotiable — it takes 30 seconds and prevents the pattern of running multiple tests, losing track of what they proved, and falling back to code reading. - After starting a new thread of work → update "Current Focus" - **Do not** dump large amounts of code into the document. Instead, reference it by `file:line`. - **Do not reorganize or reformat the document** - this is a scratchpad, not a report. - **You may** include brief, simple diagrams if they help you understand and retain information. ## Hypothesis Limits - **Maximum 3 active hypotheses at a time.** If you want to add a fourth, reject or merge one first. - **Maximum 1 `[TESTING]` at a time.** Commit to one, test it, resolve it, then move on. - **Every hypothesis must have a test or a concrete plan to write one.** "Need to investigate further" is not a valid state — that's analysis paralysis wearing a label. Valid statuses: - `[UNTESTED]` — formed but not yet tested. Must become `[TESTING]` or `[REJECTED]` soon. - `[TESTING]` — actively being tested. Only one at a time. - `[CONFIRMED]` — test reproduced the bug as predicted. - `[REJECTED]` — test disproved it, or evidence rules it out. Include why. - `[SUPERSEDED]` — replaced by a more specific hypothesis. Reference the replacement. --- > Source: [cloudflare/workerd](https://github.com/cloudflare/workerd) — distributed by [TomeVault](https://tomevault.io). <!-- tomevault:4.0:skill_md:2026-07-20 -->
Ver en GitHub