Deep research

Portable Agent Skills for non-RAPP systems and launchpads for single-file RAPP agents

Install

npx -y skills add kody-w/rapp-skills --skill deep-research

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Performs rigorous, evidence-first deep research using distinct parallel research strategies, primary sources, local artifacts, controlled experiments, adversarial verification, and confidence-rated synthesis. Use when a user asks for deep research, exhaustive investigation, reverse engineering, current landscape analysis, high-stakes comparison, or a defensible implementation recommendation.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

29.9 KB, as published. Nobody here has run it

Deep Research

Produce a decision-grade answer whose important claims can be traced to evidence. Do not confuse a long answer, many agents, or majority agreement with research quality.

Inputs

Treat the user's request, invocation arguments, or $ARGUMENTS as QUERY. Derive:

the exact question and requested decision or artifact;
scope, exclusions, and relevant time horizon;
freshness requirements;
the evidence needed to call the result complete;
safety, privacy, copyright, and authorization boundaries.

Make reasonable assumptions and proceed. Ask a question only when an answer is required to avoid unsafe work or materially different outcomes.

Research contract

Report only claims supported by cited sources, inspected artifacts, or recorded experiments.
Separate observed, documented, inferred, disputed, and unknown claims.
Prefer primary evidence. Never invent citations or cite a search-result snippet as if it were the underlying source.
Use independent tracks with non-overlapping scopes. Do not send multiple agents to repeat the same search.
Treat convergence as a prioritization signal, not proof. Verify majority-supported conclusions against evidence.
Preserve minority findings when they identify a concrete contradiction, failure mode, or missing assumption.
Do not expose credentials, private data, proprietary source, or copyrighted material beyond what is necessary for analysis.
State blockers and evidence gaps plainly. Never make a partial result look complete.

Step 1: Frame the investigation

Write a compact internal brief:

Question:
Decision or deliverable:
In scope:
Out of scope:
Freshness cutoff:
Completion checks:
Constraints:

For current facts, record the current date and verify publication or release dates. For comparisons, define evaluation criteria before collecting results. For reverse engineering, define the observable boundary and clean-room rules before inspecting artifacts.

Step 2: Design distinct tracks

For substantial or explicitly deep research, default to eight strategy tracks. Adapt these archetypes to the domain while keeping every scope distinct:

Primary-source track - official specifications, source repositories, first-party announcements, standards, papers, or authoritative records.
Artifact track - local files, datasets, logs, transcripts, binaries, schemas, or outputs owned or authorized by the user.
Public-ecosystem track - current implementations, release history, adoption, credible independent analysis, and competing approaches.
Protocol/implementation track - interfaces, data flow, state transitions, persistence, limits, and failure behavior.
Experimental track - safe black-box probes or reproducible tests that distinguish competing explanations.
Adversarial track - attempts to falsify key claims and locate contradictions, edge cases, and misleading evidence.
Systems track - the minimum causal or architectural model that explains all observations, with observed versus inferred labels.
Equivalent/action track - an independent solution, recommendation, or implementation design derived from verified behavior rather than copied internals.

For a narrow lookup, reduce the track count instead of manufacturing work. For a strategy bake-off, give each strategy agent the same normalized evidence and a different explicit approach.

Step 3: Define track contracts

Give every researcher enough standalone context to work without the parent conversation. Include:

the shared question, scope, constraints, and freshness cutoff;
one unique strategy ID and non-overlapping assignment;
allowed and prohibited sources or tools;
the expected output schema;
a requirement for exact URLs, paths, versions, dates, commands, or line references;
a requirement to label facts, inferences, confidence, contradictions, and remaining unknowns.

Use the strongest available model and reasoning level for substantial tracks. Keep contexts isolated until synthesis so one agent's conclusion does not anchor the others.

Step 4: Collect evidence

Use this source order:

directly observed behavior and reproducible experiments;
primary artifacts and official specifications;
first-party documentation and release notes;
peer-reviewed or reputable independent analysis;
community reports only as leads to verify.

