agentleFS
SebastianElvisSebastianElvis/reaper/skills/investigate/SKILL.md

investigate

Skill9 starsChanged 2 months agoApache-2.0View on GitHub

This skill tests hypotheses with proofs, counterexamples, and analysis. You use it to verify, prove, or refute research claims.

128 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use pair-agent, plan-devex-review and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • seek888Skill

    pair-agent

    Pair a remote AI agent with your browser. One command generates a setup key and prints instructions the other agent can follow to connect. Works with OpenClaw, Hermes, Codex, Cursor, or any agent that can make HTTP requests. The remote agent gets its own tab with scoped access (read+write by default, admin on request). Use when asked to "pair agent", "connect agent", "share browser", "remote browser", "let another agent use my browser", or "give browser access". (gstack) Voice triggers (speech-to-text aliases): "pair agent", "connect agent", "share my browser", "remote browser access".

    Also in 10 projects that use this

  • seek888Skill

    plan-devex-review

    Interactive developer experience plan review. Explores developer personas, benchmarks against competitors, designs magical moments, and traces friction points before scoring. Three modes: DX EXPANSION (competitive advantage), DX POLISH (bulletproof every touchpoint), DX TRIAGE (critical gaps only). Use when asked to "DX review", "developer experience audit", "devex review", or "API design review". Proactively suggest when the user has a plan for developer-facing products (APIs, CLIs, SDKs, libraries, platforms, docs). (gstack) Voice triggers (speech-to-text aliases): "dx review", "developer experience review", "devex review", "devex audit", "API design review", "onboarding review".

    Also in 13 projects that use this

  • ShreyRaviSkill

    landing-report

    Read-only queue dashboard for workspace-aware ship. Shows which VERSION slots are currently claimed by open PRs, which sibling Conductor workspaces have WIP work likely to ship soon, and what slot /ship would pick next. No mutations — just a snapshot. Use when asked to "landing report", "what's in the queue", "show me open PRs", or "which version do I claim next". (gstack)

    Also in 7 projects that use this

  • ayudaySkill

    setup-deploy

    Configure deployment settings for /land-and-deploy. Detects your deploy platform (Fly.io, Render, Vercel, Netlify, Heroku, GitHub Actions, custom), production URL, health check endpoints, and deploy status commands. Writes the configuration to CLAUDE.md so all future deploys are automatic. Use when: "setup deploy", "configure deployment", "set up land-and-deploy", "how do I deploy with gstack", "add deploy config".

    Also in 14 projects that use this

  • ayudaySkill

    cso

    Chief Security Officer mode. Performs OWASP Top 10 audit, STRIDE threat modeling, attack surface analysis, auth flow verification, secret detection, dependency CVE scanning, supply chain risk assessment, and data classification review. Use when: "security audit", "threat model", "pentest review", "OWASP", "CSO review".

    Also in 17 projects that use this

  • ramybarsoumSkill

    document-release

    Post-ship documentation update. Reads all project docs, cross-references the diff, updates README/ARCHITECTURE/CONTRIBUTING/CLAUDE.md to match what shipped, polishes CHANGELOG voice, cleans up TODOS, and optionally bumps VERSION. Use when asked to "update the docs", "sync documentation", or "post-ship docs". Proactively suggest after a PR is merged or code is shipped.

    Also in 18 projects that use this

  • +1 more from seek888

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 115 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If all hypotheses are resolved, you return to the orchestrator.

    line 53
  2. Distinctive:

    If evidence already strongly favors one outcome, you use the corresponding method.

    line 90
  3. Distinctive:

    All properties need formal predicates.

    line 104
  4. Very specific:

    If a proof has a gap, you identify the exact step.

    line 109
  5. Distinctive:

    If the outcome needs multiple claims, you record that issue for the next cycle.

    line 118
  6. Very specific:

    When you confirm a core property, you check its effect on composition.

    line 131
  7. Very specific:

    Only the main agent writes shared notes during merge.

    line 185
  8. Very specific:

    If all eight steps fail, you log inconclusive and continue to the next hypothesis.

    line 197
  9. Distinctive:

    After three cycles with the same proof failure or evidence of refutation, you change direction.

    line 201
  10. Distinctive:

    If a cycle finds incorrect model assumptions, a wrong core question, or incorrect property definitions, you request reformulation.

    line 212

“Common” is measured: kept by at least 6 in 10 of the 115 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Investigate

You must read and apply the language rules before you write any output.

Each cycle tests one hypothesis and returns a keep or discard verdict.

Usage

You invoke this skill by name with an optional cycle count. The default count is 5. Slash-command hosts use /investigate 10.

investigate 10
investigate

Inputs

