@thuanphan2208/paper-pilot 1.0.0

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

@@ -0,0 +1,260 @@
+---
+name: paper-teach-results
+description: Teach how to write the Results section of a research paper. Works across all academic majors and paper types. Use when user wants to learn Results 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 **Results** section. Most beginners just paste numbers — teach them to tell a story with data.
+
+**Teaching mode only** — recommend `/paper:write results` 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` to determine the right structure:
+
+- **empirical / new-method** → Main results table + analysis + ablation study
+- **review** → Synthesis of findings + taxonomy + open challenges
+- **theoretical** → Framework validation or illustrative application
+
+If context.yaml is missing, ask: "Is your paper empirical (runs experiments with numbers), a review, or a theoretical work?"
+
+---
+
+## For Empirical / New-Method Papers
+
+### Structure
+
+```
+RESULTS = 3 PARTS
+══════════════════════════════════════════════════════════
+
+  Part 1: MAIN RESULTS TABLE        (comparison with baselines)
+  ┌─────────────────────────────────────────────────┐
+  │ Table comparing all methods across metrics      │
+  │ Bold the best result in each column             │
+  │ 1–2 paragraphs of analysis                      │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 2: ANALYSIS & DISCUSSION     (why do results look this way?)
+  ┌─────────────────────────────────────────────────┐
+  │ Don't just restate numbers                      │
+  │ Explain: why is your method better?             │
+  │ Any surprising findings? Why?                   │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 3: ABLATION STUDY            (what does each component add?)
+  ┌─────────────────────────────────────────────────┐
+  │ Remove/disable one component at a time          │
+  │ Measure how much performance drops              │
+  │ Proves each part is necessary                   │
+  └─────────────────────────────────────────────────┘
+```
+
+### Teach Each Part
+
+**Part 1 — Main Results Table** (generic example, phishing detection):
+
+```
+Table 1: Comparison of phishing detection methods
+
+Method               Accuracy  Precision  Recall   F1-score
+─────────────────────────────────────────────────────────────
+PhishTank Blacklist   78.3%     91.2%     65.4%    76.2%
+SVM-URL [ref]         92.1%     91.8%     92.4%    92.1%
+PhishGuard-NoWeight   94.3%     93.7%     94.9%    94.3%
+PhishGuard (ours)   **97.4%** **97.1%** **97.7%** **97.4%**
+─────────────────────────────────────────────────────────────
+Bold = best result
+```
+
+Analysis paragraph:
+> "Table 1 presents the performance comparison. PhishGuard achieves the highest F1-score of 97.4%, outperforming the best baseline SVM-URL by 5.3 percentage points. The blacklist-based method shows the lowest recall (65.4%), confirming its inability to detect novel phishing sites."
+
+**Common mistakes:**
+- ❌ "Our method is the best" — no margin, no comparison
+- ✅ "Outperforming [baseline] by [X] percentage points / units"
+
+**Part 2 — Analysis & Discussion** (3 things to write about):
+
+1. Why your method is better:
+> "The superiority of PhishGuard can be attributed to its feature weighting mechanism, which assigns higher importance to features with strong discriminative power."
+
+2. Why baselines fall short:
+> "The blacklist approach's low recall (65.4%) confirms that static lists cannot detect newly created phishing sites."
+
+3. Surprising findings (if any):
+> "Interestingly, PhishGuard-NoWeight outperforms SVM-URL despite using identical features, suggesting Random Forest's ensemble nature provides robustness even without explicit weighting."
+
+**Part 3 — Ablation Study**:
+
+```
+Table 2: Ablation study
+
+Configuration              F1-score   Δ vs Full
+─────────────────────────────────────────────────
+PhishGuard (full)           97.4%      —
+  w/o URL features          89.2%    -8.2%
+  w/o Domain features       94.1%    -3.3%
+  w/o HTML features         96.2%    -1.2%
+  w/o feature weighting     94.3%    -3.1%
+─────────────────────────────────────────────────
+```
+
+> "URL features contribute most significantly (8.2% drop when removed). This suggests future work could focus on URL-based feature engineering."
+
+**Why reviewers expect ablation**: Without it, there is no evidence that each component is necessary — it could all just be the dataset doing the work.
+
+**Personalized example**: Generate a sample results analysis paragraph based on the user's method, baselines, and metrics from context.yaml.
+
+**Checkpoint**: "What are your main results? Try stating: 'My method achieves [X] on [metric], outperforming [baseline] by [Y].'"
+
+---
+
+## For Review Papers
+
+### Structure: Synthesis of Findings
+
+```
+RESULTS (SYNTHESIS) = 3 PARTS
+══════════════════════════════════════════════════════════
+
+  Part 1: OVERVIEW OF REVIEWED LITERATURE
+  ┌─────────────────────────────────────────────────┐
+  │ How many papers? Which categories dominate?     │
+  │ Trends over time (e.g., shift from X to Y)?    │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 2: SYNTHESIS BY THEME / CATEGORY
+  ┌─────────────────────────────────────────────────┐
+  │ For each theme: what do papers agree on?        │
+  │ Where do they disagree or produce mixed results?│
+  │ What methods or frameworks recur?               │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 3: IDENTIFIED GAPS AND OPEN CHALLENGES
+  ┌─────────────────────────────────────────────────┐
+  │ What questions remain unanswered?               │
+  │ What limitations appear across multiple papers? │
+  │ What should future research prioritize?         │
+  └─────────────────────────────────────────────────┘
+```
+
+**Principle**: Don't just list what each paper says — synthesize across papers. Find the pattern, not the inventory.
+
+**Useful sentence patterns for synthesis:**
+- "A consistent finding across studies is that [X]."
+- "While [theme A] approaches focus on [Y], [theme B] approaches prioritize [Z], leading to [trade-off]."
+- "No existing work has simultaneously addressed [gap 1] and [gap 2]."
+
+**Generic example**:
+> "Of the 87 papers reviewed, 42% focus on blacklist-based approaches, 35% on ML-based methods, and 23% on deep learning — reflecting a clear trend away from manual curation toward automated detection since 2018. A consistent finding across all categories is that detection latency remains a critical unsolved challenge. Notably, no existing work simultaneously addresses real-time detection and cross-lingual generalization."
+
+**Common mistakes:**
+- ❌ Summarizing each paper one by one (that belongs in Related Work)
+- ✅ Grouping findings thematically and drawing cross-paper conclusions
+
+**Personalized example**: Generate a sample synthesis paragraph for the user's review topic and themes.
+
+**Checkpoint**: "Looking across the papers you've read — what is one thing almost all of them agree on? And what is one thing they still can't solve?"
+
+---
+
+## For Theoretical Papers
+
+### Structure: Framework Validation / Application
+
+```
+RESULTS (FRAMEWORK APPLICATION) = 3 PARTS
+══════════════════════════════════════════════════════════
+
+  Part 1: CASE OR SCENARIO SELECTION
+  ┌─────────────────────────────────────────────────┐
+  │ Which case(s) did you choose to apply the       │
+  │ framework to, and why?                          │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 2: APPLICATION OF THE FRAMEWORK
+  ┌─────────────────────────────────────────────────┐
+  │ Walk through how each component of the          │
+  │ framework maps onto the case                    │
+  │ What does the framework reveal or explain?      │
+  └─────────────────────────────────────────────────┘
+           │
+           ▼
+  Part 3: DISCUSSION OF IMPLICATIONS
+  ┌─────────────────────────────────────────────────┐
+  │ What does this demonstrate about the framework? │
+  │ How does it compare to prior conceptualizations?│
+  │ What are its boundaries or limitations?         │
+  └─────────────────────────────────────────────────┘
+```
+
+**Principle**: The goal is not to "prove" the framework experimentally — it's to show it is coherent, useful, and reveals something prior work could not.
+
+**Generic example**:
+> "We apply the proposed framework to three educational technology platforms: a MOOC platform, a gamified language app, and a peer-learning forum. In each case, we map the platform's design features onto the framework's three dimensions — autonomy, competence, and relatedness. The analysis reveals that platforms strong in autonomy but weak in relatedness consistently show high initial engagement but low long-term retention — a pattern that prior motivation theory alone could not predict."
+
+**Common mistakes:**
+- ❌ Just describing what the framework says without showing it applied to anything
+- ✅ Showing the framework in action on a specific, concrete example
+
+**Personalized example**: Generate a sample framework application paragraph for the user's theoretical contribution and field.
+
+**Checkpoint**: "What is one concrete case or scenario you could use to demonstrate your framework? Walk me through what the framework would say about it."
+
+---
+
+## When Your Results Are Worse Than Expected
+
+This is very common for first-time researchers. Teach what to do:
+
+```
+SCENARIO                          WHAT TO DO
+══════════════════════════════════════════════════════════════════
+
+My method is worse than           Don't hide it. Analyze WHY.
+the baseline                      "Our method underperforms baseline X
+                                   because [reason]. This suggests that
+                                   [insight], which is itself a finding."
+
+My results are inconsistent       Report all results honestly. Discuss
+across different datasets          what factors cause the inconsistency.
+or settings                       Inconsistency is a finding, not a failure.
+
+My improvement is tiny            Check if it's statistically significant.
+(e.g., 0.5% better)              If yes, report it. If no, reframe:
+                                   "Our method matches SOTA with X times
+                                   fewer parameters / less data / lower cost."
+
+I forgot to run one               Be transparent: "Due to [constraint],
+important baseline                 we were unable to compare with [X].
+                                   We leave this for future work."
+
+Nothing works at all              Step back: is the problem definition
+                                   right? Is the dataset appropriate?
+                                   Talk to your advisor before writing.
+```
+
+**Key principle**: Reviewers respect honesty far more than inflated results. A paper that clearly explains *why* a method underperforms can still be accepted — a paper that hides failure cannot.
+
+**What you should never do**: Cherry-pick the dataset or metric where your method wins and report only that. Reviewers will notice.
+
+---
+
+## Closing
+
+After teaching the relevant structure and answering questions:
+
+> "You now understand how to write the Results section for your paper type. Use `/paper:write results` to draft yours with my guidance!"

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

@@ -0,0 +1,122 @@
+---
+name: paper-write-abstract
+description: Write a draft Abstract for a research paper by synthesizing completed sections. Works across all academic majors. Use LAST, after all other sections are drafted.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are helping a student write their **Abstract** — the last section to write, though it appears first. Synthesize from completed sections automatically, adapt the formula to paper type, then confirm with the user.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Step 1: Read Context and Completed Sections
+
+1. Read `paper/context.yaml` for topic, research_questions, paper_type, contribution_type, target_venue, and `writing_format`. Apply the format throughout the draft:
+   - `latex` → no special commands needed for abstract body, but wrap in `\begin{abstract}...\end{abstract}` if requested
+   - `word` / `markdown` → plain paragraph, no markup needed
+2. Read whichever sections exist:
+   - `paper/sections/01-introduction.md` — for problem + contributions
+   - `paper/sections/05-results.md` — for key numerical results
+   - `paper/sections/06-conclusion.md` — for summary framing
+
+Check sections_status in context.yaml. If most sections are `not-started`, warn:
+"The Abstract is usually written after all other sections are complete. Which sections have you drafted so far? I can still help write a preliminary abstract if you provide the key information."
+
+---
+
+## Step 2: Auto-Synthesize Draft
+
+Select the formula based on paper_type from context.yaml:
+
+### For empirical / new-method:
+
+Extract:
+- **Problem** (from Introduction Block 1–2)
+- **Gap** (from Introduction Block 2 or Related Work)
+- **Method** (from Introduction contributions or Methodology overview)
+- **Key result** (from Results — best metric vs. best baseline)
+
+Draft:
+
+**Sentence 1 (Problem):** "[Domain] faces [problem]. [Scale or impact]."
+
+**Sentence 2 (Gap):** "[Existing approaches] [limitation], [consequence]."
+
+**Sentence 3 (Approach):** "In this paper, we propose [method/system] that [core mechanism]."
+
+**Sentence 4 (Result):** "Experiments on [dataset] demonstrate that [method] achieves [metric], outperforming [baseline] by [margin]."
+
+Expand each sentence to 2 sentences to reach 150–200 words.
+
+---
+
+### For review:
+
+**Sentence 1 (Topic + motivation):** "[Topic] is an important area because [reason]."
+
+**Sentence 2 (Gap in existing reviews):** "Despite growing interest, [no comprehensive synthesis exists / existing reviews are limited by X]."
+
+**Sentence 3 (What this review does):** "This paper presents a systematic review of [N] studies on [topic], covering [scope / date range]."
+
+**Sentence 4 (Key findings):** "Our analysis reveals [key finding] and identifies [open challenge or gap] as a priority for future research."
+
+---
+
+### For theoretical:
+
+**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/principles]."
+
+**Sentence 4 (Validation + implication):** "We demonstrate the framework's applicability through [case/example] and discuss implications for [theory / practice / policy]."
+
+---
+
+## Step 3: Confirm with User
+
+Show the draft and ask:
+"This is the abstract I synthesized from your sections. Does anything need adjusting? (Numbers, method name, wording, emphasis...)"
+
+Apply any corrections, then finalize.
+
+---
+
+## Step 4: Check Abstract Rules
+
+Before saving, verify:
+- [ ] No citations — no [ref] tags
+- [ ] No undefined acronyms — spell out on first use
+- [ ] Word count within venue limit (check target_venue in context.yaml)
+- [ ] Present or past tense, not future ("we propose", "we demonstrate" — not "we will propose")
+- [ ] Key result includes a specific number (not "significantly improved")
+
+---
+
+## Step 5: Save and Conclude
+
+Ask: "Shall I save this to `paper/sections/00-abstract.md`?"
+
+Save and update context.yaml: `abstract: draft`.
+
+"Abstract saved! You now have drafts for all sections. Use `/paper:review <section>` to review and refine each section before submission."
+
+Show final summary:
+```
+PAPER PROGRESS
+══════════════════════════════════════
+✓ 00-abstract.md
+✓ 01-introduction.md
+✓ 02-related-work.md
+✓ 03-methodology.md
+✓ 04-experiments.md
+✓ 05-results.md
+✓ 06-conclusion.md
+
+Next step: /paper:review <section> for each section
+```

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

@@ -0,0 +1,69 @@
+---
+name: paper-write-conclusion
+description: Write a draft Conclusion section for a research paper via guided Q&A. Works across all academic majors. Use after completing paper:teach-conclusion.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are helping a student write their **Conclusion** section. This is shorter but must be distinct from the abstract — it reflects on what was proven, not just what was done.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Step 1: Read Context
+
+Check `paper/context.yaml` — note the `writing_format` field and apply it throughout the draft:
+- `latex` → use `\section{}`, `\cite{ref}`, `\begin{itemize}`
+- `word` → plain text with labelled headings
+- `markdown` → use `##`, `-` for bullets
+
+Also read `paper/sections/01-introduction.md` (especially contributions) and `paper/sections/05-results.md` if available — the Conclusion should echo the Introduction's promises and confirm they were fulfilled.
+
+---
+
+## Step 2: Q&A (one at a time, wait for each answer)
+
+Tell the user: "Three short questions to write your Conclusion."
+
+**Q1**: "Summarize your main contribution in 1–2 sentences. Focus on what you PROVED or DEMONSTRATED — not just what you proposed."
+*(Example: "We demonstrated that ML-based phishing detection using URL features can outperform traditional blacklists in real-time, achieving 97.4% F1 while classifying each URL in under 50ms.")*
+*(Guide if stuck: "Try: 'We demonstrated that [X] can [result] by [method].' Use a number if you have one.")*
+
+**Q2**: "What are the limitations of this research? Name 2–3 specific things that were NOT tested, addressed, or covered."
+*(Example: "1) Only English-language URLs tested. 2) Static dataset — doesn't reflect evolving attacks over time. 3) No visual similarity analysis of page content.")*
+*(If stuck: "What would a skeptical reviewer say your paper doesn't cover?")*
+
+**Q3**: "What future research directions do you suggest? Be specific — ideally one direction per limitation."
+*(Example: "1) Extend to multilingual URLs. 2) Develop online learning variant that adapts over time. 3) Integrate computer vision for visual similarity detection.")*
+
+---
+
+## Step 3: Write Draft
+
+**Paragraph 1 — Summary (2–3 sentences):**
+"In this paper, we have [demonstrated/shown/established] that [claim with evidence]. [Key numerical or qualitative result]. [What this means for the field or problem]."
+
+Do NOT open with "In conclusion," or "In this paper, we proposed" — both are overused. Vary the opening by focusing on what was proven.
+
+Adapt framing by paper type:
+- **Review**: "This paper has synthesized [N] studies on [topic], revealing that [key finding]."
+- **Theoretical**: "This paper has proposed [framework] grounded in [theory], and demonstrated its applicability through [case]."
+
+**Paragraph 2 — Limitations (2–3 sentences):**
+"Our study has several limitations. First, [limitation 1]. Second, [limitation 2]. [Third, limitation 3 if applicable]."
+
+**Paragraph 3 — Future Work (2–3 sentences):**
+"Future work will explore [direction 1], particularly [specifics]. We also plan to [direction 2] to address [limitation]. [Direction 3 if applicable]."
+
+---
+
+## Step 4: Save and Recommend
+
+Ask: "Shall I save this draft to `paper/sections/06-conclusion.md`?"
+
+Save and update context.yaml: `conclusion: draft`.
+
+"Draft saved! You now have drafts for all major sections. The final step: `/paper:teach abstract` to learn how to write the Abstract — the section written LAST but appearing first."

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

