Parallel read-only exploration. Facts from code become one shared report.
SKILL // CHAIN STEP 02
/10x-research - evidence from the repository
When measurements cannot be trusted, you build your own instruments - this skill is an instrument for measuring code.This skill is an instrument for measuring code before decisions are made. /10x-research answers a research question with parallel subagents and writes the findings, with file:line references, to research.md - later steps read facts from disk, not from conversation memory.
/10X-RESEARCH // PARALLEL MEASUREMENT CONVERGES INTO ONE ARTIFACT
The problem: decisions on poisoned data
"Do not trust a measurement you did not take with your own instrument."
- the scientists' reflex after the universe started to flickerThe biggest saboteur of a plan is a false "I know how this works" - knowledge from three refactors ago, someone else's code, a large repository. /10x-research replaces assumptions with evidence from the repository: it combs through the code, the decision history and the system's real behavior, and writes the result to disk.
The artifact is the whole point: research in conversation memory vanishes with the context, research in a file survives the session and becomes the input for /10x-plan - the plan is built on facts that can be cited with a line number.
earns its keep in unfamiliar, old or large code - wherever a false "I know" costs the most and a plan without grounding would be guesswork.
The agent first learns code facts, dependencies and existing patterns before proposing a solution.
From a research question to a document with evidence
The input is a research question plus the files pointed out by the user - the skill reads these in full before anything else starts, in the main context, not in subagents. If context/foundation/lessons.md exists, its rules are taken as given: what the team has already accepted does not need to be investigated again.
The output is research.md in the change folder - one research artifact per change. Follow-up questions do not create new files: they are appended to the same document as a separate section with a frontmatter annotation.
- Input
- a research question + the pointed-out files (read in full) + optionally a change-id
- Output
- research.md in context/changes/<change-id>/ with metadata (date, commit, branch, topic)
- Status
- change.md moves from new to preparing; a missing folder = created as in /10x-new
One question starts parallel safe scans and ends with one shared set of concrete evidence.
Decomposition, parallel measurement, synthesis
- 01 · Reading
- files named by the user are read in full in the main context - no limits, no delegating this reading.
- 02 · Decomposition
- the question is broken into research areas that will later compose the answer; each area gets a user-visible task on the progress list.
- 03 · Scope
- clarification with the user: breadth, depth, center of gravity (2-4 concrete options per question). Skipped when the query is unambiguous and narrowly scoped.
- 04 · Subagents
- 2-4 in parallel, each in its own dimension: fast search for files and patterns, earlier decisions in context/changes/ and context/archive/, deep analysis of system behavior.
- 05 · Synthesis
- starts only when everyone is back; findings from live code take precedence, history is supplementary context; everything is tied together with file:line references.
- 06 · Write
- metadata (commit, branch, date) is collected before writing - the document is never created with placeholders; with a pushed commit the references get GitHub permalinks.
subagents get read-only tasks and must return concrete file:line references and usage patterns - not generalities and not bare definitions.
Code facts and assumptions use separate tracks, so the plan is not built on confident-sounding guesses.
research.md - a self-sufficient document
The document opens with frontmatter carrying full temporal context: date with timezone, researcher, commit, branch, repository, topic, tags. Thanks to it, a reader three months later knows against which state of the code these findings were true.
The sections lead from summary to detail: first the answer to the question, then evidence per component, finally architectural insights and what could not be resolved. Follow-up questions land at the bottom with their own timestamp.
- Summary
- a high-level answer to the research question
- Detailed Findings
- findings per component/area with references and cross-component relationships
- Code References
- a list of path:line entries describing what lives there - the ground for the plan
- Architecture Insights
- patterns, conventions and design decisions discovered along the way
- Historical Context
- conclusions from context/changes/ and context/archive/ with references to those documents
- Open Questions
- areas that need further investigation - stated openly, instead of feigning completeness
Every important conclusion points back to code; assumptions are labeled and never presented as facts.
What /10x-research does not do
- Does not change code
- the investigation is entirely read-only - the only writes are research.md and the status bump in change.md.
- Does not trust history blindly
- fresh research of live code always comes before the archive - earlier changes are supplementary context, not a substitute for reading.
- Does not plan
- research establishes facts; design decisions and phases are the job of /10x-plan.
- Does not multiply artifacts
- one research.md per change; follow-up questions are appended to the existing file. An archived change = refusal and a pointer to /10x-new.
back to step 02 (research) on the Core Skills Chain page - the context of the whole chain and the neighboring steps.
Research can run in parallel, but it does not change the repository, keeping exploration safe and reversible.