PPT to Visual Notes

What does PPT to Visual Notes do?

A workflow skill for Codex and OpenAI agents with file and image tools. It transforms courseware into easy-to-understand, image-rich, concise yet deep learning notes, delivered in the user's chosen format or note-taking app. This skill is not a standalone PPT converter, nor does it provide file, image generation, or upload capabilities to ordinary chat models that lack them.

Getting Started and Resuming

Read the current user's request, project conventions, and existing progress. Clarify the source courseware, reader background, included/excluded chapters, output directory, target format, collaboration method, and review steps; do not ask for known information again. If no note-taking app is specified, default to standard Markdown plus an image directory; do not specify personal computer drive letters or default upload to any cloud service.

First, check whether the host can read and render the courseware, generate or view images, and produce delivery files. If required capabilities are missing, explain the specific limitations and complete verifiable parts; do not pretend that tools have been run. After preparing a scope plan, first offer the user a chance to review it.

Division of Labor and Step-by-Step Review

The overall Master Controller personally formulates the general outline; each Sub-Controller personally formulates the outline for their chapter/section; the Executor only produces content according to the approved outline. The general outline determines chapter division, order, scope, and learning objectives; the chapter outline confirms knowledge nodes, teaching order, keys, and illustration plans. Do not delegate the overall drafting of outlines to the Executor, then replace the Master Controller's role with review.

The general outline is created and self-checked by the Master Controller, then displayed; chapter outlines are created by the corresponding Sub-Controller and reviewed by the Master Controller. Both types of planning outputs proceed to the next step only after passing the user check rules for this step. During the production phase, use a flow of Executor production → Sub-Controller review and rework → Master Controller re-review. If the Executor finds gaps in the outline or technical errors, it reports the evidence and suggestions, and the Sub-Controller revises the chapter outline; matters involving overall structure or cross-chapter scope are escalated to the Master Controller, who makes a decision. After approval and clearance for this step, execution proceeds. The Executor may choose wording, image prompts, and formatting details within the established framework, but must not add, remove, or rearrange the teaching structure on its own.

At the start, refer to Workflow and Roles to select the collaboration method achievable in the current environment: when the user explicitly authorizes and the host supports it, create a new independent conversation for each chapter with its own Sub-Controller and Executor; if the user requires strictly independent conversations but the tool does not support it, first explain the limitation, and do not impersonate with internal agents. If the user does not require independent conversations, phases can be executed and reviewed within the current conversation, but planning and production responsibilities must still be distinguished, and the independence of review must be reported honestly. Do not silently create or send other conversations for using this skill.

By default, after each sub-step is reviewed by the Master Controller, show the actual output and conclusions, ask the user if they want to inspect, then wait for a clear confirmation. If the user says "no need to check/continue," only the current step is cleared; if the user wants to check, wait for the inspection feedback and a clear continue confirmation. Silence, timeouts, or completion by lower-level roles do not constitute clearance. If the user explicitly specifies autonomous advancement for one chapter or the entire task, record the scope of that instruction and execute according to the current directive.

Sub-steps are pre-divided based on reviewable outputs: Master Controller's general outline and scope, Sub-Controller's chapter outline and illustration plan, Executor's finished images and illustrated text, packaging/validation, and import into the user-chosen platform. Each phase has a clearly designated planner or producer. If the Master Controller does not pass something, first give the user an inspection opportunity, then arrange rework. While waiting, do not dispatch the next step or create roles for the next chapter in advance; after receiving feedback, review the changes without frequent polling or follow-ups.

Content and Teaching Diagrams