You always read these files:

  • reaper-workspace/notes/problem-statement.md
  • reaper-workspace/notes/ideas.md
  • reaper-workspace/notes/current-understanding.md
  • reaper-workspace/notes/results.md

You read these sources only when a hypothesis needs them or progress stops:

  • reaper-workspace/notes/paper-summary.md, if it exists.
  • reaper-workspace/notes/literature.md
  • reaper-workspace/papers/, including <id>-notes.md files.
  • ../reaper/references/methodology.md

Batch Loop

You test independent hypotheses in parallel batches when the host supports subagents. You use sequential execution for dependent hypotheses or hosts without subagents. Each batch has three stages: plan, dispatch, and merge. You repeat batches while cycles remain and unresolved hypotheses exist.

Plan

  1. You read ideas.md and notes/results.md.
  2. You identify unresolved hypotheses. You check previous results to avoid repeated failed approaches.
  3. You map dependencies between hypotheses.
  4. You select the largest independent set that fits the remaining cycle count.
  5. You assign consecutive cycle numbers to each subagent without overlap.
  6. You use a batch of one if all remaining hypotheses form a dependency chain.
  7. If all hypotheses are resolved, you return to the orchestrator. It can invoke brainstorm for more ideas.

Dispatch

You start one subagent per hypothesis with the host's parallel tool. You start the batch in one message when the host permits this. You give each subagent these inputs:

  • Its cycle numbers and hypothesis.
  • Two or three relevant findings from current-understanding.md, usually 200-500 words.
  • A pointer to current-understanding.md for additional context.
  • The single-cycle procedure in Steps A-E.
  • A request for result rows, a verdict, and any keep finding to merge.

You do not send the full current-understanding file to every subagent. Subagents read shared notes without changing them during the batch.

Step A: Create the Investigation Directory

For a new hypothesis, you create reaper-workspace/investigations/NNN-<slug>/. NNN is the assigned cycle number with leading zeros, such as 001. <slug> is a short description, such as proof-lemma3.

For a repeated hypothesis, you reuse its existing directory. You keep the original directory number. You edit analysis.md and proof.md in place. The result row uses the new cycle number.

Step B: Investigate

You select the method for the hypothesis's immediate task:

  • Proof verification: You check an existing proof for missing steps, hidden assumptions, and boundary errors.
  • Counterexample search: You construct an execution that violates a claim. You start with small cases.
  • Comparison: You compare approaches under the same specified conditions.
  • New proof: You construct an argument for a claim without an existing proof to check or a counterexample to build.

For a new proof, you use security-analysis for security claims and performance-analysis for cost claims. You use proof-attempt for other claims. You check whether the proof can use fewer steps or assumptions.

You write reasoning, attempts, failed approaches, and findings to the investigation's analysis.md. On a revisit, you revise the existing text to show the current understanding.

Parallel Work Within a Cycle

If the result is uncertain, you can start separate proof and counterexample subagents. The first complete result determines the outcome. You record the other subagent's partial work in the investigation directory. You can also search IACR, arXiv, and the web in parallel when progress stops. If evidence already strongly favors one outcome, you use the corresponding method.

Formal Proof Structure

You write formal claims and proofs in reaper-workspace/investigations/NNN-<slug>/proof.md. Each entry uses ## Theorem/Lemma/Proposition N: <name> and these fields:

  • Statement: You give the exact mathematical claim.
  • Assumptions: You list every model, hardness, and network assumption.
  • Proof: You number logical steps and justify each with a definition, assumption, lemma, or source. You end with ∎.
  • Proof technique: You name the method, such as reduction, induction, simulation, or hybrid argument.

You use the proof methods, Reduction Quality Gate, and performance checks in ../reaper/references/methodology.md. You state the selected method in the proof header. If an attempt fails, you record the method and cause. You try another method in the next cycle.

All properties need formal predicates. You specify model assumptions for every proof. Security proofs need definitions, reductions, bounds, and explicit reduction loss. Performance proofs distinguish worst-case, average, and amortized costs. Impossibility proofs specify the excluded behavior and use contradiction or reduction.

If a proof has a gap, you identify the exact step. You state any additional assumption that closes the gap. You log an incomplete proof attempt as inconclusive. You label unproven claims as conjectures.

Step C: Evaluate

A cycle makes progress through a changed answer, a new question, a simpler argument, or an error correction. A changed answer can confirm, refute, or narrow a hypothesis. You describe each finding once, even when it has multiple effects.

You prefer a proof with fewer assumptions or fewer steps for the same result. You exclude findings that do not support the research goal. You state the cycle outcome in one sentence. If the outcome needs multiple claims, you record that issue for the next cycle.

