Skip to content
demosynth
Build a demo
GITHUB WORKFLOW

Turn a public GitHub repository into a clickable tour.

Use your repository’s interface code to create a first version of a product story without booting its backend. Then review the generated screens and edit the tour in DemoSynth.

1. Choose a public web application repository

Choose a repository with interface files that describe the product you want to show. React and Next.js route files, JSX or TSX components, package metadata, and CSS theme definitions provide useful structure. README-only or backend repositories offer fewer interface clues.

The importer accepts a repository’s base URL. Remove a /tree/branch or /blob/file suffix before pasting it. You can choose a branch separately. A public repository does not require a GitHub token unless the shared anonymous API allowance is exhausted.

https://github.com/shadcn-ui/taxonomy

2. Generate the source-inspired screens

Open GitHub import, paste the repository URL, and keep “On this device” selected for an account-free draft. Use “Load branches” if you want to choose a branch other than the repository default, then select “Generate interactive demo.”

The progress display follows repository metadata, interface discovery, source extraction, screen composition, browser capture, and saving. The browser rasterizes each screen as a WebP image and measures its target element at the same 1280 × 800 viewport used for the capture.

No npm install, database connection, Docker container, or repository server is started. A full-stack repository can therefore produce a draft even when its real application needs environment variables and backend services.

3. Review the tour in the studio

When generation finishes, the storyboard opens in the studio with the captured screens. Check every title and tooltip against the feature you actually want to explain. Source notes identify the repository, branch, and commit used for the draft.

A useful first tour often explains one small result: creating a project, finding a dashboard, or changing a setting. Remove a screen if it distracts from that outcome. If a source file contains an entire landing page heading, shorten the step title to something useful in the storyboard.

4. Adjust hotspots and navigation

Select a step, drag its hotspot to the intended control, and update the tooltip heading and context. Use the appearance controls to choose a beacon, highlighted region, or invisible sandbox target. A corner handle resizes an element box; arrow keys allow small adjustments.

Use “On click, go to…” to choose the next step or a specific destination. Preview the entire route, including the final call to action. Check that a branch does not send readers to a step you removed. Generated coordinates are editable rather than permanently baked into the screenshot.

5. Save a portable backup before sharing

Save the draft and use the JSON export in the studio to keep a portable copy. Browser-local drafts stay on this device and can disappear when site data is cleared. A saved local tour URL is not a public link for another person.

For documentation, export a written guide or a README cover card. To share the interactive version across devices, the tour must be published through configured authentication and image storage. Cloud publishing is currently being connected on the hosted service.

When an import needs another attempt

If GitHub returns an allowance message, wait until its displayed reset time or use an optional public-read token. A large repository can have a truncated file tree; the tour then uses the files available from GitHub’s response.

If the draft does not resemble the flow you want, try a more relevant branch or replace generated screens with your own screenshots. Optional AI refinement can improve wording, but it does not execute the repository or prove that the replica matches a live product.