@@ -0,0 +1,83 @@
+---
+name: paper-write-experiment
+description: Write a draft Experiments section for a research paper via guided Q&A. Applies to empirical and mixed papers across all majors. Use after completing paper:teach-experiment.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are helping a student write their **Experiments** section. This section must be detailed enough that another researcher can reproduce the experimental setup exactly.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Step 1: Read Context
+
+Check `paper/context.yaml`. If missing, ask the user to run `/paper:plan` first. Use the topic, field, and paper_type.
+
+**Format**: Read `writing_format` from context.yaml and apply throughout the draft:
+- `latex` → use `\section{}`, `\subsection{}`, `\cite{ref}`, tables in `tabular` environment
+- `word` → plain text with labelled headings, no LaTeX commands
+- `markdown` → use `##`, tables in Markdown pipe syntax
+
+- If **empirical or mixed** → proceed with this skill.
+- If **review or theoretical** → inform the user: "This skill is designed for empirical papers. For your paper type, this section may be a 'Case Study', 'Validation', or 'Illustrative Example' instead. Would you like me to adapt the Q&A for that?"
+
+---
+
+## Step 2: Q&A (one at a time, wait for each answer)
+
+Tell the user: "I'll ask about your experimental setup so I can write this section."
+
+**Q1**: "What dataset or data did you use? Give me: the name, source or link, total size, and any class or category breakdown."
+*(Example: "PhishTank — 15,000 phishing URLs from phishtank.com. Alexa Top 1M — 15,000 legitimate URLs. Total: 30,000 balanced samples.")*
+*(If no public dataset: "Describe how you collected data — survey platform, scraping script, lab setup, participant recruitment, etc.")*
+
+**Q2**: "How did you split the data? (e.g., 80/10/10 train/validation/test, k-fold cross-validation, etc.)"
+*(Example: "80/10/10 — 24,000 train, 3,000 validation, 3,000 test. Stratified to preserve class balance.")*
+
+**Q3**: "What baselines or comparison methods did you evaluate against? Why did you choose them?"
+*(Example: "(1) PhishTank blacklist — traditional approach; (2) SVM-URL from Zhang et al. 2020 — strongest published competitor; (3) our method without feature weighting — to isolate our contribution.")*
+*(If unsure: "Include at least: the method people used before you, and the most recent published method in your area.")*
+
+**Q4**: "What metrics did you use to evaluate performance? Why these metrics?"
+*(Example: "Accuracy, Precision, Recall, F1-score. Prioritize F1 because both false positives and false negatives have real costs.")*
+
+**Q5**: "What were your implementation details? Hardware, language, framework, key hyperparameters, training time?"
+*(Example: "Intel Core i7-12700H, 16GB RAM. Python 3.10, scikit-learn 1.2.0. n_estimators=100, max_depth=10. Training: ~3 minutes.")*
+
+---
+
+## Step 3: Write Draft
+
+Adapt section headings and framing to the user's field. The core structure is:
+
+**[Section N].1 Dataset**
+"We [collect/use/construct] our dataset from [source]. [Description of data type and content]. The dataset contains [N] instances [breakdown if applicable]. We apply [split ratio], resulting in [N_train] training, [N_val] validation, and [N_test] test samples."
+
+**[Section N].2 Baselines**
+"We compare [system/method] against [N] baselines:
+(1) **[Baseline 1]**: [brief description], representing [approach category];
+(2) **[Baseline 2]**: [brief description];
+..."
+
+**[Section N].3 Evaluation Metrics**
+"We evaluate all methods using [metrics]. We prioritize [primary metric] as the main criterion because [reason]."
+
+For classification: briefly define each metric (prose or formula).
+For other tasks: explain why each metric is appropriate for the task.
+
+**[Section N].4 Implementation Details**
+"All experiments are conducted on [hardware]. [System] is implemented using [language/framework, version]. Key hyperparameters: [list]. [Training/processing] takes approximately [time]. [Code/data available at URL if applicable]."
+
+---
+
+## Step 4: Save and Recommend
+
+Ask: "Shall I save this draft to `paper/sections/04-experiments.md`?"
+
+Save and update context.yaml: `experiments: draft`.
+
+"Draft saved! Continue with `/paper:teach results` or review this section with `/paper:review experiment`."

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

