Initial commit

2025-11-29 18:19:41 +08:00
commit 0b8462a252
8 changed files with 1222 additions and 0 deletions
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -0,0 +1,12 @@
 {
  "name": "deep-reading-framework",
  "description": "Three-pass critical reading framework for systematic document analysis",
  "version": "1.0.0",
  "author": {
    "name": "devkade",
    "email": "zhongweili@tubi.tv"
  },
  "skills": [
    "./"
  ]
 }
--- a/README.md
+++ b/README.md
@@ -0,0 +1,3 @@
 # deep-reading-framework
 Three-pass critical reading framework for systematic document analysis
--- a/SKILL.md
+++ b/SKILL.md
@@ -0,0 +1,235 @@
 ---
 name: deep-reading-framework
 description: Three-pass critical reading framework for systematic document analysis. Supports tech blogs, retrospectives, technical documentation, personal writing, and academic papers. Primary focus on Third Pass critical analysis, context validation, and actionable reconstruction. Use when analyzing complex documents, performing critical reading, extracting actionable insights, or conducting deep analysis. Triggers include Third Pass, 비판적 분석, critique, 깊이 읽기, 심층 분석.
 ---
 # Deep Reading Framework
 A systematic approach to deep document analysis based on the three-pass reading methodology. This skill guides critical analysis with emphasis on Third Pass: assumption validation, context dependencies, and actionable reconstruction.
 ## Overview
 This skill provides structured guidance for Third Pass critical analysis of documents. Users complete First and Second Pass independently (reading, understanding, note-taking), then use this skill for deep critical analysis that challenges assumptions, identifies context dependencies, and extracts actionable insights.
 ## Quick Start
 **Typical workflow:**
 1. User reads document and completes First/Second Pass independently
 2. User triggers skill: "Third Pass 시작" or "이 글 비판적으로 분석해줘"
 3. Skill detects document type automatically
 4. Guides systematic critical analysis
 5. Outputs structured analysis compatible with user's template
 ## Document Type Detection
 Automatically detect and adapt analysis to document type based on content, structure, vocabulary, and writing style.
 **Supported types:**
 - **tech-blog**: Technical articles, tutorials, engineering posts (problem-solution structure, code examples)
 - **retrospective**: Project retrospectives, experience sharing, lessons learned (temporal narrative, reflective tone)
 - **technical-doc**: API documentation, architecture docs, specifications (reference structure, technical precision)
 - **personal-writing**: User's own drafts, essays, thought pieces (exploratory tone, argument structure)
 - **academic-paper**: Research papers, scholarly articles (abstract, methods, citations)
 **Detection approach:**
 1. Analyze content markers (abstract, code blocks, section headings)
 2. Identify vocabulary patterns (academic vs conversational, technical depth)
 3. Assess structure (sequential vs reference vs argumentative)
 4. If ambiguous, ask: "이 문서는 [TYPE1] 또는 [TYPE2] 중 어느 것에 가까운가요?"
 ## Third Pass Workflow
 Follow these steps systematically:
 ### Step 1: Document Type Confirmation
 State the detected type and confirm with user:
 "이 문서를 [TYPE]로 판단했습니다. Third Pass 비판적 분석을 시작할까요?"
 ### Step 2: Critical Analysis
 Challenge core claims and validate reasoning.
 **Universal questions (all types):**
 - What are the central claims or messages?
 - What evidence or reasoning supports them?
 - What are potential weaknesses or limitations?
 - What counterexamples or failure cases exist?
 - Is this generalizable or context-specific?
 **Load type-specific questions:** Read `references/critical-questions.md` for detailed questions per document type.
 Output format:
 ```markdown
 #### Critical Analysis
 - **주장의 약점 / 적용 한계**
  - [Specific issues with claims, evidence, or reasoning]
  - [Scenarios where this approach fails]
  - [Generalization limits]
 ```
 ### Step 3: Context Dependencies
 Identify implicit assumptions that constrain validity.
 **Key dimensions:**
 - **Technical environment**: Stack, tools, scale, constraints
 - **Prerequisites**: Assumed knowledge or experience level
 - **Temporal context**: When written, evolving technologies
 - **Cultural/organizational**: Team structure, company culture, regional factors
 Output format:
 ```markdown
 - **컨텍스트 의존성 (환경, 스택, 시기)**
  - Environment: [Tech stack, scale, constraints that this assumes]
  - Prerequisites: [What reader needs to know/have]
  - Temporal: [Time-dependent assumptions]
  - Cultural: [Organizational or regional assumptions]
 ```
 ### Step 4: Missing Perspectives
 Find gaps, alternatives, and unexplored angles.
 **Look for:**
 - Alternative approaches not mentioned
 - Trade-offs or costs not discussed
 - Contrary viewpoints or debates
 - Edge cases or exceptions
 - Relevant references or prior work not cited
 Output format:
 ```markdown
 - **누락된 관점 / 대안**
  - Alternatives: [Other approaches not considered]
  - Trade-offs: [Costs or sacrifices not discussed]
  - Contrary views: [Opposing perspectives]
  - Edge cases: [Scenarios not addressed]
 ```
 ### Step 5: Reconstruction
 Demonstrate deep understanding by restating core ideas without reference to source.
 **Tasks:**
 - Summarize key concepts in own words
 - Explain the approach as if teaching someone
 - Identify what applies to your context
 - Consider how you would approach differently
 Output format:
 ```markdown
 #### Reconstruction
 - **핵심을 나만의 언어로**
  - [Restate the central thesis and key supporting ideas without looking at source]
 - **내 상황에 적용한다면**
  - 직접 적용: [What can be adopted as-is]
  - 변형 필요: [What needs modification and how]
  - 적용 불가: [What doesn't fit my situation and why]
 ```
 ### Step 6: Actionable Insights
 Extract practical value and next steps.
 **Focus on:**
 - Immediate takeaways
 - Limitations to remember
 - Follow-up questions or experiments
 - Related areas to explore
 - Actions to take
 Output format:
 ```markdown
 #### Discussion
 - **가져갈 것**
  - [Most valuable insights - what to remember and apply]
 - **한계**
  - [Boundaries of applicability, remaining uncertainties]
 #### Action Items
 - [ ] [Specific action item or research question]
 - [ ] [Related concept to explore]
 #### Future Ideas
 - [ ] [Experiment to validate understanding]
 ```
 ## Interactive Guidance
 Guide user through analysis with checkpoints:
 **After type detection:**
 "[TYPE]로 분석을 시작합니다. 이 유형에 맞는 비판적 질문을 적용하겠습니다."
 **After each major step:**
 "[STEP] 완료했습니다. 다음 단계([NEXT_STEP])로 진행할까요, 아니면 이 부분을 더 깊이 탐구할까요?"
 **When user seems uncertain:**
 "특정 섹션이나 주장에 대해 더 자세히 분석하고 싶으신 부분이 있나요?"
 ## On-Demand Support
 Provide targeted assistance beyond Third Pass:
 **Second Pass support:**
 - "이 그림/표가 정확히 무엇을 의미하는지 도와줘"
 - "핵심 주장과 증거를 정리해줘"
 **Contextual research:**
 - "관련 논문/글 찾아줘"
 - "이 접근법을 사용한 다른 사례는?"
 **Concept clarification:**
 - "이 용어/개념이 정확히 무엇을 의미하는지 설명해줘"
 - "이 가정이 타당한지 검증해줘"
 **Comparison:**
 - "이 글과 [[다른글]] 비교 분석해줘"
 - "이 두 접근법의 차이는 무엇인가?"
 ## Best Practices
 **For optimal results:**
 1. **Complete First/Second Pass independently** - Have basic understanding before critical analysis
 2. **Provide context** - Share your background, goals, or specific concerns
 3. **Be specific** - Point to particular sections or claims for focused analysis
 4. **Iterate** - Refine sections that need deeper exploration
 5. **Connect to practice** - Always consider real-world applicability
 **When to use this skill:**
 ✅ After reading complex technical content
 ✅ When evaluating whether to adopt an approach
 ✅ Before citing or building upon an article
 ✅ When reviewing your own writing for gaps
 ✅ During literature review or research
 **When NOT to use:**
 ❌ For quick skimming or surface reading
 ❌ When basic comprehension is sufficient
 ❌ For simple reference lookups
 ## Progressive Disclosure
 For complex analysis needs:
 1. **Start with SKILL.md** - Core workflow and guidance
 2. **Load references as needed**:
   - `references/critical-questions.md` - Type-specific analytical questions
   - `references/reconstruction-guide.md` - Detailed reconstruction techniques
   - `references/common-patterns.md` - Frequently encountered patterns and pitfalls
 3. **Use assets for output** - Standard templates for consistent formatting
 ## Notes on Output
 - Match user's existing template structure when provided
 - Use bullet points with bold headings for clear structure
 - Keep analysis concise but thorough
 - Focus on actionable insights over abstract critique
 - Prioritize practical applicability
