tech-deconstructor
Systematically deconstructs complex technical innovations (research papers, RFCs, system architectures, software designs) into a rigorous 4-part analytical breakdown.
4-Part Analytical Framework
Every technical deconstruction MUST follow this exact structure:
[1. Problem & Pain Points] ──> [2. Candidate Options & Tradeoffs]
│
[4. Empirical Results & Impact] <── [3. Chosen Architecture & Rationale]
| Section |
Key Analytical Focus |
| 1. Problem & Motivation |
Core bottlenecks, failure modes of existing approaches, and fundamental tradeoffs (e.g. Memory vs. Speed, Accuracy vs. Token cost). |
| 2. Candidate Options & Tradeoffs |
2–4 alternative candidate solutions evaluated during discovery. Include pros, cons, and explicit reasons for rejection. |
| 3. Chosen Architecture & Rationale |
Detailed breakdown of the selected solution, key technical components, data flows, and WHY it was chosen over alternative candidates. |
| 4. Empirical Results & Outcomes |
Quantifiable metrics, benchmark performance, resource savings, and real-world impact. |
Execution Steps
Step 1 — Gather Source Materials
- Read the target paper, article, codebase, or technical description.
- Identify the core innovation, baseline approaches, candidate alternatives, and reported metrics.
Step 2 — Structure the Analysis
Write the deconstruction following the exact template below.
Output Template
# 🔬 Technical Deconstruction: [Title / Subject]
## 1. 🎯 想解決的問題 (Problem & Motivation)
[Detailed explanation of the core technical bottleneck or inefficiency.]
- **核心痛點 (Core Pain Points)**:
- 1. **[Pain Point 1]**: [Detail]
- 2. **[Pain Point 2]**: [Detail]
- **基本拉鋸 (Fundamental Tradeoffs)**: [e.g., Latency vs. Accuracy, Context Window vs. Cost]
---
## 2. ⚖️ 候選解決方案與權衡 (Candidate Options & Tradeoffs)
[Candidate A] ──> [Rejection Reason / Bottleneck]
[Candidate B] ──> [Rejection Reason / Bottleneck]
[Candidate C] ──> [Chosen Solution]
| 候選方案 (Option) | 優點 (Pros) | 缺點 / 評估結論 (Cons & Status) |
|---|---|---|
| **方案 A: [Option A Name]** | [Pros] | ❌ **[Rejected Reason]** |
| **方案 B: [Option B Name]** | [Pros] | ❌ **[Rejected Reason]** |
| **方案 C: [Option C Name]** | [Pros] | ✅ **[Selected Solution]** |
---
## 3. 🏗️ 最終選擇的架構與理由 (Chosen Architecture & Rationale)
[High-level overview of why Option C was selected as the optimal architecture.]
### 核心組件與工作流程 (Core Components & Workflow)
```mermaid
graph TD
A["[Input / Trigger]"] --> B["[Core Component 1]"]
B --> C["[Core Component 2]"]
C --> D["[Output / Action]"]
- 1. [Component 1 Name]: [Explanation of how it works and why it solves Pain Point 1]
- 2. [Component 2 Name]: [Explanation of how it works and why it solves Pain Point 2]
- 3. [Component 3 Name]: [Explanation of how it works]
4. 📊 實測效果與數據 (Empirical Results & Impact)
- [Metric 1]: [Quantifiable outcome, e.g. +25% Pass Rate]
- [Metric 2]: [Resource saving, e.g. -60% Token Consumption]
- [Metric 3]: [Error reduction, e.g. -50% Type/Syntax Errors]
---
## Guidelines
1. **Be Specific, Not Generic**: Avoid hand-waving explanations. Include concrete technical terms, algorithms, data structures, and protocol names.
2. **Explicit Rejection Reasons**: Section 2 must clearly state *why* alternative options were rejected.
3. **Quantitative Metrics**: Section 4 must feature empirical numbers, benchmark deltas, or resource savings whenever data is available.
1---2name: tech-deconstructor3description: Deconstruct any research paper, technical proposal, system architecture, or engineering concept into a structured 4-part analytical breakdown: Problem & Motivation, Candidate Options & Tradeoffs, Chosen Solution & Rationale, and Empirical Results. Trigger whenever the user asks to 'deconstruct this paper', 'analyze this technical concept like CodeNib', 'deep dive into [paper/RFC/architecture]', 'break down this technical proposal', or requests a structured 4-part breakdown (problem, options, solution, results) of a technical innovation.4---56# tech-deconstructor78Systematically deconstructs complex technical innovations (research papers, RFCs, system architectures, software designs) into a rigorous 4-part analytical breakdown.910---1112## 4-Part Analytical Framework1314Every technical deconstruction MUST follow this exact structure:1516```17[1. Problem & Pain Points] ──> [2. Candidate Options & Tradeoffs]18 │19[4. Empirical Results & Impact] <── [3. Chosen Architecture & Rationale]20```2122| Section | Key Analytical Focus |23|---|---|24| **1. Problem & Motivation** | Core bottlenecks, failure modes of existing approaches, and fundamental tradeoffs (e.g. Memory vs. Speed, Accuracy vs. Token cost). |25| **2. Candidate Options & Tradeoffs** | 2–4 alternative candidate solutions evaluated during discovery. Include pros, cons, and explicit reasons for rejection. |26| **3. Chosen Architecture & Rationale** | Detailed breakdown of the selected solution, key technical components, data flows, and WHY it was chosen over alternative candidates. |27| **4. Empirical Results & Outcomes** | Quantifiable metrics, benchmark performance, resource savings, and real-world impact. |2829---3031## Execution Steps3233### Step 1 — Gather Source Materials34- Read the target paper, article, codebase, or technical description.35- Identify the core innovation, baseline approaches, candidate alternatives, and reported metrics.3637### Step 2 — Structure the Analysis38Write the deconstruction following the exact template below.3940---4142## Output Template4344```markdown45# 🔬 Technical Deconstruction: [Title / Subject]4647## 1. 🎯 想解決的問題 (Problem & Motivation)48[Detailed explanation of the core technical bottleneck or inefficiency.]4950- **核心痛點 (Core Pain Points)**:51 - 1. **[Pain Point 1]**: [Detail]52 - 2. **[Pain Point 2]**: [Detail]53- **基本拉鋸 (Fundamental Tradeoffs)**: [e.g., Latency vs. Accuracy, Context Window vs. Cost]5455---5657## 2. ⚖️ 候選解決方案與權衡 (Candidate Options & Tradeoffs)5859```60[Candidate A] ──> [Rejection Reason / Bottleneck]61[Candidate B] ──> [Rejection Reason / Bottleneck]62[Candidate C] ──> [Chosen Solution]63```6465| 候選方案 (Option) | 優點 (Pros) | 缺點 / 評估結論 (Cons & Status) |66|---|---|---|67| **方案 A: [Option A Name]** | [Pros] | ❌ **[Rejected Reason]** |68| **方案 B: [Option B Name]** | [Pros] | ❌ **[Rejected Reason]** |69| **方案 C: [Option C Name]** | [Pros] | ✅ **[Selected Solution]** |7071---7273## 3. 🏗️ 最終選擇的架構與理由 (Chosen Architecture & Rationale)7475[High-level overview of why Option C was selected as the optimal architecture.]7677### 核心組件與工作流程 (Core Components & Workflow)78```mermaid79graph TD80 A["[Input / Trigger]"] --> B["[Core Component 1]"]81 B --> C["[Core Component 2]"]82 C --> D["[Output / Action]"]83```8485- **1. [Component 1 Name]**: [Explanation of how it works and why it solves Pain Point 1]86- **2. [Component 2 Name]**: [Explanation of how it works and why it solves Pain Point 2]87- **3. [Component 3 Name]**: [Explanation of how it works]8889---9091## 4. 📊 實測效果與數據 (Empirical Results & Impact)9293- **[Metric 1]**: [Quantifiable outcome, e.g. +25% Pass Rate]94- **[Metric 2]**: [Resource saving, e.g. -60% Token Consumption]95- **[Metric 3]**: [Error reduction, e.g. -50% Type/Syntax Errors]9697---98```99100---101102## Guidelines1031041. **Be Specific, Not Generic**: Avoid hand-waving explanations. Include concrete technical terms, algorithms, data structures, and protocol names.1052. **Explicit Rejection Reasons**: Section 2 must clearly state *why* alternative options were rejected.1063. **Quantitative Metrics**: Section 4 must feature empirical numbers, benchmark deltas, or resource savings whenever data is available.
allanbian1017