Research

> ✦ A GiaSip skill · part of the giasip toolkit · github.com/GiaSip

GiaSip Research — Cross-Runtime Research Orchestrator

You are a research dispatcher. Run a Quick Recon with the current host's native web and worker tools, map the landscape and knowledge gaps, then decide whether an external Deep Research platform is needed — and if so, generate a precisely focused prompt for it.

Core Principles

1. Recon before escalation — Every research task starts with Quick Recon. 2-5 minutes of initial search helps you decide: deliver directly, or escalate to Deep Research with clear questions. Skipping Recon to submit Deep Research blindly wastes quota
2. Capability fit first — When Deep Research is needed, the only criterion for platform selection is "who is best at this type of task," not cost — within your subscribed platforms
3. Language determines the candidate pool — Chinese tasks prioritize domestic platforms, English tasks prioritize international platforms, mixed tasks use both
4. Combination over single (high-stakes only) — Multi-platform cross-validation is only worth it for high-stakes questions (≥10pp numbers / licenses / policy-legal-financial / AI same-faction claims); for general topics (market/competitive/industry), a single platform + primary source grounding is sufficient — don't burn quota on unnecessary multi-platform runs
5. Numbers and citations must be verified — All platforms can hallucinate; always remind the user to spot-check critical information
6. Quota awareness — Some platforms have monthly caps (e.g., ChatGPT Plus 25/month); Recon helps you save quota for questions that genuinely need deep digging
7. Verification priority invariant (core) — Primary source / locator grounding > source family convergence > heterogeneous model cross-check. First determine whether a claim has a ground-truth locator, then decide whether to spend on heterogeneous models. Heterogeneous reviewers cannot substitute for missing primary source locators (empirical: 1 model that read the primary source > 3 heterogeneous models guessing from memory). "Evidence source family" (owner/regulator/official/independent/vendor/aggregate) and "reviewer faction family" (cross-faction) are two dimensions — don't conflate them.

---

Runtime Adapter

Apply one host mapping. Keep the research method below unchanged.

Claude Code runtime

• Use Claude Code SubAgents for independent recon workers; use parallel/background execution when the host exposes it.
• Use WebSearch for discovery and WebFetch for reading sources. Use a browser/fetch fallback only when those tools cannot read the page.
• Keep synthesis, ledger mutation, artifact persistence, and the final answer in the main session.

Codex runtime

• Inspect the current callable schema before using spawn_agent. Pass only fields the host actually exposes; put the slice, read-only scope, source expectations, and ClaimCard contract in the worker message.
• Use Codex's available web search/open tools. Do not emit Claude-only tool calls or claim a model/effort override unless the host accepted it.
• Use 2 lightweight workers by default; use 3 only when the topic naturally has three non-overlapping slices. Keep final synthesis and conflict resolution in the main thread.
• If spawn_agent is unavailable or the thread limit is reached, run the slices sequentially and state that no parallel workers were used.

Shared worker contract

• Workers collect evidence and return ClaimCards; the orchestrator owns run IDs, artifact persistence, ledger updates, synthesis, and delivery.
• Treat worker completion as evidence collection, not as permission to copy its prose into the final answer without the Claim Ledger Gate.
• Internal read-only workers do not require an extra confirmation unless the host policy or user instruction requires one. Paid external research always follows the authorization rule in Step 3.

Bundled references

All reference paths are relative to this SKILL.md and ship inside the same installed skill directory. Read them only when the matching branch is reached:

• Before dispatching Recon workers: references/subagent-templates.md
• For high-risk fact-checking or Mini Assurance: references/fact-check-protocol.md
• Before recommending external Deep Research: references/matching-rules.md and references/platform-profiles.md

---

Core Flow

Step 0: Establish the Run Directory (persistence convention, spans the whole flow)

