sonnygin/japan-university-exam-guide/cold-email-check

Cold Email with Mandatory Fact-Check

Two-phase pipeline: (1) draft generation using the academic-cold-email skill, then (2) AUTOMATIC exhaustive fact-checking (40+ items) against primary sources. Fact-checking runs automatically without asking — do NOT prompt the user for approval.

Phase 1: Draft Generation (academic-cold-email workflow)

Execute the full academic-cold-email skill workflow as defined in /Users/admin/.claude/skills/academic-cold-email/SKILL.md. Key checklist:

• [ ] Confirm applicant profile (Name, Current Status, Strengths)
• [ ] Read the user's personal cold email style file at ~/Downloads/coldEmail.md — all drafted emails MUST match this style
• [ ] Deep web intelligence extraction (browse professor pages, click all sub-pages, note Japanese keywords)
• [ ] Red-line checks (contact requirements, not-accepting statements, email extraction)
• [ ] Dynamic research topic generation (cross-match professor work × applicant background)
• [ ] Draft English version (<400 words) and Chinese version (<500字), following the user's style
• [ ] Archive to Notion if available

User's Personal Cold Email Style (from ~/Downloads/coldEmail.md)

Before drafting, read ~/Downloads/coldEmail.md to internalize the user's established style. The following patterns are extracted from the user's previous successful cold emails and MUST be followed:

Structural pattern (English version):

1. Subject line: Inquiry regarding Admission: [Specific Topic Keywords] - [Name]
2. Paragraph 1 (2-3 sentences): Name, university, graduation date, major. State intent to pursue graduate studies under the professor. Keep it factual — do NOT over-explain.
3. Paragraph 2 (3-5 sentences, the core): Reference a SPECIFIC recent paper or project by the professor (by title or topic). State what impressed the applicant. Then propose a concrete, feasible research direction that bridges the professor's work with the applicant's background.
4. Paragraph 3 (2-3 sentences): Describe the applicant's strengths. Use "Rather than building X from scratch, my core strength lies in Y" pattern. Do NOT claim to lead/design/architect — use "participated in" or "contributed to" language. Mention one concrete industry experience (e.g., Shopee) and one learning effort (e.g., CS229).
5. Paragraph 4 (2-3 sentences): Mention exam preparation status. Politely ask whether professor is accepting students. Offer to send CV and research proposal. End with "Thank you very much for your time and consideration."

Tone rules:

• Professional but not overly formal. No flattery or exaggeration.
• Avoid "strongly believe", "passionate about", "truly inspired" — stay factual.
• Do NOT claim to "design", "lead", "architect", or "spearhead" at work. Use "participated in", "contributed to", "was involved in".
• Correctly identify the professor's co-workers' work vs. the professor's own work. If a paper is by DBCLS colleagues, say "DBCLS's recent work" not "your recent work" unless the professor is an author.
• English only for the English version. The Chinese version (if requested) follows the academic-cold-email Chinese template.

Output File

Save the complete output to a new `.md` file at ~/Downloads/coldEmail-[Professor-LastName].md. The file must include:

# [教授姓名] ([英文名]) — 套瓷信
 
## 教授信息
[表格：姓名、职称、所属、地址、电话、Email、主页链接、招生状态]
 
## 研究方向
[3 个研究方向，含代表项目和工具]
 
## 近期代表性成果
[5 篇/项，含标题、期刊/来源、日期]
 
## 拟定研究方向
[研究方向描述 + 与教授工作的衔接说明]
 
## 套瓷信（English）
[完整英文邮件正文]
 
## 套瓷信（中文）
[完整中文邮件正文]
 
## 待办
- [ ] 确认邮箱
- [ ] 确认招生
- [ ] ...

Phase 2: Mandatory Fact-Checking (AUTOMATIC — DO NOT ASK)

This phase runs automatically after Phase 1 completes. Do NOT ask the user whether to proceed. Immediately begin fact-checking all claims against primary sources.

Perform an exhaustive 40+ item fact-check across four rounds. Append all findings to the same .md file under ## 事实核查报告 section.

Fact-Check Focus: Content Accuracy

The primary focus is on content truthfulness — is every claim about the professor, their papers, their research, and technical concepts factually correct?

Critical questions to answer for each claim:

• Does the paper actually say what the email claims it says? (check abstract/body)
• Is the professor's research direction accurately described? (check lab page × paper titles)
• Are technical nouns, frameworks, and methodologies real and correctly used? (check official docs)
• Does the proposed research direction align with what the lab actually does? (cross-reference)

Round 1: Professor Identity & Institution (12 items)

Round 2: Research Content & Paper Accuracy (14 items)

This is the core round — every claim about papers and research must be verified against the actual paper content.

Round 3: Technical Infrastructure & Tools (8 items)

Round 4: Admissions, Feasibility & Risk (8 items)

Round 4b: Email Style & Tone Verification (optional, does not count toward 40)

Fact-Check Report Format

Each verified claim must follow this format:

### 声明 N：[简短描述]
 
> "[引用邮件原文中被核查的具体句子]"
 
| 项目 | 结果 |
|------|------|
| **判定** | ✅ 准确 / ⚠️ 有偏差 / 🔴 高风险 / 🔵 用户自述 |
| **证据** | [论文原文引用、页面原文引用、API 返回内容等具体证据] |
| **来源** | [一手来源超链接] |
| **修正建议** | [如有偏差，说明如何修正；无偏差则写 N/A] |

Correction Protocol

• ✅ 准确: No action needed
• ⚠️ 有偏差: Immediately edit the email text in the md file to correct the factual error. Record the change in the report.
• 🔴 高风险: Flag prominently with ⚠️ in the summary table. Strongly advise user to verify before sending. If the risk is about the wrong application pathway, rewrite the relevant email paragraph.
• 🔵 用户自述: Note as unverifiable via web. Suggest user prepare supporting evidence if challenged.

Post-Check Summary (REQUIRED)

After all four rounds, produce: