bryllim/workout-guide: 302 exercise illustrations as a typed npm package

What bryllim/workout-guide actually ships

The repository is a monorepo for an exercise illustration library, not a workout planner. The README states it contains 302 exercises, three consistent frames per exercise, a typed framework-neutral npm package, and a searchable static gallery. The three frames matter more than the count: an exercise illustration is only useful in an app if the start, middle and end poses come from the same drawing session, with the same body proportions and camera angle. A mixed set of poses looks broken when animated. The project's own framing is that Bryl Lim expanded on the Everkinetic pose artwork with additional exercises and animation frames, normalized assets and structured metadata. The audience is developers building fitness, workout or physical therapy interfaces who would otherwise commission illustrations or scrape them. It is not written for someone searching for a six day gym schedule. There is no program generator, no set and rep model, no progression logic anywhere in the described surface.

The catalog, the assets and the package API

Three pieces fit together. The canonical manifest and all 906 transparent 512 x 512 SVGs live in packages/workout-guide, with PNG sources retained for compatibility. That is 302 exercises times three frames, and the arithmetic is worth checking before you plan storage or bundle size. The Astro app in apps/site renders the landing page, gallery, detail pages and guide. The scripts directory holds deterministic catalog import and validation utilities, and the README notes the normalized catalog and all package assets are checked into the repository rather than fetched at install time. Maintainers can regenerate them from a compatible source export with a catalog import command. The package exposes functions rather than raw file paths: getExercise takes an identifier, searchExercises takes a query with options such as equipment, and getAssetUrl takes an identifier plus a frame index. That indirection is the design decision worth noting. It means asset locations are not part of your code, so the project can reorganize files without breaking consumers, but it also means you cannot statically analyze which images your app uses. Direct asset imports and literal React Native require() examples are documented in the integration guide rather than the README, so React Native users should read that page before assuming the helper functions are the intended path.

Installing the package and rendering a first exercise

Install from npm with the package name exactly as published. The README gives this command.

npm install @bryllim/workout-guide

Then import the three exported helpers the README names and call them. This snippet is the README's own example, unchanged.

import { getExercise, searchExercises, getAssetUrl } from '@bryllim/workout-guide';

const pushUp = getExercise('push-up');
const bodyweightChest = searchExercises('chest', { equipment: 'bodyweight' });
const firstFrame = getAssetUrl('push-up', 1);

What you should see: getExercise returns the catalog record for the identifier 'push-up', searchExercises returns the bodyweight chest entries matching that query, and getAssetUrl returns a URL for frame 1 of that exercise. The identifier is a slug, so check the gallery for the exact string before hardcoding one; a typo returns nothing useful rather than throwing a helpful error unless you handle that case yourself. Frame indices start at 1 in this example, and the README does not document whether 0 is valid.

To work on the library itself, clone the repository and run the workspace scripts. The README lists these three.

npm install
npm run check
npm run dev

The root package.json sets engines.node to >=24, so an older runtime will fail before any of this runs. npm run check chains catalog validation, typecheck, lint, vitest and the build, which is a heavier gate than most libraries impose on a local change.

Where the design gets in the way

The licence split is the first real constraint. Code and documentation are MIT, but the visual assets are CC BY-SA 4.0, and the README points to LICENSES.md and ATTRIBUTION.md for the breakdown including Everkinetic-derived poses. Share-alike applies to the images, so an app that displays them is not simply doing whatever it likes with MIT-licensed code. If your product cannot carry attribution or cannot accept share-alike on adapted artwork, this library is the wrong source and you should budget for original illustration instead. The second constraint is weight. All 906 SVGs are checked into the repository, and the README does not describe a per-exercise or subset install. If your app needs twelve exercises, you are still consuming a package built around the whole catalog. Whether your bundler tree-shakes unused assets is a question the README does not answer, and it is worth answering before you commit. Third, the project has no training logic at all. It cannot tell you how many sets to do, how to progress, or how to schedule a week. That is a deliberate scope boundary rather than a gap, but it rules the library out for anyone who read the name and expected a program.

Compared with hosting the Everkinetic data yourself

The upstream source this project builds on is Everkinetic's data repository, also CC BY-SA 4.0. Taking that route gives you the original poses and nothing else: no normalized 512 x 512 transparent SVGs, no three-frame consistency per exercise, no typed manifest, no search function, and no gallery to browse when you need to find an exercise identifier. You would write the import pipeline, the validation and the lookup API yourself, and the repository's scripts directory exists precisely because that work is tedious. The trade-off runs the other way too. Everkinetic gives you the raw material without an intermediary's naming decisions, and if your catalog needs to diverge from this project's slugs or metadata shape, you will be fighting the package rather than using it. Choose the package when you want the normalized, typed result and can live with the identifiers it defines. Choose the upstream data when you need to own the pipeline.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-26, with v1.0.0 released on 2026-08-24. That is a first stable release rather than a long track record, so treat the API surface as young. The project is a monorepo with a real test setup: vitest for unit tests, Playwright with axe-core for end-to-end and accessibility checks, ESLint and TypeScript, plus separate scripts for catalog validation, site validation and consumer package testing. That tooling lowers the cost of trusting a change, but the Node >=24 engine requirement raises the floor on your build environment. On licensing, code under MIT and assets under CC BY-SA 4.0 is a split you should route past whoever handles compliance at your organization; this is a description of the terms, not legal advice. Upgrades should be cheap if you stick to the three documented functions, and expensive if you depend on the exact shape of catalog records, because those records are generated from a source export and regenerating them is a maintainer workflow rather than a consumer one.

Editorial conclusion

Adopt bryllim/workout-guide if you are building a fitness or workout app and need exercise artwork and metadata you can import directly, and if you can comply with CC BY-SA 4.0 on the images. Do not adopt it if you need a training program, rep schemes or progression logic; the package ships illustrations and catalog data, not workout plans. Verify first that your build can consume 512 x 512 SVGs at the size your UI needs, that you have read LICENSES.md and ATTRIBUTION.md closely enough to satisfy the share-alike terms, and that getAssetUrl returns the frame index your screens expect.

Frequently asked questions

Official sources

1. bryllim/workout-guide on GitHub
2. License: MIT
3. Project website
4. README
5. Releases