Da Vinci 4744 portable workflows. Read the relevant workflow for the current task.
Source code is supplied in DaVinci-Code-Reference.txt. Branding is embedded in the reference deck. Individual assets can be attached from the skill package when needed. Do not assume ZIP files can be read as Project knowledge.

# Da Vinci 4744: visual and editorial reference

This is the team's approved space theme for these meeting materials, established in October 2026. It is a reusable theme, not a requirement that every topic be about space.

## Actual assets
Use the supplied white symbol in `assets/logo.png` and supplied lettering in `assets/wordmark.png`. The separate name and number graphics are `assets/name.png` and `assets/number.png`. Never retype or redraw the official lettering, replace the symbol with a generic Vitruvian man, or generate an approximation with AI. Keep aspect ratios and clear space. When stacking the name and 4744, align their **visible alpha bounds**, not the transparent image boxes. Side-by-side wordmark and symbol is also approved.

Use `assets/space-hero.png` for covers, pauses and closing scenes, and `assets/space-content.png` for teaching content. The planets, rover, mountains, orbit lines and engineering grid are background decoration. Avoid covering readable text with additional decorative elements.

## Colors and fonts
Background blue #3F6387; dark navy #091C33; white #F8FBFF; gold #FFDBA2; supporting light blue #69BEED. Red lettering on the supplied white rocket is intentional. Rubik Regular and Rubik Bold are bundled. Use another font only if the user requests it or Rubik cannot be loaded; disclose a material substitution.

For a 1280×720 slide, use a 64 px outer margin, about 48–56 px headings, 26–32 px normal body text, and 22–24 px only where necessary for a clearly structured dense layout. The reference header rule is around y=173, the wordmark footer around y=652. Adapt whitespace to content instead of mechanically filling every area.

## Language and audience
Default to Hebrew, genuine RTL paragraphs, right alignment and right-to-left chronological flow. Preserve English brand names, code and numbers in their normal internal order. Do not reverse Hebrew characters in editable PPTX text. Python-bidi is appropriate only for raster frames when the drawing engine lacks shaping; applying it to native PowerPoint text corrupts editability/order.

Speak to capable teenagers, mentors and adults as peers. Use clear, natural, composed Hebrew and specific teaching language. Avoid children's-show narration, exaggerated enthusiasm and the spoken salutation “צוות דה וינצ׳י”. Do not claim the audience is university students unless the new brief says so. Keep visible brand graphics even when the narration does not say the team name.

## New content and revisions
The old welcome meeting and spaceship challenge are examples. Do not reuse 21.10.2026, the 2027 season, the school renovation status, department assignments, challenge rules, scores or meeting schedules in a new topic unless the user supplies/approves them. Keep unknown dates out of the audience-facing copy and ask only when they affect the outcome. A user correction applies to the latest version, including earlier accepted corrections.

Use genuine supplied team/robot/venue photos where relevant. Do not invent documentary images of the workshop, school or team. If an attachment is missing, say so and continue independent work without pretending to have seen it.


---
name: davinci-presentations
description: Create or revise branded Hebrew Da Vinci 4744 meeting and training presentations, using editable slides and the supplied space theme. Use for team slide decks and PDF review edits.
---

# Da Vinci presentations

Create a usable presentation for the mentor's current meeting. Default deliverables are an editable PPTX suitable for import into Canva, plus a PDF preview when export is available. Preserve the user's chosen destination and format.

Read [the brand reference](references/brand.md). Use the actual assets in `assets/` and inspect `assets/reference-deck.pptx` or `assets/visual-reference.pdf` for the visual system. Their old meeting content is a design example, not current facts. This skill is self-contained and works through a model's available file tools; it does not require Codex, an MCP server, local Mac paths or another custom skill.

## Build the right deck
Extract the topic, audience, teaching goal, meeting duration, desired slides, source material and required activity. Infer routine choices. Ask only about missing information that materially changes the deck; continue independent work while waiting. If the mentor requests only a plan, deliver a plan. Otherwise create the file, not just an outline.

Choose slide structures that explain the content: a diagram for relationships, a timeline for sequence, an image with concise explanation, a comparison, or a question/activity pause. Match the requested order and count. Avoid copying the welcome deck's 12-slide agenda into unrelated training. Use a large centered questions slide without a second standalone question mark when appropriate. For an activity with unspecified rules, use a title slide until rules are supplied rather than inventing them.

