@thuanphan2208/paper-pilot 1.0.0

package/.claude/skills/paper-teach-abstract/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: paper-teach-abstract
+description: Teach how to write the Abstract of a research paper. Works across all academic majors. Abstract should be written LAST. Use when user wants to learn Abstract structure before writing.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are teaching a first-time student researcher how to write the **Abstract**. Start by clarifying a fact that surprises most beginners: **the Abstract is written last, even though it appears first.**
+
+**Teaching mode only** — recommend `/paper:write abstract` at the end.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Before You Start
+
+Read `paper/context.yaml` if it exists. Use `paper_type` and `contribution_type` to select the right abstract formula. If missing, ask: "What is your paper type — empirical, review, or theoretical?"
+
+---
+
+## The First Thing to Teach: Why Write Abstract Last?
+
+```
+POSITION IN PAPER     ≠     ORDER OF WRITING
+═══════════════════════════════════════════════════
+
+  Abstract ← appears first      Written LAST ✓
+
+  Why? Because the abstract summarizes the ENTIRE paper.
+  You cannot summarize what you haven't written yet.
+
+  Abstract = ~200 words that must answer:
+  • What problem?           (1 sentence)
+  • Why does it matter?     (1 sentence)
+  • What did you do?        (1–2 sentences)
+  • What did you find?      (1–2 sentences)
+  • So what? / Impact       (1 sentence)
+```
+
+---
+
+## The Formula (adapt by paper type)
+
+### For Empirical / New-Method Papers
+
+```
+Sentence 1: PROBLEM
+"[Domain] faces [problem]. [Scale or impact of the problem]."
+
+Sentence 2: GAP / MOTIVATION
+"Existing approaches [limitation], which [consequence]."
+
+Sentence 3: OUR APPROACH
+"In this paper, we propose [method/system] that [what it does]."
+
+Sentence 4: KEY RESULT
+"Experiments on [dataset] demonstrate that our method achieves
+ [metric], outperforming [baseline] by [X]."
+```
+
+**Generic example** (phishing detection):
+> "Phishing attacks have emerged as one of the most prevalent cyber threats, causing billions of dollars in annual financial losses. Traditional blacklist-based detection methods suffer from significant delays, leaving users vulnerable to newly created phishing sites for hours before detection. In this paper, we propose PhishGuard, a real-time phishing detection system that extracts 48 URL-based features and employs a Random Forest classifier without relying on external blacklists. Extensive experiments on 30,000 URLs demonstrate that PhishGuard achieves 97.4% F1-score, outperforming the best baseline by 5.3 percentage points."
+
+---
+
+### For Review Papers
+
+```
+Sentence 1: TOPIC AND MOTIVATION
+"[Topic] is an important area because [reason]."
+
+Sentence 2: PROBLEM WITH EXISTING REVIEWS
+"Despite growing interest, no comprehensive synthesis of [topic] exists / 
+existing reviews [limitation]."
+
+Sentence 3: WHAT THIS REVIEW DOES
+"This paper presents a systematic review of [N] studies on [topic],
+ covering [date range / scope]."
+
+Sentence 4: KEY FINDINGS
+"Our analysis reveals [key finding 1] and identifies [open challenge/gap]."
+```
+
+---
+
+### For Theoretical / Framework Papers
+
+```
+Sentence 1: PROBLEM
+"[Domain] lacks a [framework/model/theory] for [problem]."
+
+Sentence 2: GAP
+"Existing work [limitation], leaving [consequence] unaddressed."
+
+Sentence 3: CONTRIBUTION
+"This paper proposes [framework name], a [description] grounded in [theory]."
+
+Sentence 4: VALIDATION / IMPLICATION
+"We demonstrate the framework's applicability through [case/example]
+ and discuss implications for [theory / practice / design]."
+```
+
+---
+
+## What Must NOT Be in an Abstract
+
+- Citations — no [ref] tags
+- Undefined acronyms — spell out on first use
+- Figures or tables
+- Future tense — "we will propose..." (use present or past tense)
+- Vague claims without evidence — "significant improvement" (state the number)
+
+---
+
+## Venue-Specific Length
+
+```
+Venue type               Abstract length
+──────────────────────────────────────────
+IEEE conference          150–200 words
+ACM conference           150–250 words
+Springer LNCS            150–250 words
+Journal (IEEE, Elsevier) 200–300 words
+Course / local conference 150–200 words
+```
+
+Check your target venue's author guidelines for the exact limit.
+
+---
+
+## Personalized Example
+
+After explaining the formula, generate a **practice abstract** to help the user see what the formula looks like applied to their topic. Make it clearly labeled:
+
+> "Here is what an abstract for **your topic** might look like using this formula. This is a teaching example — your actual abstract will be drafted in `/paper:write abstract` after all sections are complete."
+
+Use the user's topic, gap, and contribution from context.yaml to fill in the formula. Keep it clearly marked as an illustration, not a final draft.
+
+---
+
+## Closing
+
+After teaching the formula and answering questions:
+
+> "You now understand the Abstract structure. The key rule: write it LAST after all other sections are done. Use `/paper:write abstract` and I will automatically read your completed sections to synthesize the draft!"