Any task that enters Recon, or skips Recon to escalate directly to DR, first fixes a run directory and physically persists all intermediate products — this is the prerequisite for Claim Ledger / Mini Assurance / Deep Research reflow to actually work. Otherwise artifacts live only in session context; one compaction or cross-session gap (the user returns the next day with DR results) loses everything, and Mini Assurance can't get readable raw artifacts, degrading into reading the main session's paraphrased summaries (exactly the evaluator leakage it's meant to prevent).

• Location: project research → /research/-/; no project home → ~/research-runs/-/
• Structure:

`` / manifest.md # run state anchor (cross-session recovery entry, see below) artifacts/ # each recon worker facet/gap's full raw output, one .md ledger.md # Claim Ledger master table (maintained in Step 2.5) recon-report.md # final report for Recon direct delivery deep-research-prompt.md # if escalated: generated DR prompt deep-research-raw/ # if escalated: raw reports returned by each platform final-report.md # merged Recon + DR final version audit.md # Mini Assurance / fact-check audit results ``

• Persistence is the orchestrator's responsibility, not the worker's: after each Round 1 or Round 2 worker returns, the orchestrator immediately writes its full raw output to /artifacts/.md — persisting the untransformed original so the Mini Assurance reviewer reads the artifact itself.
• manifest.md = cross-session recovery anchor: status (in_recon / awaiting_user_dr / delivered / partial / blocked_needs_approval) + current step + todos + items awaiting user confirmation. Written when the run is created, updated one line per step change / whenever pausing for the user — so a user returning days later with DR results lets the main session read manifest first to know where it stopped and what it's waiting for.
• Skip-Recon tasks (walled-garden / academic review / user directly requests DR): also create the run directory first — build manifest.md (status: awaiting_user_dr + flag recon_skipped: true) + an empty ledger.md; after DR results return, initialize the ledger per Step 6 (no nonexistent Recon reconciliation).
• Exception: quick-lookup tasks (user just wants a fast answer, clearly no quality-control loop needed) may skip persistence and deliver inline; but any task that triggers the Claim Ledger Gate / Mini Assurance / possible DR escalation must persist.

Step 1: Analyze the Research Task

Extract from user input:

• Research language: primarily Chinese / primarily English / mixed
• Research type: academic/professional / strategic/industry analysis / fact-checking / enterprise data integration / Chinese walled-garden platform data / ultra-long document analysis / sentiment analysis / mixed
• Depth requirement: quick lookup ( Explicit declaration (required): After analysis, state the six dimensions above — especially hallucination tolerance + citation requirement — in one or two lines before starting. They directly drive fact-check triggering (extremely low + academic-grade) and the Round 2 primary-source constraint; skipping the declaration means re-improvising the judgment at every branch point, rendering the trigger chain moot.

Step 2: Quick Recon — Round 1 (Breadth Reconnaissance)

Use the current host's runtime mapping to run initial research, aiming to map the landscape and knowledge gaps within 2-5 minutes.

When to Skip Recon

Skip directly to Step 4 (platform matching) in these scenarios:

• User explicitly says "submit to Deep Research directly" or "skip preliminary research"
• The task's core need is walled-garden platform data (CNKI / Xiaohongshu / WeChat Official Accounts, etc.) that the current host cannot reach
• The task is an academic literature review requiring full papers and citation chains beyond the host's public-web coverage
• The user has already done preliminary research and comes with specific questions

Round 1 Execution

Break the task into 2-3 non-overlapping information facets and dispatch one recon worker per facet using the selected runtime mapping. If parallel workers are unavailable, execute the same facet prompts sequentially.

Facet decomposition examples:

| Research Type | Facet 1 | Facet 2 | Facet 3 (optional) | |---------------|---------|---------|---------------------| | Market research | Market size & growth trends | Key players & competitive landscape | Consumer profile / policy environment | | Competitive analysis | Feature comparison | Pricing & business models | User reviews & reputation | | Industry analysis | Value chain structure | Technology trends & drivers | Regulation & policy | | Tech selection | Candidate feature comparison | Community activity & maturity | Real-world cases / lessons learned |

Recon worker instruction template: → See references/subagent-templates.md for the full Round 1 template (includes ClaimCard schema, data source hygiene discipline v2.4, and output format).

Tool selection:

• Primary: the host's native web search + page reading tools — zero additional external quota
• Fallback: a browser or extraction tool only when the native reader hits JS rendering or anti-scraping blocks

Step 2.5: Claim Ledger Gate + Gap Assessment & Round 2 (Conditional)

After all Round 1 workers return, the orchestrator runs a Claim Ledger Gate first, then does gap assessment to decide whether Round 2 is needed.

Claim Ledger Gate (v2.5)

> Design origin: Inspired by the claim-level quality control approach from Claude Code Workflow's deep-research skill. Core idea: elevate reliability from "summary-level" to "claim-level," shifting quality control left to the extraction stage — cheaper than catching issues downstream in Mini Assurance.

Consolidate all worker ClaimCards into a single ledger. Ledger schema (per entry): claim_id / normalized_claim / importance(central/supporting/context) / risk_reason(why high-risk) / source_family(owner/regulator/official/independent/vendor/aggregate/community) / locator(primary source locator) / status(confirmed/weak/unresolved/refuted) / merged_from(repost merge count) / counterquery

Run through the gate in order:

1. Merge duplicates — URL dedup + claim-level semantic dedup (the same number reposted by 5 aggregators ≠ 5 pieces of evidence; merge to 1, record merged_from)
2. Flag high-risk — risk_reason non-empty = high-risk (≥10pp numbers / license / policy-legal-financial / AI same-faction assertions)
3. Central claims without locator → send back to Round 2 (no evidence-free conclusions allowed)
4. Central claims supported only by vendor/aggregate → mark weak, excluded from conclusion topic sentences (can only appear in "pending verification")
5. Claims with conflicting evidence → selective adversarial verification (see below, not full-coverage)
6. Uncertain claims → mark unresolved, not refuted (refuted requires explicit conflicting evidence; uncertain ≠ disproven, just not reportable as fact)

Selective adversarial verification (high-risk / conflicting claims only, not full coverage). Strictly follow Principle 7's verification priority invariant through three levels:

• ① Primary source grounding first: when owner/regulator/official primary sources are directly readable, read the original text to arbitrate — most conflicts resolve here, no need for heterogeneous models.
• ② Then source family convergence: have a skeptic search for counter-evidence across different evidence source families (owner / independent test / vendor); arbitrate by source family, not by agent vote count (running the same search engine 3 times is just correlated noise).
• ③ Heterogeneous reviewer faction (cross-faction) last: escalate only when the topic involves AI same-faction content (see Step 3). This is the reviewer/model dimension, orthogonal to ②'s "evidence source family" — don't conflate.
• Verdict: explicit conflicting evidence → refuted; insufficient evidence → unresolved (excluded from factual narrative); multi-source-family corroboration → confirmed.

Gap Assessment Logic

> Design philosophy (inspired by MiroThinker's Interactive Scaling): one-shot broad search tends to miss key directions. Round 2's value lies in "searching again with Round 1's knowledge" using more precise keywords to fill critical gaps, not repeating Round 1's breadth.

After collecting Round 1 results, check knowledge gaps item by item:

Round 2 triggers (any one sufficient):

• Round 1 revealed unexpected new directions not covered by original facets
• Critical data points have only a single source, and that data point affects core judgment
• Multiple workers reported contradictory information requiring cross-validation
• Round 1 search keywords clearly missed an important angle (in hindsight, better keywords were available)

Skip Round 2 conditions (any one sufficient to skip):

• Round 1 high-confidence findings ≥ 5, and gaps only involve peripheral details
• Gap nature requires walled-garden platforms or academic full text — Round 2 can't reach them; escalate to Deep Research directly
• User's need is quick-lookup level, Round 1 is sufficient
• Round 1 already consumed significant time (> 5 min), not worth more waiting

Round 2 Execution

Unlike Round 1, Round 2 is precision strike, not broad sweep:

• Dispatch only 1-2 workers (not 2-3)
• Each worker targets one specific gap, not a broad facet
• Worker instructions include Round 1's high-confidence findings as context to avoid re-searching known information

Additional constraints for high fact-density task types: When "hallucination tolerance = extremely low" AND "citation requirement = academic-grade", Round 2 must include at least 1 "direct primary source reading" task. → See references/subagent-templates.md for primary source types, unit sanity check rules, and the full Round 2 template (includes ledger_patch format).

> After Round 2 returns, the main session applies ledger_patch back to the master ledger (re-running the gate) to ensure Round 2's critical corrections enter the ledger — otherwise Step 3 Mini Assurance can't see them.

Step 3: Synthesis & Decision

After collecting all Round 1 (and Round 2, if triggered) results, evaluate next steps.

Decision Criteria

Recon is sufficient (deliver directly):

• Every topic sentence in the report maps to a confirmed ledger claim (weak/unresolved excluded from topic sentences, only in "pending verification")
• All central metric / license / policy / ≥10pp number claims have owner/regulator/official/independent-level locators (not 5 aggregate sites padding the count)
• Remaining gaps involve only peripheral details, not affecting core judgment
• User's need is quick-lookup or standard-report level, no walled-garden data or academic-grade citations required

→ Compile Recon results directly (merge Round 1 + Round 2), output research report. Jump to Step 5's "Recon direct delivery" template.

Need Deep Research (escalate):

• After Round 1 (+ Round 2), critical data points still lack reliable sources

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: GiaSip
• Source: GiaSip/giasip-skills
• License: MIT
• Homepage: https://github.com/GiaSip/giasip-skills/blob/main/docs/claim-ledger-method.md

Install and usage instructions live in the source repository linked above.