Custom-deep-research — orchestrate, don't aggregate

Your job splits in three: compose a sharp brief, delegate the gathering, then interrogate what comes back. Never hand-roll your own research subagents alongside the harness — it fans out, fetches, and adversarially fact-checks internally; duplicating that is slower and unverified.

1. Compose the brief

Pick the template for the caller's focus and fill it from everything already learned (calibrate verdict, loaded context, clarify-intent answers if already gathered). A sharp brief is the difference between a focused report and a vague one — weave constraints and success criteria into the question itself.

Focus `product` (used by /create-specs — always full depth):

We are designing: <feature/product>, part of <OpenLatch enterprise control plane | SaferSkills
developer-led wedge> — two-motion strategy: SaferSkills free/public/dev-led, OpenLatch
paid/enterprise/CISO-led (buyer: CISO at 1000+ employee enterprises).
Context: <constraints, stack, timeline>. This succeeds if: <success criteria>.

Research and report on (note dates, cite sources):
1. Business context — how this market segment works today; who pays for what.
2. Value — what outcome users/buyers actually want here; willingness-to-pay signals.
3. State of the art — how leading products solve this; recent launches and lessons (dated).
4. Market & competitive analysis — direct/adjacent competitors, their approach, gaps we can own.

Focus `technical` (used by /create-plans):

We are implementing: <unit> in <repo> (<stack summary>).
Constraints: <repo conventions, schema-driven codegen, coverage gates, etc.>.

Research and report on (2026 state of the art, note dates, cite sources):
1. Recommended patterns/designs/frameworks for <domain>, with official-docs guidance.
2. Risks and anti-patterns — documented failure cases, each with a mitigation.
3. Key trade-offs where credible sources genuinely disagree.

Drop an item that doesn't apply; add one domain-specific item if the topic demands it (compliance, accessibility, pricing). One comprehensive call — the harness fans out internally.

2. Delegate

Invoke the `deep-research` skill with the brief as its arguments and let it run to completion.

3. Interrogate, then synthesize

You are the critical reviewer, not a forwarder:

• Test the evidence — are key claims backed by real, dated sources? Treat thin ones as unconfirmed and say so.
• Surface tensions — where the report contradicts itself or contradicts codebase/vault truth, name the conflict and take a position.
• Fill the gap — if one perspective that matters is missing, run ONE focused follow-up call on just that gap. Never re-run the whole brief.

Output — the synthesis block

RESEARCH SYNTHESIS (<focus>, <date>)
State of the art: …
Landscape: …            (market+competitors for product; frameworks+patterns for technical)
Existing foundations: … (what we already have in repo/vault to build on)
Risks & mitigations: …
Key trade-offs: …
Gaps & unknowns: …      (and whether they matter)
Sources: <the citations that carried weight>

Carry forward only conclusions that change the design — the caller gets the synthesis, not the raw report.