복고풍 픽셀 스타일의 세 장면 영상을 Hyperframes용 HTML로 만듭니다. 제목과 색상을 바꾸고 장면 전환과 움직임을 갖춘 구성으로 완성합니다.
- 픽셀 스타일의 소개 영상을 만들 때
- 세 장면 영상의 내용을 교체할 때
- HTML에서 장면 전환을 확인할 때
HTML에서 생성한 PPTX를 원본과 비교해 글자 잘림, 바닥글 겹침, 기울임꼴 손실을 조사합니다. 원인을 정리하고 배치 규칙을 수정한 뒤 다시 출력하고 검증합니다.
Audit a python-pptx export against its source HTML deck, identify layout/content drift (footer overflow, cropped content, missing italic/em, lost styling, off-rhythm spacing), and re-export with strict footer-rail + cursor-flow layout discipline. Use this skill whenever the user has a .pptx that was generated from an HTML slide deck and asks to compare/audit/verify/fix the export — including phrases like "compare ppt with html", "fidelity audit", "fix the pptx", "ppt is cut off", "footer overlap", "italic missing in pptx", "re-export the deck", "pptx-html-fidelity-audit", or any case where a python-pptx → HTML round-trip needs verification or repair. Also trigger when the user shows you a deck.html and a deck.pptx side by side and is debugging visual differences.
pptx-html-fidelity-audit는 HTML 슬라이드와 여기서 생성한 PPTX를 비교해 내용과 배치의 차이를 조사합니다. 각 도형의 위치, 크기, 글자 서식을 추출하고 글자 잘림, 바닥글 겹침, 기울임꼴이나 색상 손실을 심각도별 표로 정리합니다. 공통 원인을 찾고 본문 영역의 아래쪽 경계와 위에서부터 블록을 순서대로 배치하는 규칙을 적용해 다시 출력합니다.
HTML에서는 정돈되어 있던 자료가 PowerPoint용으로 변환되면서 흐트러질 때 유용합니다. 개별 슬라이드를 수정하고, 가운데 정렬이나 여백 결정 방식처럼 출력 과정에 공통으로 적용되는 문제도 검토할 수 있습니다.
원본 HTML과 생성된 PPTX가 모두 필요합니다. 추출과 배치 검증에는 python-pptx를 사용합니다. 수치 검증은 도형이 경계를 넘는지 확인하며, 글꼴 렌더링과 글자 간격 문제는 스크린샷을 눈으로 확인해야 할 수 있습니다.
이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.
AI가 SKILL.md의 내용만을 근거로 4가지 관점에서 판정했습니다. 스타 수나 인기도는 판정에 넣지 않았습니다.
총점은 각 항목을 A=25점, B=15점, C=5점으로 더한 값입니다. 2026년 10월 20일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
A repeatable workflow for catching the ways a python-pptx export silently drifts from its HTML source — and fixing them with a layout discipline that prevents the same regressions on the next pass.
The user has:
A source HTML slide deck (typically a single-file deck with <section class="slide"> blocks):
<section class="slide light">
<div class="chrome">2026 · Q2 review</div>
<span class="kicker">Pillar 03</span>
<h2 class="h-xl">Shipping <em>velocity</em> doubled</h2>
<p class="lead">…</p>
<div class="foot">page 5 / 14</div>
</section>
A PPTX file generated from that deck via python-pptx (or similar).
A suspicion (or visible evidence) that the PPTX doesn't match the HTML — text bleeding into the footer, italic words gone flat, hero slides not centered, sections cropped, tag styling lost.
If the user only has one of those two artifacts, this skill doesn't apply yet — first generate the missing one, or ask the user to provide it.
PPTX is a fixed-canvas, absolute-positioned medium. HTML is a fluid, flow-based medium. A naive python-pptx export pins each block at hand-picked (top, left) coordinates, which works for the first slide it was tested on and silently fails for every other slide whose content has different intrinsic height. The result is the most common drift modes:
top + height crosses into the footer row.7.5" (16:9 canvas).<em> in HTML never gets run.font.italic = True.MARGIN_TOP instead of computing center.Every one of these is a layout discipline problem, not a content problem. Once you adopt the discipline, they stop happening.
The audit is five steps. Don't skip any of them — the discipline only works if the audit produces a real list of issues to drive the re-export. A fix-without-audit pass tends to leave half the issues alive.
Run scripts/extract_pptx.py <path-to.pptx> > pptx_dump.json. The script walks every shape on every slide and dumps text, position (top / left), size (width / height), and per-run typography (font name, size pt, bold, italic, color). This is the actual state of the export — don't trust the export script's intent, trust the dump.
For 14-slide decks, the dump is ~30–60 KB and human-readable.
Read the source HTML and enumerate <section class="slide"> blocks. For each, note:
light / dark / hero light / hero dark).chrome row text (top metadata).kicker (small uppercase eyebrow above the headline).foot row (bottom metadata).<em> or italic-styled spans — italic is the silent regression.Map each HTML slide to a PPTX slide index. For decks following the convention "slide 1 = cover, slide N = closing", the mapping is positional.
For each slide, walk shapes from the dump and check against expected layout rules. Use this exact table format — the severity column is what drives the fix priority:
| Slide | Issue | Severity |
|---|---|---|
| 1 cover | meta-row 底端 6.95" 蓋過 footer (6.7") | 🔴 |
| 5 checklist | row B 步驟描述底端 7.2" 切到 footer | 🔴 |
| 8 3E | 收束段落直接坐在 footer 起點 | 🔴 |
| 9 on-day | step 描述底端剛好碰 footer,無安全距 | 🟠 |
| 多處 | em (Playfair italic) 未保留 | 🟡 |
Severity rubric:
After the table, write a short root-cause section: 90 % of the issues usually come from 2–3 systemic causes (e.g. "no footer rail enforced", "hero stacks pinned to MARGIN_TOP instead of centered", "italic never propagated"). Naming the systemic causes makes the re-export script much smaller and more correct.
This is the load-bearing technique. See references/layout-discipline.md for the full rules; the summary:
Define the rails up front, once, for the whole deck:
from pptx.util import Inches
CANVAS_W = Inches(13.333) # 16:9
CANVAS_H = Inches(7.5)
MARGIN_X = Inches(0.6)
MARGIN_TOP = Inches(0.5)
CONTENT_MAX_Y = Inches(6.70) # NOTHING in content area may cross this
FOOTER_TOP = Inches(6.85) # footer row pinned here, edge-to-edge
Customizing the rails. The defaults above suit a 16:9 canvas with a slim footer. If your design system uses a wider footer or a 4:3 canvas, override these constants in your export script and pass the same values to
verify_layout.pyvia--content-max-y/--canvas-h/--canvas-w. Seereferences/layout-discipline.md§1 for the full constant table.
Use a cursor for content blocks instead of pinning each block at an absolute y:
class Cursor:
"""Advances down the slide; refuses to cross the footer rail."""
def __init__(self, y_start, cap=CONTENT_MAX_Y):
self.y = y_start
self.cap = cap
def take(self, h, gap=Inches(0.12)): # ~1 line of whitespace at 14pt; tighten/loosen per design system
top = self.y
self.y = top + h + gap
if self.y > self.cap:
raise OverflowError(
f"cursor at {self.y} exceeds footer rail {self.cap}; "
f"reduce block height or split slide"
)
return top
For each slide, instantiate Cursor(MARGIN_TOP) and take(height) each block in reading order. The slide refuses to render if any block would cross the rail, so overflows become loud build errors instead of silent visual bugs.
Hero (vertically-centered) slides use a budget instead of a cursor:
def hero_layout(blocks):
"""blocks = list of (height, gap_after) tuples in reading order."""
total = sum(h + g for h, g in blocks)
y_start = (CANVAS_H - total) / 2
return Cursor(y_start)
That single change kills "hero slide content sticks to top" — the most common hero defect.
Tighten box height to fit text + minimal padding. PowerPoint reveals shape bounds when they overlap (selection halos, Z-order conflicts), and an oversized box can visually cross the footer rail even when the text inside doesn't. Compute box height from text metrics + ~0.05" pad, not from generous wrappers.
Preserve italic / em explicitly:
def add_run(p, text, font, size_pt, italic=False, bold=False, color=None):
r = p.add_run()
r.text = text
r.font.name = font
r.font.size = Pt(size_pt)
r.font.italic = italic
r.font.bold = bold
if color:
r.font.color.rgb = color
return r
When walking HTML, detect <em> / <i> / inline style font-style: italic and pass italic=True. Use the EN serif face (Playfair Display, Source Serif, or fallback Georgia) for italic display copy — the CJK serif typically has no italic and looks broken if you try to italicize it.
For deeper font issues that the layout rails can't catch — variable-font traps where PowerPoint silently swaps to Calibri / Microsoft JhengHei, missing <a:ea> slot causing CJK runs to fall back, fake-italic on Han characters — read references/font-discipline.md. The five layers there cover everything verify_layout.py can't see.
After writing the new .pptx, run scripts/verify_layout.py <path-to.pptx>. The script:
top + height ≤ CONTENT_MAX_Y for content shapes (footer/page-number shapes are allowed below the rail).top + height ≤ CANVAS_H for all shapes (no off-canvas).left + width ≤ CANVAS_W and left ≥ 0.Zero violations is the gate for "this re-export is shippable". Don't claim the audit is fixed without running the verifier — the human eye misses 1–2 mm overflow at zoom-out, the script doesn't.
After Step 5 passes, report:
.pptx.The user is reading for two reasons: confirming the visible bugs are fixed, and trusting the systemic fix is right. Cover both.
scripts/extract_pptx.py — dump every shape on every slide as JSON. Run before the audit. Important: also run on the original export to compare, and on the re-exported one to confirm.scripts/verify_layout.py — post-export rail checker. Returns nonzero exit code on violations so it slots into a CI pipeline if needed.references/layout-discipline.md — the full footer-rail + cursor-flow rule set with code snippets for each common slide type (hero, content, pipeline, two-column, observation grid).references/font-discipline.md — five-layer font audit: mapping, presence, variable-vs-static traps, the three XML language slots (latin / ea / cs), CJK + Latin italic interaction.references/audit-table-template.md — copy-pasteable table template with severity legend.Read the references when:
layout-discipline.md.Calibri / Microsoft JhengHei in the XML → font-discipline.md.audit-table-template.md.italic=True, and the result looks mechanically deformed. Italicize only runs whose primary script supports italic — Latin, Cyrillic, Greek. See references/font-discipline.md Layer 5 for the implementation pattern.MARGIN_TOP for hero slides. Hero slides need budget centering, not top-anchored. This is the most common hero defect and the cheapest to fix.An earlier iteration of this skill leaned on visual diffing — render the
.pptx through Keynote → PDF → PNG, screenshot the HTML through Chrome
headless, stitch them side-by-side with magick. It worked, but with
three sharp drawbacks:
magick and
font-discovery commands vary across OSes; CI pipelines on Linux can't
reproduce the chain.python-pptx.Geometry-based verification gives up one thing the visual diff is good
at: catching cases where shape positions are correct but the rendered
glyph looks wrong (font fallback, kerning bugs, missing weight). When
that case appears, fall back to a manual screenshot review — the
five-layer audit in references/font-discipline.md covers most of the
underlying causes.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
복고풍 픽셀 스타일의 세 장면 영상을 Hyperframes용 HTML로 만듭니다. 제목과 색상을 바꾸고 장면 전환과 움직임을 갖춘 구성으로 완성합니다.
소셜 미디어 광고와 검색 광고의 제목, 설명, 본문을 작성하고 표현을 반복해서 수정합니다. 광고 문구 후보를 준비하고 개선안을 검토할 때 활용합니다.
어두운 배경과 세리프 글꼴로 패션 잡지 같은 세 페이지 동적 연출을 만듭니다. 글자 단계 표시와 장면 전환을 포함한 단일 HTML 파일로 출력합니다.
브라우저에서 페이지를 살펴보고 클릭, 입력, 화면 캡처, 정보 추출을 수행합니다. OpenDesign의 로컬 미리보기를 중심으로 웹 앱의 동작과 품질을 확인합니다.
AI 음악 앨범의 콘셉트 구상부터 가사 초안, 곡 순서 검토, 내보내기까지 다룹니다. 독립 제작 실험과 브랜드 음악 기획에 활용합니다.
p5.js에서 계산 규칙과 난수로 생성 예술을 만듭니다. 난수의 초깃값을 고정해 같은 그림을 재현하며, 포스터와 동적인 느낌의 정지 이미지, 구도 시안 제작에 활용합니다.