Why & What It Delivers
Why build it? Shipping to GitHub means juggling README, screenshots, badges, .github templates, and launch posts. Most developers cobble these together by hand or use generic generators that miss project-specific details.
What Git Launcher delivers:
- GitHub-optimized README — structure tuned for discovery, badges, and clear quick start
- Multi-viewport screenshots — desktop, tablet, mobile captured automatically
- Architecture diagrams — Mermaid-based from your actual code
- Social preview image — Open Graph-ready for link sharing
- Platform launch posts — Reddit, HN, Twitter, Dev.to, Product Hunt, each with the right tone and format
All assets are drop-in ready. One command copies everything to your project root. Saves hours of repetitive setup so you can focus on shipping.
Visual Evidence
Output evolution, key UI moments, and diagrams from the build.
Role & Scope
Solo product builder: designed, implemented, and shipped Git Launcher end-to-end.
Constraints
Local-first, no cloud
Git Launcher runs entirely inside the AI IDE. No API keys, no external services, no cost. This limits scale but maximizes privacy and simplicity.
Node.js 18+ and AI IDE required
Screenshot capture and codebase analysis need Node.js. The workflow assumes an AI agent (Cursor, Claude Code, Cowork) to execute prompts.
Submodule install model
Installed as a git submodule rather than an npm package. Keeps the plugin self-contained and version-pinned to the project.
Tradeoffs
execFileSync over exec for screenshot runner
execFileSync avoids shell injection. Arguments are passed as an array, so user-controlled paths cannot inject commands.
Alternative considered: Using exec() would allow shell metacharacters in paths; a malicious path could run arbitrary commands.
Submodule over npm package
Submodule keeps the plugin in-repo, version-locked, and easy to inspect. No registry dependency.
Alternative considered: npm install would simplify onboarding but adds registry dependency and version drift risk.
Risks & Mitigations
Each risk was identified during development and patched before shipping.
Screenshot staleness
Mitigation: Added staleness check and --preview mode. Users can re-run screenshot-runner when the app changes.
Path traversal in generated paths
Mitigation: Path validation and normalization before file writes. No user input used raw in paths.
SSRF if URLs are user-supplied
Mitigation: SSRF prevention in URL handling; secret scanning in generated content.
Security Design
Security was a primary design constraint, not an afterthought.
Shell injection in screenshot runner
Replaced exec with execFileSync. Arguments passed as array; no shell interpretation.
Secrets in generated launch posts
Secret scanning before writing. Pre-commit hooks and .dockerignore to avoid leaking credentials.
Docker mount scope
Narrowed Docker mount to project directory only. No broad filesystem access.
Architecture
The system maps directly to its component model. Each concern has a dedicated layer.
Git Launcher is structured as prompts + scripts: 00-MAIN.md orchestrates the workflow; scripts handle README generation, screenshot capture, Mermaid diagrams, and social preview. Playwright drives screenshots; Node.js runs the pipeline. Optional Docker provides isolated execution.
Iteration Timeline
Click an event to expand details.