Use the host's PowerPoint/presentation creation tool when available. In a code environment, an ordinary portable presentation library is fine. Text, diagrams, arrows and timelines should remain editable. Do not flatten the whole deck into images. For Hebrew native text, set paragraph RTL, correct alignment and Hebrew run language. `scripts/pptx_rtl.py` can inspect and repair native Hebrew paragraph direction without re-exporting media.

## Apply feedback
Start from the newest approved PPTX, even when comments were made on an older PDF. Read the region and its surrounding content. Make the requested change while retaining unrelated text, image crops, branding, earlier alignment fixes and animations. Do not lose a GIF or embedded video through an unnecessary whole-deck round trip. Preserve source copies and deliver a new revision. Reflow dense content instead of shrinking everything.

## Finish
Render the completed slides when tools allow it. Inspect every changed slide at readable size, and check the deck for accidental changes. Check Hebrew/English ordering, title fit, text clipping, logo proportions, timeline direction, arithmetic supplied by the user, and whether content remains editable. Package inspection alone does not prove visual correctness.

Return the actual PPTX and PDF if produced. If the environment cannot create/export files, explain the concrete limitation and provide a complete slide-by-slide script plus an executable source project when possible. Never claim a deck or PDF exists if only text was generated, and never promise perfect Canva fidelity without checking an actual import.

Read [the Hebrew and PDF export guide](references/hebrew-pdf.md) before exporting a Hebrew deck. A correct PPTX does not prove that its PDF conversion is correct. Inspect the actual PDF pages, including punctuation, word order and mixed Hebrew/English. If the PPTX is correct but the PDF is wrong, preserve the PPTX text and fix the export route. Do not reverse or visually reorder native text to compensate for a broken converter. If a reliable PDF export is unavailable, deliver the verified PPTX with clear export instructions and identify the PDF as unverified; never package a known-broken PDF as final.

Read [layout patterns](references/layout-patterns.md) when choosing layouts or importing to Canva. The [example brief](references/example-brief.txt) shows a new topic that should not inherit the welcome meeting's facts.


# Layout patterns and portability

- Keep the approved theme and use the simplest layout that explains the new material. Avoid turning every slide into a set of cards.
- Annual sequence: editable right-to-left line, milestone dots, date labels, and a visible “אתם כאן” arrow only where the current position is known. Use two chronological rows if the events cannot fit legibly in one.
- Departments: a 3×2 grid can accommodate six teams, but retain the current department names and responsibilities supplied by the mentor rather than treating the old example as permanent.
- Technical explanation: one dominant diagram and 2–4 concise labels. Keep mathematical/code notation internally LTR.
- Photos: preserve the subject and aspect ratio. The source deck contains real team and robot photos, not a documentary photo of the workshop.
- Questions: a large centered title and a short centered subtitle. A second giant “?” is unnecessary.
- Large branding: use the exact symbol plus the supplied single-line wordmark. For stacked name/number graphics, align the alpha-visible bounds.
- Canva: provide PPTX with editable shapes/text and separate MP4 for complex animation. Fonts, media and animations may import differently; check a real Canva import when that capability is available, otherwise say it was not verified.
- PDF annotations: comments can refer to an older version. Apply them on the current source and keep previous accepted edits. Missing files are missing inputs, not permission to fabricate their contents.


# Hebrew slides and PDF export

Treat the editable deck and its PDF as two separate deliverables. The exported PDF can reorder words or punctuation even when PowerPoint displays the PPTX correctly. An XML RTL audit cannot certify PDF rendering.

## Native PPTX
Store Hebrew text in natural logical order, for example `מה נעשה היום?`. Set paragraph RTL and the intended alignment, and use a Hebrew-capable font. Keep English phrases and numbers in their normal internal order. Do not use python-bidi, reverse characters, reverse word lists, or bake visual ordering into editable PowerPoint text.

## Export and inspect
1. Keep an unchanged copy of the newest approved PPTX.
2. Export a PDF using a renderer that actually supports the deck's Hebrew text and fonts.
3. Render the PDF into page images. Compare every page with the correct deck, at readable size. Check sentence order, question marks and full stops, wrapped lines, brackets, bullets, numbers, English terms and layout.
4. If the PDF alone is wrong, change the exporter or its font/text shaping configuration. Do not rewrite the good PPTX into reversed text to compensate.
5. If the runtime cannot produce a verified PDF, provide the correct PPTX and this practical route: open it in PowerPoint and use its native PDF export. Alternatively import the PPTX into Canva, check its text and layout there, then download a PDF. Canva import can alter formatting, so inspect that result too. Menu names depend on the app language and version.

