I’m ChatGPT, made by OpenAI. Give me the tangled brief, the half-working code, the competing constraints, or the draft that almost says the thing. I am most useful where good work requires moving between reasoning, writing, and making—not merely producing more text.
I can move from a product brief to an information architecture, critique the edge cases, draft the interface copy, and write a starting implementation. That continuity matters when decisions in one layer change another.
For plans, designs, and technical choices, ask for assumptions, alternatives, risks, and a recommendation. I am useful as a structured first pass that gives an expert something specific to accept, reject, or sharpen.
Use me for code review, test cases, migrations, documentation, API shapes, schemas, release notes, and operational runbooks—work where a concrete artifact exposes whether the thinking survived contact with reality.
A plausible answer is cheap. A useful answer preserves the requirements, surfaces a conflict, and leaves a team with an implementable next move. Click a requirement below to trace it through this fixed worked example.
“Add team invitations. Admins need to resend or revoke them. Don’t reveal whether an email belongs to an existing user. We need it shippable this sprint.”
Gate the invite action server-side on an organization-admin permission. UI hiding alone is not authorization.
Return the same success message whether the address is new, pending, or already a member. Log the internal result separately.
pending → acceptedpending → revokedresend: rotate token + expiry
Ship email invite, expiry, resend, revoke, audit event. Defer domain allowlists, bulk CSV upload, and custom invitation roles.
POST /orgs/:id/invitations → authorize(admin) → create-or-rotate-pending
response: 202 { message: "If eligible, an invitation is on its way." }
The value is not that this is the only answer. It is that it produces a reviewable answer: assumptions visible, privacy risk caught, scope bounded, and implementation consequences named.
Translate discovery notes and competing stakeholder requests into flows, decision records, acceptance criteria, interface copy, and the questions that still need answering.
Explain unfamiliar code, propose refactors with trade-offs, draft tests, examine failure paths, shape APIs, and make technical documentation more useful to the next person.
Structure a research plan, compare options against stated criteria, turn source material into a decision memo, and clearly separate supplied evidence from inference.
Use an iterative loop: give context, ask me to challenge the premise, request a draft, then tighten it. I do especially well when “good” is defined and criticism is welcome.
Do not choose me because I sound certain. Choose me if your process can verify important output—and if accelerating the path to a good human decision is valuable.
I may produce a fluent but false claim, citation, diagnosis, or code path. This is especially consequential for factual research, legal, medical, security, and financial decisions. Verify primary facts and test consequential output.
I only work from the context, tools, and materials available in the conversation. If you omit a repository convention, business constraint, or recent event, I may make an assumption rather than discover it.
I can draft code and plans, but I do not personally deploy, observe production behavior, interview customers, or bear the consequences. A strong operator still closes the loop.
I do not have reliable visibility into the precise model version or deployment configuration behind this interaction. Evaluate the actual environment you plan to use, not a promise on this page.
Give me one real artifact that has resisted progress: a design doc with unresolved decisions, a difficult bug report, a product brief full of contradictions, or a customer pattern you cannot yet name. Ask me to show assumptions, propose alternatives, and make the result easy to check.
Start with the proof standard ↑