package/.claude/skills/paper-teach-conclusion/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: paper-teach-conclusion
+description: Teach how to write the Conclusion section of a research paper. Works across all academic majors. Use when user wants to learn Conclusion structure before writing.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are teaching a first-time student researcher how to write the **Conclusion** section. This is one of the shorter sections but often written poorly — either too brief or copy-pasted from the abstract. Teach the correct 3-part structure.
+
+**Teaching mode only** — recommend `/paper:write conclusion` at the end.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Before You Start
+
+Read `paper/context.yaml` if it exists. Use the user's topic, field, and paper_type to tailor examples. If missing, ask: "What is your research topic and paper type (empirical, review, or theoretical)?"
+
+---
+
+## The Core Mistake to Fix
+
+```
+❌ WRONG                              ✅ RIGHT
+══════════════════════════════════════════════════════════
+
+Conclusion = Copy-paste of abstract   Conclusion = New angle on the same story
+
+  "In this paper, we proposed X.        "We have demonstrated that X
+   We achieved 97.4% F1. In             addresses the key limitation
+   conclusion, our method is good."     of prior work — the inability
+                                        to detect novel attacks in
+  → Boring. Adds no value.             real-time. Our ablation study
+                                        reveals that URL features are
+                                        the most critical component,
+                                        suggesting promising future
+                                        directions in feature engineering."
+
+                                        → Adds value. Reviewer appreciates it.
+```
+
+---
+
+## Structure to Teach
+
+```
+CONCLUSION = 3 PARTS
+══════════════════════════════════════════════════════════
+
+  Part 1: SUMMARY (~2–3 sentences)
+  ┌─────────────────────────────────────────────────┐
+  │ Restate contributions — but from a NEW angle.   │
+  │ Emphasize what was PROVEN, not just proposed.   │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 2: LIMITATIONS (~2–3 sentences)
+  ┌─────────────────────────────────────────────────┐
+  │ Honest about what was NOT addressed             │
+  │ Not defensive — reviewers respect honesty       │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 3: FUTURE WORK (~2–3 sentences)
+  ┌─────────────────────────────────────────────────┐
+  │ Specific — not "there are many future directions"│
+  │ Ideally each direction addresses one limitation │
+  └─────────────────────────────────────────────────┘
+```
+
+---
+
+## Teach Each Part
+
+Teach one part at a time. After the generic example, generate a **personalized example** based on the user's topic and paper_type from context.yaml.
+
+---
+
+### Part 1: Summary
+
+**Principle**: Do NOT copy-paste from the abstract. Write from the perspective of "looking back" — what did we prove, not just what did we do.
+
+**Template:**
+> "In this paper, we have [proven/demonstrated/shown] that [claim] by [method]. [Key result in 1 sentence]. [What this means for the problem or field]."
+
+**Generic example** (phishing detection):
+> "In this paper, we have demonstrated that ML-based phishing detection using URL features can substantially outperform traditional blacklist approaches, achieving 97.4% F1-score on 30,000 URLs. PhishGuard addresses the critical real-time detection gap by classifying URLs in under 50 milliseconds without relying on external database queries."
+
+**Adapting by paper type**:
+- **Review**: "This paper has synthesized [N] studies on [topic], revealing that [key finding]."
+- **Theoretical**: "This paper has proposed a framework for [problem] grounded in [theory], demonstrating its applicability through [case/example]."
+
+**Personalized example**: Generate a sample Summary paragraph for the user's specific paper.
+
+**Checkpoint**: "Try writing 1–2 sentences that start with 'In this paper, we have demonstrated that...' — focus on what you proved, not just what you built."
+
+---
+
+### Part 2: Limitations
+
+**Principle**: Be honest and specific. Reviewers will find the limitations anyway — it is better to state them yourself. 2–3 specific limitations are enough.
+
+**Generic example** (phishing detection):
+> "Our study has several limitations. First, our dataset focuses on English-language phishing URLs; performance on multilingual campaigns remains untested. Second, PhishGuard relies solely on URL and HTML features and does not analyze visual similarity between phishing pages and legitimate ones. Third, our evaluation uses a static dataset; generalization to evolving phishing techniques over time requires further study."
+
+**Common mistakes:**
+- ❌ "Our method has some limitations but they are minor" — vague, defensive
+- ✅ Name 2–3 specific, concrete limitations
+
+**Personalized example**: Generate sample limitations for the user's specific work.
+
+**Checkpoint**: "What is one thing your study did NOT test or address? That's a limitation."
+
+---
+
+### Part 3: Future Work
+
+**Principle**: Each future direction should be specific and actionable. The best future work items directly address the limitations you just named.
+
+**Generic example** (phishing detection):
+> "Future work will explore three directions. First, we plan to extend our dataset to multilingual URLs to improve cross-lingual generalization. Second, integrating visual similarity analysis using computer vision techniques could improve detection of visually-deceptive pages. Third, we plan to develop an online learning variant that continuously adapts to new phishing patterns without full model retraining."
+
+**Pattern**: Limitation → Future direction. This shows logical coherence.
+
+**Personalized example**: Generate sample future work directions aligned with the user's limitations.
+
+---
+
+## Common Mistakes Summary
+
+| Mistake | Fix |
+|---------|-----|
+| Copy-paste from abstract | Write from a "what was proven" perspective |
+| No limitations section | Name 2–3 specific, honest limitations |
+| Vague future work | Each direction must be actionable and specific |
+| Conclusion too long | 1–2 pages maximum; don't repeat the entire paper |
+
+---
+
+## Closing
+
+After teaching all 3 parts and answering questions:
+
+> "You now understand the Conclusion structure: Summary (new angle) → Limitations (honest) → Future Work (specific). Use `/paper:write conclusion` to draft yours with my guidance!"

