Docskrive

Docskrive uses OpenAI and Gemini to generate documentation for your code from a GitHub link — just drag and drop. The built-in markdown editor lets you refine the output, then download or share it.

The problem

Writing docs for an existing codebase is the chore everyone defers. LLMs can summarize files, but stitching them into a coherent README, generating module-level docs, and keeping output structured takes a careful pipeline.

Approach

• GitHub repo fetcher walks the tree, prioritizing entry points (package.json, README, exported types).
• LLM prompts are layered — file summary → module summary → overall narrative — to keep context within token limits.
• Provider abstraction lets the user pick OpenAI or Gemini per generation.
• Markdown editor uses a CodeMirror-based two-pane preview with live syntax highlighting via Shiki.

Highlights

• Layered prompts beat one big context. The first version stuffed every file into a single prompt and hit the context window almost immediately on real repos. Restructuring into file → module → narrative tiers — each tier consuming only summaries of the tier below — let Docskrive handle codebases an order of magnitude larger without changing the model.
• Provider switch as a first-class feature. Same generation, two backends. Useful for cost (Gemini's longer context is cheaper for the file-summary tier) and for cross-checking when an output feels wrong — re-run with the other provider and diff the result.
• Editor matters as much as the model. The generated markdown is rarely perfect on the first pass. A CodeMirror split-pane with live Shiki highlighting means users can fix code blocks, restructure headings, and ship — instead of dropping output into a separate editor.
• No GitHub auth required for public repos. Reads via the unauthenticated GitHub API where it can; only asks for a token when rate limits or private repos require it.

What I'd do differently

• Embeddings + retrieval over flat summaries. The file-tier summaries are good but they're static; querying a vector index per generation would let Docskrive surface the right context for what the user actually wants to document (the API surface, the data model, the testing strategy) instead of trying to summarize everything equally.
• Stream the output. Long generations sit silent for 30+ seconds, which feels broken. Streaming partial markdown as it arrives — even just per-section — would change the perceived speed completely.