roger-genius-noteweaver

name: roger-genius-noteweaver description: >- 深度笔记与面试问题生成器。能从某个主题或现有笔记中，生成简洁而深刻的知识笔记，并在适当时生成高质量的面试问答。兼顾深度与简洁，强制严格格式，并包含交互式用户提示。

When to Use

Activate this skill when the user requests:

• Organize a technical topic into study notes
• Generate or restructure interview questions from note files
• Produce both notes and interview questions for a given topic

Interactive Startup Flow (Mandatory)

Step 1: Input Source Selection

Before anything else, use the AskUserQuestion tool to ask the user how they want to provide the topic:

• Question: 请选择笔记的输入来源：
• Header: 输入来源
• Options (with preview to simulate placeholder hints):
  1. 基于知识点 — Description: 直接输入一个知识点主题来生成笔记 / Preview:

     请输入知识点主题
     
     例如：面向对象思想
     

  2. 基于文本文件 — Description: 从已有的 Markdown 文件中读取内容来生成笔记 / Preview:

     请输入文件路径
     
     例如：C:\Notes\xxx.md
     

After the user selects:

• 基于知识点: The user will type the topic via the "Other" option or in a follow-up message. If neither happened, send a text prompt with inline-code placeholder hint and wait for the user's next message:

  请输入知识点主题：例如：面向对象思想

• 基于文本文件: The user will type the file path via "Other" or in a follow-up message. If neither happened, send a text prompt with inline-code placeholder hint:

  请输入文件路径：例如：C:\Notes\xxx.md

  After receiving the path, use the Read tool to load the file content and use it as the source material for note generation. If the file cannot be read, inform the user and ask for a corrected path.

Step 2: Generation Type Selection

After obtaining the topic/source, present the following options and wait for a reply:

请选择要生成的内容：

1. 仅笔记
2. 仅面试题
3. 笔记 + 面试题
4. 取消

• If the user selects 4, immediately stop and do nothing.
• If the user selects 1, 2, or 3, then ask for the storage location:

请选择文件保存位置：

1. 当前工作目录
2. 自定义路径（请输入路径，例如：./docs/）

• Use the user-provided path as the output directory (create it if it does not exist).

Anti-Laziness & Quality Mandate

• Never produce superficial summaries. Every concept must be explained with depth (mechanisms, trade-offs) but in a concise manner.
• Never use placeholders or cut off explanations.

Research Protocol

1. Identify at least 3 authoritative sources (official docs, tutorials, specifications).
2. Read, cross-verify, and extract core concepts, common pitfalls, and best practices.
3. Build a concept map (internal outline); ensure coverage but only keep the most valuable parts in the output.
4. Before writing, ask: "Can this be expressed shorter and more precisely?"

Output Files

File Naming

• All output file names must primarily use Simplified Chinese. If English technical terms are needed, use a Chinese-English mixed name (e.g., Spring Boot自动配置.md, Vue3组件通信.md, MySQL索引优化.md).
• Do not use kebab-case or pure-English names.
• If a file already exists, ask whether to overwrite.

Notes Splitting Rules

When the user selects notes generation (1 or 3), analyze the topic content and split the notes into two categories:

1. Configuration notes — Any content related to installation, setup, environment configuration, dependency configuration, tool configuration, etc. If the topic involves multiple technologies or tools each with their own configuration, split them into separate configuration note files, one per technology/tool. Name each file descriptively, e.g., Vite配置.md, ESLint配置.md, TypeScript配置.md.

2. Main body notes — All remaining conceptual, principle-based, and practical knowledge. Do not split the main body into multiple files; keep it as a single file. However, reorder the content within the main body file to follow a logical learning sequence (foundational concepts first, then intermediate topics, then advanced/applied topics).

Completeness Review (Post-Split)

After splitting notes into configuration and main body files, perform a completeness review before finalizing:

1. Configuration notes review — Check each configuration note for missing or incomplete steps:

   • Missing installation or prerequisite commands
   • Missing environment variable or dependency setup
   • Incomplete configuration examples (e.g., required fields omitted)
   • Missing verification/testing steps after configuration
   • Missing version compatibility notes or known caveats

2. Main body notes review — Check the main body note for missing knowledge points or logical gaps:

   • Core concepts that are referenced but never explained
   • Missing "why" — the reasoning or motivation behind a pattern or practice
   • Missing common pitfalls, gotchas, or typical mistakes
   • Logical jumps where intermediate concepts are skipped
   • Missing connections or comparisons between related concepts

3. Cross-file consistency check — Ensure configuration notes and main body notes work together:

   • Any configuration referenced in the main body must have a corresponding configuration note
   • The main body should not duplicate detailed configuration steps already covered in configuration notes
   • Terminology and naming must be consistent across all files

If gaps are found, fill them in directly. Do not prompt the user for each gap — fix them silently and include a brief summary of additions in the final output message to the user.

File Generation Summary

Generate the files according to the user's selection:

• If notes are selected: produce one main body note file + one or more configuration note files (only if configuration content exists in the topic).
• If interview questions are selected: produce one interview questions file.
• If both: produce all of the above.

Example output for a topic "Vue3项目搭建":

• Vue3项目搭建-笔记.md (main body)
• Vite配置.md (configuration)
• ESLint配置.md (configuration)
• Vue Router配置.md (configuration)
• Vue3项目搭建-面试题.md (interview questions, if selected)

Knowledge Notes Format

All note files (configuration notes and main body notes) must follow the formatting specification defined in the roger-genius-note-style skill (/roger-genius-note-style). Before writing any note content, load and apply all rules from that skill, including: headings, paragraphs & layout, code & diagrams, emphasis, further reading, and depth vs. brevity requirements.

Interview Questions Format

Generation Conditions

• Only generate this file if the topic has sufficient technical depth. If the topic is too basic (e.g., "Introduction to HTML tags"), omit the file and briefly explain why.
• Quality over quantity: the number of questions is not fixed; each must test understanding or application. Avoid simple definition questions.

Structure

• Start with # {Topic Name}.
• Group questions under ## headings that mirror the knowledge modules; keep these headings short.
• Each question must follow this exact format:
  • Question line: starts with - and the question text.
  • Answer block: an indented ```txt code block. The answer must be complete and self-contained, with manual line breaks inside the block so that no line exceeds 80 characters. This ensures proper wrapping when displayed.

Answer Depth

• Each answer should be at least 5–7 sentences, covering what, why, how, and common mistakes.
• Avoid questions that can be answered in one sentence, unless followed by a deeper "explain" clause.

Pre-Finalization Checklist

• All concepts are explained deeply but without verbosity
• Note files pass the roger-genius-note-style formatting checklist (headings, overview prefix, diagrams, emphasis, further reading, depth)
• If interview questions were generated, every answer block has manual line breaks and questions meet depth requirements
• Completeness review performed: no missing steps in configuration notes, no missing knowledge points in main body notes
• Cross-file consistency verified: no duplicated content, consistent terminology
• Configuration content is split into separate files per technology/tool
• Main body note content is ordered by logical learning sequence
• All file names use Simplified Chinese (with English terms mixed in where needed)
• Files are saved to the user-chosen location