# workout-guide ships 906 SVGs under a different license than its code

> An exercise illustration library and framework-neutral npm package: 302 exercises, three frames each, three exported functions, and a split license where MIT covers the code while every illustration stays under CC BY-SA 4.0.

**bryllim/workout-guide** — 302 open exercise illustrations and a framework-neutral npm package by Bryl Lim

- Repository: https://github.com/bryllim/workout-guide
- Website: https://bryllim.github.io/workout-guide/
- Stars: 1,326 · Forks: 196
- Language: Astro
- License: MIT
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/bryllim-workout-guide

## MIT covers the code, CC BY-SA 4.0 covers all 906 illustrations

The package ships under two licenses and they do not cover the same thing. Code and documentation sit under the MIT License, while the visual assets sit under CC BY-SA 4.0 in a separate LICENSE-ASSETS file, with LICENSES.md and ATTRIBUTION.md carrying the complete breakdown. For a consumer that split matters more than the MIT headline, because the illustrations are the part an app actually renders and they arrive under a share-alike term rather than a permissive one. CC BY-SA 4.0 is the share-alike Creative Commons license, so a modified version of the licensed material carries the same license term, and redistribution of the files untouched is a separate question from modification. The MIT file says nothing about the SVGs, so a project that reads the repository LICENSE and stops there misreads the terms on the part it draws on screen.

## The poses are derived from Everkinetic data under a share-alike term

The artwork has an upstream. The original pose drawings come from the Everkinetic data repository under CC BY-SA 4.0, and the project states that Bryl Lim expanded on that foundation with additional exercises and animation frames, normalized assets, structured metadata, package APIs and the documentation gallery. So the 302 exercises are not 302 independent works. Some poses are Everkinetic's, and that subset stays under upstream share-alike terms regardless of which license the derived files ship under. The expansion is what lifts this above a mirror, since normalized assets and typed package APIs are new work stacked on top, but the credit chain runs back to a different repository and the README links to it by name rather than burying it in a footnote. Redistribution is where the attribution obligation bites, which is why ATTRIBUTION.md exists as a separate file instead of a paragraph.

## 302 exercises times three frames lands exactly on 906 files

The counts in this repository are mutually consistent, which is more than most asset packs manage. 302 exercises, three consistent frames per exercise, and all 906 transparent 512 × 512 SVGs in packages/workout-guide. 302 times 3 is 906, so the headline number can be checked against the asset count instead of taken on faith. The frame count is also the animation contract, since three frames per pose is what turns still drawings into movement, and a consumer who wants a single static illustration still receives three files per exercise in the same directory. PNG sources are retained for compatibility alongside the SVGs, so a bundle carrying both is shipping two copies of every frame. No per-exercise byte budget or size figure appears anywhere in the project, and no lazy loading story is given either: whether all 906 files reach a user at once is left to the bundler and whatever sits in front of it.

## The whole documented API is three functions in one TypeScript example

Installing is one command, and the entire documented API fits in a four-line example:

```sh
npm install @bryllim/workout-guide
```

```ts
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);
```

Three named exports, and the framework-neutral claim does real work in that list. Nothing in the example imports React, a component or a bundler plugin, and the return values are not annotated even though the package is described as typed. Two integration paths are pointed at rather than shown: direct asset imports and literal React Native `require()` calls live in the integration guide, which is the page a React Native consumer has to find before writing any code.

## Frame numbers start at 1 and exercise ids are kebab-case slugs

The three calls also reveal the shape of the identifier space. Exercise ids are kebab-case slugs, `push-up` rather than `pushUp` or a numeric key, and the same slug feeds both the lookup and the asset call, so the string a caller stores is the string the animation uses. Frame numbers are one-based, since the example asks for frame 1 and calls it the first frame, which means a consumer writing a loop has to decide for itself what index 0 should mean. Search takes free text plus an options bag, and `equipment: 'bodyweight'` is the only filter key on show, so filtering by muscle group, difficulty or any other equipment value is undocumented here. Because getAssetUrl is addressed by id and frame rather than returning asset bytes, the question of how the SVG reaches a React Native bundle is answered in that integration guide, not in the example.