--- a/assets/analysis-template.md
+++ b/assets/analysis-template.md
@@ -0,0 +1,204 @@
 # Third Pass Analysis Template
 Use this template structure for consistent Third Pass analysis output.
 ## Standard Format
 ```markdown
 ### Third-Pass
 #### Critical Analysis
 - **주장의 약점 / 적용 한계**
  - [Specific weakness 1: explain the issue]
  - [Specific weakness 2: where this approach fails]
  - [Generalization limits: boundaries of applicability]
 - **컨텍스트 의존성 (환경, 스택, 시기)**
  - Environment: [Tech stack, scale, constraints assumed]
  - Prerequisites: [Knowledge, tools, or resources required]
  - Temporal: [Time-sensitive assumptions or dated information]
  - Cultural: [Organizational, regional, or domain-specific factors]
 - **누락된 관점 / 대안**
  - Alternatives: [Other approaches not explored]
  - Trade-offs: [Costs or sacrifices not discussed]
  - Contrary views: [Opposing arguments or debates]
  - Edge cases: [Scenarios not addressed]
 #### Reconstruction
 - **핵심을 나만의 언어로**
  - [Restate the central thesis and key supporting ideas]
  - [Explain the logical flow or architecture]
  - [Capture the "why" behind the approach]
 - **내 상황에 적용한다면**
  - 직접 적용: [What can be adopted as-is, why it fits]
  - 변형 필요: [What needs modification, how to adapt it]
  - 적용 불가: [What doesn't fit, why not, what to do instead]
 #### Discussion
 - **가져갈 것**
  - [Most valuable insights to remember and apply]
  - [Specific actions or changes to make]
 - **한계**
  - [Boundaries of applicability]
  - [Remaining questions or uncertainties]
  - [Situations where caution is needed]
 #### Action Items
 - [ ] [Specific action item or experiment to try]
 - [ ] [Related concept or document to explore]
 - [ ] [Validation step before applying]
 #### Future Ideas
 - [ ] [Follow-up research or investigation]
 - [ ] [Related question to explore]
 ```
 ## Variation for Tech Blog
 ```markdown
 ### Third-Pass
 #### Critical Analysis
 - **Technical Limitations**
  - Problem scope: [What problems this doesn't solve]
  - Scale considerations: [Where performance/complexity becomes issue]
  - Trade-offs: [What's sacrificed for benefits gained]
 - **Implementation Context**
  - Stack requirements: [Languages, frameworks, tools needed]
  - Prerequisites: [Existing infrastructure or knowledge]
  - Assumed scale: [Team size, user load, data volume]
 - **Alternatives & Edge Cases**
  - Simpler approaches: [When to use something simpler]
  - Alternative solutions: [Other ways to solve this]
  - Edge cases: [Scenarios where this breaks]
 #### Reconstruction
 - **Technical Approach**
  - [Explain the solution architecture in own words]
 - **Applying to My Stack**
  - 직접 적용: [Components that transfer as-is]
  - 변형 필요: [What to modify for my environment]
  - 다른 접근: [Where I'd do something different]
 #### Discussion
 - **Worth Adopting**
  - [Specific techniques or patterns to use]
 - **Watch Out For**
  - [Gotchas, anti-patterns, or risks]
 #### Action Items
 - [ ] Test with small prototype
 - [ ] Benchmark against current approach
 - [ ] Read [related article/docs]
 ```
 ## Variation for Retrospective
 ```markdown
 ### Third-Pass
 #### Critical Analysis
 - **Context Specificity**
  - Team context: [What's unique about their team/org]
  - Situational factors: [Circumstances that affected outcomes]
  - Generalizability: [Where lessons may not apply]
 - **Success Factors**
  - What they controlled: [Decisions and actions]
  - What they didn't: [Luck, timing, external factors]
  - Key enablers: [What made success possible]
 - **Unstated Lessons**
  - Reading between lines: [Implicit insights]
  - Missing perspectives: [Other team members' views]
  - Survivorship bias: [What about failed attempts?]
 #### Reconstruction
 - **Key Lessons**
  - [Core takeaways in own words]
 - **Relevance to My Situation**
  - 직접 적용: [Lessons that transfer to my context]
  - 변형 필요: [How to adapt for my situation]
  - 적용 불가: [What's too context-specific]
 #### Discussion
 - **Actionable Insights**
  - [Changes to make based on this]
 - **Caveats**
  - [Limitations of lessons learned]
 #### Action Items
 - [ ] Apply [specific practice] on next project
 - [ ] Validate [assumption] in my context
 - [ ] Discuss with team
 ```
 ## Variation for Academic Paper
 ```markdown
 ### Third-Pass
 #### Critical Analysis
 - **Methodological Issues**
  - Design limitations: [Threats to validity]
  - Sample issues: [Size, representativeness, bias]
  - Alternative explanations: [Other ways to interpret results]
 - **Assumptions & Scope**
  - Theoretical assumptions: [Framework dependencies]
  - Boundary conditions: [Where findings don't apply]
  - Generalizability: [Population, setting, time]
 - **Research Gaps**
  - Missing variables: [What wasn't considered]
  - Unexplored angles: [Related questions not asked]
  - Future work: [What needs investigation]
 #### Reconstruction
 - **Research Contribution**
  - [Main findings and their significance]
 - **Application to Practice**
  - 실무 적용: [How this informs real-world decisions]
  - 후속 연구: [Follow-up studies this enables]
  - 내 연구: [How this relates to my work]
 #### Discussion
 - **Key Findings**
  - [Most important results]
 - **Limitations**
  - [Validity threats and boundaries]
 #### Action Items
 - [ ] Replicate with [different population/setting]
 - [ ] Extend to [related phenomenon]
 - [ ] Address [limitation] in future study
 ```
 ## Usage Notes
 **Adapt the template:**
 - Not every section is needed for every document
 - Combine sections when appropriate
 - Add subsections for complex analysis
 - Use bullet points with bold headings for clear structure
 **Maintain consistency:**
 - Use same structure across similar documents
 - This enables easy comparison later
 - Makes it easier to find information
 **Be concise but complete:**
 - Each point should be specific and actionable
 - Avoid vague statements
 - Include enough context to understand later
