deep-research

name

deep-research

description

Run a decision-grade, multi-source research pass that verifies claims across official docs, implementation evidence, field evidence, and counter-evidence, then turns them into a source-backed memo or an adopt/experiment/watch/reject decision. Use when the task needs multiple source layers, counter-evidence, contradiction handling, or a source-of-truth comparison across tools, vendors, workflows, repos, standards, or market/technical claims. Do not use for quick fact lookup, a single-doc answer, routine digest review, simple feature comparison, code review, or implementation-only work.

Deep Research

Contract

• Lock the decision question first.
• Separate what is true, what is implemented, what is used in practice, and what is only claimed.
• End with a recommendation, uncertainty statement, or explicit "not enough evidence."

Read next only when needed

• Before choosing depth or collecting sources, run this escalation check.
• If any escalation condition matches, read references/superiority-rubric.md before proceeding.
• If the pass escalates to long-run, also read references/long-run-artifact-spec.md.
• Only skip the rubric when none of the escalation conditions match.

Use the rubric when any of these are true:

• the decision changes architecture, process, spend, or security posture
• the user wants "best possible", "deepest", "exhaustive", or "decision-grade" research
• the topic is contested, benchmark-heavy, or marketing-saturated
• multiple ecosystems, vendors, or source layers must be compared
• 3 or more ecosystems, vendors, or major options must be compared
• the recommendation must be auditable by another reviewer
• the topic is freshness-sensitive enough that stale model knowledge is risky

Pick the smallest depth that can answer the question

• standard: one memo, 4 to 8 strong sources, at least 2 source layers, and at least 1 source that could falsify the likely answer
• deep: 8 to 15 strong sources, at least 2 adversarial or counter-evidence sources, contradiction handling, explicit recommendation
• long-run: multi-hour or high-stakes pass; externalize state under Research/<date>-<slug>/ using:
  • 00_scope.md
  • 01_plan.md
  • 02_queries.md
  • 03_sources.jsonl
  • 04_notes/
  • 05_contradictions.md
  • 06_report.md

For long-run, copy the starter pack from assets/long-run-pack/ into Research/<date>-<slug>/ unless that folder already contains an intentional file stack.

• Force long-run when any of these are true:
  • 3 or more ecosystems, vendors, or major options must be compared
  • the pass needs 3 or more source layers plus active contradiction tracking
  • the topic is freshness-sensitive and likely to drift during the run
  • losing provenance would make the recommendation unsafe or hard to review

Do not default to long-run for every question. Use it when scope, stakes, or uncertainty justify the overhead.

Source model

Split sources before reading:

• official truth: docs, release notes, standards, official repos, source-of-truth product pages
• implementation truth: source code, config examples, issue threads, benchmark methods, reproducible artifacts
• field evidence: practitioner writeups, operator reports, curated lists, adoption signals, and platform-native practitioner content from places like YouTube, X/Twitter, Telegram, Reddit, Discord, forums, LinkedIn, or Facebook groups when they materially show what people actually do
• adversarial evidence: criticisms, failure reports, negative comparisons, security notes, unresolved issues

Use these roles consistently:

• capability claims need official truth or implementation truth
• workflow claims need field evidence
• strong recommendations need at least one counter-source or failure check

Evidence admissibility

Search results are leads, not evidence. A search result tells you where to look. It is not proof until you verify the claim at the actual source page.

When verifying claims, use this source preference order:

1. official product/spec page at the manufacturer's own domain
2. official repo docs (README, install guide, API reference)
3. official issue tracker, changelog, or release notes
4. named practitioner report with disclosed hardware and methodology
5. independent test with disclosed methodology
6. everything else is a lead to be verified, not evidence by itself

Review aggregators, affiliate articles, and secondary summaries are leads. They are useful for discovery but do not count as evidence for decision-bearing claims.

When the question touches privacy, retention, residency, liability, compliance, or enterprise procurement, trust centers and sales pages are not enough by themselves. Read the operative documents where the edge cases live:

• DPA or data-processing terms
• privacy policy and retention/help-center docs
• abuse-monitoring, logging, or human-review docs
• enterprise security / audit docs
• BAA or other contractual addenda when relevant

If a recommendation depends on a vendor's privacy or compliance posture, at least one decisive claim must come from those operative documents, not just a marketing summary page.

