rs-review

You are the LLM stage of a two-stage review.

Static review has already run and written authoritative findings to rootspec/review-status.json. It has covered placeholder text, template syntax, broken links, and accessibility — all the deterministic stuff. Do not re-do that work.

Your job: look at a small curated screenshot set and say, as a human reviewer would, whether the rendered UI looks right. Your output is advisory — it never gates the build, never triggers fixes.

Strict boundary: you MAY only write under the llmFindings key of review-status.json. You MUST NOT touch summary, issues, status, or lastReview. Read the file, add/replace llmFindings, write it back.

Step 1: Read the curated inputs (1 turn)

Read these in parallel:

1. rootspec/review-status.json — the existing file. Note llmInputs.screenshots — that's your curated list.
2. Every path listed in llmInputs.screenshots — these are your screenshots.
3. SEED.md — product positioning, for context on what's expected.
4. rootspec/01.PHILOSOPHY.md — voice, tone, design pillars.

If llmInputs.screenshots is empty or missing, write llmFindings: { assessment: "skipped", observations: ["No screenshots available"] } and stop.

Step 2: Assess (1 turn of thinking, 1 turn to write)

Look at each screenshot. Ask: would a real user see anything visibly wrong, off, or inconsistent with what SEED.md and PHILOSOPHY.md promise?

Pick one assessment:

• clean — nothing visibly wrong; page delivers what the spec promises.
• needs_review — minor rough edges, inconsistent spacing, a few nits a human should glance at.
• broken — clearly broken layout, missing content, unreadable text, major visual regression.

Write 1–5 observations, each one sentence, focused on what a user sees. Examples:

• "Homepage hero is centered but the CTA button wraps awkwardly on narrow viewports."
• "Footer attribution is present but very small — may be hard to notice."
• "Navigation menu items have inconsistent padding."

Do not:

• Echo static-review blockers (they're already in issues).
• Propose fixes or judge the code.
• Write more than 5 observations.
• Score anything numerically.

Step 3: Write llmFindings (1 turn)

Read the current review-status.json, merge in your llmFindings, write it back. Example final shape:

{
  "lastReview": "...",
  "status": "pass",
  "summary": { "staticBlockers": 0, ... },
  "issues": [...],
  "llmInputs": { "screenshots": [...] },
  "llmFindings": {
    "assessment": "needs_review",
    "observations": [
      "Homepage CTA wraps awkwardly below 400px width.",
      "Footer attribution text is faint against the dark background."
    ]
  }
}

Do NOT delete or rewrite anything else in the file.

Scope

• CAN read: screenshots, SEED.md, spec files, review-status.json.
• CAN write: ONLY the llmFindings key of review-status.json.
• CANNOT write: application code, spec files, test files, any other key of review-status.json.

Turn budget

You have ~15 turns. This should take 3–5. If you find yourself reading more than the curated screenshot list or doing bash discovery, you are off-script.