FAQ

sticky reads a repo through GitHub's public REST API as an anonymous client. Private repos return 404 from that path. Supporting private repos would mean asking you to authenticate with GitHub and storing tokens with enough scope to read source — that's a much bigger surface area than this version of the project is trying to take on.

If there's demand, a future version may add "bring your own GitHub token" for a single private generation, where the token is used in-memory for one request and never persisted.

Accounts would solve problems sticky doesn't have yet — there's no per-user history to track, no profile, no settings. Adding auth before there's a reason means writing code (and storing data) that the product doesn't need. If a real reason shows up — saved wikis, private workspaces, regeneration credits — that's when auth gets added.

The most common reason is that the file wasn't in the snapshot. sticky picks at most 40 files; the heuristic (see How it works) favors source code in canonical directories, READMEs, and well-known configs. Things it skips:

• Files inside node_modules, dist, build, .next, vendor, etc.
• Files larger than 12 KB.
• Tests, specs, and .d.ts declarations (penalized in the score).
• Files with extensions outside the readable allowlist (binary, lock files).

The model is also explicitly told notto invent APIs or modules it hasn't seen. If something matters to a project and isn't mentioned, that usually means it wasn't in the 40 picked files.

Not yet via UI. The data model already captures repoCommitShaat generation time so we can tell when a stored wiki is out of date, and a "regenerate if stale" button is on the roadmap. For now, regeneration would require manually clearing the content column for that slug and revisiting the URL with ?stream=1.

A wiki reflects the default branch at the moment it was generated — see repoCommitShaon the stored row. Wikis don't auto-update. For a fast- moving repo, an old wiki may diverge from the current code; until regeneration ships, the createdAt timestamp is your honest signal of staleness.

No. It's a language model writing about source code it has seen for the first time. The system prompt insists on grounding ("don't invent APIs", "say so when something is unclear"), and in practice the output is accurate for the typical case, but you should treat any specific claim — function name, file path, behavior detail — as something to verify in the actual source.

The wiki view links back to github.com/owner/repo right under the title so you can cross-reference quickly.

Honestly, because validation hasn't been pushed up to the submit step yet — the action currently inserts the row and lets the /api/generate request fail when Octokit returns a 404. Adding a lightweight repos.get check at submit time (and surfacing a real error message) is tracked work.

Usually 30–90 seconds end-to-end. The Octokit snapshot is a few seconds; the rest is the streaming model call. The function has a 300-second ceiling as a safety net.

Generated wikis use standard Markdown headings, which become id-anchored elements when rendered. /w/some-repo#architectureworks the way you'd expect. Heading anchor links shown on hover are on the polish backlog but the underlying IDs are already there.

anthropic/claude-sonnet-4-6, accessed through the Vercel AI Gateway via the Vercel AI SDK's streamText. The model identifier is stored on each wiki row so we can tell what produced what when prompts or models change.

Yes — the project is small enough to read end-to-end in an afternoon. If you're about to fork it: most of the interesting code is in src/lib/github.ts (snapshot + scoring), src/lib/generate.ts (the prompt), and src/app/api/generate/route.ts (the streaming handler).