project-retrospective-skill

name	project-retrospective-skill
description	Use when turning work experiences, internships, projects, hackathons, research, GitHub repos, folders, PDFs, screenshots, or Notion pages into private project retrospective assets for top AI FDE, AI Engineer, Agent Architect, AI Product Engineer, DevRel, product, research, or technical interviews; also use when optimizing hub pages that connect multiple projects.

项目复盘skill

Core Principle

Turn raw project materials into a private, interview-grade knowledge asset. The output should read like a project dossier or project report, not a speech draft, not resume bullets, and not a Notion database schema.

Always separate:

• 已有证据: materials the user gave, files read, repos inspected, public sources verified, Notion pages fetched.
• 用户确认: facts the user stated directly.
• 合理生产化推演: credible extrapolation needed to complete the story, clearly labeled and never written as an achieved result.

First Moves

1. Classify the task:
   • hub page: optimize a parent page that connects several projects or experiences.
   • single project page: create or rewrite one project dossier.
   • subproject page: deep dive one module inside a larger experience.
   • interview prep page: expand likely questions and full answers.
   • source conversion: convert docs/PDFs/screenshots/repos into Notion pages plus summary and interview framing.
2. Read available sources before writing. Use Notion fetch for Notion links, rg / rg --files for local folders, and the relevant document/PDF/GitHub tools for files or repos.
3. Build a short evidence ledger in your notes before drafting. Do not force it into the page unless it helps credibility.
4. If the user asks to write/update Notion, use Notion MCP only. Fetch before editing, preserve child page links, update, then fetch again to verify.
5. Ask questions in batches only after reading available material. If enough material exists, write a useful first version and leave a “待补证据清单”.

Required References

Read these when drafting substantial content:

• references/page-blueprints.md: page structures for hub pages, project pages, subprojects, source pages, and interview prep pages.
• references/quality-rules.md: writing style, evidence boundaries, metric translation, Notion update rules, and final QA checklist.

Page Strategy

Hub Page

Use when a parent page contains several child pages, such as one company experience with multiple projects.

The hub page must do more than list children. It should explain:

• the overall positioning of the experience;
• how the child projects connect into one story;
• what capabilities the user built across the projects;
• a reusable 60-90 second interview narrative;
• high-level interview follow-ups;
• resume bullets for the whole experience;
• evidence still missing.

Keep the child page links in the hub. Never delete existing child pages while replacing content.

Single Project Page

Use when writing one project, competition, research, internship, product, or technical asset.

Default sections:

1. 01 项目档案｜项目简介与定位
2. 02 项目背景与问题定义
3. 03 我的角色与核心贡献
4. 04 系统架构总览
5. 05 核心技术模块
6. 06 数据 / 算法 / 评估闭环
7. 07 结果、价值与胜出逻辑
8. 08 工程边界与生产化路线
9. 09 简历表达
10. 10 面试追问准备

Adapt the structure for non-technical work. For DevRel, GTM, research, product strategy, or community projects, keep the story loop but replace pure architecture modules with community systems, operating model, research design, stakeholder workflow, or evaluation model.

Module Pattern

For each important module, include:

• 面试表达： a reusable paragraph the user can say in an interview.
• Background and design reason.
• Implementation or operating logic.
• The user’s personal contribution.
• Small loop: input -> decision -> action -> result/feedback.
• One or more <details> follow-ups with complete answers.

Writing Contract

Every major section starts with **面试表达：**.

Write in professional Chinese by default. Use English only for resume bullets, role titles, API names, technical names, or when the user asks.

Prefer paragraphs over dense bullets. Use bullets only for structured lists that improve scanning.

Do not write:

• 页面使用方式
• 阅读说明
• 这页不是讲稿
• 我将会怎么写
• 本页面用于
• generic disclaimers that belong in the assistant response rather than the Notion page

Do not overclaim. If a project is a prototype, say prototype. If it is a PRD, say PRD. If it is officially delivered, say delivered only when the user confirms or evidence supports it.

Interview Standard

Calibrate for top AI FDE, AI Engineer, Agent Architect, AI Product Engineer, and adjacent elite AI roles.

Strong pages show:

• clear ownership, not vague “we” language;
• a real problem and why it mattered;
• hard decisions and tradeoffs;
• system thinking across product, engineering, data, users, and evaluation;
• metrics or at least a credible metric design;
• production boundaries and failure modes;
• what the user learned or can defend under follow-up.

Metrics and Technical Terms

Convert raw metric names into Chinese concepts.

Bad:

• latency / false positive / CPU utilization

Good:

• 端到端检测延迟：衡量从状态变化到判断和告警生成的速度。
• 误报率：衡量正常情况被错误判断为异常的比例。
• 主机 CPU 安全负载占用：衡量系统能力是否占用关键业务计算资源。

Keep essential English terms in parentheses when useful, such as Issue Payload, Prerender, SSR, Agent Workflow, Core Web Vitals.

Notion MCP Protocol

When updating Notion:

1. Fetch the target page first.
2. If replacing a page with child pages, include every existing child page as <page url="...">title</page> in the new content.
3. Prefer replace_content for clean rewrites when all child links are preserved. Use update_content for smaller precise edits.
4. Never create complex databases, tables, or many fields unless the user explicitly asks.
5. After writing, fetch the page again and verify:
   • title and target page are correct;
   • child pages are still linked;
   • headings are in the expected order;
   • <details> blocks survived;
   • Mermaid diagrams render as fenced mermaid;
   • no prohibited meta text was inserted;
   • evidence boundaries are clear.

If Notion tools are unavailable, ask the user to reconnect Notion and stop before pretending to update it.

Final Response After Updating

Keep the final answer short:

• link the updated page;
• summarize what changed;
• mention verification;
• ask only for the highest-value missing evidence.

Do not paste the full Notion content back unless the user asks.