--- a/plugin.lock.json
+++ b/plugin.lock.json
@@ -0,0 +1,61 @@
 {
  "$schema": "internal://schemas/plugin.lock.v1.json",
  "pluginId": "gh:devkade/collaborator:skills/deep-reading-framework",
  "normalized": {
    "repo": null,
    "ref": "refs/tags/v20251128.0",
    "commit": "2f8d9e6cea7c66a7d21ad0d7beb8a0d4305bc1e0",
    "treeHash": "cb725581cdaf03954357094f5feabc97e9b1e1ea098ff6fe4edab57ed40f70aa",
    "generatedAt": "2025-11-28T10:16:19.382453Z",
    "toolVersion": "publish_plugins.py@0.2.0"
  },
  "origin": {
    "remote": "git@github.com:zhongweili/42plugin-data.git",
    "branch": "master",
    "commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
    "repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
  },
  "manifest": {
    "name": "deep-reading-framework",
    "description": "Three-pass critical reading framework for systematic document analysis",
    "version": "1.0.0"
  },
  "content": {
    "files": [
      {
        "path": "README.md",
        "sha256": "88c3df0473e07ce6bb52a102ad3190119b0945f5cf25a55d0cbb66a02a13a17c"
      },
      {
        "path": "SKILL.md",
        "sha256": "0ec0304cb19e76fda791f3459374418934b402650d7e40322ead7f9079e31590"
      },
      {
        "path": "references/reconstruction-guide.md",
        "sha256": "1fba134e51f3a704b665e78abf4c44296ff6f3685282446f374b7304515e8e1b"
      },
      {
        "path": "references/critical-questions.md",
        "sha256": "458a2273970449ee09a629412dc763a6d8449f0662f059c575168326d2fe62da"
      },
      {
        "path": "references/common-patterns.md",
        "sha256": "4a1ec87fd9798f6af11bc5f4b621a6614638bb854406bf9ee45a822c8c0c468c"
      },
      {
        "path": ".claude-plugin/plugin.json",
        "sha256": "104357585ec3eab21524c171978740f66a869b02205ba68c363d5cb5f46d18a4"
      },
      {
        "path": "assets/analysis-template.md",
        "sha256": "56db6ae765633bde8bf4ea3da5f833fcbda841f9a1e5c533baebdc1a7c002c40"
      }
    ],
    "dirSha256": "cb725581cdaf03954357094f5feabc97e9b1e1ea098ff6fe4edab57ed40f70aa"
  },
  "security": {
    "scannedAt": null,
    "scannerVersion": null,
    "flags": []
  }
 }