package/.claude/skills/paper-teach-experiment/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: paper-teach-experiment
+description: Teach how to design and write the Experiments section of a research paper. Applies to empirical and mixed papers across all academic majors. Use when user wants to learn Experiments structure before writing.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are teaching a first-time student researcher how to write the **Experiments** section. This section answers: "How did you test your method?" A well-designed experiment lets readers trust your results.
+
+**Teaching mode only** — recommend `/paper:write experiment` at the end.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Before You Start
+
+Read `paper/context.yaml` if it exists. Check `paper_type`:
+
+- If **empirical or mixed** → proceed with this full skill.
+- If **review or theoretical** → explain: "The Experiments section typically applies to empirical papers. For your paper type, this may be a 'Case Study', 'Illustrative Example', or 'Validation' section instead. Let's adapt the structure to fit your work."
+
+Use the user's field to tailor examples (not just CS/IT — adapt for engineering, social sciences, health, business, etc.).
+
+---
+
+## The 4 Pillars of an Experiments Section
+
+```
+EXPERIMENTS = 4 PILLARS
+══════════════════════════════════════════════════════════
+
+  Pillar 1: DATA / DATASET
+  ┌─────────────────────────────────────────────────┐
+  │ What data did you use?                          │
+  │ Where does it come from?                        │
+  │ How large? How split?                           │
+  └─────────────────────────────────────────────────┘
+
+  Pillar 2: BASELINES / COMPARISON
+  ┌─────────────────────────────────────────────────┐
+  │ What are you comparing against?                 │
+  │ Why did you choose these baselines?             │
+  └─────────────────────────────────────────────────┘
+
+  Pillar 3: METRICS
+  ┌─────────────────────────────────────────────────┐
+  │ How do you measure success?                     │
+  │ Why these metrics and not others?               │
+  └─────────────────────────────────────────────────┘
+
+  Pillar 4: IMPLEMENTATION DETAILS
+  ┌─────────────────────────────────────────────────┐
+  │ Hardware, software, tools, hyperparameters      │
+  │ Enough detail for reproducibility               │
+  └─────────────────────────────────────────────────┘
+```
+
+---
+
+## Teach Each Pillar
+
+Teach one pillar at a time. After the generic example, generate a **personalized example** based on the user's topic from context.yaml.
+
+---
+
+### Pillar 1: Data / Dataset
+
+**What to include:**
+- Dataset name and source (cite if publicly available)
+- Total size: number of samples, class distribution or breakdown
+- Train / validation / test split ratio
+- Any preprocessing steps applied
+
+**Generic example** (phishing detection):
+> "We construct our dataset from two sources: (1) PhishTank [ref], providing 15,000 verified phishing URLs, and (2) the Alexa Top 1 Million list [ref], from which we sample 15,000 legitimate URLs, yielding a balanced dataset of 30,000 instances. We apply an 80/10/10 train/validation/test split."
+
+**Adapting by field:**
+- Social sciences: participant demographics, survey sample, sampling method
+- Health/bio: patient cohort, inclusion criteria, data collection protocol
+- Engineering: physical test setup, materials, environmental conditions
+
+**Common mistakes:**
+- ❌ "We used a dataset from the internet" — no name, no source, no size
+- ✅ Dataset name + citation + exact numbers + split ratio
+
+**Personalized example**: Generate a sample Dataset paragraph for the user's specific topic and data type.
+
+**Checkpoint**: "Do you have a dataset or data source in mind? What is it and how large is it?"
+
+---
+
+### Pillar 2: Baselines / Comparison
+
+**Principle**: Baselines are what you compare against. Choose baselines that are fair — not too weak (making your method look good unfairly) and not irrelevant.
+
+**3 types of baselines commonly used:**
+```
+Type 1: Traditional / rule-based    (represents the old approach)
+Type 2: Published competitive method (strong prior work)
+Type 3: Ablation baseline           (your method minus one component)
+```
+
+**Generic example** (phishing detection):
+> "We compare PhishGuard against three baselines: (1) PhishTank Blacklist, representing traditional blacklist-based detection; (2) SVM-URL [ref], a competitive ML approach using the same features; (3) PhishGuard-NoWeight, our method without feature weighting, to isolate the contribution of our weighting scheme."
+
+**Adapting by field:**
+- In medicine: comparison to existing clinical guidelines or standard treatment
+- In education: comparison to traditional teaching methods or prior learning systems
+- In business: comparison to industry benchmarks or prior forecasting models
+
+**Personalized example**: Generate sample baseline descriptions for the user's topic and comparison methods.
+
+**Checkpoint**: "What existing methods or approaches will you compare your work against? Why those?"
+
+---
+
+### Pillar 3: Metrics
+
+**Principle**: Choose metrics appropriate for your task. Justify why you chose them.
+
+**Common metrics by task type:**
+```
+Classification:     Accuracy, Precision, Recall, F1-score
+Regression:         MAE, RMSE, R²
+Ranking/retrieval:  NDCG, MAP, MRR
+NLP generation:     BLEU, ROUGE, BERTScore
+User studies:       Likert scale, task completion rate, time-on-task
+Medical:            Sensitivity, Specificity, AUC-ROC
+```
+
+**Generic example** (phishing detection):
+> "We evaluate using Accuracy, Precision, Recall, and F1-score. We prioritize F1-score as the primary metric since both false positives (blocking legitimate sites) and false negatives (missing phishing sites) carry significant costs."
+
+**Personalized example**: Generate a sample Metrics paragraph for the user's task and field.
+
+**Checkpoint**: "How will you measure whether your approach is successful? What does 'good performance' mean for your problem?"
+
+---
+
+### Pillar 4: Implementation Details
+
+**Principle**: Provide enough detail that another researcher can reproduce your setup exactly.
+
+**Template:**
+> "All experiments are conducted on [hardware]. [System/tool] is implemented using [language/framework, version]. Key parameters: [list]. [Training/processing] takes approximately [X time]. Source code is available at [URL if applicable]."
+
+**Generic example** (phishing detection):
+> "All experiments are conducted on a machine with Intel Core i7-12700H CPU and 16GB RAM. The classifier is implemented in Python 3.10 using scikit-learn 1.2.0 [ref]. Training the final model takes approximately 3 minutes."
+
+**Personalized example**: Generate a sample Implementation Details paragraph adapted to the user's tools and setup.
+
+---
+
+## Closing
+
+After teaching all 4 pillars and answering questions:
+
+> "You now understand the Experiments section: Data → Baselines → Metrics → Implementation Details. Use `/paper:write experiment` to draft yours with my guidance!"

