Research Synthesis

Manual triggers:

• "synthesize my research" / "整合研究結果"
• "write a decision doc" / "寫決策文件"
• "what should we do based on the research?"
• "summarize findings and recommend"
• "ADR" / "architecture decision record"

Prompted by other skills:

• After brainstorming Phase 3 invokes tech-feasibility and/or critical-research — synthesis aggregates before returning to design
• After running narrative-auditor + codebase-audit on the same topic — findings need reconciliation

Do NOT use when:

• Only one research skill was run (its own output is sufficient)
• The user wants raw research, not a decision
• The question is simple enough that a single skill already answered it

Workflow

Phase 1: Inventory Research Findings

Scan the current conversation for outputs from research skills. Identify each by its distinctive structure:

If findings are from a previous session, ask the user to paste or provide the relevant outputs.

Minimum requirement: 2 distinct research outputs. If only 1 exists, inform the user: "Only one research source found. Its conclusion stands on its own — synthesis adds value when there are multiple sources to reconcile."

Phase 2: Normalize Verdicts

Map each skill's verdict system to a common schema:

Phase 3: Identify Conflicts and Agreements

Create a findings matrix:

## Findings Matrix

| Topic / Claim | critical-research | tech-feasibility | narrative-auditor | codebase-audit | Consensus |
|--------------|-------------------|------------------|-------------------|----------------|-----------|
| [Claim A] | Confirmed (Strong) | — | — | — | Single source |
| [Claim B] | Confirmed (Mod) | Confirmed (Strong) | — | — | Agreement |
| [Claim C] | Challenged (Weak) | Confirmed (Strong) | — | — | **Conflict** |

For each conflict:

1. State what each source found
2. Assess why they disagree (different scope? different evidence?)
3. Determine which source is more authoritative for this specific claim
4. Document the resolution rationale

Phase 4: Weigh Evidence and Decide

Apply evidence hierarchy:

1. Direct verification (codebase-audit ran the code) > Indirect analysis (critical-research cited papers)
2. Primary sources (narrative-auditor checked originals) > Secondary sources (summaries, articles)
3. Reproducible evidence (tests, benchmarks) > Theoretical arguments
4. Specific evidence (about this exact case) > General evidence (about similar cases)

When evidence is evenly split, state the uncertainty explicitly rather than forcing a false conclusion.

Phase 5: Generate Decision Document

Produce an ADR-style document:

# Decision: [Title]

**Date**: YYYY-MM-DD
**Status**: Proposed | Accepted | Superseded by [link]
**Decision makers**: [user / team]

## Context

[What prompted this research? What question needed answering?]

## Research Conducted

| Skill | Focus | Verdict | Confidence |
|-------|-------|---------|------------|
| critical-research | [topic] | [normalized] | [High/Medium/Low] |
| tech-feasibility | [topic] | [normalized] | [High/Medium/Low] |
| ... | ... | ... | ... |

## Findings

### Agreements
<!-- Claims confirmed by 2+ sources -->

### Conflicts and Resolutions
<!-- Disagreements with explicit resolution rationale -->

### Uncertainties
<!-- Claims that remain unresolved -->

## Decision

[Clear, actionable statement of what we decided and why.]

## Consequences

### Expected Benefits
- [Benefit traced to evidence]

### Known Risks
- [Risk traced to evidence]