--- a/references/common-patterns.md
+++ b/references/common-patterns.md
@@ -0,0 +1,300 @@
 # Common Patterns and Pitfalls
 This reference catalogs frequently encountered patterns in documents and common analytical pitfalls to avoid.
 ## Document Patterns
 ### Persuasive Techniques to Recognize
 **Authority Appeals:**
 - Pattern: "As [expert/company] does..."
 - Watch for: Cherry-picked examples, ignoring context differences
 - Question: Does their context match yours?
 **Bandwagon Effects:**
 - Pattern: "Everyone is moving to..."
 - Watch for: Exaggeration of adoption, ignoring failures
 - Question: What's the actual evidence? Who's not adopting and why?
 **Complexity Hiding:**
 - Pattern: "Simply do X" or "Just Y"
 - Watch for: Downplaying difficulty, ignoring prerequisites
 - Question: What's the real complexity? What could go wrong?
 **False Dichotomies:**
 - Pattern: "Either X or Y"
 - Watch for: Missing middle ground, other alternatives
 - Question: What other options exist?
 **Survivorship Bias:**
 - Pattern: Success stories without failure context
 - Watch for: Missing information about what didn't work
 - Question: How many tried and failed? What's the selection bias?
 ### Structural Patterns
 **Problem-Solution-Benefit:**
 - Common in tech blogs and marketing
 - Watch for: Problem exaggeration, solution oversimplification
 - Verify: Is problem real? Is solution complete?
 **Before-After:**
 - Common in retrospectives and case studies
 - Watch for: Overfitting to specific context, ignoring other factors
 - Verify: What else changed? Is causation clear?
 **Theory-Evidence-Conclusion:**
 - Common in academic and analytical writing
 - Watch for: Evidence cherry-picking, logical leaps
 - Verify: Is evidence representative? Does conclusion follow?
 ## Analytical Pitfalls
 ### Confirmation Bias
 **Pattern:** Looking for information that confirms existing beliefs
 **How it manifests:**
 - Focusing on supporting evidence while ignoring contradictions
 - Interpreting ambiguous information favorably
 - Remembering hits and forgetting misses
 **Counter-strategy:**
 - Actively seek disconfirming evidence
 - Steelman opposing views
 - Ask "What would prove me wrong?"
 ### Dunning-Kruger Effect
 **Pattern:** Overestimating understanding of complex topics
 **How it manifests:**
 - Thinking you understand after superficial reading
 - Missing subtle complexities
 - Overconfidence in applying concepts
 **Counter-strategy:**
 - Try to teach it to someone
 - Attempt implementation
 - Identify what you don't know
 ### Availability Heuristic
 **Pattern:** Overweighting easily recalled examples
 **How it manifests:**
 - Recent experiences seem more relevant
 - Vivid examples dominate thinking
 - Common cases seem universal
 **Counter-strategy:**
 - Seek statistical baselines
 - Look for quiet counterexamples
 - Question representativeness
 ### Hindsight Bias
 **Pattern:** "I knew it all along" after seeing outcomes
 **How it manifests in retrospectives:**
 - Outcomes seem more inevitable than they were
 - Overlooking genuine uncertainty at decision time
 - Undervaluing decisions that happened to work out
 **Counter-strategy:**
 - What was known at decision time?
 - What uncertainties existed?
 - What could have gone differently?
 ### Context Collapse
 **Pattern:** Ignoring contextual constraints and factors
 **How it manifests:**
 - "Why don't they just..."
 - Assuming your context matches author's
 - Missing organizational/cultural factors
 **Counter-strategy:**
 - Map explicit context: stack, scale, team, timeline
 - Identify implicit context: expertise, resources, constraints
 - Consider counter-factuals: what if context differed?
 ## Content-Specific Patterns
 ### Tech Blog Patterns
 **"Magic Solution" Pattern:**
 - Presents one approach as universal answer
 - Reality: Every approach has trade-offs
 - Ask: When does this NOT work?
 **"Works on My Machine" Pattern:**
 - Success in specific environment
 - Reality: May not generalize
 - Ask: What's special about this environment?
 **"Premature Optimization" Pattern:**
 - Complex solution to simple problem
 - Reality: Simpler approaches often sufficient
 - Ask: What's the simplest approach that works?
 ### Retrospective Patterns
 **"Hero's Journey" Pattern:**
 - Obstacles → Struggles → Triumph
 - Reality: Often luck, timing, or missing context
 - Ask: What role did circumstances play?
 **"Lessons Learned" Pattern:**
 - Lists of takeaways
 - Reality: May be overgeneralized
 - Ask: What contexts do these apply to?
 **"If I Knew Then" Pattern:**
 - Advice from hindsight
 - Reality: Knowledge wasn't available then
 - Ask: What was actually knowable?
 ### Technical Documentation Patterns
 **"Happy Path Only" Pattern:**
 - Documents ideal use cases
 - Reality: Edge cases and errors matter
 - Ask: What can go wrong?
 **"Assumes Expert" Pattern:**
 - Missing prerequisite knowledge
 - Reality: Users have varying backgrounds
 - Ask: What's assumed as known?
 **"Version Lag" Pattern:**
 - Documentation trails implementation
 - Reality: Features changed, docs didn't
 - Ask: Is this current? What changed?
 ### Academic Paper Patterns
 **"Novel Technique" Pattern:**
 - Emphasizes novelty
 - Reality: May be incremental or narrow
 - Ask: What's genuinely new vs repackaged?
 **"Statistical Significance" Pattern:**
 - p < 0.05 therefore important
 - Reality: Statistical ≠ practical significance
 - Ask: What's the effect size? Does it matter?
 **"Future Work" Pattern:**
 - Lists limitations as future work
 - Reality: May indicate fundamental flaws
 - Ask: Are these minor gaps or major issues?
 ## Red Flags
 Watch for these warning signs:
 **Credibility Issues:**
 - Anonymous or unclear authorship
 - No sources for bold claims
 - Credentials don't match domain
 - Conflicts of interest not disclosed
 **Methodological Issues:**
 - Unreproducible steps
 - Missing crucial details
 - Cherry-picked results
 - No discussion of alternatives
 **Logical Issues:**
 - Circular reasoning
 - False dichotomies
 - Correlation → causation
 - Generalizing from single case
 **Practical Issues:**
 - "Just trust me" explanations
 - Missing costs or trade-offs
 - Ignoring deployment challenges
 - Unrealistic assumptions
 ## Strengthening Your Analysis
 ### Build Reference Classes
 **Instead of single data point:**
 - How many have tried this?
 - What's the success rate?
 - What patterns exist across cases?
 ### Seek Disconfirmation
 **Actively look for:**
 - Opposing viewpoints
 - Failure cases
 - Limitations and boundaries
 - Alternative explanations
 ### Map Uncertainty
 **Identify what's:**
 - Known and verified
 - Assumed but reasonable
 - Speculative or uncertain
 - Unknown or missing
 ### Consider Stakeholders
 **Ask who:**
 - Benefits from this framing?
 - Would disagree and why?
 - Isn't represented here?
 - Has conflicting incentives?
 ## Meta-Patterns
 ### Evolution of Ideas
 **Trace idea lineage:**
 - Where did this come from?
 - How has it evolved?
 - What criticisms emerged?
 - What's the current consensus?
 ### Domain Transfer
 **When ideas cross domains:**
 - What gets lost in translation?
 - What analogies are imperfect?
 - What needs adaptation?
 ### Zeitgeist Effects
 **Recognize current trends:**
 - What's fashionable now?
 - What pressures shape discourse?
 - What's being over/under-valued?
 - What will look different in 5 years?
 ## Practical Guidelines
 **Before accepting claims:**
 1. Identify the evidence provided
 2. Consider alternative explanations
 3. Check for context dependency
 4. Assess generalizability
 5. Verify with other sources
 **Before applying ideas:**
 1. Map context similarities/differences
 2. Identify adaptation requirements
 3. Consider failure modes
 4. Start with small experiments
 5. Build feedback mechanisms
 **When uncertain:**
 1. State your uncertainties explicitly
 2. Identify what would resolve them
 3. Estimate confidence levels
 4. Plan validation steps
 5. Remain open to revision
