agentleFS
Sign inStart free
websublimewebsublime/mister-anderson/skills/investigate/SKILL.md

investigate

Skill3 starsChanged 7 months agoMITView on GitHub

Dispatch codebase investigation for a bead task. Resolves bead context, runs the research agent, and flags spec drift before implementation.

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

12 rules. 0 are common, 4 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 115 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run codebase investigation on a bead task before implementation.

    line 9
  2. Very specific:

    If the user provides $ARGUMENTS, check if it contains a bead ID (e.g., bd-a3f, bd-001.2).

    line 14
  3. Distinctive:

    If bead ID provided: use it directly.

    line 16
  4. Very specific:

    Run bd ready --json to get unblocked tasks

    line 19
  5. Very specific:

    Check for existing investigation: Read bead comments: bd comments {BEAD_ID}.

    line 26
  6. Very specific:

    Read the epic: bd show {EPIC_ID} --json

    line 45
  7. Distinctive:

    Read the design doc content — this is the implementation contract

    line 47
  8. Very specific:

    After the research agent completes, read the investigation comment: bd comments {BEAD_ID}

    line 65
  9. Very specific:

    Ask: "Spec drift detected.

    line 69
  10. Very specific:

    If user chooses (1) → stop and recommend /spec

    line 70
  11. Very specific:

    If user chooses (2) → inform user to run /do {BEAD_ID} with drift noted

    line 71
  12. Distinctive:

    If user chooses (3) → stop

    line 72

“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

Run codebase investigation on a bead task before implementation. Dispatches the research agent to analyze the task context, trace code paths, and flag spec drift.

<on-init> If the user provides $ARGUMENTS, check if it contains a bead ID (e.g., `bd-a3f`, `bd-001.2`).

If bead ID provided: use it directly.

If no bead ID provided:

  1. Run bd ready --json to get unblocked tasks
  2. Present the list showing: ID, title, priority, and labels
  3. Pick by order and priority; if unclear, ask the user</on-init>
<on-check> 1. **Bead must exist.** Validate with `bd show {BEAD_ID} --json`. 2. **Check for existing investigation.** Read bead comments: `bd comments {BEAD_ID}`. Search for a comment containing `INVESTIGATION:`. </on-check><on-check-fail if="bead"> Bead does not exist. Inform the user and stop. </on-check-fail><on-check-fail if="investigation_exists"> An investigation already exists for this bead. Show the existing findings and ask: "An investigation already exists. Do you want to (1) re-investigate, or (2) proceed to `/do` with the existing findings?" </on-check-fail><on-execute>

Step 1: Read Full Bead Context

  1. Parse bead JSON. Extract: description, acceptance, design, notes, status, parent, labels
  2. If bead is an epic child (BEAD_ID contains a dot, e.g., bd-001.2):
    • Extract EPIC_ID: the part before the first dot (e.g., bd-001)
    • Read the epic: bd show {EPIC_ID} --json
    • Extract the design doc path from the epic if available
    • Read the design doc content — this is the implementation contract
  3. Store all context for the dispatch prompt

Step 2: Dispatch Research Agent

Dispatch using exactly these parameters — no more, no less:

Agent(
    subagent_type="research",
    prompt="Investigate BEAD {BEAD_ID}. [Include EPIC_ID if epic child]. Read the bead (bd show {BEAD_ID}) for full context — description, acceptance criteria, and design notes. Read the spec and plan referenced in the bead's external-ref or spec-id fields. If the spec has a Research Findings section, spot-check 2-3 assumptions against the current codebase. Flag any SPEC_DRIFT in your investigation comment. Log your structured findings as a bead comment using bd comments add."
)

Do NOT add extra parameters unless the user explicitly requests it.

Step 3: Handle Spec Drift

After the research agent completes, read the investigation comment: bd comments {BEAD_ID}

If SPEC_DRIFT found:

  • Present the drift to the user clearly
  • Ask: "Spec drift detected. Do you want to (1) update the spec first with /spec, (2) proceed to /do anyway with known drift, or (3) skip this task?"
  • If user chooses (1) → stop and recommend /spec
  • If user chooses (2) → inform user to run /do {BEAD_ID} with drift noted
  • If user chooses (3) → stop

If no SPEC_DRIFT → inform user investigation is complete.

</on-execute><on-complete> 1. Show the investigation summary from the bead comments 2. Report spec drift status (clean or drift detected) </on-complete><on-next> Recommend proceeding with `/do {BEAD_ID}` to dispatch the implementation supervisor. </on-next>

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.

Check your setup, free