build-carousel — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited build-carousel (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Carousels are currently the strongest format on LinkedIn. They reward more design effort, hold more dwell time per swipe, and pass more algorithmic signal per post than text or video. This skill exists to plan and write a carousel from an idea, not to design it (the user or their designer does that), but to produce slide-level copy and a clear visual brief that a designer can execute.
LinkedIn document carousels (uploaded as PDFs) currently outperform equivalent text posts by 5-10x on engagement, and educational carousels with 8-12 slides perform best. Each swipe counts as an engagement signal. The format works because it requires more effort to create (a quality signal), keeps the reader on LinkedIn (the platform rewards this), and the swipe behavior holds attention longer than scrolling past text.
But carousels can also fail badly. Slides full of stock photos and motivational quotes have the lowest engagement of any LinkedIn format. The difference between a carousel that works and one that does not is whether each slide does its own job. This skill exists to make sure each slide earns its place.
Trigger when:
Do NOT trigger when:
The angle (one sentence), plus the underlying material (the framework, the steps, the items, the comparison data). If they have only the angle, ask:
"What are the 5-12 concrete points that make up this carousel? Or do you want me to help you list them?"
If voice-profile.md exists, read it for the copy. Also note: do they prefer minimal design or more visual? (If they have not said, default to minimal text-forward.)
A good carousel has three parts:
1. The cover slide. One job: make people swipe. The cover is the carousel's hook. It should have:
Bad covers: "5 Lessons I Learned" / "Tips for Better Productivity" / motivational quotes attributed to "anonymous"
Good covers: "What we changed after a $40K mistake" / "The 7-question script we use before every customer call" / "Why our onboarding emails get 90% open rates (and your subject lines won't work for you)"
2. Content slides (6-12). Each slide does one job and stands alone if removed from context. The reader who only swipes through quickly should still get value.
Each content slide should have:
Common slide patterns:
Bad slides: pure text with a bold header. Slides full of bullet points. Slides that just repeat the cover. Slides with a single quote and nothing else.
3. Closing slide. Two options:
The closing is also the place to credit collaborators or link to the source material. Keep it light.
Output must read as written by a human on the first pass. The constraints below are how you write, not a checklist to apply later. Do not narrate this process to the user. Do not show a "before humanizer / after humanizer" sequence. Just produce clean output.
Hard bans — never appear in output:
- **Speed:** ...). Write as prose.Required patterns:
Final scan before output:
— and –. Any hit means redraft.Full 33-pattern reference: see humanizer/SKILL.md in this plugin.
# [Carousel title]
## Slide 1: Cover
Header: [the cover title]
Subtitle: [optional]
Visual direction: [what should be on the cover visually]
## Slide 2: [one-line description of this slide's job]
Header: [the claim]
Body:
[the prose]
Visual direction: [diagram, number, icon, screenshot, etc.]
## Slide 3: ...
[continue for each slide]
## Slide N: Closing
[takeaway or CTA]
Visual direction: [usually the user's name and any handle/link]
---
## Image generation prompts (if user wants AI-generated visuals)
For Slide 1 cover: "[prompt]"
For Slide N visual: "[prompt]"
## Notes for design
[Any overall design notes: color palette, font preferences, density target. If voice-profile.md indicates the user is minimal/dense/etc., note it here.]Seed from find-ideas:
Angle: I changed my mind on type validation after spending a year arguing for it. The catalyst was shipping a script without Pydantic and it being fine.
User confirms: "Make this a carousel."
Slide plan (before writing copy):
Now the copy:
## Slide 1: Cover
Header: I spent a year arguing for type validation. Then I shipped a script without it.
Subtitle: What I changed my mind about.
Visual direction: A code block snippet showing a Pydantic class crossed out with a line through it. Minimal, monochrome, terminal aesthetic.
## Slide 2: The position I held
Header: I argued for static typing on every endpoint.
Body:
For a year, I was the loudest voice for type validation on our team. I wrote the RFC. I held up merges. I left a hundred review comments with the same suggestion: type this.
Visual direction: A faded screenshot of a code review with "needs proper validation" highlighted.
## Slide 3: The thing that happened
Header: Last week I shipped a script without a single type annotation.
Body:
A 12-field JSON payload. A queue write. I almost spent half a day writing a Pydantic model. I didn't. I shipped it raw.
Visual direction: A small terminal screenshot or a single line of code.
## Slide 4: What I expected
Header: I expected a production fire by Wednesday.
Body:
The arguments I had been making for a year all predicted what would go wrong. Malformed payloads. Schema drift. The 3am page.
Visual direction: A blank PagerDuty notification or generic alert icon.
## Slide 5: What actually happened
Header: Nothing.
Body:
The script has been running for a week. No errors. No pages. No drift. The thing I was worried about did not happen.
Visual direction: A flat green status indicator or "0 incidents" tile.
## Slide 6: What I noticed
Header: Most of the bugs I cited had never actually happened.
Body:
The malformed payload was hypothetical. The schema drift was theoretical. I was arguing the worst case as if it were the common case. It wasn't.
Visual direction: A simple before/after diagram showing "what I argued" vs "what happens in practice."
## Slide 7: The new default
Header: Type the things that have actually caused problems. Justify the rest.
Body:
Smaller change than it sounds. I would have rejected this default in a review six months ago. But it matches the actual evidence, not my anxieties.
Visual direction: A decision tree or simple flowchart in monochrome.
## Slide 8: What I am accepting
Header: I am giving up some defensibility. I am gaining a lot of time.
Body:
This will sometimes bite me. When it does, I will add the validation. That is okay. The cost of being wrong about a specific script is lower than the cost of slowing every script down for hypotheticals.
Visual direction: A simple scale or two-pan balance illustration.
## Slide 9: Closing
Body:
Curious whether anyone else has had this shift. What is something you argued for and then walked back?
Visual direction: User's name, role, and LinkedIn handle. Optional: link to a related write-up if they have one.
---
## Image generation prompts (if requested)
Slide 1 cover: "A terminal screen showing Python code with a Pydantic class struck through, monochrome, minimal, 1080x1080 square."
Slide 6 diagram: "A simple before/after diagram in flat design, two columns labeled 'what I argued' and 'what happened,' no color, no clutter."
## Notes for design
Voice profile suggests minimal aesthetic. Stick to monochrome. Avoid stock photos. Each slide should have one focal element. Font: Inter or similar clean sans-serif. Slide count: 9 (within the optimal 8-12 range).~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.