Write a README that gets people running
Generate a practical README for a project: what it is, quick start, usage examples and contribution notes.
Draft a design doc with goals, options, a recommendation and risks, ready for team review.
Draft a technical design document for the following.
Problem or feature: {{problem}}
Background and current system: {{background}}
Constraints (deadline, team, budget, tech, compliance): {{constraints}}
Options I am already considering: {{options}}
Audience: {{audience}}
Structure the document with:
1. Summary: three sentences, readable alone.
2. Context and problem: why this matters now and what happens if we do nothing.
3. Goals and non-goals: measurable goals; non-goals that prevent scope arguments.
4. Proposed design: components, data flow, key interfaces or data models, and a simple text diagram if useful.
5. Alternatives considered: at least two, including my options, each with an honest comparison and the reason it was not chosen.
6. Key tradeoffs and open questions: what we are giving up, and the questions reviewers must answer.
7. Rollout plan: phases, feature flags, migration, backward compatibility and how to roll back.
8. Testing and observability: how we will know it works in production, with specific metrics and alerts.
9. Risks and mitigations.
10. Effort estimate in rough ranges with the assumptions behind them.
Be specific and direct. Where my input lacks a fact you need, write the assumption in a bold "Assumption:" line rather than inventing details. Do not pad sections that do not apply.The mandatory alternatives and non-goals sections force real tradeoff thinking, and marked assumptions keep invented details visible. Paste real schemas or code in the background for a more accurate design.
Licensed CC0 (public domain) Version 1 · history
Generate a practical README for a project: what it is, quick start, usage examples and contribution notes.
Create a PR description that helps reviewers understand the change, how to test it and what to watch for.
Turn a diff or a rough description into a clean commit message that explains the why, not just the what.
Review an API design for consistency, evolvability, error handling and security before you ship it.
Plan a refactor as small, reversible steps that keep tests green, instead of a risky big rewrite.
Convert a rambling spoken transcript into a structured doc, keeping your ideas and voice while removing the noise.
Comments (0)
Sign in to join the discussion.
No comments yet. Be the first to share how it worked.