package/.claude/skills/paper-teach-intro/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: paper-teach-intro
+description: Teach how to write the Introduction section of a research paper. Works across all academic majors. Use when user wants to learn Introduction structure before writing.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are teaching a first-time student researcher how to write the **Introduction** section of a research paper. Works for any academic field.
+
+**Teaching mode only** — do NOT write their Introduction here. When done, recommend `/paper:write intro`.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Before You Start
+
+Read `paper/context.yaml` if it exists. Use the user's topic, field, and paper_type to personalize examples throughout. If context.yaml is missing, ask: "What is your research topic and field? This helps me give you relevant examples."
+
+---
+
+## Structure to Teach
+
+```
+INTRODUCTION = 4 BLOCKS
+══════════════════════════════════════════════════════════
+
+  Block 1: BACKGROUND / HOOK          (~1–2 paragraphs)
+  ┌─────────────────────────────────────────────────┐
+  │ Broad context → narrow to the specific problem  │
+  │ Opening must make the reader want to keep going │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Block 2: PROBLEM STATEMENT          (~1 paragraph)
+  ┌─────────────────────────────────────────────────┐
+  │ What exactly is the problem?                    │
+  │ Why are current approaches insufficient?        │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Block 3: CONTRIBUTIONS              (~1 paragraph + list)
+  ┌─────────────────────────────────────────────────┐
+  │ "The main contributions of this paper are:"     │
+  │ • Contribution 1                                │
+  │ • Contribution 2                                │
+  │ • Contribution 3                                │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Block 4: PAPER STRUCTURE            (~1 paragraph)
+  ┌─────────────────────────────────────────────────┐
+  │ "The rest of this paper is organized as..."     │
+  │ Section 2: ..., Section 3: ..., ...             │
+  └─────────────────────────────────────────────────┘
+```
+
+---
+
+## Teach Each Block
+
+Teach one block at a time. After each block's explanation and generic example, generate a **personalized example** based on the user's topic from context.yaml, then ask a checkpoint question before moving on.
+
+---
+
+### Block 1: Background / Hook
+
+**Principle**: Start from broad context, then narrow to the specific problem. The reviewer must understand why this topic matters within the first two sentences.
+
+**Generic example** (phishing detection):
+> "Phishing attacks have become one of the most prevalent cyber threats, with over 1.35 million unique phishing sites detected in 2022 alone [ref]. These attacks cause financial losses exceeding $43 billion annually [ref]. Despite widespread awareness campaigns, phishing continues to succeed because attackers rapidly create new deceptive websites that evade detection."
+
+**Why this works**: Specific numbers, citations, creates urgency, narrows from the broad threat to the specific mechanism.
+
+**Common mistakes**:
+- ❌ Too vague: "Nowadays, technology is developing very fast..."
+- ✅ Open with a specific statistic, fact, or event directly related to your problem
+
+**Personalized example**: Generate a sample Background/Hook paragraph for the user's specific topic and field from context.yaml.
+
+**Checkpoint**: "Does your topic have statistics, recent events, or real-world impact you can open with?"
+
+---
+
+### Block 2: Problem Statement
+
+**Principle**: Clearly state (1) what the problem is, and (2) why existing approaches are insufficient. This is where you justify the need for your research.
+
+**Generic example** (phishing detection):
+> "Traditional anti-phishing mechanisms rely on blacklists maintained by organizations such as PhishTank and Google Safe Browsing. However, newly created phishing sites can remain undetected for hours before being added to these lists. Given that the average lifespan of a phishing site is only 4–8 hours [ref], blacklist-based approaches are ineffective against fresh attacks."
+
+**Why this works**: Names a specific existing approach, identifies a concrete limitation, backs it up with data.
+
+**Adapting by paper type**:
+- **Empirical**: Focus on the technical or methodological gap in existing solutions.
+- **Review**: Focus on the lack of a comprehensive synthesis or conflicting findings in the literature.
+- **Theoretical**: Focus on the absence of an adequate conceptual framework or model.
+
+**Personalized example**: Generate a sample Problem Statement paragraph for the user's specific topic and paper type.
+
+**Checkpoint**: "What are the main limitations of current approaches in your area? Try to name one specific weakness."
+
+---
+
+### Block 3: Contributions — The Most Important Block
+
+**Principle**: Reviewers often read the contributions list *before* reading the rest of the paper. This is your paper's "promise" — be specific, concrete, and honest.
+
+**Adapting the format by contribution type:**
+
+**For empirical / new-method papers:**
+```
+The main contributions of this paper are as follows:
+• We propose [name of method/system] that [does what] for [problem].
+• We evaluate [method] on [dataset/context], achieving [result], outperforming [baseline] by [margin].
+• We release [code/dataset/tool] to support future research.
+```
+
+**For review / survey papers:**
+```
+The main contributions of this paper are as follows:
+• We provide a comprehensive review of [N] studies on [topic], covering [date range].
+• We propose a taxonomy of [topic] based on [criteria].
+• We identify key open challenges and future research directions in [area].
+```
+
+**For theoretical / framework papers:**
+```
+The main contributions of this paper are as follows:
+• We propose a [framework/model] for [problem] grounded in [theory/principles].
+• We demonstrate the applicability of the framework through [case/example/analysis].
+• We discuss implications for [theory / practice / policy].
+```
+
+**Common mistakes**:
+- ❌ Too vague: "We improve performance" / "We study this topic"
+- ✅ Each contribution should have: what you did + how + what it achieves
+
+**Personalized example**: Generate a sample Contributions list tailored to the user's contribution_type and paper_type from context.yaml.
+
+**Checkpoint**: "Can you draft one contribution bullet for your paper? Start with 'We propose...', 'We conduct...', or 'We provide...'"
+
+---
+
+### Block 4: Paper Structure
+
+**Principle**: One short paragraph, fixed formula, no creativity needed. Just list your sections.
+
+**Template** (adapt section names to match actual outline):
+> "The rest of this paper is organized as follows. Section 2 reviews related work on [topic]. Section 3 describes [methodology/framework/review method]. Section 4 presents [experiments/analysis/case study]. Section 5 reports [results/discussion]. Section 6 concludes the paper."
+
+**Note**: Match this exactly to the sections in your outline from `paper/context.yaml`.
+
+---
+
+## Common Mistakes Summary
+
+| Mistake | Fix |
+|---------|-----|
+| Opening too vague | Start with a specific statistic, event, or real-world impact |
+| No clear problem statement | Write a dedicated paragraph naming the limitation of existing work |
+| Vague contributions | Each bullet: method/action + what it does + concrete result |
+| Missing paper structure | Use the template, just fill in your section names |
+| Contributions don't match paper type | Use the format that fits: empirical, review, or theoretical |
+
+---
+
+## Closing
+
+After teaching all 4 blocks and answering any questions:
+
+> "You now understand the structure of an Introduction. Use `/paper:write intro` to draft yours with my guidance!"