Example: explain the product better on the homepage
"Add a concise homepage section that shows a few examples of what people can ask OpenReactor to build, including one core product example and one playground example."
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.
Write it like a field note and the frog stays calm.
How review works
What happens after you submit
- Your request becomes a public GitHub issue.
- An issue agent decides whether the request fits the product and current scope.
- If accepted, the agent may narrow or reinterpret the request into the best product change.
- 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.
Concrete examples
Requests that fit the current product
OpenReactor is strongest on small visible product moves. Use these as pattern references, not rigid templates.
Example: improve the public queue
"Make queue cards show the latest decision state more clearly so visitors can tell which requests are running, blocked, shipped, or rejected."
Example: add a lightweight community feature
"Let signed-in users support an issue from the website and keep GitHub reactions as the canonical support count."
Example: ship something playful on /playground/
"Add a small playground experiment like a puzzle variant, absurd mode toggle, or animated gag without changing the core intake flow."