Classify Proof Issues

IssueMeaningOutcome
Gap (fillable)The proof lacks a step, but its approach remains valid.partially-confirmed
Gap (structural)The proof method cannot establish the claim as written. You test an alternative proof.inconclusive
Error (theorem likely false)A concrete counterexample or execution trace violates the claim.refuted
OverclaimThe proof establishes a weaker claim. You state the exact weaker result.partially-confirmed

Check Composition

When you confirm a core property, you check its effect on composition. You use ../reaper/references/definitional-standards.md for relevant conditions, such as rewinding or shared setup. You record composition limits in analysis.md, even if the hypothesis did not request this check.

Step D: Log

You prepare a row for reaper-workspace/notes/results.md:

| NNN | H# | action-type | outcome | confidence | status | one-sentence description |

The fields use these values:

  • action-type: proof-verification, proof-attempt, counterexample-search, security-analysis, performance-analysis, comparison, literature-search, reformulation.
  • outcome: confirmed, refuted, partially-confirmed, inconclusive, new-hypothesis, reformulate.
  • confidence: high, medium, low.
  • status: keep, discard.

Subagents return rows to the main agent without editing results.md. They mark revisits as updates with the latest cycle number, outcome, confidence, and description.

You create reaper-workspace/logs/cycle-NNN-<slug>.md for every cycle. You use the current cycle number, including on revisits. You never change this log after creation.

The log uses title # Cycle NNN: <hypothesis title>. It records Hypothesis, Action, Outcome, confidence, and Verdict. Its ## Summary explains the attempt, evidence, and verdict in 1-3 short paragraphs.

Set Confidence

You start one level below your initial confidence estimate. You use high confidence only after you check every proof step.

ConfidenceRequired evidence
highThe argument is complete. Every step has a justification. Reductions pass the Reduction Quality Gate.
mediumThe argument seems correct, but at least one step lacks full verification or formal justification.
lowThe argument has large gaps or unchecked assumptions. It supports a conjecture rather than a proven result.

Step E: Keep or Discard

You return keep and the finding when Step C shows progress. Otherwise, you return discard. You retain every investigation directory for the audit record. Subagents do not write to current-understanding.md.

Merge

The main agent waits for all subagents in the batch. It performs these actions:

  1. It updates existing hypothesis rows in notes/results.md.
  2. It adds rows only for new hypotheses. It orders rows by hypothesis number.
  3. It merges keep findings into notes/current-understanding.md as a coherent explanation.
  4. It adds new hypotheses from the batch to ideas.md.
  5. It updates resolved, lower-priority, or covered ideas in place.
  6. It adds a batch summary after the results table.
  7. It reads the updated state before it plans another batch.

The summary uses ## Batch Summary (Cycles NNN-MMM). It lists Keep findings and Discard patterns with one sentence per finding or pattern.

Only the main agent writes shared notes during merge. The brainstorm and write-paper skills use batch summaries to reduce file reading. For a batch of one, the main agent can run Steps A-E directly.

Completion

You run all N cycles unless all hypotheses reach high-confidence resolution and no useful new hypotheses remain. You do not ask whether the user wants you to continue. You also return early for the reformulation condition below.

When Progress Stops

You follow "When Stuck: 8-Step Escalation" in ../reaper/references/methodology.md. You use ../reaper/references/search-tools.md for search commands. Those commands use arxiv.py and iacr.py from the /search-paper skill.

You download relevant new papers to reaper-workspace/papers/. You write <id>-notes.md for each paper. You integrate findings into the existing sections of notes/literature.md. You do not create a separate section for additions during investigation. You log the search with action-type literature-search.

If all eight steps fail, you log inconclusive and continue to the next hypothesis. The orchestrator can invoke brainstorm after the batch.

Negative Results

After three cycles with the same proof failure or evidence of refutation, you change direction.

  1. You attempt a concrete attack, execution trace, or reduction to a known impossibility.
  2. You identify the weakest additional assumption that restores the positive claim.
  3. You record a supported negative result as outcome refuted and status keep.
  4. You state the result and its implications in the cycle description for later brainstorming.

You do not repeat minor changes to the same failed proof method.

Re-Formalization Protocol

If a cycle finds incorrect model assumptions, a wrong core question, or incorrect property definitions, you request reformulation.

  1. You log outcome reformulate and status keep.
  2. You add ## Re-Formalization Signal to the cycle's analysis.md.
  3. That section states the error, evidence, and proposed correction.
  4. You start the result description with REFORMULATE, followed by a one-sentence explanation.
  5. You stop further batches and return the signal to the orchestrator.

The orchestrator invokes formalize-problem with this evidence before investigation resumes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.