Marp Authoring
Load only the authoring detail the deck needs.
| Need | Read or use |
|---|---|
| Directives and syntax | references/syntax-guide.md |
| Common layouts | references/patterns.md |
| Complex layouts | references/advanced-layouts.md |
| Theme behavior | references/themes.md |
| Content and QA guidance | references/best-practices.md |
| Structural precheck | scripts/check_marpit_structure.sh <deck.md> |
| Syntax, render, and visual checks | references/preview-workflow.md |
| Starting point | assets/templates/ |
| Known-good patterns | assets/examples/ |
Workflow
- Inspect the request, existing deck, theme, assets, output target, and repository conventions.
- Start from the nearest template or preserve the current structure. Define valid Marp frontmatter and repository-relative asset paths.
- Author a clear slide sequence with consistent hierarchy and layouts. Use
bgsyntax for full-slide or split-layout visuals; keep logos, icons, and other small visuals inline. - Load color or SVG guidance only when the task requires new palette or illustration work.
- Resolve this skill directory and run the limited structural precheck with
bash "$SKILL_DIR/scripts/check_marpit_structure.sh" path/to/deck.md. It checks delimiters andmarp: truebut does not parse YAML or Marp syntax. Then followreferences/preview-workflow.mdto export with the actual Marp renderer; inspect whether directives took effect, plus the title, densest slide, and every image/SVG slide. Report structural, strict-YAML, renderer, and visual evidence separately; never infer one from another. - Return the deck artifact first, followed by checks performed and any rendering, font, asset, or environment caveat.
Do not claim visual validation from Markdown inspection alone. Temporary renders used only for validation are allowed; do not commit, publish, or deliver another format unless requested.