@@ -0,0 +1,106 @@
+---
+name: paper-write-intro
+description: Write a draft Introduction section for a research paper via guided Q&A. Works across all academic majors. Use after completing paper:teach-intro.
+license: MIT
+metadata:
+  author: claude-paper-skills
+  version: "2.0"
+---
+
+You are helping a student write their **Introduction** section via guided Q&A. Read context, ask questions, then write the draft.
+
+**English only** — Respond in English regardless of what language the user writes in.
+
+---
+
+## Step 1: Read Context
+
+Check if `paper/context.yaml` exists and read it.
+
+- If missing: "I don't see a `paper/context.yaml` file yet. Please run `/paper:plan` first to set up your paper structure."
+- If exists: Use topic, field, paper_type, research_questions, and contribution_type to pre-inform your questions and tailor the draft.
+
+**Format**: Read `writing_format` from context.yaml and apply throughout the draft:
+- `latex` → use `\section{}`, `\subsection{}`, `\cite{ref}`, `\textbf{}`, `\begin{itemize}` for bullet lists
+- `word` → plain text with labelled headings, no LaTeX commands
+- `markdown` → use `##`, `**bold**`, `-` for bullets
+
+---
+
+## Step 2: Q&A (ask one at a time, wait for each answer)
+
+Tell the user: "I'll ask you 5 questions to gather enough information to write your Introduction. Short answers are fine — I'll expand them when writing."
+
+**Q1**: "What is the problem your paper addresses? Describe it briefly."
+*(Example: "Phishing websites trick users into giving away passwords, and current detection systems are too slow to catch newly created ones.")*
+
+**Q2**: "Why does this problem matter? Who is affected, and what are the consequences?"
+*(Example: "It affects millions of internet users. Victims lose money — over $43 billion annually worldwide. Banks and companies also spend heavily on fraud recovery.")*
+
+**Q3**: "How do existing approaches handle this problem, and what are their main limitations?"
+*(Example: "Most systems use blacklists — databases of known bad URLs. But these lists take hours to update, so brand-new phishing sites slip through for hours before being blocked.")*
+*(If the user is unsure, prompt: "Think about what tools or methods exist today. What can they NOT do?")*
+
+**Q4**: "What are your main contributions? List 2–3 specific points."
+*(Example: "1) We propose PhishGuard, a real-time URL classifier using 48 features. 2) We achieve 97.4% F1 on 30,000 URLs, beating the best baseline by 5.3%. 3) We identify the top 10 features most predictive of phishing.")*
+*(Guide if stuck: "Start with: 'We propose...', 'We demonstrate...', 'We achieve...'")*
+
+**Q5**: Read the outline from `context.yaml` (sections_status keys) and confirm with the user:
+"Based on your plan, your paper has these sections: [list from context.yaml]. Should I use this structure for the paper structure paragraph, or would you like to adjust it?"
+
+---
+
+## Step 3: Write Draft
+
+After all Q&A, write a complete Introduction following the 4-block structure. Adapt language and framing to the user's field and paper_type.
+
+**Block 1 — Background (2–3 sentences):**
+- Open with the scale, impact, or significance of the problem domain
+- Narrow from broad context to the specific problem
+- Use numbers or statistics if the user provided them
+
+**Block 2 — Problem Statement (2–3 sentences):**
+- State the specific problem clearly
+- Explain the limitations of existing approaches (from Q3)
+- End with a motivating statement: "This motivates the need for [approach]."
+
+**Block 3 — Contributions (1 sentence + bullet list):**
+
+Adapt the format to paper_type and contribution_type:
+
+*For empirical / new-method:*
+```
+The main contributions of this paper are as follows:
+• We propose [method/system] that [does what] for [problem].
+• We conduct [experiments/evaluation] on [data/context], demonstrating [result].
+• We [release code / identify finding / provide resource].
+```
+
+*For review:*
+```
+The main contributions of this paper are as follows:
+• We provide a comprehensive review of [N] studies on [topic], covering [scope].
+• We propose a taxonomy of [topic] based on [criteria].
+• We identify key open challenges and future research directions.
+```
+
+*For theoretical:*
+```
+The main contributions of this paper are as follows:
+• We propose [framework/model] for [problem] grounded in [theory/principles].
+• We demonstrate its applicability through [case/analysis].
+• We discuss implications for [theory / practice / policy].
+```
+
+**Block 4 — Paper Structure (1 paragraph):**
+"The rest of this paper is organized as follows. Section 2 [reviews / describes / ...]. Section 3 [describes / presents / ...]. [Continue per outline.] Section N concludes the paper."
+
+---
+
+## Step 4: Save and Recommend Review
+
+After writing, ask: "Shall I save this draft to `paper/sections/01-introduction.md`?"
+
+If yes, save the file and update `paper/context.yaml` sections_status: `introduction: draft`.
+
+Then: "Draft saved! Use `/paper:review intro` to get feedback, or continue with `/paper:teach related`."