non-storybook

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)

1. 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).
2. 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.
3. 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.
4. 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.