### Open Questions
- [What we still don't know]

## Alternatives Considered

| Alternative | Why Rejected | Source |
|-------------|-------------|--------|
| [Option B] | [Reason] | [Which skill found this] |

Phase 6: Review and Save

1. Present the draft to the user
2. Iterate until approved
3. Save to docs/decisions/YYYY-MM-DD-<topic>.md
4. Commit with message: docs(decisions): add <topic> decision record
5. Transition based on context:
   • If called from brainstorming → return to brainstorming with the decision as input for design
   • If standalone → done, or suggest superpowers:writing-plans if implementation follows

Examples

Example 1: Technology Choice After Multiple Research Skills

Context: User ran tech-feasibility on Redis vs. Memcached, then critical-research on "Redis is always faster than Memcached for session storage."

WRONG:

"tech-feasibility says Go for Redis. critical-research says the 'always faster' claim is Partially Supported. So Redis is probably fine." (No conflict resolution, no decision document)

RIGHT:

"Synthesizing research findings into a decision document."

1. Inventories: tech-feasibility (Go, High confidence for Redis) + critical-research (Partially Supported — Redis is faster for reads but Memcached wins on multi-threaded write loads)
2. Identifies conflict: tech-feasibility assumed read-heavy workload; critical-research found write-heavy counter-evidence
3. Resolves: "Our session store is 90% reads, 10% writes — Redis's read advantage applies to our case"
4. Produces ADR with clear "Decision: Use Redis" + risk note about write-heavy growth scenario

Example 2: Claim Verification Across Sources

Context: User ran narrative-auditor on a vendor's blog post claiming "99.9% uptime", then codebase-audit on the vendor's SDK docs.

RIGHT:

1. narrative-auditor: "99.9% uptime" rated DECONTEXTUALIZED (only applies to US-East region)
2. codebase-audit: SDK docs claim "automatic failover" rated FALSE (no failover code found in SDK)
3. Synthesis: "Vendor uptime claim is region-limited and their SDK lacks the failover they advertise. Recommendation: require SLA contractually, implement our own failover."

Rationalization Prevention

Red Flags — STOP

• You're writing a decision without citing which skill produced the evidence → every claim needs attribution
• You resolved a conflict by ignoring one side → go back and explain why one source outweighs the other
• Your "synthesis" is just the research outputs pasted in sequence → that's concatenation, not synthesis
• You recommended an option without listing alternatives → document what was rejected and why

Writing Tone（暖色調語氣指南）

決策文件的敘述段落應帶有溫度，像在跟同事分享觀察。分析判斷段落維持客觀。

1. 對話式口吻 — 適度用「你」拉近距離，不說教
2. 問句引導節奏 — 用問句推進思路，特別適合段落開頭。例如「那這些研究結果放在一起看，告訴我們什麼？」
3. 具體案例錨定 — 每個論點有具體人名、產品、數據支撐，不說空話
4. 坦誠面對不確定 — 用「值得注意的是...」「目前看來...」保留探索空間，不武斷定調
5. 段落短、呼吸快 — 一個段落一個觀點，短句收尾
6. 引用是為了對話 — 引述後接「這點呼應了...」「但換個角度看...」，不堆砌
7. 開放式收束 — 結尾留下問題或延伸方向

適用範圍：Executive Summary、Narrative synthesis、Recommendation rationale。Evidence matrix、conflict resolution 表格維持客觀中性。

Constraints

• Minimum 2 research sources — don't synthesize a single output
• Every claim traced to a source — no unsourced assertions
• Conflicts must be resolved explicitly — no silent omissions
• ADR format — all decision documents follow the template
• Save to docs/decisions/ — consistent location
• Short by default — minor decisions: 1 page; major: 2 pages max

Error Handling

Only One Research Source Available

• Inform the user that synthesis requires 2+ sources
• Suggest running an additional research skill, or confirm that the single source's conclusion is sufficient

Research Findings Are Stale (From a Prior Session)

• Ask the user to paste relevant outputs
• Flag that evidence may be outdated if the codebase or external context has changed since the research was conducted
• Consider re-running research skills if findings are older than 2 weeks

All Sources Agree (No Conflicts)

• Synthesis is still valuable: it produces a formal decision record
• Note the agreement explicitly: "All N sources converge on the same conclusion, increasing overall confidence"
• Keep the document shorter since conflict resolution is unnecessary

Irreconcilable Conflict

• When two sources directly contradict with equal authority, do not force a resolution
• Present both positions clearly and recommend the user make a judgment call, or suggest a PoC / experiment to break the tie
• Document: "This conflict could not be resolved from available evidence. Recommended next step: [experiment / expert consultation]"

Security Considerations

Decision Document Content

• Decision documents may reference proprietary architecture or vendor evaluations — remind the user if the repo is public
• Do not include API keys, credentials, or pricing details verbatim from research outputs
• Sanitize vendor names or internal project names if the document will be shared externally

Evidence Integrity

• Do not modify or paraphrase research findings in ways that change their meaning — quote or summarize faithfully
• If a research skill's output was ambiguous, flag the ambiguity rather than resolving it silently

File Path Safety

• Sanitize filenames: strip characters outside [a-z0-9-]
• Validate docs/decisions/ exists before writing; create if missing

Related Skills

• critical-research — upstream: provides falsification-first verdicts
• tech-feasibility — upstream: provides Go/No-Go technology assessments
• narrative-auditor — upstream: provides per-claim accuracy verdicts
• codebase-audit — upstream: provides documentation accuracy scores
• assumption-extractor — upstream: provides structured assumption inventories with verification status and risk classification
• micro-poc-validator — upstream: provides empirical evidence (PASS/FAIL/PARTIAL) for specific technical assumptions
• research-cross-validator — upstream: provides multi-strategy cross-validation results with per-claim consensus ratings
• brainstorming — caller: invokes research skills in Phase 3, then synthesis before returning to design
• tech-research-pipeline — orchestrator: invokes synthesis as the final phase (Phase 7) to produce the decision document
• deep-reading — parallel methodology: synthesis reconciles multiple research outputs; deep-reading reconstructs thinking from multiple documents. Different goals, similar multi-source input.
• superpowers:writing-plans — downstream: once a decision is made, plan the implementation