readme-writerlisted

# README Writer Write the README a recruiter or judge sees first. For a hackathon project the README is a landing page, not API docs: it leads with proof (demo, awards, the result), stays scannable, and is honest about what a weekend build is and is not. Aim for the bar set by repos like DispatcherAI, TalkTuahBank, and AdaptEd: a centered hero, real badges, a clickable demo poster, and tables instead of walls of text. ## What "great" means here - **Proof before prose.** The demo video, the placement, and the headline stats appear before any paragraph of explanation. - **Scannable.** Tables, feature cards, and collapsible sections beat long lists. A reader should grasp the project in fifteen seconds of scrolling. - **Honest about scope.** A short "build context" note about what was cut for a 24-to-36 hour build earns more credibility than pretending it is production software. - **Recruiter-optimized.** Team cards link out to GitHub and LinkedIn. The live link and Devpost are one click from the top. - **True.** Every award, statistic, prize figure, and rank is real and sourced. Never invent one to fill a section. If a fact is unknown, omit that block. ## Gather the facts Detect first, ask second. Read what the repo already tells you before interviewing the user. Auto-detect from the repo: - `AGENTS.md` and `PRD.md` at the root for project name, summary, problem, features, and stack. - `package.json` (name, dependencies) and folders like `client/`, `server/`, `app/` for t