1. Read the courseware by chapter and original page order. Use the courseware parsing/rendering tools provided by the host; if related skills like presentations:Presentations exist, follow their workflow. Check diagrams, equations, screenshots, and necessary notes; do not treat text extraction as equivalent to visual verification. Extract raw material once; each chapter shares it read-only.
2. In the chapter outline, the Sub-Controller determines the coverage mapping from original page numbers to knowledge nodes, teaching priorities, and the scope of any extensions. The Executor explains concepts, principles, reasons, operations, applicable conditions, and common mistakes according to the approved outline. First explain the plain meaning; define terms upon first occurrence nearby. For formulas and code, explain their meaning and purpose. Examples come from the current courseware and the current project; do not copy chapter names, specific objects, or backgrounds from other projects.
3. The Sub-Controller inspects core difficulties according to the Content and Teaching Diagram Standards, then formulates an illustration plan and checklist. The Executor actually generates, saves, and self-checks images according to the approved plan; it does not undertake the design of the teaching diagram structure. When graphics help explain structure, flow, process, timing, states, or differences, the plan defaults to actually calling the available GPT image generation function; if the user specifies another image creation method, follow their choice. When using existing images, the plan identifies which specific image and how it adequately explains the current issue.
4. Choose from knowledge overviews, principle illustrations, sequential steps, method comparisons, correct/incorrect contrasts, or application scenario diagrams based on the current difficulty. If the original image is too dense, keep the original and create a simplified teaching version. Images and text together explain reading order, mechanism, and boundaries; acceptance is based on actual teaching effectiveness, not a fixed number of images or generation ratio.
5. Before calling the image tool, verify facts and describe the reader, teaching objective, layout, accurate annotations, and unalterable conditions. If the environment has an imagegen skill, follow its tool workflow; only commit to capabilities the host can actually provide; do not silently switch to an API that requires additional authorization or fees. If the user specifies a model version, record it only when the actual tool can be configured and confirmed.
6. Check each image for text, relationships, directions, states, values, formulas, and units. Save prompt, tool response, source image, and file fingerprint. Clearly distinguish sources, generated images, and actual test results; planned generation does not count as generated. For critical facts, consult current primary sources and provide direct links at the relevant nodes; errata and extensions must be differentiated from the original courseware content.

Output and Original Courseware Attachments

Select the format according to Output Format and Validation:

• Default: Standard Markdown with relative path images in the same package; deliver together when moving or sharing.
• When offline single-file reading is needed: Self-contained HTML; check actual browser rendering for images, table of contents, narrow screen, and long content.
• When a specific note-taking app is specified: First verify a sample in that app, then generate a platform-adapted copy; do not generalize success on one platform to others.
• When Mubu is explicitly chosen: Also read Mubu Adapter and use the PNG embedding method confirmed by the current sample. Mubu is an optional adapter, not the default target.

Preserve the mapping between each chapter's source courseware and page numbers. Include the corresponding original PPT as an attachment in the delivery package, or upload it to a platform chosen by the user that supports attachments; for merged courseware, extract the chapter by original page numbers; for single-chapter courseware, use the original file directly, preserving content, page order, and required resources. Do not publish the original courseware, screenshots, or personal creations with this skill to a code repository.

Only execute external import/upload when the user has authorized the target location and action; otherwise, deliver local files and clearly mark them as "to be imported/uploaded." If the platform does not support PPT attachments or cannot accurately split them, explain the limitation and provide the original file and page range that can be opened; do not falsely claim that attachments have been uploaded or split. Do not silently delete or replace existing remote content.

Optional PNG Tool

scripts/Image_Embedding_Tool.py requires Python 3.10+ and Pillow. It only converts restricted Markdown placeholders to PNG Data URIs and compares them; it does not parse PPTs, generate teaching images or HTML, or perform platform uploads. Use it only when the target format truly supports embedded images; normal Markdown does not need it by default.

python <skill-dir>/scripts/Image_Embedding_Tool.py embed --input body.md --images images --output embedded_note.md --manifest image_manifest.json
python <skill-dir>/scripts/Image_Embedding_Tool.py verify --input embedded_note.md --manifest image_manifest.json

Body placeholders look like [[Image:process_explanation.png|Key steps and relationships in the current knowledge point]]. Create the parent output directory first; existing files will not be overwritten. Replace placeholder paths in the command with actual local paths. The manifest contains absolute paths to local source files; it is only for local re-verification; check and clean it before public sharing.

Acceptance and Handover

Review actual files, source page numbers, teaching depth and comprehensibility, images and their generation evidence, necessary calculations/code checks, chosen format, and original courseware attachment. Report which items were fully checked, sampled, or not executed; record local validation, platform import, and actual hardware tests separately; do not substitute one for another.

The working directory records scope, current step, roles and authorizations, file fingerprints, issues and rework, user's response for this step, import status, and next action. When resuming, first verify already authorized work and the next step waiting for clearance; do not backfill permissions. The learning body contains only knowledge, figure captions, necessary examples, and sources; process logs are archived separately. Finally, provide the user with a learning entry point at the specified location and a clear list of remaining tasks.