design-slides
Skill4 starsChanged 19 days agoMITView on GitHub
Use when creating, restyling, reviewing, or editing a presentation, pitch deck, slide deck, talk, portfolio or interview case study shown as slides, or design review deck, in Figma Slides, Figma Design, pptx, Google Slides, or HTML. Also use when a deck looks generic, templated, or AI-made and needs fixing.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- ldaume/agentic-engineering-harnesstheir own version, first seen Nov 8, 2026
- schudarin/chudarin-figma-skillsword for word, first seen Oct 26, 2026
Other versions2 projects use a version of this.
Word for word · 1
- schudarin/chudarin-figma-skills★ 4100% same
Edited · 0
None found.
Wrote their own version · 1
- ldaume/agentic-engineering-harness★ 3same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- audit-design-systemSkill
- design-screensSkill
- figma-fix-variable-bindingsSkill
- figma-plugin-api-rulesSkill
- plan-user-flowsSkill
- writing-textsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Wait for the plan to be confirmed and the questions answered.
- Distinctive: line 37
After each step the state is written to the deck file: plan, sources, style, what was confirmed and what was rejected.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Slides
A deck built on defaults is recognized at once: every slide on one template, the main point given the same weight as the minor ones, no product in sight, placeholders instead of data, an export nobody opened. This skill puts the story before the layout, takes the style from the person or the company, and checks the deck in the form it will be sent in.
Text on slides follows the writing-texts skill, with the person's and the product's voice. The deck's state lives in <project>/.claude/slides/<deck>.md, one file per deck (format in references/story.md).
Which branch
| What exists | Branch |
| No deck | new deck |
| A deck; asked to change part of it | partial edit |
| A deck; asked to look at it or assess it ("what's wrong?") | review without edits |
| A deck; asked to check it and hand it over or send it | pre-send check |
| A deck; asked to redo it entirely | full rework |
New deck
Each step ends where it says "wait". The next step starts only after the person answers.
First reply: questions and a plan, no slides. One message:
- questions the request does not answer: who is watching and what they decide; how the deck will be used (shown live, sent as a file, edited by others, printed, animated) and in which format;
- a plan per
references/story.md: a table "claim · slide job · layout"; - data questions: every claim without a number or a source becomes a question. Such a claim does not go on a slide until the data exists.
Wait for the plan to be confirmed and the questions answered.
- Style and tool per
references/style.mdandreferences/tools.md. There is no default style: if the person has nothing, three directions to choose from. Wait for the choice. - Two or three key slides with different jobs and different layouts, as screenshots. Wait for confirmation.
- The remaining slides per the plan: each slide's layout follows its job and is taken from a key slide when the job is the same.
- Checks per
references/checks.md, fixes, export again. The person gets the deck after this.
After each step the state is written to the deck file: plan, sources, style, what was confirmed and what was rejected.
Existing deck
Frames that repeat one text in a row are a build. A run of frames with the same heading and small changes between them is an animation spread over several frames (a step-by-step reveal, Smart Animate between frames). It is one beat of the talk, not a set of empty slides: count it as one slide in timing and in the plan. Before suggesting to cut or merge such a run, check the prototype connections between its frames or ask how it plays in the show.
Partial edit. Only what was asked changes; plan, style and key slides are not agreed again. The affected slides are checked and exported. If something else in the deck stands out along the way (a repeated layout, a number without a source, a tell from references/tells.md), the reply ends with a list "Noticed, not changed": slide number and one line per item.
Review without edits. All checks from references/checks.md, but the deck files do not change: no fixes, no export over them. Reply: what I found, by slide, and what I suggest changing. Each finding names what it rests on: the render, a number checked against its source, or a guess. A guess about how the audience will react ("they will notice this at once") is labelled as a guess and is not ranked above checked defects. If the deck has been shown before, ask how it was received before calling anything the main risk.
Pre-send check. All checks from references/checks.md on the whole deck. Only defects are fixed without asking: an element lost or broken in export, a typo. Style, plan and layouts do not change. Everything else goes into a "Suggested changes" list. The final export is checked again. Reply: what was found, what was fixed, what is suggested.
- A number on a slide differs from the source table. This is not a typo: the person may have updated the slide and not the table. Do not change the number. Show both values and ask which is right and where it comes from; the export waits for the answer.
- No deck file (the deck was made elsewhere). The source table is not filled from the deck itself: "source: slide" or "source: deck" is not a source. Every number is recorded with the status "unverified", and a question is asked about each.
Full rework. The plan is rebuilt from the deck (the claim and the job of each slide) and shown for confirmation. Then steps 2–5 of a new deck.
Data
A number is on a slide only if it is in the deck file's source table. No source: a question to the person. A placeholder on a slide or in a proposal ("TBD", "to follow", "data later", bars without values, "[screenshot]") is neither placed nor offered: a question goes in its place, and a slide without data waits for the answer or leaves the plan. The status "estimate" or "forecast" stays next to the number. Details in references/story.md.
Files
| File | When to read |
references/story.md | plan, slide jobs, deck types, source table, deck file format |
references/style.md | choosing the style, layout by job, grid, type, contrast, accents, charts |
references/tells.md | catalogue of tells; before the key slides and during checks |
references/checks.md | checks before the deck is handed over |
references/tools.md | choosing the tool; Figma, pptx, HTML |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

