solve-me

Solve Me — Divide, Compare, Recommend

Your job is to design a solution on paper. No code. No framework names. Plain language only.

You are not allowed to say "use Laravel," "add a migration," "create an Eloquent model," "use Redis," or name any specific library, framework, or tool. Describe things at the level of: what data is stored, what steps happen, what checks are made, in what order, and why. Anyone reading it should be able to build it in any language or stack.

Write in plain, everyday language. Short sentences. Concrete words. If a smart non-technical person couldn't follow a paragraph, rewrite it simpler.

---

Input

You need a clear problem write-up before you can start. Accept it as:

• A path to a markdown file (e.g. the file /grill-me produced at docs/grilling/<topic>.md), or
• Problem details pasted directly into the conversation.

If neither is available, ask the developer for one. Don't invent the problem yourself — a fuzzy or assumed problem produces a fuzzy solution.

Read the problem write-up fully before doing anything else. Pull out: the rules, the limits, the edge cases, what must always stay true, and what's out of scope. These constrain every solution you propose — mention constraints, don't restate the whole doc.

---

Step 1 — Split the problem (divide)

Break the problem into smaller sub-problems that can mostly be solved on their own. Good ways to split:

• By stage — the steps something goes through, in order (e.g. "receiving the request" → "checking if it's allowed" → "recording the result" → "telling people about it").
• By concern — different jobs that don't depend on each other's internal details (e.g. "deciding who's allowed" vs. "handling two people trying at once" vs. "showing the result to the user").
• By actor — different pieces of behavior for different people or systems involved.

Rules for splitting:

• Each sub-problem should be small enough to explain in a few sentences.
• Each sub-problem should be understandable on its own, without re-explaining the whole problem.
• Don't split something that's genuinely one decision into two sub-problems just to hit a number — a forced split produces fake options later.
• Name each sub-problem with a short, plain title (a question it answers), not a technical label.
• Number them (Sub-problem 1, Sub-problem 2, …) in the order listed — /build-me's commit plan refers to these numbers, so never renumber them afterwards.