Technical Design Doc

Write the design doc that gets approved: problem, constraints, the chosen approach against real alternatives, and the risks stated up front.

Write a technical design document.

What we are building and why now: [THE PROBLEM AND THE TRIGGER]
Who is affected: [USERS, TEAMS, SYSTEMS]
Requirements: [FUNCTIONAL, PLUS ANY SCALE, LATENCY, AVAILABILITY, OR COMPLIANCE NUMBERS]
Existing system: [WHAT IS THERE NOW, THE STACK, AND WHAT WE MUST NOT BREAK]
Constraints: [TEAM SIZE, DEADLINE, BUDGET, TECHNOLOGIES WE ARE COMMITTED TO OR CANNOT USE]
Approach I am leaning toward: [YOUR IDEA, or "help me choose"]
Reviewers and what they will care about: [WHO SIGNS OFF AND THEIR CONCERNS]

Structure:

1. **Summary**: the problem, the chosen approach, and the main tradeoff in under 200 words. Most reviewers read only this, so it has to stand alone.
2. **Problem and context**: what is broken or missing today, with evidence. Include what happens if we do nothing.
3. **Goals and non-goals**: goals as observable outcomes. Non-goals are the section that prevents scope arguments in review, so be generous with it.
4. **Requirements and constraints**: functional and non-functional, with numbers where numbers exist. Mark anything assumed rather than given.
5. **Proposed design**: the components, the data model, the interfaces between them, and the request or data flow for the main paths. Describe diagrams in text where a diagram would help, marked [DIAGRAM: what it shows].
6. **Alternatives considered**: 2-3 real options with their tradeoffs and why each was not chosen. Include the boring option (do nothing, or extend what exists). An alternatives section that exists to make the chosen design look inevitable convinces nobody.
7. **Failure modes**: what happens when each dependency is slow, unavailable, or wrong. What is the degraded behavior and what is the blast radius.
8. **Migration and rollout**: how we get from here to there with the system running, including the feature flag or dual-write strategy, backfill, and how to roll back after each stage.
9. **Testing and observability**: how we will know it works, and what we will be able to see in production. Name the metrics and alerts.
10. **Security and privacy**: what data is touched, who can reach it, and what changes about the threat surface.
11. **Open questions**: the decisions not yet made, each with who decides and by when.
12. **Estimate**: phases with rough sizes and the assumptions behind them.

Rules: use only what I gave you and mark inferences as such. Where a requirement is missing that changes the design (expected load, consistency needs, retention), ask for it instead of assuming a value quietly.

How to use

The non-goals and alternatives sections are what get a design approved quickly, because most review friction is really a disagreement about scope or a reviewer relitigating an option you already ruled out. Section 7 is where reviewers with production scars will focus, so write it before the meeting rather than during it. Keep the open questions visible in the published version; a design doc with no open questions is usually one that has not been thought about hard enough.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.