--- a/references/critical-questions.md
+++ b/references/critical-questions.md
@@ -0,0 +1,166 @@
 # Critical Questions by Document Type
 This reference provides type-specific questions for Third Pass critical analysis. Use these to supplement the universal questions in SKILL.md.
 ## Tech Blog
 **Core Analysis:**
 - What problem does this solve, and for whom?
 - What are the trade-offs of this solution vs alternatives?
 - What's the assumed technical environment (stack, scale, team size)?
 - How would this approach fail or scale poorly?
 **Design & Implementation:**
 - Why this approach instead of simpler alternatives?
 - What are the hidden costs (complexity, maintenance, performance)?
 - What edge cases or error scenarios are not addressed?
 - How testable/debuggable is this approach?
 **Applicability:**
 - What prerequisites or constraints does this assume?
 - How well does this generalize to other contexts?
 - What would need to change for my use case?
 - Are there better-suited alternatives for my situation?
 **Evidence Quality:**
 - Are benchmarks/metrics provided? Are they representative?
 - Is there production experience or just prototypes?
 - What's missing from the evaluation?
 ## Retrospective
 **Context & Validity:**
 - What was the specific context (team, org, timeline, constraints)?
 - How much is success due to approach vs context/luck?
 - Would this work in a different setting? Which aspects are transferable?
 **Lessons & Generalization:**
 - Are lessons backed by specific evidence or anecdotal?
 - What's the sample size (one project, multiple iterations)?
 - Are there alternative explanations for outcomes?
 - What would have happened with different decisions?
 **Missing Perspectives:**
 - What didn't work that isn't mentioned?
 - Who else was involved? What's their perspective?
 - What conflicts or tensions were glossed over?
 - What failed attempts preceded success?
 **Temporal Factors:**
 - When was this? Are lessons still valid?
 - How has the landscape changed since then?
 - What would be different if done today?
 ## Technical Documentation
 **Design & Rationale:**
 - What design philosophy underlies this approach?
 - Why these abstractions vs alternatives?
 - What trade-offs were made (flexibility vs simplicity, etc.)?
 - What's explicitly not supported, and why?
 **Completeness & Accuracy:**
 - What common use cases are not documented?
 - Are there undocumented edge cases or gotchas?
 - Is error handling clearly explained?
 - What's the migration/upgrade story?
 **Context & Constraints:**
 - What assumptions about usage patterns?
 - What scale/performance characteristics?
 - What dependencies or prerequisites?
 - What's the intended audience expertise level?
 **Alternatives & Ecosystem:**
 - How does this compare to competing approaches?
 - What problems does this NOT solve well?
 - When should you use something else?
 ## Personal Writing
 **Argument Structure:**
 - What's the core thesis or claim?
 - Is the claim clearly stated or implicit?
 - What evidence supports each point?
 - Are there logical gaps or leaps?
 **Assumptions & Biases:**
 - What's taken for granted without justification?
 - What perspectives or counterarguments are missing?
 - Are there hidden biases in framing?
 - What's the assumed audience knowledge?
 **Clarity & Coherence:**
 - Is the argument easy to follow?
 - Do examples actually support the points?
 - Are terms used consistently?
 - Is the conclusion justified by the body?
 **Rigor & Evidence:**
 - Are claims supported by evidence or assertion?
 - Are sources credible and relevant?
 - Are alternative explanations considered?
 - What would strengthen this argument?
 **Practical Application:**
 - Is this actionable or purely theoretical?
 - Who benefits from these ideas?
 - What's needed to implement these suggestions?
 - What could go wrong in practice?
 ## Academic Paper
 **Research Design:**
 - Are research questions clearly stated?
 - Is methodology appropriate for questions?
 - Are there confounding variables not controlled?
 - Is sample size adequate and representative?
 - Could results be explained differently?
 **Assumptions & Validity:**
 - What theoretical assumptions underlie this work?
 - Are measurements valid for constructs?
 - Are there threats to internal/external validity?
 - How replicable is this research?
 **Related Work:**
 - Is related work comprehensive and fair?
 - What relevant prior work is missing?
 - How does this advance beyond existing work?
 - Are comparisons appropriate and fair?
 **Results & Interpretation:**
 - Do conclusions follow from results?
 - Are alternative interpretations possible?
 - Is statistical significance practical significance?
 - What are limitations and boundary conditions?
 **Contribution & Impact:**
 - What's genuinely novel here?
 - Is contribution incremental or significant?
 - What future research does this enable?
 - What are real-world applications?
 ## Cross-Cutting Questions
 These apply to all document types:
 **Authority & Credibility:**
 - What's the author's expertise in this area?
 - What potential conflicts of interest exist?
 - Is tone confident or overconfident?
 **Temporal Context:**
 - When was this written?
 - What was the state of the field then?
 - What's changed since publication?
 **Rhetorical Choices:**
 - What's emphasized vs downplayed?
 - What language choices reveal assumptions?
 - What's the intended audience and purpose?
 **Actionability:**
 - What can I do with this information?
 - What would I need to verify before using this?
 - What risks come with applying this?
