GitReverse: turning a public repository into one pasteable coding prompt

What the app actually reads from a repository

The input is narrow on purpose. GitReverse pulls three things from a public GitHub repository: the repo metadata, a root file tree at depth 1, and the README. A model then turns that context into a single short conversational prompt, described in the README as one someone might paste into Cursor, Claude Code, Codex or a similar tool to build the project from scratch.

That is the whole mechanism, and the smallness of the input is the interesting design decision. There is no clone, no dependency graph, no per-file summarisation pass, and no embedding of the whole codebase. One HTTP round trip to the GitHub API for metadata, one for the tree, one for the README, then a single generation. A project like this can therefore answer quickly enough to feel like a lookup rather than a batch job.

It also means the output quality is bounded by what a directory listing and a README can convey. For a repository whose README is thin or whose interesting code sits four directories deep, the prompt will be correspondingly vague. The README is explicit that subfolder awareness is planned for later, which is an honest admission that the depth one tree is the current ceiling.

Two ways in, and a redirect that avoids 404s

The home page accepts either a full GitHub URL or an `owner/repo` pair, which is the low friction path. The second is the shareable one: `/vercel/next.js` style paths run the same flow and produce a link you can send to someone else. The route table spells this out as `/[owner]/[repo]` for a shareable quick reverse link.

The nicety is the redirect. If somebody pastes a GitHub-style path such as `/owner/repo/tree/some/path`, the site does not return a 404. It redirects to `/owner/repo` and runs the reverse flow against the whole repository. The README is careful to say the reverse still uses the whole repo for now, so the redirect is a convenience rather than a scoping feature.

Two other routes round out the app. `/library` lists cached quick prompts, and it requires Supabase, which makes it an optional surface rather than a core one. `/history` holds your own prompt history, reachable from the profile menu when signed in and synced to Supabase. The interesting contrast is between `/library`, which shows what other people generated and therefore requires the cache, and `/history`, which is scoped to you.

Five providers and an automatic fallback order

Configuration is the part of this project with real depth. The quick reverse endpoint supports five providers, and `GITREVERSE_QUICK_LLM` pins one. Left unset, the app runs in `auto` mode and uses whichever key it finds first, in a documented order: Grok, then OpenRouter, then Azure, then Google, then ApiSmart.

Each provider has a key variable, a model variable and a default model. Grok from xAI uses `XAI_API_KEY` and `XAI_MODEL` with `grok-3` as the default. OpenRouter uses `OPENROUTER_API_KEY` and `OPENROUTER_MODEL`, defaulting to `google/gemini-2.5-pro`. Azure OpenAI needs both `AZURE_OPENAI_API_KEY` and `AZURE_OPENAI_BASE_URL`, with `gpt-5.4` as the default. Google AI Studio uses `GOOGLE_GENERATIVE_AI_API_KEY` and defaults to `gemini-2.5-pro`. ApiSmart uses `APISMART_API_KEY` and defaults to `DEEPSEEK_V4_FLASH`.

Two details in that table matter in practice. ApiSmart is a sponsored OpenAI-compatible gateway, so its model IDs differ from the display names on its models page and have to be copied exactly, which the README calls out directly. And Azure is tuned rather than left at defaults: quick reverse uses `gpt-5.4` with `AZURE_OPENAI_REASONING_EFFORT=medium`, while title generation uses `gpt-5.4-mini` with reasoning disabled. The split is a sensible one, since a short title has nothing to reason about.

Optional services: Supabase caching, Stripe, and a required salt

Three services are optional and one is mandatory in production. `GITHUB_TOKEN` is optional but worth setting, because it raises the GitHub API rate limits that the whole flow depends on. Without it you are subject to unauthenticated limits, which is the most likely cause of an app that works locally and then starts rate limiting on a shared IP.

Supabase is optional and unlocks two things: server-side caching of generated prompts in a table called `prompt_cache`, and the `/library` page. With `SUPABASE_URL` and `SUPABASE_PUBLISHABLE_KEY` set, repeat lookups of a popular repository can be served from cache rather than regenerating. Without them the app still works, it just costs more model calls and has no library to browse.

The mandatory one is `VIEWS_IP_SALT`, which is required in production, and the app refuses to start in production without a non-default value. Generate one with:

openssl rand -hex 32

That variable exists because the app counts views, and hashing IPs with a server-held salt means the view counter works without storing raw addresses. It is also the one configuration item that will stop a deploy outright, which is a reasonable trade for something that fails loudly at startup rather than silently leaking an address.

Running it locally with pnpm and the Next.js scripts

Development follows the standard Next.js shape, with pnpm as the package manager:

pnpm install
pnpm dev

Then open http://localhost:3000. The production and lint paths are equally conventional:

pnpm build
pnpm start
pnpm lint

The stack is Next.js 16 with the App Router, React 19, TypeScript and Tailwind CSS 4, with the GitHub API for data and Supabase and Stripe as optional additions. The repository tree supports that reading: `app/` for routes, `components/` and `contexts/` for the client side, `lib/` for the API and generation logic, `supabase/` for migrations, `proxy.ts` at the root, and `caddy/` for what looks like a deployment proxy configuration.

A few files suggest the project is developed with coding agents in mind rather than merely targeting them. There is an `AGENTS.md`, a `CLAUDE.md` and a `.cursor/` directory at the root, plus a `scripts/` directory with npm scripts for testing titles and applying a title migration. The package scripts confirm it, with a `test:titles` entry that runs a script through the env file. For a tool whose entire premise is prompt generation, shipping its own agent instruction files is a fitting detail.

What the repository does not settle

There are two gaps worth naming before you rely on this. The first is licensing: the tree contains no LICENSE file, and no license is stated for the project, even though it carries 1933 stars and 320 forks. That is a real consideration if you plan to run the code yourself, because a public repository without a stated license grants fewer rights than you might assume, even though the hosted service is open to anyone.

The second is versioning. There are no releases, so there is no changelog to read and no version to pin. What you can see is that the repository is active, with the last push on 2026-09-02 and 13 open issues, and that the topics are `prompt-engineering`, `reverse-engineering` and `vibe-coding`, which says plainly what the author thinks the project is for. The description on the repository, reverse engineer any repo into it's original prompt, promises more than the implementation delivers, and it is worth separating those two things before you build a habit around it.

The related searches around this project point at Gitingest and Repomix, which are the projects to compare against if you need the actual file contents rather than a description of them. GitReverse deliberately stays on the other side of that line, and the difference is the whole design.

Editorial conclusion

GitReverse is best understood as a context packager rather than a recovery tool, and it works because the context it sends is small and legible: metadata, a depth one tree and a README are enough for a model to describe what the project is and what building it would involve. It earns its keep when you want a starting point in a coding agent rather than a copy of the code. It is worth knowing that the tree contains no license file, so the repository itself carries no stated license even though the hosted service is usable, and the last push was on 2026-09-02 with no tagged releases. Point `GITREVERSE_QUICK_LLM` at the provider you already pay for, leave `VIEWS_IP_SALT` at a generated value in production, and treat the output as a first prompt rather than a specification.

Frequently asked questions

Official sources

1. filiksyos/gitreverse on GitHub
2. Issues
3. Project website
4. README