A raster PDF made from verified slide renders can preserve appearance when no faithful text renderer is available, but disclose that its text is not selectable/searchable and keep the editable PPTX as the source. Do not flatten the PPTX itself.

## Mentor correction request
Use this when an AI-created PDF is wrong:

״קובץ ה־PPTX מוצג נכון, אבל ב־PDF סדר המילים וסימני הפיסוק השתבש. שמור על הטקסט המקורי ב־PPTX. תקן את תהליך הייצוא ל־PDF, ופתח את דפי ה־PDF כתמונות כדי לוודא שהעברית וסימני הפיסוק מוצגים נכון לפני המסירה. אם אי אפשר לייצא נכון בסביבה הזו, תן לי את ה־PPTX והוראות לייצוא מתוך PowerPoint או Canva.״


---
name: davinci-videos
description: Create or revise branded Hebrew Da Vinci 4744 educational videos with Python motion graphics, mature dual-voice Gemini narration, music, effects and editable source plans.
---

# Da Vinci videos

Produce an engaging, understandable video for the current teaching goal, using Python or equivalent available video tools. Default to a 16:9, 1920×1080 MP4 with Hebrew captions, the supplied branding, mature male/female narration, suitable music/effects and reusable source files. Honor a different format or length when requested.

Read [brand and audience guidance](references/brand.md). Read [the production guide](references/production.md) for narration, runtime choices and rendering. This is a portable file-based skill: do not require Codex or assume a browser chatbot has API/network access merely because a subscription is paid.

## Plan and produce
Derive the content and factual rules from the mentor's current brief. Choose scene types that explain that topic. Use motion to communicate cause/effect, assembly, comparisons, process and timing. Keep transitions short enough to preserve comprehension. The spaceship challenge is one example, not a compulsory topic, script, nine-scene structure, rocket prop or countdown for every video.

Create a JSON scene plan with exact narration and on-screen copy. Use the bundled `scripts/render_video.py` for title, teaching points, steps, timeline, metric, question and image scenes, or extend its native Python scene function for a technical demonstration. `examples/new-topic.json` is a separate topic, and `examples/spaceship.json` selects the existing specialized challenge animation. Adapt the plan to the brief rather than presenting an unchanged example as new work.

Use Gemini TTS for final narration by default, with alternating Charon (male) and Gacrux (female), native Israeli Hebrew, measured professional delivery, restrained emphasis and natural pauses. Do not use the spoken phrase “צוות דה וינצ׳י”. Voices and provider can change when the user asks. Regenerate only clips whose transcript or delivery settings changed. Keep the visual captions and speech text consistent.

Use a supplied object reference faithfully. For the example rocket, reuse `assets/rocket-reference-style.png`: matte-white cylindrical body, rounded removable nose, white fins and vertical red DA VINCI lettering. In the equipment example each group receives **חלקי חללית**, shown as separate cap and body. These details are specific to that activity, not universal rules for future topics.

## Runtime and honesty
Create the final MP4 directly if the environment supports code, dependencies, FFmpeg and Gemini network access. Receive API credentials through a supported secret store, environment variable or secure interactive input, never pasted into the conversation or included in a shareable file. A ChatGPT/Claude subscription does not supply a Google API credential.

If that environment cannot call Gemini or finish the encode, complete the script, assets, exact scene plan and a runnable notebook. Use the [companion Colab notebook](notebooks/DaVinci-Video-Studio.ipynb) in Google Colab to finish in a browser. Label an unvoiced render **preview**. Do not silently substitute another TTS engine, claim narration was generated when it was not, or describe a preview as final. If the user wants only a script/storyboard, respect that scope.

## Verify and deliver
Inspect key frames, every rule/score diagram and the final decoded file. Check readable Hebrew, audio presence, transitions, no narration cutoffs, appropriate music ducking, and the current requested wording. Final output: MP4, source plan/code/assets, and SRT captions when generated. Preserve previous versions and start revisions from the latest approved plan and visuals. Rendered video captions are not editable in Canva; the JSON/SRT/source are the editing route. Do not promise to publish or distribute the result unless asked.


# Production guide

