git clone --depth 1 https://github.com/asgeirtj/system_prompts_leaks /tmp/non-storybook && cp -r /tmp/non-storybook/Anthropic/claude-code/skills/design-sync/non-storybook ~/.claude/skills/non-storybookSKILL.md
# Package source shape
No Storybook - the component list comes from the package's shipped `.d.ts` exports, and there is **no reference render to verify against**. Preview quality therefore comes from two layers: the converter ships every component fully functional (bundle + `.d.ts` + `.prompt.md`) with an honest **floor card**, and rich previews are **authored** - by you, from the repo's own usage examples - for the components the user scopes in (§4). Authored previews are graded on an absolute rubric (§4.3) and reviewed by the user (§4.4); the floor card is never a failure, just an unauthored component.
## 2. Explore, then write config (continued)
3. The converter needs the built `dist/` entry + its `.d.ts` tree. Check whether the entry (from `package.json` `module`/`main`/`exports['.']`) already exists - install may have built it via `prepare`. If missing:
- Run `<pm> run build`. No `build` script -> try `prepare`/`prepack`. In a monorepo, build the package *and its workspace dependencies* from the repo root: `turbo build --filter=<pkg>` or `pnpm -F "<pkg>..." build` (the trailing `...` is required - bare `-F <pkg>` skips dependencies and you'll see `Cannot find module '@scope/tokens'`). **Some build scripts fork a watcher and exit 0 early - after the command returns, `ls` the expected output (dist/, build/esm/, or whatever `package.json` `module`/`main` points at) and confirm it's populated before continuing.** If it's empty, check for a `--watch` flag in the script and use the one-shot variant, or poll the output dir.
- Still missing -> `AskUserQuestion`("What command builds this package?", options = any `scripts.*` containing `tsc|tsup|rollup|vite build|esbuild|swc`, plus freeform). Record the answer as `buildCmd` in the config.
- User says there's no build -> the converter will synthesize an entry from `src/` (last resort - `.d.ts` contracts will be weaker; recommend adding a build).
4. **Check what's already in the project.** `DesignSync(list_files)` on the target (the base skill §1 already picked the upload path: pinned-at-run-start -> atomic; otherwise empty -> incremental, non-empty -> atomic). If it has files, fetch the small verification anchor: `DesignSync(get_file, path: "_ds_sync.json")` and save it locally (`.design-sync/.cache/remote-sync.json`) - never download `_ds_bundle.js` for this. The driver run (the "Re-syncs are one command" block, `--remote` pointing at the saved anchor) diffs it into `.sync-diff.json` with TWO partitions answering different questions. **Verification** (`unchanged`/`changed`/`added`): which components need capture + grading - `unchanged` were verified at the last upload and skip §4 entirely. **Upload** (`upload.components`/`upload.deletePaths`/`upload.bundle`/`upload.styling`): which files the project is missing - sourceHashes-based, so `.d.ts`/`.prompt.md`-only edits, regroups (old paths land in `deletePaths`), and bundle-only changes still ship even when no render changed. Never scope uploads by the verification partition. No sidecar in the project (never synced, or shape change) -> no anchor -> full first-sync scope; if `list_files` showed the project NON-empty, deletes can't be derived - review its file list once for files this build doesn't produce; those reviewed paths go into the upload plan's `deletes` at §5.
5. **Confirm the plan AND the preview scope with the user before building.** `AskUserQuestion` with: the component list you found (or a count + a few names if it's long), which files the tokens/CSS are coming from, and which build command you'll run. The build can take minutes and burn tokens - aligning now avoids re-running because it was pointed at the wrong package or missed half the components.
- **Preview scope** (this shape's cost slider - all N components import fully functional either way; this only decides which get authored preview cards): **(a)** author rich previews for the core components - the user picks them, or you propose ~20-40 from docs prominence; **(b)** author everything (significantly longer - state the estimate from N × a few minutes each); **(c)** floor cards everywhere for now (fastest; previews can be authored incrementally on any later re-sync - authored files and grades carry forward).
- If the project already has components from a prior sync (step 4), also offer: full re-verify + re-upload (`--force`-equivalent) or changed-components-only (the verdict's worklist; default). The precise partition exists only after the driver runs - state it then ("N verified-by-upload, M to verify: [names]") before starting §4 work, and check in with the user if it's surprisingly large.
6. **Write `.design-sync/config.json` and commit it** - re-sync reuses it so output is reproducible. Only `pkg` and `globalName` are required. **If the file already exists, read it first and preserve `dtsPropsFor`, `libOverrides`, and `overrides` - only add to those fields, never replace them.** They accumulate fixes from prior verify-loop iterations. **Also Read `.design-sync/NOTES.md` before anything else** - it holds repo-specific gotchas a prior sync recorded.
| Field | Value |
|---|---|
| `pkg` / `globalName` | package name (required) and the `window.*` global to assign (auto-derived from `pkg` when omitted) |
| `projectId` | the claude.ai/design project this repo syncs to - recorded automatically in §1, the moment the target is settled (the atomic upload's post-verify record is a backstop); re-syncs fetch their verification anchor (`_ds_sync.json`) from it without asking |
| `shape` | `'storybook'` or `'package'` - pins the source shape (overrides auto-detection). Written on first run. |
| `buildCmd` | the discovered build command - tells Claude what to re-run before the converter on re-sync |
| `srcDir` | source root when not `src/`/`lib/`/`components/` |
| `tsconfig` | path to `tsconfig.json` - esbuild reads `compilerOptions.paths` so `@/...` path aliases resolve in synth-entry mode |Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.
Author or improve the run-<unit> skill - a per-project skill that tells agents how to build, launch, and drive this project's app. Use when the user asks to set up the project, get it running, write run instructions, or verify build/run steps work from a clean environment.
Runtime capabilities a published Artifact page can be granted — behavior static HTML cannot provide on its own, such as the page reading live or connected data, remembering what people do on it (a poll, a sign-up sheet, a checklist, a document edited in place — it saves new versions of itself), keeping state shared across viewers, knowing who is viewing, asking Claude a question of its own, storing files people add, or handing the viewer a file to save. Serves this user's live capability roster and the typed call definitions. Load it whenever the user asks for an artifact needing any such runtime behavior.
Design guidance and fundamentals for Artifacts.
Diagramming know-how for Artifacts - when a picture earns its place, how to draw one that shows the real mechanism, and the inline-SVG mechanics that keep it legible in both themes.
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
Automates your Chrome browser to interact with web pages - clicking elements, filling forms, capturing screenshots, reading console logs, and navigating sites. Opens pages in new tabs within your existing Chrome session. Requires site-level permissions before executing (configured in the extension).
Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings; ultra: deep multi-agent review in the cloud); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. For ultra on a GitHub.com PR target, --post asks to post the finished review’s findings to the PR as a single comment from the user’s GitHub account (not a review; the launch dialog still confirms in interactive sessions, while non-interactive mode posts on the flag alone) and --no-post hides that option.