For legal or regulatory claims, distinguish primary materials (rule, statute, regulator guidance, enforcement release, court decision, no-action letter) from secondary commentary. Commentary may guide search, but it should not carry the top-line conclusion without the primary document.

Decision-bearing numeric claims

A numeric claim (tokens per second, benchmark score, price, bandwidth) may appear in the decision table or recommendation only if it meets one of these:

• verified at an official spec page or repo docs
• comes from a benchmark with disclosed model, quantization, backend, prompt length, and workload shape
• comes from a named practitioner with disclosed hardware setup

If no source meets this bar, you may include directional estimates as ranges but must label them partially verified or directional estimate and must not let them be the decisive factor in the recommendation.

Quantified claims sourced from blogs, review aggregators, or media explainers (e.g., "4.7 billion views wiped") may inform discussion but cannot drive the analytical thesis, What Is True, or the final verdict without primary or multi-source corroboration. Label them directional estimate or secondary and keep them out of top-line findings.

When the question is about workflows, adoption, creator practice, or "what people actually use," do not limit field evidence to blogs and curated lists. Look for platform-native artifacts such as:

• YouTube walkthroughs, build logs, or postmortems
• X/Twitter threads
• Telegram channel posts or discussions
• Reddit threads
• Discord/forum discussions
• LinkedIn or Facebook posts only when they add real implementation or operator evidence

Treat these as evidence of practice, not evidence of capability. Do not let one viral post decide the conclusion.

For workflow-heavy or creator-heavy topics, include at least one platform-native practitioner source in deep, and at least two in long-run if such material exists. If there is meaningful video-native practitioner evidence, include YouTube explicitly rather than relying only on text summaries of the same material.

When the question is about agent tools, workflow systems, or ecosystem reuse, map each serious option across these layers before judging portability:

• always-on guidance: AGENTS.md, CLAUDE.md, global instructions, or equivalent
• rules: scoped behavioral constraints, usually always-on or path-triggered
• skills: reusable procedures with SKILL.md and optional resources
• manual workflows: slash commands, workflow prompts, or explicit runbooks
• memory: auto or file-based durable context layers
• adjacent control layers: hooks, subagents, plugins, or marketplace packaging when material

Project context intake

Use this when the research is being done inside a real workspace and the answer is meant to influence that project. Skip it for generic public research that is not tied to a local project.

Before web research, read a small local context set. Read only 2 to 5 files that define project reality, such as:

• AGENTS.md or equivalent local operating rules
• PRD.md or equivalent product source of truth
• the active research memo, benchmark packet, or planning doc when relevant
• one domain-specific config or source-of-truth file if it materially constrains the decision

Write down:

• what project this research is for
• what decision this research is supposed to unblock
• local constraints and non-goals
• who will consume the output
• the rewritten project-aware version of the research question

Do not turn this into a full repo audit. The goal is to align the research to project reality before gathering outside evidence.

Workflow

Backbone principle: discovery -> classification -> decision. First find what exists. Then type and classify each candidate. Only then shortlist and decide. The classification step is the one most often skipped under pressure -> do not skip it.

0. Run an optional framing preflight when the path is unclear.

Use this only when the user knows the goal but the research framing is still fuzzy. Skip it when the question is already well locked.

In one short pass:

• state the goal in one sentence
• state the main constraint in one sentence
• list 2 to 4 realistic research framings
• give one tradeoff for each framing
• choose the framing that best fits the decision
• rewrite the final research question before starting the real pass

Typical framings:

• decision memo
• workflow or layer analysis
• vendor or tool comparison
• market map or inventory
• risk-first memo
• procurement or compliance memo

Output only:

• chosen framing
• rejected framings
• rewritten research question
• first research step

Do not let this preflight turn into a second research pass. It exists only to choose the right path before evidence gathering.

1. Lock the research question.

Write down:

• the decision we are trying to make
• who the answer is for
• what a useful answer must include
• what is out of scope
• what would change the conclusion
• what workload lanes or requirement lanes the question contains (e.g., coding, transcription, vision, serving)

If the question names specific workloads or requirements, list them as lanes. Each lane must be covered by verified evidence or logged as an explicit coverage gap in the final report. Do not claim a workload is covered in the decision table if no stack or tool was actually verified for it.

If the question touches privacy, compliance, procurement, or geography, split those concerns into separate lanes rather than one generic "enterprise" lane. At minimum, separate:

• retention / training usage
• logging / auditability
• region / residency
• sovereignty / jurisdiction
• buyer-facing controls or procurement requirements

