Conduct independent primary research on a single technical claim from 4 dimensions, complementing the inline verification of /design:
- /design: inline verification during the plan-building process (verifying whether existing citations in the plan are sufficient)
- /evidence-check: independent post-hoc deep investigation (conducting primary multi-source research on any claim, not relying on an existing pipeline)
Methodological basis: the four EBSE evidence categories (Kitchenham et al., 2004), ITIL CMDB Reconciliation, DAMA-DMBOK Completeness
Step 0: Cost Confirmation (HITL)
This skill launches 2 parallel subagents to conduct a deep investigation, which consumes a relatively high number of tokens. Use AskUserQuestion to confirm:
About to launch a 4-dimension parallel investigation (2 subagents); estimated additional token consumption is approximately 16,000-30,000. Investigation subject: [summary from $ARGUMENTS] (independent deep investigation, unlike the inline verification of /design)
- Continue — launch investigation
- Cancel — end the process
If Cancel is selected, end the process.
Step 1: Parse the Claim and Dimension Manifest
1a. Standardize the claim
Extract the technical claim to be verified from $ARGUMENTS and restate it in one sentence:
Claim to be verified: [standardized technical claim]
1b. Build a dimension tracking table
Before launching the subagents, build a list of expected items; after the investigation is complete, fill in the three columns "Status / Confidence / Primary Basis" in Step 4b:
| Dimension | Investigation scope | Status | Confidence | Primary Basis |
|---|---|---|---|---|
| D1: Academic research | Related papers, benchmarks, experimental data (arXiv, IEEE, ACM) | PENDING | — | — |
| D2: Industry standards | Standards documents such as RFC, W3C, OWASP, ITIL, NIST | PENDING | — | — |
| D3: Best practices | Official guidance, canonical patterns of well-known libraries, production cases | PENDING | — | — |
| D4: Community consensus + dissenting opinions | GitHub discussions, SO, Reddit, official forum | PENDING | — | — |
Step 2: Assemble Subagent Context
According to the EBSE evidence categories (Kitchenham et al., 2004), divide the 4 dimensions into 2 groups:
- Formal Sources (Group A): D1 academic + D2 industry standards — formally published or standardized sources
- Practitioner Sources (Group B): D3 best practices + D4 community — practitioner experience and collective wisdom
Subagent A prompt(Formal Sources)：
你是一個證據評估助理。請對以下主張搜集正式來源的證據。
主張：{CLAIM}
D1 學術研究：
- 使用 WebSearch 搜尋學術文獻(arXiv、IEEE、ACM、Google Scholar)
- 回報：論文標題、ID/DOI、年份、關鍵發現、與主張的相關性
- 若無學術文獻，明確聲明 "NOT-FOUND"，不可用不相關論文填充
D2 業界標準：
- 搜尋 RFC、OWASP、W3C、NIST、ITIL、12-Factor 等標準
- 回報：標準名稱、版本、章節、如何適用
每個維度須回傳：
- status: FOUND | NOT-FOUND | PARTIAL
- confidence: HIGH | MEDIUM | LOW(LOW = 僅間接相關，HIGH = 直接引用主張)
- sources: [來源清單，含 URL 或 DOI]
- summary: 2-3 句摘要
Subagent B prompt(Practitioner Sources)：
你是一個證據評估助理。請對以下主張搜集實踐者來源的證據。
主張：{CLAIM}
D3 最佳實踐：
- 搜尋官方文件、canonical pattern、生產案例
- 回報：來源、版本、pattern 描述
D4 社群共識+反面意見：
- 搜尋 GitHub discussions、Stack Overflow(高票答案)、Reddit、官方 forum
- 特別搜尋反面意見：「X considered harmful」、migration guides(說明為何放棄某做法)
- 回報：來源 URL、票數/星數、立場(FOR / AGAINST / NUANCED)、核心論點
每個維度須回傳：
- status: FOUND | NOT-FOUND | PARTIAL
- confidence: HIGH | MEDIUM | LOW
- sources: [來源清單，含 URL]
- summary: 2-3 句摘要
Step 3: Launch Subagents in Parallel
Launch 2 subagents simultaneously; place both Agent() calls in the same message to achieve parallelism:
Agent(subagent_type="general-purpose", model="haiku")
— prompt: Subagent A context(D1 學術 + D2 業界標準)
Agent(subagent_type="general-purpose", model="haiku")
— prompt: Subagent B context(D3 最佳實踐 + D4 社群共識)
Merge rules:
- Wait for both subagents to complete
- Merge the results of the 4 dimensions into a unified dimension table
- If a subagent returns a format that does not match expectations, mark that dimension as NO-DATA (do not interrupt the process)
- Update the Status column of the dimension Manifest in Step 1b (PENDING -> FOUND / NOT-FOUND / PARTIAL / NO-DATA)
Step 4: Conflict Detection and Verdict
4a. Cross-dimension conflict analysis
Identify each aspect of the claim from the merged results, and for each aspect compare the stances across the 4 dimensions:
| Conflict point | D1 Academia | D2 Industry standards | D3 Best practices | D4 Community | Verdict |
|---|---|---|---|---|---|
| [Claim aspect A] | ... | ... | ... | ... | AGREE / PARTIAL / CONFLICT / NO-DATA |
| [Claim aspect B] | ... | ... | ... | ... | ... |
Verdict definitions (based on ITIL CMDB Reconciliation):
- AGREE: All dimensions with data point in the same direction
- PARTIAL: The majority agree, but one dimension raises reservations or lacks data
- CONFLICT: At least two dimensions actively contradict each other
- NO-DATA: Fewer than two dimensions have data on that aspect
For each CONFLICT verdict, write a conflict description:
- What the conflict is about
- Which dimension's evidence is stronger (based on recency, citation count, official status)
- Whether this conflict is a known debate or context-dependent
4b. Complete the dimension tracking table
Fill in the "Status" (FOUND / NOT-FOUND / PARTIAL), "Confidence" (HIGH / MEDIUM / LOW), and "Primary basis" columns of the Step 1b table.
4c. Overall Verdict
Based on dimension coverage and conflict analysis, determine one of the following:
| Verdict | Condition |
|---|---|
| WELL-SUPPORTED | 3-4 dimensions FOUND + conflict table all AGREE or PARTIAL |
| CONDITIONALLY-SUPPORTED | 2+ dimensions FOUND, at least one PARTIAL, no CONFLICT |
| WEAKLY-SUPPORTED | Only 1 dimension FOUND or the majority NOT-FOUND |
| CONFLICTED | The conflict table has at least one CONFLICT verdict |
| INSUFFICIENT-EVIDENCE | 3+ dimensions NOT-FOUND or NO-DATA |
Disclaimer: WELL-SUPPORTED does not mean absolutely correct -- subagents use the same base model and may have systematic blind spots (arXiv:2509.18970). Please verify the URLs and quotations of key sources yourself.
4d. /design-compatible output
Generate a table that can be pasted directly into a /design plan:
Industry & Standards Reference：
| Technical decision | Reference basis | Type | Source |
|---|---|---|---|
| [Claim] | [D1/D2 source] | Academic research / Industry standards | [URL/DOI] |
Community Consensus & Dissenting Views：
| Technical decision | Community consensus | Dissenting opinions/Known pitfalls | Source |
|---|---|---|---|
| [Claim] | [D4 FOR stance summary] | [D4 AGAINST stance summary] | [URL] |
4e. Report persistence (optional)
Use AskUserQuestion to ask:
Should the full report be written to plans/active/evidence-.md?
- Write — persist for later reference
- Do not write — show only in the conversation
Slug generation rules: take kebab-case from the claim text, prefix with evidence-, maximum 60 characters.