# Deep Tech Research > Build Chinese prose-first, evidence-led deep-tech research and technical due diligence with independently calibrated research scope (S1-S3) and explanation depth (D1-D4). Use for pure technology or route analysis, company-level technical analysis with a mandatory financing-and-ownership appendix, team-capability-transfer analysis, full public technology-system studies, or technical work intended to support performance, cost, commercial, or investment decisions. Cover mechanisms, metrics, engineering maturity, scale-up constraints, competition, falsification, evidence tracing, and optional evidence-gated scoring without forecasting financial returns. Use doc-format only when the user explicitly requests Word/DOCX (Office Open XML Document, Word document format). - Skill: `twinklezhang/deep-tech-research` (Agent Skill, multi-file: 12 files) - Install (CLI): `npx skillmds@latest add twinklezhang/deep-tech-research` - Raw SKILL.md: https://api.skillmd.com/api/skills/twinklezhang/deep-tech-research/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: TwinkleZHANG (https://skillmd.com/u/twinklezhang) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/twinklezhang/deep-tech-research --- # Deep Tech Research ## 1. Route the research object before searching Classify every request into exactly one research object type: 1. **Technology analysis**: analyze a technology, scientific route, platform, or technical field without treating any company as the report subject. 2. **Company analysis**: analyze a named company using company-level products, performance, customers, engineering evidence, and external comparisons. 3. **Team-transfer company analysis**: complete the company analysis and add a separate team-capability-transfer module when the trigger is met. Do not replace the company analysis with founder biography. Record the selected type at the start of the report. Do not force company products, financing, shareholders, or company-specific conclusions into a technology analysis. A company or laboratory name in the request does not by itself determine the object. Use technology analysis when the subject is its public technical corpus or architecture and company execution, customers, ownership, and company-relative performance are outside scope. Use company analysis when the conclusion evaluates that entity's actual products, performance, customers, engineering execution, commercial capability, or competitive position. ## 2. Load only the references required by the route - Always read `references/research-workflow-and-evidence.md` and `references/report-modes-and-acceptance.md` before research. - Read `references/scope-depth-and-decision-translation.md` whenever the selected scope is S3, the selected depth is D3/D4, the intended use is commercial/investment decision-making, or the deliverable is a multi-document research library. - Read `references/public-technology-system-evidence.md` whenever official repositories, model hubs, open weights, public infrastructure, organization activity feeds, or open-source/reproducibility claims are material evidence. - Read `references/maturity-profiles.md` whenever evaluating engineering, manufacturing, deployment, clinical, regulatory, reliability, or scale maturity. - For every company analysis, including S1 and summary delivery, read `references/capital-and-ownership-appendix.md` and place the required financing-and-ownership appendix at the end. - After freezing the new-company evidence set, read `references/team-capability-transfer.md` only if its trigger is met or the user explicitly requests a transfer analysis. - Read `references/scoring-protocol.md` only when the user explicitly requests numerical scores, ratings, ranking, or a scored comparison. Qualitative evaluation is the default. - Use `doc-format` only when the user explicitly requests Word/DOCX output. Formatting must not change facts, evidence labels, section logic, or conclusions. ## 3. Lock object, scope, depth and identity Before retrieval, record: - research object type; - research scope: S1, S2, or S3; - explanation depth: D1, D2, D3, or D4; - delivery mode: summary, standard report, or research library; - research purpose, decision question, and intended reader; - target application, use environment, and system boundary; - technology version or product generation; - for companies: exact legal entity, brand relationship, geography, and relevant subsidiaries; - research cutoff date and evidence boundary; - role of code, model weights, raw data, and implementation artifacts; - included and excluded questions. Use scope to control **how much of the system is covered**: - **S1 Targeted**: one technical question, mechanism, product module, company claim, or decision gate, including only directly implicated dependencies. - **S2 Core system**: the decision-critical causal chain, representative alternatives, engineering bottlenecks, and material evidence gaps. - **S3 Panoramic**: the complete relevant technology system, genealogy, major branches, interfaces, public boundaries, and source universe requested by the user. Use depth to control **how far each covered item is explained**: - **D1 Understanding**: what it is, why it exists, how it broadly works, and which problem it solves. - **D2 Decision**: inputs/outputs, causal mechanism, metrics, boundary, trade-offs, engineering consequences, unit resource or cost, decision implications, evidence, and falsifiers. - **D3 Implementation**: add data/tensor/material flow, train-versus-run behavior, parameters, process conditions, hardware dependencies, and targeted code or implementation evidence. - **D4 Reproduction**: add environment, data, configuration, code, weights or materials, experiment procedure, benchmark protocol, failure diagnosis, and an explicit reproduction result or boundary. Default generic deep research and technical due diligence to **S2-D2**. Use **S1-D2** for a single named question. Use **S3-D2** when the user requests the complete technology system, full stack, or “everything” about a technical subject. Escalate to D3 for implementation questions and to D4 only for an explicit reproduction request. Do not infer D3 or D4 merely from “deep,” “complete,” or “full report.” Record selective escalation, for example `overall S3-D2; decisive mechanism C-02 at D3`. Delivery mode changes presentation, not research scope or depth: - **Summary**: one-page, quick view, committee memo, or key points; - **Standard report**: default coherent report; - **Research library**: multiple reports, source catalogues, glossaries, evidence ledgers, or maintained knowledge bases. A summary can still be S3-D2, and a long report can still be S1-D3. Do not use page count, file count, or formatting as a proxy for scope or depth. ## 4. Research before writing Use this execution sequence; do not use the final report headings as the search order: `object and S/D contract -> scope and identity -> decisive claim map -> source discovery -> evidence ledger -> counterevidence search -> comparability check -> evidence freeze -> object/profile decision -> analysis -> writing -> acceptance` Build a small set of decision-critical claims, usually three to seven, chosen by causal importance rather than quota. For each claim, identify what would support it, what would falsify it, and what evidence is missing. Draft the report only after the decisive evidence set and major conflicts are visible. If new evidence changes a decisive claim, reopen the affected evidence set and downstream analysis. Do not merely patch the prose. ## 5. Apply the common analytical chain For each decisive technical conclusion, explain: `problem -> mechanism -> metric -> system boundary -> design choice -> trade-off -> engineering consequence -> supporting and opposing evidence` At D2 and above, include unit-level cost, energy, mass, throughput, yield, reliability, compute, memory, bandwidth, or other resource constraints when they determine technical viability. For commercial or investment decision use, extend the chain without turning the report into a financial forecast: `engineering consequence -> performance variable -> unit resource/cost -> product or commercial variable -> observable verification signal -> falsifier` Separate technical feasibility, measured performance, production economics, product value, and commercial inference. Do not forecast company revenue, profit, valuation, market share, security price, or investment return. Select foundational work, frontier results, competitors, and metrics by causal coverage, source quality, and research saturation. Do not pad the report to satisfy arbitrary item counts. Explain material omissions when the evidence set is unusually narrow. ## 6. Enforce claim and evidence discipline Use four claim labels when the distinction matters: - `[事实]`: directly supported fact, number, date, identity, or observed result; - `[披露]`: a company, customer, investor, or other source's claim that lacks independent verification; - `[推断]`: analyst synthesis derived from cited premises and an explicit reasoning chain; - `[预测]`: forward-looking scenario based on a reference class, stated assumptions, time window, falsifier, and confidence. Cite factual premises and reported claims directly. For a synthesis, cite the evidence set and show the reasoning; do not attach one loosely related source to make the conclusion appear externally proven. For a forecast, state the reference class, assumptions, sensitivity, and evidence that would overturn it. Keep the following rules absolute: 1. **No company-metric imputation**: never fill a missing company performance, capacity, compute, yield, cost, or product parameter with peer data, industry averages, financing, headcount, or model inference. Present peer ranges only as `行业参考范围（非公司数据）`; never place them in the company's comparison cell or use them for company ranking, maturity, or scoring. Allow only transparent deterministic calculations from disclosed inputs, with formula, units, assumptions, and the label `派生计算`. 2. **Missing is not negative**: absence of public evidence cannot produce a low score, laggard label, low maturity, failed product, or nonexistence claim. Distinguish `已证明落后` from `尚不可见`. 3. **Source role follows the claim**: company-originated papers and patents may prove what the company or team produced or claimed. They may enter field history as primary data points. Independent sources must establish frontier significance, reproducibility, comparative superiority, or broad adoption. 4. **Patents are not performance tests**: patents can support inventorship, ownership claims, filing scope, or technical intent; they cannot alone prove performance, production readiness, defensibility, or freedom to operate. 5. **One evidence chain counts once**: syndicated media, repeated versions, related papers/code/patents, and a shared financing narrative do not become independent confirmation merely through repetition. 6. **Seek disconfirmation**: actively search for replication failures, negative trials, retractions or corrections, recalls, certification failures, customer failures, structural counterexamples, and credible alternative routes. When an official organization interface exposes member research or community activity, preserve the observation but classify its attribution strength. Visibility on an official channel does not automatically prove institutional authorship, adoption, ownership, or production use. Follow `references/public-technology-system-evidence.md` when this issue is material. ## 7. Keep financing and ownership in a sealed appendix For every company analysis, include `附录A：融资与股东架构` as the final substantive section and follow `references/capital-and-ownership-appendix.md`. Treat the appendix as descriptive, fact-bound, and analytically isolated: - do not use financing amount, investor prestige, valuation, shareholder identity, or control structure as evidence of mechanism validity, product performance, relative technical position, engineering maturity, growth headroom, or technical scoring; - do not cite an appendix conclusion as a premise in the technical body; - do not infer compute, equipment, headcount, data, production capacity, or milestone completion from financing amount; - place any explicit technical-resource agreement in the main evidence ledger only if independently documented as an operating fact, not because an investor or financing round exists. Every company report must include the appendix even when financing or ownership evidence is limited. Use an evidence-gap statement rather than omitting it. Technology analyses do not include this appendix unless the user separately asks for company capital information. ## 8. Treat team transfer as a separate special module For team-transfer company analysis, insert `特别模块：团队能力迁移` after the new-company evidence and current-state section. Complete the normal company analysis before and after it. The special module must separately maintain: - a historical-capability ledger; - a new-company evidence ledger; - contribution attribution; - transferable, conditionally transferable, non-transferable, and unknown assets; - team and operating-resource reassembly evidence; - the current CTS (Capability Transfer Stage, capability-transfer stage) and the next unmet gate; - upside, base, and downside scenarios with falsifiers and decisive milestones. Do not let historical capability raise the company's relative position, maturity, or score without new-company evidence. Do not use financing or shareholder signals to determine CTS. Keep the mandatory financing-and-ownership appendix separate. ## 9. Use domain-appropriate maturity profiles Do not use NASA TRL (National Aeronautics and Space Administration Technology Readiness Level, technology readiness level) as a universal maturity proxy. Select the relevant profile in `references/maturity-profiles.md` and assess multiple axes such as technical demonstration, reproducibility, reliability, manufacturing or deployment, quality, regulatory status, supply chain, and customer environment. Use TRL only as one axis when it fits the technology. State the evidence for the highest completed milestone; do not infer maturity from company age, funding, hiring, plans, or a demo label. ## 10. Use the correct report profile ### Technology analysis Cover the target problem and boundary, bottom-layer mechanism and metrics, causal genealogy, current routes and disputes, engineering maturity and scale constraints, ceiling and alternatives, strongest counterevidence, risks, falsifiers, and decisive next questions at the selected S/D level. Do not add company financing or shareholder sections. ### Company analysis Cover the technology core, external route map, company products and claims, comparable performance, customer or external validation, current maturity and engineering bottlenecks, relative position and differentiation, growth boundary and alternative routes, risks, falsifiers, and due-diligence questions. End with the mandatory financing-and-ownership appendix. ### Team-transfer company analysis Complete the company profile, add the separate team-transfer module, and end with the mandatory financing-and-ownership appendix. Base current company position only on new-company evidence. Follow the detailed ordering and acceptance rules in `references/report-modes-and-acceptance.md`. ## 11. Keep evaluation qualitative unless scoring is requested Default to a bounded qualitative conclusion that states what is established, what is only reported, what is inferred, what is forecast, the strongest counterevidence, and what would change the conclusion. When scoring is explicitly requested: - separate route-level scientific evaluation from company-level implementation evaluation; - use E0-E4 only for company evidence maturity and assign it separately to each company claim family; - use `NR (Not Rated, 暂不评分)` when a relevant dimension fails evidence admission; - use `N/A (Not Applicable, 不适用)` only when a dimension is logically inapplicable; - require affirmative negative evidence for a low score; - do not create totals, weighted averages, or rankings from `NR`; - do not draw a radar chart when any required dimension is `NR`; - exclude the financing-and-ownership appendix and CTS from all technical scores. ## 12. Write and validate the deliverable Write in Chinese prose first, retaining important English terminology. Define every professional English abbreviation on first use. Use tables only for naturally repeated fields or truly comparable values; explain why the dimensions were selected before a table and what the table means afterward. Do not use empty tables or placeholder text. Default to Markdown or plain text. Generate a DOCX file only when explicitly requested and then use `doc-format` on the final approved content. Keep decision-facing prose, detailed mechanisms, and evidence/implementation artifacts in separate layers when their audiences differ; do not force readers to inspect code or raw evidence to understand the conclusion. Before delivery, apply the acceptance matrix in `references/report-modes-and-acceptance.md`. If a Markdown report is saved locally, run: ```powershell python scripts/lint_report.py --object-type technology|company|team-transfer --scope S1|S2|S3 --depth D1|D2|D3|D4 ``` For chat-only output, perform the same checks manually. Do not claim completion while any mandatory item is `FAIL`. When the user requests handoff to an independent investment-judgment agent, create a neutral input manifest containing only the evidence actually needed for the next stage. Record evidence ID (Identifier, 标识符), material type, relative path, version or date, and cutoff date; include a SHA-256 (Secure Hash Algorithm 256-bit, 256-bit secure hash algorithm) digest when locking a formal package. Exclude user investment preferences and prior advisor or red-team conclusions.