If the question is about a domain ecosystem, skill landscape, or "what exists in this space," also lock which output mode is needed:

• landscape first: inventory the real ecosystem before deciding what is adoptable
• adoption first: shortlist only immediately usable options, but still log larger ecosystems that materially shape the market

Default to landscape first when the user asks what exists, what we missed, or whether a domain already has a real skill ecosystem.

1.25 Differentiate before you broaden.

For product, pack, workflow, or skill research, write a provisional differentiation thesis before broader search:

• what is uniquely unsolved here?
• what mature tools already solve well?
• what should likely be recommended rather than built?
• where does AI add real value: ingestion, synthesis, explanation, classification, or execution?
• what user segment and repeated pain make this worth building at all?
• what would still be valuable if the AI layer disappeared?

Do not keep a build-shaped thesis just because it is feasible. If the strongest answer is "recommend existing tools and build only the interpretation, control, or safety layer," say so.

2. Decompose and build a search plan.

Before browsing anything:

• break the question into 3-7 sub-questions that together cover the full decision
• at least one sub-question must be adversarial: "what would make this fail?", "why does X not work in practice?", or "what are the known failure modes?" Do not treat this as optional or deferrable.
• for each sub-question, draft 2-4 search queries across different source classes (official, implementation, field/social, adversarial)
• this produces a query pack of 10-25 planned searches; not all must run, but the plan must exist before the first search
• for long-run, write the query pack to 02_queries.md
• if the workflow depends on heterogeneous artifacts (PDFs, screenshots, CSVs, exports, OCR, vendor-specific files), dedicate one sub-question to format diversity, format drift, importer fragility, and parser failure modes

For domain, ecosystem, or skills-market scans, make the query pack explicitly two-pass:

• landscape pass: broad ecosystem and naming queries
• adoption pass: narrow workflow and installability queries

The landscape pass should search not only by task, but also by:

• domain noun + skills
• domain noun + agent
• domain noun + workspace
• domain noun + framework
• domain noun + copilot
• domain noun + openclaw, claude, codex, gemini, or other relevant agent/runtime names

Do not rely only on workflow-level queries like differential diagnosis skill or drug interaction skill. Those find practical leaves, but often miss the big ecosystem trunks.

3. Build the comparison frame before reading.

For each candidate or claim, check:

• what is actually true today
• what is only promised or marketed
• what practitioners appear to do in reality
• what procedural delta it adds
• what it costs in time, risk, or permissions
• what breaks or stays painful if we do nothing
• for recurring artifacts or mandatory protocols, what the likely scale breakpoint is (entry count, review load, or recurring read burden) before the system becomes hard to follow or reliably execute

If the design requires an agent or operator to re-read the same growing artifact every session, estimate the recurring read burden. Use rough numbers when needed, but do not hide behind "it gets messy later" without naming a scale risk.

For high-stakes or calculation-heavy topics, explicitly separate:

• what the model may safely parse, classify, summarize, or explain
• what must remain deterministic code, formulas, rules, or audited calculations
• what outputs must be reproducible outside the model

If the model is allowed to originate decision-bearing numbers, transformed user values, or ranked recommendations, say so explicitly and justify why.

For privacy, compliance, or procurement questions, compare each serious option separately on:

• training usage and retention
• logging and auditability
• region / residency controls
• sovereignty / jurisdiction exposure
• enterprise control surface (SSO, RBAC, private networking, exportable logs, admin controls)
• what the buyer will still ask your team to prove

If this is a tool or ecosystem comparison, also classify each serious option as one or more of:

• standard or spec
• official catalog or marketplace
• community catalog
• workflow framework
• translation or sync layer

If the pass is about skills, agents, or domain ecosystems, also classify each option as one of:

• installable skill pack
• broader skill library or ecosystem
• agent platform or workspace
• retrieval / RAG / knowledge-graph infrastructure
• research artifact or paper-backed prototype

Do this classification before ranking practical usefulness. A platform, skill pack, and backend library are not interchangeable findings.

Candidate typing gate

This is a hard gate. Do not proceed to shortlisting or ranking until every serious candidate has a type assigned from the classification above.

• No shortlist before candidate typing.
• No ranking before category assignment.
• No "best option" until entity types are separated.

If a candidate does not fit any existing type, create a new type and log it. Do not force-fit candidates into wrong categories to move faster.

Candidate reality check