Record claims in an evidence ledger. Use references/evidence-ledger.md when the investigation has more than a handful of claims.

For each source:

open the underlying document;
capture title, publisher or owner, date, retrieval date, and stable URL/path;
extract only the evidence needed for the claim;
note version, commit, environment, or account tier when behavior may vary;
cross-check stale or frequently changing information.

Step 5: Run safe experiments

Use experiments when documentation is absent, ambiguous, or contradicted.

Change one variable at a time.
Prefer read-only, reversible, zero-cost probes.
Record exact input, environment/version, output, and interpretation.
Distinguish "not observed" from "impossible."
Do not bypass access controls, organizational policy, quotas, or licensing.
Do not treat static string presence as proof that a feature is active.

For clean-room reverse engineering:

analyze user-owned artifacts and public interfaces;
summarize behavior instead of reproducing proprietary implementation;
label each conclusion observed or inferred;
hash/version the inspected build where useful;
design an independent equivalent from behavior and requirements.

Step 6: Execute efficiently

If the host supports dynamic workflows:

express real dependencies explicitly;
use parallel fan-out for independent tracks;
use streaming map/verify only when each item can advance independently;
require structured outputs with a schema;
journal starts and successful results;
make side-effecting work idempotent before enabling resume.

If the host supports ordinary subagents:

launch independent tracks in parallel;
continue genuinely independent parent work while they run;
collect each result once when completion is reported;
retry only failed or invalid tracks, not successful work;
reuse the same agent for a refinement when it retains context.

If no subagents exist, run the same tracks sequentially and preserve their separate evidence ledgers.

Do not poll background workers. If a global quota or authentication failure will make queued work fail, stop admitting new work and surface the blocker.

Step 7: Adversarial verification

Before synthesis, create a verification pass independent from the original researchers.

For every decision-changing claim:

locate its strongest evidence;
check whether the evidence actually entails the claim;
search for version, scope, account, geography, or environment qualifiers;
attempt one concrete falsification or counterexample;
downgrade or remove claims that cannot survive verification.

When agents disagree, resolve the disagreement using source quality and reproducibility. Do not settle it by vote alone. When verification is blocked, retain both interpretations and name the missing experiment.

Step 8: Synthesize

Build the answer from the claim ledger, not from agent prose.

Answer the user's core question first.
Present confirmed findings in impact order.
Explain the minimum model that accounts for the evidence.
Distinguish facts from high-, medium-, and low-confidence inference.
Include contradictions and genuine unknowns.
For recommendations, connect each action to a verified finding.
If strategies were compared, choose a majority-supported approach only after it passes evidence checks; preserve consequential minority objections.
Cite every externally verifiable, time-sensitive, or non-obvious claim.

Use concise prose by default. Do not dump internal agent transcripts or process logs unless requested.

Output contract

Use the smallest structure that fully communicates the result:

# Answer
Direct conclusion.

## Confirmed findings
- Claim - evidence and citation.

## Model or explanation
Observed behavior, then clearly labeled inference.

## Contradictions and unknowns
- What remains unresolved and why.

## Recommended action
Prioritized, evidence-linked steps.

## Sources
- Primary sources first.

For implementation research, add a testable clean-room specification, invariants, failure modes, and acceptance tests.

Resume and failure rules

Persist track IDs, inputs, source list, result status, and evidence hashes when the host supports artifacts.
On resume, reuse validated results whose inputs and evidence are unchanged.
Rerun a failed track and any downstream synthesis that depends on it.
Assume side effects are at-least-once unless protected by an idempotency key.
A completed orchestration is not necessarily complete research. Disclose failed tracks and enforce the completion checks below.

Completion checks

Do not declare completion until:

every required track succeeded or its failure is explicitly disclosed;
every high-impact claim has primary, observed, or independently reproduced support;
important contradictions are resolved or preserved as unknowns;
freshness-sensitive claims were checked against current sources;
recommendations follow from the evidence;
citations or artifact references are usable;
a fresh verification pass found no unaddressed critical gap.

The RAPP conversion path for this skill is documented in references/rapp-agent-conversion.md.