Menu
Research discipline: how to investigate before acting, verify claims. Auto-invoke when researching, answering questions, or planning migrations.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use fff MCP / Grep / Read / Glob — never Bash grep/cat/find/head/tail/sed/awk/rg/wc — for file search and read. Use jq for JSON parsing/shaping (not node -e / python -c). A hook hard-blocks the banned Bash calls, and the dedicated tools return clean, cacheable, line-numbered results. Auto-invoke when searching, reading, or counting in files.
Planning and problem-solving discipline: enter plan mode first, write plans in the plan file (not chat), structured research, validation, implementation. Auto-invoke when the user says "plan", "make a plan", or when fixing issues or implementing features.
Use before any action: five-question self-check that catches destructive ops, scope creep, fabrication, premature completion, and ignored instructions. Auto-invoke before executing commands, editing files, or answering factual questions.
Reconcile skill collections, backport from ~/.claude/skills into a marketplace plugins tree, scrubbing proprietary refs. Use when local has diverged from upstream, or when promoting local-only skills to a marketplace.
Communication and scope discipline: how to interact with the user, handle rejection, stay in scope. Always active.
Final checklist before declaring any task complete. Auto-invoke before saying "done", "ready", "complete", or asking to commit/push.
| name | research |
| description | Research discipline: how to investigate before acting, verify claims. Auto-invoke when researching, answering questions, or planning migrations. |
| user-invocable | true |
When /research is invoked, hit ALL four channels before
writing anything; skipping a channel is not research,
it's guessing. (The one carve-out: a single trivial fact,
such as does this flag exist or what is the latest version,
needs only one authoritative source. Everything that is a
migration, an architectural question, "suggest better
approaches", or "ARE YOU SURE?" gets the full four-channel
sweep.) Minimum bar before presenting any non-trivial
finding: at least one local read/grep AND one
WebSearch/WebFetch; if you haven't used both, you haven't
researched, go back and do it.
Grep the codebase, read configs, check what's already in place. Look at existing skills, hooks, settings, package.json scripts, CLAUDE.md files. The answer may already be in the project.
Use available MCP servers (Svelte, Storybook, knip, etc.).
Fetch llms.txt for libraries. Read official
documentation via WebFetch. The authoritative source beats
a blog post.
WebSearch for ALL of these, not just the first one that returns results:
Cross-reference findings. Check if GitHub issues are still open or already closed. Check if suggested solutions actually work in the current version. Don't present the first search result as the final answer.
A data-flow / trace request must cover every hop in one pass; getting re-prompted for a forgotten layer is a fail. Layers to check before writing:
bind:*, eventsInclude every layer in the trace (a Mermaid graph helps); mark any layer N/A explicitly rather than silently skipping it.
The failure that keeps happening: reading this skill, saying "let me research this", then writing an answer from existing knowledge without using a single search tool. Classic shape: asked to "suggest better approaches", the answer gets written from memory and misses that the problem is a known tracked bug with a community fix far better than the vibe answer.
If you catch yourself about to write an answer without having used WebSearch or WebFetch, STOP. You are doing the thing. Go search.
npmx.dev for package info, not npmjs.com.socket package score npm <pkg>@<ver> --markdown
before use.pnpx node-actionlint to validate GitHub Actions
workflows.Before answering ANY factual question about a tool, CLI flag, API, library behavior, or compatibility, ask: "Did I verify this, or am I about to guess?"
If the answer is "guess", STOP. Do one of:
Red flags that you're about to bullshit:
| Thought | Reality |
|---|---|
| "I'm pretty sure the flag is..." | You're guessing |
| "This should work because..." | You haven't tested it |
| "The alternative is X" | Have you verified X works? |
| "It's a known bug" | Do you have a link? Is it still open? |
Common bullshit patterns to recognize:
--pre 1 does, when the flag does not
accept that)eslint --stats reports)The pattern is always the same: confident delivery of unverified claims. The fix is always the same: verify BEFORE speaking, or say "I don't know."