Before proceeding to evidence gathering, verify for each candidate:

• does the product, version, or SKU actually exist? (check at the manufacturer's page)
• is the lineup and release date real, or assumed from memory?
• are there previous-generation or used-market options still shipping and price-competitive?
• is the recommendation at risk of building on a phantom product or MSRP fantasy?

For hardware comparisons specifically: a well-understood previous-gen option with stable pricing and known behavior may be stronger than a current-gen option with supply issues or immature software support. Do not skip it.

Contract and procurement reality check

When the question touches enterprise adoption, privacy, compliance, or legal exposure, verify for each serious candidate:

• which claims are in a trust center or sales page versus a DPA, ToS, or privacy doc
• whether stricter controls are default, self-serve, approval-gated, or contract-gated
• whether residency is the same thing as sovereignty in this context, or a weaker guarantee
• what a small team would still need to provide in procurement (DPA, subprocessor list, deletion statement, logging story, security questionnaire answers, AI disclosure, SOC 2 or equivalent)

4. Gather sources across lanes.

Prefer:

• primary sources first for mechanism and support boundaries
• implementation artifacts when docs are vague
• field evidence only after the official baseline is clear
• for workflow/use-in-practice questions, field evidence should include at least one platform-native source class when available, not only blogs or curated lists

Do not inflate source count with repeats. Two strong sources beat ten paraphrases.

When designing a workflow, protocol, or skill, check known skill ecosystems before building from scratch. If the project has a skill catalog, watchlist, or known ecosystem list, search it first. A ready-made skill or tool in a known ecosystem is stronger evidence than a design invented from first principles.

For decision-bearing conclusions, read at least 3-5 key sources in full when available. Do not rely only on search snippets, summaries, or extracted passages. Snippets are leads for discovery; decisive claims must come from full-text reading.

For workflow, protocol, or agent-reliability questions, search at least one adjacent domain for transferable patterns when relevant. Good adjacent domains include incident management, DevOps, distributed systems, and project management.

When the topic has active measurement literature, include benchmark studies, evaluation papers, or systematic comparisons in the evidence base. Do not create a new source tier for this; treat them as supporting evidence alongside the existing source model.

For hardware, tool, or workflow comparisons: require at least one concrete practitioner setup description in deep and at least two in long-run when the ecosystem is active. A concrete setup means a specific person's actual hardware model, software stack, and workflow with enough detail to reproduce or evaluate. Forum threads, build logs, and "share your setup" posts are the strongest form of this evidence. If no concrete practitioner setup is found, log it as a critical coverage gap.

For enterprise, privacy, compliance, or procurement questions: run a dedicated contract-and-policy pass before treating the official baseline as complete. Read the DPA, ToS, privacy/retention docs, abuse-monitoring docs, and any security or enterprise addenda you can access for each serious option.

Then run a procurement reality pass. The goal is not just "which vendor is better" but "what would a small team actually have to ship, document, or negotiate to close deals safely." Look for:

• DPA execution requirements
• subprocessor review burden
• security questionnaire expectations
• audit-log and deletion/export expectations
• AI disclosure or transparency requirements
• minimum compliance baselines such as SOC 2, BAA, or private networking

After the official and implementation lanes, run a dedicated community and practitioner media pass:

• YouTube: search for walkthroughs, tutorials, teardowns, postmortems related to the question
• Reddit: search site:reddit.com <topic> experience or similar
• HN: search site:news.ycombinator.com <topic>
• X/Twitter: search when accessible and relevant
• Telegram, Facebook, LinkedIn, Discord: use when they add real operator evidence, but log as a coverage gap if inaccessible

This is a separate pass from blog-based field evidence. Platform-native artifacts often reveal workflow patterns that blogs miss.

4.5. Run conditional ecosystem passes when the question is a domain or ecosystem scan.

For domain ecosystem scans and landscape-first passes, the distribution and domain-native query passes are required. The enterprise/commercial and frontier/preprint passes are conditional. Skip this whole block for standard tool comparisons or single-vendor questions.

Distribution and installability pass. Before concluding that something "exists," check where it actually ships. See references/distribution-registries.md for the checklist.

Domain-native query pass. Search using the domain's own vocabulary, not just "agent" / "skill" / "copilot." See references/domain-ecosystem-scans.md for guidance.

Enterprise and commercial pass (conditional). When the question is about ecosystem shape, market landscape, or "what exists," check the enterprise/commercial layer. Vendor pages, press releases, analyst reports, institutional deployments. See references/domain-ecosystem-scans.md.

Frontier and preprint pass (conditional, research-heavy domains only). When the domain is research-active (biomedical, ML, scientific computing), check arXiv, bioRxiv, medRxiv, conference proceedings, and supplementary code. See references/domain-ecosystem-scans.md.

5. Extract evidence, not vibes.

For every important claim, record:

• the source and date
• what it supports
• what it contradicts
• why the source is credible or limited
• whether the claim is verified, partially verified, unverified, or marketing only

6. Chase contradictions and run adversarial falsification. This step is mandatory, not optional.

• go closer to the primary artifact
• prefer newer evidence when the topic is time-sensitive
• if conflict remains, keep both sides and state the uncertainty

After collecting evidence, run a dedicated adversarial search pass for each key design decision or recommendation. Search explicitly for:

• "why X fails in practice"
• "X problems", "X merge conflicts", "X protocol fatigue"
• "X incident", "X postmortem", "X production failure"
• real-world failure case studies, not just theoretical objections
• compliance decay and ceremony fatigue when the recommendation involves multi-step protocols

This is not the same as checking for "other opinions." It is a targeted search for failure modes of the thing you are about to recommend. If you cannot find failure evidence, log it as a coverage gap, not as proof that there are no failures.

For multi-step mandatory protocols, estimate the per-step reliability and the compound chance that all required steps actually happen. Use rough ranges when exact measurement is unavailable. If the protocol only works under unrealistic compliance assumptions, flag it as a structural risk.

For append-only artifacts, recurring review rituals, or growing worklogs, estimate the breakpoint where quality or reliability degrades. Name a number or range when possible instead of saying only that it will "stop scaling."

Every material structural criticism must include at least one concrete alternative, mitigation, or simplification path. Criticism without an alternative is incomplete analysis.

Every contradiction must resolve to a decision impact, not just exist in a log:

• resolved -> adopt (evidence clearly favors one side)
• resolved -> watch (evidence favors one side but risk remains)
• resolved -> experiment (both sides have merit, needs hands-on testing)
• left uncertain (not enough evidence to resolve; state what would resolve it)

The contradiction log must change the decision table. If a contradiction does not affect any row in the decision table, either the contradiction is not material or the decision table is missing a relevant criterion.

7. Check source coverage and saturation.

Before writing the final memo, check:

• are all source classes covered (official, implementation, field/social, adversarial)?
• is any decisive claim supported by only one source?
• have community/practitioner sources been checked when the question involves workflows or adoption?
• if a source class is missing or inaccessible, log it as an explicit coverage gap

Do not use a fixed source count as the primary gate. The test is coverage saturation: would adding more sources likely change the conclusion? If yes, keep searching. If additional searches only produce paraphrases of what you already have, stop and write.

However, minimum floors still apply as a safety net:

• standard: do not stop below 4 sources
• deep: do not stop below 8 sources across at least 3 source classes
• long-run: do not stop below 12 sources across all 4 source classes

If the floor is met but saturation is not reached, keep searching. If saturation is reached below the floor, check whether a source class is missing before stopping.

For landscape-first passes, do not down-rank or drop a finding only because it is not immediately installable in the current project. First capture the ecosystem map, then decide which findings are:

• adopt now
• experiment
• watch
• not directly usable

An ecosystem scan fails if it only returns the directly adoptable leaves and misses the larger structures that explain where the market actually is.

8. Synthesize into a decision memo.

Before writing the decision sections, state your primary analytical thesis in 1-3 sentences. This is your own conclusion from the evidence, not a restatement of any single source. The thesis sets the frame for the rest of the memo. If you cannot state a thesis, the evidence may not be saturated yet.

Use:

• Options Compared when there are 2 or more serious options
• Decision Table when the pass is comparative
• Signal Assessment
• What Is True
• What Seems Used In Practice
• What Is Uncertain
• What Would Change The Conclusion
• Decision / Outcome
• Recommended Next Move
• Best Argument Against This Recommendation
• What Should Be Removed Or Simplified -> when the recommendation involves a protocol or multi-step design, explicitly ask: is this too heavy for v1? What can be cut without losing core value? What will die from ceremony fatigue?
• Source Layer Coverage
• Biggest Blind Spot / Missed Signals

For landscape-first passes, also include:

• Ecosystem Map
• Practical Shortlist
• What We Missed In The First Pass

If the pass recommends adoption, also preserve:

• Prerequisites
• Blast Radius
• Rollback / Escape Hatch

For high-stakes recommendations, also preserve:

• Differentiation Thesis
• Deterministic vs Generative Boundary
• Release Gates with measurable go/no-go thresholds when possible
• Language Policy including safe verbs, forbidden verbs, escalation triggers, not for lists, and fail-closed phrases such as unknown, cannot determine, or insufficient evidence
• User Misunderstanding Risk
• Segment Viability / Abandonment Risk

If the pass is inconclusive, say so explicitly instead of forcing an adoption verdict.

For deep and long-run passes, also include a compact evidence table or appendix with:

• key claim
• claim status
• source IDs or URLs (use inline clickable URLs, not just source IDs)
• strongest counter-source or unresolved objection

When the question touches enterprise adoption, privacy, compliance, or procurement, make Recommended Next Move concrete enough to survive a buyer conversation. It should not stop at vendor choice. Include the smallest viable procurement program when relevant:

• which agreements must be in place
• what logging / deletion / audit answer the team needs ready
• whether a subprocessor list or DPA packet is required
• whether AI disclosure or transparency obligations apply
• which control gaps remain your team's responsibility even if the vendor looks strong

For tool or ecosystem comparisons, also include a Layer Compatibility Matrix: a table of [layers x tools] with Y = native, P = partial, N = no, ? = unknown, and a short note per cell.

For deep and long-run passes, also include a Self-Evaluation section:

• source count and whether saturation was reached
• source class coverage (which of the 4 layers are represented)
• community/social source count (YouTube, Reddit, HN, X, Telegram, etc.)
• contradictions found and resolution status
• coverage gaps logged
• decisive primary/operative sources versus weaker directional sources
• overall confidence: high / moderate / low

9. Verify claims against sources.

Before declaring done, spot-check the 3-5 most consequential claims:

• re-read the source that backs each claim
• confirm the claim is actually supported, not just adjacent
• if a claim cannot be verified, downgrade its status or remove it

This step exists because LLM-generated citations are often imprecise or hallucinated. Do not skip it.

10. Promote only durable procedural deltas.

If the pass reveals a repeatable workflow:

• update the relevant project-owned skill, config, or catalog
• keep only the non-obvious reusable procedure
• do not promote hype, one-off preferences, or unstable rankings

Quality bar

• Every non-trivial claim must map to a source or be labeled as an inference.
• Separate date-sensitive facts from stable concepts.
• Use exact dates when freshness matters.
• Benchmarks count only if the method is inspectable.
• Stars, likes, and reposts are supporting evidence, not proof.
• Views, subscribers, likes, reposts, and follower counts are supporting evidence, not proof.
• Catalogs, marketplaces, and frameworks are not the same thing; label them correctly.
• If the answer is inconclusive, say so plainly.

Pricing discipline

When the question involves buying decisions, separate these price types and do not mix them:

• official MSRP: manufacturer's listed price; verify at the official product page
• current street price: what the product actually sells for today at retail; verify from a retailer, price tracker, or dated practitioner report
• used market price: what the product sells for second-hand; verify from a marketplace listing or dated community report
• regional price: location-specific pricing when it differs materially

For software, service, or adoption decisions, also separate direct vendor price from total cost of ownership:

• vendor or API price
• gateway / orchestration cost
• compliance and procurement cost (SOC 2, legal review, questionnaires, support plans)
• operational cost (on-call, logging, monitoring, incident response)

A recommendation must not rely on MSRP if the street price is materially different. If used pricing is relevant, state the source and date. If you cannot verify a price, label it unverified and do not build the recommendation on it.

Guardrails

• Do not collapse official truth, OSS enthusiasm, and operator lore into one bucket.
• Do not let one tweet, one Telegram post, or one curated list decide the outcome.
• Do not treat a YouTube walkthrough, conference talk, or creator demo as proof of real repeated adoption by itself.
• Do not cite README superiority claims as settled fact.
• Do not stop at "many people mention it"; find the backing artifact.
• Do not let an adopt-now filter erase the existence of broader ecosystems, platforms, or infrastructure layers.
• Do not mix up skill pack, skill ecosystem, agent platform, and RAG / backend infrastructure.
• Do not hide unresolved contradictions.
• Do not leave the result as a brainstorm. End with a decision.