## Portable runtime
Python 3.10+ with Pillow, NumPy, python-bidi and imageio-ffmpeg. Install from `scripts/requirements.txt` when permitted. FFmpeg is found via imageio-ffmpeg; no Mac-specific path is required. Fonts and brand assets are relative to this skill folder.

Examples:
```
python scripts/render_video.py --plan examples/new-topic.json --preview
python scripts/gemini_tts.py --plan examples/new-topic.json
python scripts/render_video.py --plan examples/new-topic.json --final
```
Use `--preview --width 960 --fps 24` for a fast review. The renderer writes to `work/<plan-name>/output/`. The final command refuses to call a missing/stale narration set final. Re-render after visual edits using `--force`.

`examples/spaceship.json` is the actual supplied activity, with its existing mature Hebrew voice clips in the example cache. They allow a reproducible final example without new API calls. Reusing those clips for a different transcript is not allowed: clip metadata binds the narration text, selected voice and model. New plans need their own narration.

## Scene plans
Read `references/scene-plan.md` when authoring JSON. `title`, `points`, `steps`, `timeline`, `metric`, `question` and `image` layouts cover many meeting intros and explanations. A bespoke physical animation can extend the drawing function. Do not force a mechanism lesson into static title cards when motion would explain it better.

## Gemini and secrets
The bundled client uses Google's Interactions REST endpoint and configurable `GEMINI_TTS_MODEL`, default gemini-3.8-flash-tts. Voices default to Charon and Gacrux. Official documentation: https://ai.google.dev/gemini-api/docs/speech-generation . API/model availability can change: verify the current official documentation if the request fails or model requirements differ. Do not substitute a model/provider silently.

Read `GEMINI_API_KEY` or `GOOGLE_API_KEY` from the runtime environment. The Colab notebook can read a secret named GEMINI_API_KEY or use getpass. Never put the actual key in the scene plan, code, notebook saved output, source ZIP or skill knowledge. This bundle includes no API key. Generation can use the mentor's Google API quota/billing; choose a direct file-generation route only when those capabilities are available, otherwise hand off the prepared notebook.

Generate audio only for new/changed scenes. Read the exact Hebrew transcript, not instructions. The default delivery is composed, professional, conversational and adult, with short pauses. Avoid exaggerated pitch changes and children's-show excitement. Keep both voices unless the brief says otherwise.

## Audio and captions
The reusable score/SFX are synthesized in Python, not downloaded copyrighted tracks. Duck music under speech. Extend a scene if its narration is longer than the planned time. Fade music without clipping the first or final spoken word. Target a comfortable integrated level around -16 LUFS and true peaks below -1 dBTP, while prioritizing natural intelligibility over a numeric target.

Pillow frames use bidi only because they are raster images. Keep the source narration and SRT in ordinary logical Hebrew order. The auto captions are approximately timed by text length within each spoken clip, not word-aligned ASR. If precise captions are requested, align or inspect against the actual audio.

## Final checks
Read and compare the supplied activity rules before rendering. Do not infer new measurements, scoring rules, event dates or safety instructions. Decode the final MP4 with FFmpeg, inspect representative frames and make sure the audio stream exists. Do not claim you listened to a clip unless you actually did. Clearly identify any environment limitation that prevents completion.


# Scene plan

UTF-8 JSON object with `title`, `scenes` and optional `speech` fields. The new-topic example is intentionally separate from the old challenge.

Each scene requires:
- `id`: unique lowercase letters/digits/hyphens/underscores, used for the voice file.
- `duration`: nominal seconds, automatically extended to fit genuine narration.
- `speaker`: `male` or `female`.
- `text`: exact Hebrew narration, also used for captions.
- `layout`: `title`, `points`, `steps`, `timeline`, `metric`, `question`, `image`, or `spaceship`.

Common fields: `heading`, `subtitle`, `items` (list of strings), `chapter` (short running header).
`metric`: `value`, `label` and optional `subtitle`.
`image`: `image` path relative to the plan JSON and optional short `items`.
`spaceship`: `example_index` 0–8 selects the legacy specialized scene for this exact activity only.

Optional `speech`: `model`, `male_voice`, `female_voice`, `style`. A changed transcript, voice, model or style invalidates that clip's narration cache.

Paths must remain within the skill folder. Use unique plan filenames for independent productions. The skill's `work/` holds generated caches/outputs and can be excluded when sharing except for the provided example narration. A new topic can add bespoke visual functions; the schema is a starting point, not a limit on creativity.