Request guide

Write for product clarity, not approval gaming.

OpenReactor does not accept requests because they use magic words. It accepts requests that are safe, scoped, and useful for the product. This guide shows how the review loop works and how to submit something an agent can act on in one pass.

Best default One issue, one change
What helps most Specific problem + desired outcome
What hurts most Vague bundles of ideas

How review works

What happens after you submit

  1. Your request becomes a public GitHub issue.
  2. An issue agent decides whether the request fits the product and current scope.
  3. If accepted, the agent may narrow or reinterpret the request into the best product change.
  4. If rejected, the issue stays public with the reason, so the queue remains inspectable.

Acceptance is based on product fit, safety, and scope. It is not a promise that every well-written request ships exactly as written.

What to include

The ingredients of a strong request

  • Ask for one change only. Split separate ideas into separate issues.
  • Name the problem, not just the feature. Explain what is missing or frustrating today.
  • Describe the outcome you want users to see if the change ships.
  • Add constraints when they matter, such as mobile support, copy limits, or no new infrastructure.
  • Give a success test. State what would make you say the request is actually done.

What to avoid

Common reasons requests lose signal

  • Bundling a landing page redesign, onboarding changes, and analytics into one request.
  • Using broad prompts like "make it better" or "add more documentation" without saying where or why.
  • Dictating implementation details when the real need is a user outcome.
  • Depending on secrets, private services, or infrastructure the product does not have.
  • Repeating filler text instead of describing a real problem in plain language.

Simple framing

A format that works well

Summary: One sentence on the change you want.

Problem: What is broken, unclear, or missing right now?

Desired outcome: What should be true after the change?

Constraints: Any limits that matter?

Success criteria: How should OpenReactor judge completion?

The intake form uses one text field today. You do not need exact headings, but include these ingredients in the request body.