--- a/references/reconstruction-guide.md
+++ b/references/reconstruction-guide.md
@@ -0,0 +1,241 @@
 # Reconstruction Guide
 This reference provides detailed techniques for demonstrating deep understanding through reconstruction.
 ## Purpose of Reconstruction
 Reconstruction is the ultimate test of understanding. If you can reconstruct the core ideas without reference to the source, explain them to someone else, and identify how they apply to your context, you've truly understood.
 ## Reconstruction Techniques
 ### 1. Mental Re-implementation
 **For technical content:**
 - Close the document and explain the approach from memory
 - Draw diagrams or write pseudocode from scratch
 - Identify what information you need to look up vs what you remember
 - Explain why each component exists and how they fit together
 **For conceptual content:**
 - State the main argument in your own words
 - Rebuild the logical flow from first principles
 - Identify key insights vs supporting details
 - Explain the "why" behind each claim
 ### 2. Teaching Test
 Imagine explaining this to someone with different background:
 **To a beginner:**
 - What analogies would you use?
 - What examples would clarify complex points?
 - What prerequisites need explanation?
 - Where would confusion likely arise?
 **To an expert in different domain:**
 - What core principles transfer?
 - What domain-specific jargon needs translation?
 - What parallels exist in their field?
 ### 3. Critical Comparison
 **Against your prior understanding:**
 - What did you believe before?
 - What changed your thinking?
 - What remains uncertain?
 - What conflicts with other knowledge?
 **Against alternative approaches:**
 - How would someone with different philosophy approach this?
 - What would a skeptic question?
 - What would an enthusiast emphasize?
 ### 4. Contextual Translation
 **To your specific situation:**
 **Direct application:**
 - What can you use exactly as presented?
 - What problems of yours does this solve?
 - What resources do you have that the author didn't?
 **Required adaptation:**
 - What needs modification for your context?
 - What constraints do you have that differ?
 - What would you simplify or elaborate?
 - What risks are specific to your situation?
 **Not applicable:**
 - What doesn't fit your situation?
 - Why not? (constraints, scale, goals, environment)
 - What would you do instead?
 - What can you learn from this even if not applicable?
 ### 5. Stress Testing
 **Push the ideas to boundaries:**
 - What happens at extreme scale?
 - What if key assumptions don't hold?
 - What if opposite approach was taken?
 - What corner cases break this?
 **Identify fragility:**
 - Where is this most likely to fail?
 - What makes it robust or brittle?
 - What failure modes are hidden?
 - What early warning signs would indicate problems?
 ## Reconstruction Checklist
 Verify your understanding by confirming you can:
 - [ ] State core ideas without referencing source
 - [ ] Explain why approach makes sense (not just what it is)
 - [ ] Draw diagrams or structure from memory
 - [ ] Identify what would change in different contexts
 - [ ] Explain to someone with different background
 - [ ] Critique the approach intelligently
 - [ ] Generate examples not in original
 - [ ] Identify related concepts or approaches
 - [ ] Predict what author would say about edge cases
 - [ ] Apply insights to your own problems
 ## Common Pitfalls
 **Surface-level paraphrasing:**
 - Rewording original sentences without deep processing
 - Changing vocabulary but keeping same structure
 - Memorizing examples instead of understanding principles
 **Missing implicit knowledge:**
 - Assuming author's background knowledge
 - Not questioning unstated assumptions
 - Missing contextual factors
 **Overgeneralization:**
 - Applying lessons beyond valid scope
 - Ignoring boundary conditions
 - Assuming universal applicability
 **Undergeneralization:**
 - Treating as one-off solution
 - Missing transferable principles
 - Not abstracting core insights
 ## Reconstruction Strategies by Type
 ### Tech Blog
 **Key elements to reconstruct:**
 - Problem definition and constraints
 - Solution architecture (draw from memory)
 - Why this approach vs alternatives
 - Implementation considerations
 - Where approach would fail
 **Validation:**
 - Can you implement core idea without referencing?
 - Can you explain trade-offs to teammate?
 - Can you identify when to use vs avoid?
 ### Retrospective
 **Key elements to reconstruct:**
 - Context and constraints
 - What happened (timeline)
 - Why outcomes occurred (causal analysis)
 - Lessons and their applicability boundaries
 - Your interpretation vs author's
 **Validation:**
 - Can you teach lessons to your team?
 - Can you identify what's context-dependent?
 - Can you predict when lessons apply?
 ### Technical Documentation
 **Key elements to reconstruct:**
 - Design philosophy and rationale
 - Core abstractions and relationships
 - Common patterns and anti-patterns
 - Edge cases and error handling
 - When to use this vs alternatives
 **Validation:**
 - Can you use API/system without docs?
 - Can you explain design decisions?
 - Can you troubleshoot problems independently?
 ### Personal Writing
 **Key elements to reconstruct:**
 - Central argument and support
 - Logical flow and structure
 - Key insights vs supporting details
 - Author's assumptions and perspective
 - Your critical response
 **Validation:**
 - Can you steelman the argument?
 - Can you articulate disagreements clearly?
 - Can you extract actionable insights?
 ### Academic Paper
 **Key elements to reconstruct:**
 - Research question and motivation
 - Methodology and rationale
 - Key results and implications
 - Limitations and future work
 - How this advances the field
 **Validation:**
 - Can you explain to non-expert?
 - Can you identify follow-up experiments?
 - Can you critique methodology intelligently?
 ## Output Format
 Structure reconstruction output to show depth:
 ```markdown
 #### Reconstruction
 > [!Abstract] Core Ideas in Own Words
 > [Main thesis without referencing source]
 >
 > [Key supporting concepts - explain the "why"]
 >
 > [How pieces fit together - the mental model]
 > [!Example] Application to My Context
 > **Direct application:**
 > - [What I can use as-is and why it fits]
 >
 > **Requires adaptation:**
 > - [What needs changing and how I'd modify it]
 > - [Why changes are necessary for my context]
 >
 > **Not applicable:**
 > - [What doesn't fit and why]
 > - [What I'd do instead and reasoning]
 ```
 ## Advanced Reconstruction
 ### Meta-Cognitive Layer
 Go beyond content to process:
 - Why did author choose this presentation?
 - What's the intended reader journey?
 - What rhetorical strategies are used?
 - What would you have done differently?
 ### Generative Understanding
 True mastery enables generation:
 - Create new examples applying principles
 - Extend ideas to new domains
 - Identify implications not stated
 - Generate hypotheses to test
 - Connect to other frameworks
		`@@ -0,0 +1,3 @@`
							`# deep-reading-framework`

							`Three-pass critical reading framework for systematic document analysis`