Skip to content
Back to skills

Mslides

BSecurity

Build, edit by chat, and refresh after UI changes — a step-by-step, per-role user manual for any web app as an editable PowerPoint deck + PDF, made from real Playwright screenshots with numbered callout boxes (step N = box N). Use whenever someone asks for a user manual, user guide, how-to slides, training deck, onboarding guide, SOP walkthrough or "slides showing users how to do X" for a web app, screen, feature or role (admin, editor, viewer, approver…), wants one edition per role, wants to...

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 9, 2026
documentationpythongoshellnodegit

Security analysis

B84/100
  • mediumInstalls packages at runtime which could introduce malicious dependencies
  • mediumInstalls packages at runtime which could introduce malicious dependencies

Pro scans all 20 files and shows the line behind each finding

Scanned October 9, 2026

npx -y skills add JiramedFirst/MSlides --skill mslides --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Mslides?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Mslides
[![Security: B — Skills Directory](https://www.skillsdirectory.com/api/skills/jiramedfirst-mslides/badge)](https://www.skillsdirectory.com/skills/jiramedfirst-mslides)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: mslides
description: Build, edit by chat, and refresh after UI changes — a step-by-step, per-role user manual for any web app as an editable PowerPoint deck + PDF, made from real Playwright screenshots with numbered callout boxes (step N = box N). Use whenever someone asks for a user manual, user guide, how-to slides, training deck, onboarding guide, SOP walkthrough or "slides showing users how to do X" for a web app, screen, feature or role (admin, editor, viewer, approver…), wants one edition per role, wants to update/refresh/re-QA an existing manual because the screens changed, or asks to change a slide's wording, tip, order or table — including in Thai — คู่มือการใช้งาน, คู่มือผู้ใช้, ทำคู่มือ, สไลด์สอนใช้งาน, สไลด์สอนการใช้ระบบ, อัปเดตคู่มือ, หน้าจอเปลี่ยนแล้ว, แก้คู่มือ, แก้ slide — even if they only say "make a manual for this app".
---

# MSlides — user manuals from real screenshots

Builds a deck like this: cover → overview tables → one chapter per role (divider + **one slide per task**:
numbered steps left, cropped screenshot right with matching numbered boxes, a tip) → reference tables → Q&A.
Every element is a native PowerPoint shape, so anyone can edit the deck afterwards. `assets/example/` holds a
complete `manual.json` + `manifest.json`; the plugin repository's `examples/demo/` is the same manual with real
screenshots, replayable capture steps and the tiny app it was captured from — read one before starting.

## Ground rules

- **Capture only against a local or test environment** you control — never production. Capturing writes sample
  data, and `cap.mjs` refuses non-loopback hosts unless `capture.allow_hosts` lists them on purpose.
- **Never handle passwords in the chat.** The user sets them as environment variables (`MANUAL_PW_<ROLE>` or
  `MANUAL_PW`) in their own shell; the scripts read them at runtime and never write or print them. Never type,
  echo, store or ask for a password in plain text.
- **The app's code is the source of truth for wording.** Button names, statuses, field rules and error texts come
  from its i18n message files and source (workflow code, validation schemas) — note `file:line` in the workspace.
  A manual that describes behaviour the code does not have is a defect.
- **Step N points at box N.** Step count must equal mark count (`manual.py` refuses otherwise). A step that
  names a control with no box goes in the tip instead.
- **Output may be confidential.** Screenshots show internal screens and data. Keep the workspace and decks out of
  public repositories and public links unless the user says the app is public.
- **Name everything you create `MANUAL-…`** and log every data tweak in `<ws>/PROGRESS.md` — the next session
  (or teammate) resumes from that file.

## Workflow

Set two variables once per shell: `S=<this skill's directory>` (the folder holding this SKILL.md) and
`WS=<workspace>`; `PY` is the workspace venv's interpreter — `$WS/venv/bin/python` on macOS/Linux,
`$WS\venv\Scripts\python.exe` on Windows (PowerShell: `$S`, `$WS`, `$PY` work the same way).

### 1. Ask (one round)
Ask what you cannot read from the code: which **app / area**, which **roles/chapters** (one edition per role?),
which **template .pptx** (default: the bundled `$S/templates/plain.pptx`), the **workspace folder** (default
`~/Documents/<App>-Manual/`), the **language** (default English), and **how to run the app** locally with test
accounts. Skip anything the user already said. Ask them to export `MANUAL_PW_<ROLE>` themselves.

### 2. Set up the workspace
```
<ws>/manual.json   config (schema: references/content.md) — start from $S/assets/example/manual.json
<ws>/manifest.json one entry per task slide (written during capture)
<ws>/shots/        NAME.png + NAME.json (marks) from cap.mjs
<ws>/steps/        capture step scripts (NN-name.js, one per screen/state)
<ws>/out/          built editions
<ws>/PROGRESS.md   resume notes: chapter status, MANUAL-… records and their state, data tweaks
```
`python3 $S/scripts/setup.py $WS` does the tooling in one go (idempotent): the venv with `requirements.txt`,
Playwright + chromium in the workspace unless node already resolves it (the app's own install via `"repo"` in
manual.json, or `NODE_PATH`), and it names the PDF renderer it found. By hand instead:
`python3 -m venv $WS/venv && $PY -m pip install -r $S/requirements.txt && cd $WS && npm i -D playwright && npx playwright install chromium`.

### 3. Template → `manual.json` "template"
Run `$PY $S/scripts/inspect_template.py <template.pptx> --suggest --render $WS/tpl`: `--suggest` prints a
`"template"` block to start from (layouts by placeholder type, measured `area`, dark colours for a dark theme);
look at the rendered pages and adjust cover/divider/content layouts, the content `area`, colours (dark template ⇒
light text), fonts (`script_font: "Tahoma"` for Thai) and `tip_label`. A dark unbranded template ships too:
`$S/templates/dark.pptx`. Details and worked configs: **references/template.md**.

### 4. Plan the manual from the code
Read the app's routes, i18n message files, workflow transitions and permission checks; write the role list, the
task list per role, and the **capture order** (states only exist in order — a "sent back" banner needs a record
that was submitted and then sent back). If product docs/specs exist, read them too: the manual documents
**current behaviour (code)**; where docs say otherwise, note the discrepancy in PROGRESS.md and tell the user.
Fill `manual.json` chapters, intro tables (who does what, statuses) and reference tables (fields, error → fix).
Rules: **references/content.md**. Show the user the task list before capturing — the cheapest point to change scope.

### 5. Run the app + capture
Start the app with test data (its README). Then the capture REPL
`MANUAL_CONFIG=$WS/manual.json node $S/scripts/repl.mjs` and one `steps/NN-*.js` per screen, each ending in
`shot(page, name, marks)` + `slide({...})`. Check marks with `$PY $S/scripts/overlay.py $WS <shot>` as you go.
Write steps so they replay from fresh data. Procedure, mark rules and traps: **references/capture.md**.
Shrink shots before keeping them: `$PY $S/scripts/optimize_shots.py $WS/shots`.

### 6. Build
```
$PY $S/scripts/manual.py $WS/manual.json --all --pdf --md
```
→ `<ws>/out/<out_name>-ALL.pptx` + one per chapter edition, each with a PDF (Keynote on macOS, PowerPoint on
Windows, LibreOffice anywhere; none installed ⇒ PPTX only, say so) and, with `--md`, a Markdown edition
(`<out_name>-<Edition>.md` + `out/md-images/`, the shots cropped like the slides with the boxes drawn — for a wiki
or a repo). Editions build into `out/.staging/` and replace `out/` only when
every edition and PDF succeeded. A chapter with no task slides fails the build — add `--draft` for a mid-capture
preview. The build refuses overflowing steps/tips/tables and step/mark mismatches — fix the content, don't bypass.

### 7. Visual QA loop (do not skip)
Render pages, hand them to a **fresh** subagent with the QA prompt in **references/qa.md**, fix what it returns
(re-capture or re-mark; placer changes need a full re-QA because badges move on every slide), rebuild, repeat
until it answers SHIP. Report the edition paths and how many QA rounds it took.

## Edit an existing manual by chat

Most requests are content edits typed in plain language — "slide editor-02 step 2 should say …", "add a tip to
viewer-03", "swap these two slides", "split this slide in two", "add a row to the status table".

1. Find the slide by its `shot` name or task title in `manifest.json`; tables, chapters and cover text are in
   `manual.json`.
2. Edit only what was asked. Keep the rules: step count = mark count (a new step needs a new box — that means a
   re-capture, so say so instead of faking it), on-screen text in quotes, tip ≤ ~120 chars. Wording about
   behaviour is checked against the app's code and messages, not invented.
3. Rebuild (`manual.py --all`, plus `--pdf` where a renderer exists) and show the changed slide(s).

## Refresh an existing manual (UI changed)

The workspace is the manual's source: `manual.json` + `manifest.json` (polished wording) + `steps/` (replayable
capture) + `shots/` (accepted pictures). A refresh re-takes pictures and keeps wording.

1. **What changed:** `git log <captured_sha>..HEAD --oneline -- <code_paths>` in the app repo → affected chapters.
2. **Fresh data:** reset the app's test data the way its README says, start it.
3. **Replay:** `MANUAL_CONFIG=$WS/manual.json node $S/scripts/replay.mjs` → `shots-new/`. It stops at the first
   step that no longer works — fix that step (the UI moved), reset, replay again.
4. **Diff:** `$PY $S/scripts/diff_shots.py $WS` → `refresh-report.md`: broken · changed · new · unchanged.
   Look at every changed slide's new shot; `--accept <shot…>` / `--accept-changed`.
   A changed mark count means the steps must be re-counted.
5. **Wording:** `$PY $S/scripts/check_copy.py $WS/manual.json` lists quoted labels no longer in the app's
   messages (`copy.messages` in manual.json) — fix those steps/tips in `manifest.json` (and re-read the code for
   changed rules/tables).
6. **Release:** bump `version`, set `captured_at` / `captured_sha`, `manual.py --all --pdf` (the previous version
   is archived), QA the changed slides (qa.md §4), note the refresh in PROGRESS.md.

## Files

| Path | Use |
|---|---|
| `scripts/setup.py` | one-shot workspace tooling: venv + requirements, Playwright + chromium, names the PDF renderer |
| `scripts/manual.py` | composer + edition loop + staging/publish + PDF export (`--pdf`) + Markdown export (`--md`) |
| `scripts/export_md.py` | Markdown edition: tables, steps, cropped shots with boxes, tips (`manual.py --md` calls it) |
| `scripts/build_manual.py` | slide primitives: task slide (steps, tip slot, crop-to-marks, badge placer), tables, cover, dividers |
| `scripts/inspect_template.py` | template facts (layouts, placeholders, colours), `--suggest` config block, `--render` preview |
| `scripts/cap.mjs`, `scripts/repl.mjs` | Playwright session (configurable login, env-var passwords, identity check), `shot()` with marks, REPL that keeps pages alive |
| `scripts/overlay.py` | preview a shot's marks before building |
| `scripts/replay.mjs`, `scripts/diff_shots.py`, `scripts/check_copy.py` | refresh: replay steps → shots-new, per-slide diff + accept, stale-label check |
| `scripts/optimize_shots.py`, `scripts/slim_template.py` | shrink shots and a large template before keeping them |
| `scripts/make_plain_template.py`, `templates/plain.pptx` · `dark.pptx` | the bundled unbranded 16:9 templates (light / dark) and their generator |
| `scripts/render.applescript` · `render.ps1` · `renderers.py` | Keynote (macOS) / PowerPoint (Windows) PDF+PNG export; renderer detection incl. LibreOffice |
| `references/capture.md` · `content.md` · `template.md` · `qa.md` | read at steps 5 · 4 · 3 · 7 |
| `assets/example/` | `manual.json` + `manifest.json` of the demo manual — the reference implementation |

Files in this skill

  • SKILL.md11.1 KB
  • assets/example/manifest.json2 KB
  • assets/example/manual.json2.9 KB
  • references/capture.md9.5 KB
  • references/content.md9.2 KB
  • references/qa.md7.8 KB
  • references/template.md10.1 KB
  • requirements.txt52 B
  • scripts/build_manual.py27.4 KB
  • scripts/cap.mjs6.8 KB
  • scripts/check_copy.py5.5 KB
  • scripts/diff_shots.py5.7 KB
  • scripts/export_md.py3.8 KB
  • scripts/inspect_template.py5.8 KB
  • scripts/make_plain_template.py2.3 KB
  • scripts/manual.py10.6 KB
  • scripts/optimize_shots.py986 B
  • scripts/overlay.py1.5 KB
  • scripts/render.applescript2 KB
  • scripts/render.ps11.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…