## npm run check chains five gates and typecheck starts with a build

The scripts show what runs before anything is published, and the chain is longer than a typical library:

```sh
npm install
npm run check
npm run dev
```

`check` is five gates in one command: catalog validation, typecheck, lint, tests and build, in that order. Typecheck is not independent of build, because it runs the package workspace build first and then typechecks the workspaces that opt in, so a broken build stops typechecking before it begins. Unit tests come from vitest, end to end tests come from Playwright, and @axe-core/playwright sits in the dev dependencies, which puts an accessibility scanner in the same toolchain as the browser tests instead of in a separate audit step. The root declares node 24 or newer in engines, the one hard platform constraint the project states. There is also a dry-run pack command for inspecting what would be published and a consumer test script that exercises the package from the outside.

## The catalog ships in the repository, the export that regenerates it does not

The normalized catalog and all package assets are checked into the repository, which is why installing the package needs no artwork build step. Regeneration is a maintainer path: `npm run catalog:import -- /path/to/source` reads a source export from outside the tree, and no such export sits at the top level of this repository. Vectorizing is a separate step again, `assets:vectorize`, and the dev dependencies say what it is made of: potrace for tracing, sharp for raster work, svgo for optimizing the result. Of the four utilities under scripts/, the README mentions catalog import and validation only, and never mentions the vectorizer or the separate site validation script, so two maintenance steps are visible only in package.json. The practical effect for users is a fixed, reviewed asset set, and for anyone wanting to add poses of their own, producing a compatible source export first.

## Conclusion

As a source of consistently sized, consistently named exercise frames, this repository is in a different class from the usual free clip art, and the three-function API is small enough to read in one sitting. Two things decide whether it works for you, and neither is in the API. First, the artwork is CC BY-SA 4.0 while the code is MIT, so anything you derive from the frames carries that term, and the attribution chain runs back to the Everkinetic poses that went in first. Second, the package sits at version 1.0.0 from a single release tagged on 2026-08-24: confirm the 302 and 906 counts still match the copy you install, and read ATTRIBUTION.md before the artwork ships rather than after.

## FAQ

### How many exercises and frames are in workout-guide?

302 exercises with three consistent frames each. All 906 assets are transparent 512 × 512 SVGs in packages/workout-guide, and PNG sources are retained for compatibility alongside them.

### What license covers the workout-guide illustrations?

Visual assets are under CC BY-SA 4.0 in LICENSE-ASSETS, while code and documentation are MIT. LICENSES.md and ATTRIBUTION.md carry the complete breakdown, including the Everkinetic-derived poses.

### Which functions does the workout-guide package export?

The documented example uses three: getExercise, searchExercises and getAssetUrl. Direct asset imports and literal React Native require() calls are pointed at the integration guide rather than shown in the README example.

### What does the workout-guide monorepo require to build?

The root package.json declares node 24 or newer in engines. Its check script runs catalog validation, typecheck, lint, tests and build in that order, and typecheck runs the package workspace build first.

### Where does the artwork in workout-guide come from?

The original pose artwork comes from the Everkinetic data repository under CC BY-SA 4.0. Bryl Lim expanded on it with additional exercises and animation frames, normalized assets, structured metadata, package APIs and the documentation gallery.

## Sources

- [bryllim/workout-guide on GitHub](https://github.com/bryllim/workout-guide)
- [License: MIT](https://github.com/bryllim/workout-guide/blob/main/LICENSE)
- [Project website](https://bryllim.github.io/workout-guide/)
- [README](https://github.com/bryllim/workout-guide/blob/main/README.md)
- [Releases](https://github.com/bryllim/workout-guide/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bryllim-workout-guide