npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@measnalazi/design-ss

v0.1.6

Published

Design App Store and Play Store screenshot strips as HTML, render them to store-size PNGs, and drive it all from one CLI.

Downloads

839

Readme

design_ss

Design App Store and Play Store screenshot strips with an AI agent.

A five-panel iPhone strip: warm parchment ground, serif headlines, upright devices

Checkout the screenshots above Bio — AI Journal & Life Story on the App Store.

The same app on a deep green ground with a bleed of device art behind each panel

The same app again: a photo band across the top, numbered panels, dark ground

Give it your app's description and a folder of screen captures. An agent reads them, designs the strip, and renders it at the exact size the stores require.

Three runs, one input/ folder, three designs. A template gives every app the same layout with its content swapped in. Here the concept is composed per run — palette, typeface, rhythm, how the devices sit, what the panels do together — so a run you do not like is a run away from one you do.

A strip is one HTML document. strips/<target>/strip.html is the single source of truth — the renderer exports that file and the visual editor edits that file, in the same browser engine. There is no second representation.

input/app.md          ┐                  ┌─ strips/<target>/strip.html
input/<target>/*.png  ┴─►  the agent  ─►─┤
                                         └─ strips/<target>/rendered/*.png
                                                    ▲
                                       strip_editor ┘  (optional, by hand)

Five targets: iphone and ipad for the App Store, phone, tablet_7 and tablet_10 for Play Store.

| Target | Screenshot | Store | | --- | --- | --- | | iphone | 1290 × 2796 | App Store | | ipad | 2048 × 2732 | App Store | | phone | 1080 × 1920 | Play Store | | tablet_7 | 1200 × 1920 | Play Store | | tablet_10 | 1600 × 2560 | Play Store |

One panel is one screenshot at these dimensions; a five-panel iPhone strip is 6450 px wide. The two Apple sizes are specifications — Apple publishes exact export sizes and rejects anything else. The Play sizes are house choices inside Google's permitted range (320–3840 px per side, at most 2:1).

Requirements

| | | | --- | --- | | Node 22.x | the renderer and the editor | | Chromium | headless export — design-ss design install, once. Without it, an installed Google Chrome is used instead (and the CLI says so) | | An agent | anything that reads AGENTS.md: Claude Code, Gemini CLI, Codex, Open Code, Co-Pilot, Cursor...etc |

Install it, and design-ss is on your path:

npm install -g @measnalazi/design-ss@latest
design-ss --version
design-ss design install #fetches chromium's dependency
design-ss editor install #fetches editor's dependency

Or clone it, which is the same thing plus the sources to edit:

git clone https://github.com/MeasnaLazi/design_ss.git
cd design_ss
npm install          # add `npm link` if you want the `design-ss` command
npm run setup        # fetches Chromium and the editor's dependencies (~350MB, once)

The agent is the part that designs, so a run costs whatever your agent costs. Everything else — rendering, checking, editing — is local and offline.

Running the agent

The designer is the agent.

1. Put your captures in input/<target>/, named for what they show. timeline.png tells the agent what that screen proves; IMG_4821.PNG tells it nothing. Five or more is comfortable.

2. Write input/app.md. The whole gate is a name and a summary:

# Bio

## Summary

A private journal that turns everyday moments into a story worth keeping.
For people who want to write a little, not a lot.

Everything else — tone, palette, device frame, panel count, the headlines themselves — is optional, and anything you leave out the agent works out and tells you what it chose.

3. Start your agent in the repo root and ask for a strip:

can you design the screenshot?

design the iphone strip

CLAUDE.md / GEMINI.md / AGENTS.md all point at the skill. From there the run is: read the brief → draft any panel copy you did not write, back into app.md → choose a concept and say it → write the HTML → check the schema → render → look at the PNGs → iterate. Roughly four rounds, then it stops.

Name no target and it designs every device folder you have populated, as one family rather than five cousins. It announces the set before the first write.

It will draft your marketing copy. It will not invent your app: every claim has to be visible in a capture or supported by your summary.

input/ — what you write

input/
  app.md              the app: name, summary, request, pinned values, panel copy
  *icon*.png          your app icon — optional
  iphone/             one folder per target; the folder name IS the target
    welcome.png
    timeline.png

app.md has four sections, three of them optional: # Name and ## Summary (required), ## Request for intentions written as prose — "premium and quiet, not a productivity app" — ## About for pinned values like theme: and frame:, and ## Panel N for copy you want taken verbatim. Panels you skip are drafted and written back into this file, so the next run starts from copy you have had a chance to correct.

→ input/README.md is the full format: every key, the five target sizes, sharing one design across targets with follows:, and what happens when you have more captures than panels.

strips/ — what comes out

strips/iphone/
  strip.html          the document — the single source of truth
  screenshots/        the captures it used, copied in
  images/             artwork made for it
  rendered/           panel0.png … panel4.png, strip.png, strip-data.json

Self-contained: a strip never references anything outside its own folder, so it can be moved or cloned whole.

strips/ is output and is gitignored.

design-ss — the command line

The same run without a conversation: takes flags, writes files, returns an exit code, and never asks a question — so a script or a pipeline can drive it.

design-ss design   --target iphone --message "warmer palette, lead with the timeline" --input <dir>
design-ss retarget --target iphone --size 1284x2778   # rescale to another store size
design-ss gate     --target iphone                    # check + render, no agent, no key
design-ss check    --all                              # schema only, no browser
design-ss render   --target iphone                    # strip -> store-size PNGs
design-ss frames iphone --list                        # device frame packs
design-ss design install                              # fetch Chromium, once
design-ss editor install                              # fetch the visual editor, once
design-ss editor start --port <port>                  # ...run it in the background, default port 4714
design-ss editor stop                                 # ...and stop it
design-ss stop                                        # cancel this project's run

--input <dir> applies to design only and may point anywhere; output always goes to <work root>/strips/, so the toolkit can be installed once and aimed at any project. --agent stub runs the whole path with no model and no cost.

design-ss design drives Claude Code only for now.

Full reference, including which store sizes retarget can and cannot reach: docs/cli.md.

Developed and tested on macOS. Linux should be fine — the process handling is POSIX — and Windows is untested.

strip_editor — the parts you want to move yourself

cd strip_editor
npm install
npm run dev          # http://localhost:4714

Opens strip.html directly — no import, nothing converted. Drag and resize with snapping, edit text in place, swap screenshots and device poses, tune type and colour, undo anything; every save is surgical, rewriting the one line you changed and leaving the rest of the file byte-for-byte alone. Leave it open during a run and the design appears as the agent writes it — the canvas goes read-only, names whoever holds it, and releases on its own if the run dies.

→ strip_editor/README.md for the full editor, its keyboard map, the server API and the architecture notes.

Why use this

What the alternatives cost you:

  • always the same layout ~ template
  • looks like every other app that used it ~ template
  • your design fits the tool, not your app ~ template
  • a subscription that never ends ~ template
  • expensive ~ designer
  • days for a round of changes ~ designer
  • every new screenshot is another invoice ~ designer
  • five device targets is five jobs ~ designer
  • an afternoon per target, every time ~ yourself
  • export sizes are easy to get wrong ~ yourself
  • needs design skill you may not have ~ yourself
  • one screen changes and you re-export all five by hand ~ yourself

None of this beats a good designer on your first strip. It beats the alternatives on your fifth.

Read more

| | | | --- | --- | | AGENTS.md | the agent entry point — start an agent here | | skills/strip-design/SKILL.md | how a design run works, and the rules learned from real failures | | skills/strip-design/archetypes.md | the design vocabulary — the authority on anything visual | | docs/cli.md | the design-ss command line: flags, exit codes, cancelling a run | | docs/composer.md | the renderer, the schema checker, and the frame packs | | composer/strip-schema.md | the markup contract a strip has to satisfy | | NOTES.md | non-obvious logic, and what breaks if you "fix" it | | CONTRIBUTING.md | what to contribute — the vocabulary and the frame packs come first |

License

MIT © 2026 SovannmeasnaLy.

The typefaces bundled in composer/fonts/ — EB Garamond, Lora, Inter, Poppins, Space Grotesk and IBM Plex Mono — are licensed under the SIL Open Font License 1.1, not MIT.