deep-research · diff
git:20260715.8644be9 to git:20260723.6e5370b
63 added, 27 removed. Audit A to A.
---
name: deep-research
- description: Produce an approved deep-research brief from bounded research, synthesis, and governed packaging.
+ description: Produce a decision-ready deep-research brief from bounded governed evidence and preserve every material source binding.
runx:
category: research
---
- # Deep Research Brief
-
- This graph turns one important question into a decision-ready brief.
+ # Deep Research
- It is for research that needs more than a quick answer but less than an open-
- ended report. The output should feel like an operator memo: what the answer is,
+ Turn one important question into a durable operator brief: what the answer is,
what evidence supports it, what remains uncertain, and what posture the reader
- should take next.
+ should take next. Use this when a quick answer is too shallow but an open-ended
+ report would obscure the decision.
- Do not drift into a generic article, daily update, or trend recap. The point is
- to help a human decide, not to narrate that research happened.
+ The output should feel like a thoughtful memo, not a narration of the research
+ process. It leads with the decision and operational implication, then exposes
+ the evidence, inference, alternatives, and unresolved questions that justify
+ that posture.
- Separate verified evidence from inference and carry unresolved questions into
- the memo. The synthesis must say what the reader should monitor, do, defer, or
- investigate next. Return `needs_more_evidence` when the packet cannot support a
- recommendation, and `not_worth_publishing` when the answer is sound but does not
- matter to the stated decision.
+ ## When to use it
- ## Output
+ Use `deep-research` for architecture choices, market or ecosystem questions,
+ product bets, trust decisions, or other consequential analysis that needs a
+ reader-ready synthesis. Use plain `research` when the evidence packet itself is
+ the desired artifact. Use `content-pipeline` when the primary outcome is public
+ content for a known channel.
- - `research_packet`: bounded evidence, confidence, inference, and open questions.
- - `brief_draft`: the decision memo synthesized from that packet.
- - `approval_decision`: review of the exact brief and its remaining uncertainty.
- - `publish_packet`: approved brief and delivery metadata.
+ Do not use this skill for an unbounded literature review, a daily trend recap,
+ or research whose sources have not been fetched through a governed reader.
- ## Inputs
+ ## How the chain works
- - `objective` (optional): specific question the brief should answer.
- - `audience` (optional): primary reader for the memo.
- - `channel` (optional): final delivery channel; defaults to `brief`.
- - `domain` (optional): product, ecosystem, or market slice to bound the work.
- - `operator_context` (optional): local decision context or evaluation lens.
- - `target_entities` (optional): structured list of products, projects,
- companies, or repos to keep in scope.
+ 1. The caller supplies the exact question, audience, and governed source
+ packets, normally produced by `web-fetch` or a provider reader.
+ 2. The canonical `research` skill admits and indexes those sources, separates
+ evidence from inference, and verifies every citation and recommendation.
+ 3. Only a ready research packet proceeds to `ghostwrite`. The writing stage
+ turns decision support into a clear brief without introducing unsupported
+ facts.
+ 4. The final artifact preserves the research and content packet bindings. It
+ remains local and is not a publication claim.
+
+ Local research and drafting need no approval because they do not cross an
+ external boundary. If the brief is later sent, posted, or published, the
+ provider delivery skill owns approval, idempotency, acknowledgement, and
+ readback.
+
+ ## Inputs and result
+
+ - `objective` is the exact decision question.
+ - `source_packets` are bounded governed evidence; operator context, URLs, and
+ model memory do not substitute for them.
+ - `audience` and `channel` shape the memo's presentation.
+ - `domain`, `operator_context`, and `target_entities` keep the analysis scoped
+ but do not count as evidence.
+
+ The result contains the citation-validated `research_packet` and, when evidence
+ is ready, the evidence-bound `content_draft_packet`. It may finish at
+ `needs_more_evidence` or `not_worth_publishing` rather than manufacture a memo.
+
+ ## Stop conditions
+
+ - Stop before drafting when no valid source survives research admission.
+ - Preserve uncertainty that could change the recommendation.
+ - Do not turn operator preference into a verified market or product fact.
+ - Do not add a publish or delivery state to a local brief.
+ - Route any outward action to its owning provider skill with the exact artifact
+ digest and evidence packet intact.
+
+ ## Example
+
+ For “Should this provider become a native Runx tool?”, the source set might
+ include its official API contract, two existing consumer implementations, and
+ runtime measurements. The brief should recommend native ownership, package
+ ownership, or no change; show which evidence supports that boundary; and name
+ the remaining operational risk. It should not become a generic provider profile
+ or imply adoption merely because the API exists.