docs: rewrite README with value-first positioning and Web UI section#179
docs: rewrite README with value-first positioning and Web UI section#179
Conversation
- Opening line sells outcome ("Stop shipping UI bugs") with competitive
positioning vs Percy/Chromatic/BackstopJS
- Renamed "HTML Reporter" to "Web UI for Reviewing Screenshot Changes"
with GitHub Actions PR comment integration shown inline
- Promoted Web UI to its own section (was buried in 1 line)
- Replaced tuning table with single configure block
- Reframed Troubleshooting as "Common Questions"
- Added Diff.compare usage showing actual return API
- Folded ruby-vips into Quick Start Gemfile
Based on 3-reviewer brutal honesty review (Rails dev, DevOps, OSS maintainer).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Reviewer's GuideRepositions the README and reporters documentation around outcome-focused value, surfaces the Web UI as a first-class feature with GitHub Actions integration, simplifies configuration guidance, and clarifies common workflows and troubleshooting examples without changing any runtime code. Flow diagram for the documented screenshot baseline and Web UI review processflowchart LR
A[Run tests first time] --> B[Save baseline screenshots to doc/screenshots]
B --> C[Commit baselines to git]
C --> D[Run tests again]
D --> E[Compare new screenshots to committed baselines]
E --> F{Screenshots different?}
F -->|No| G[Test passes]
G --> H[CI uses committed baselines to guard regressions]
F -->|Yes| I[Generate diff, overlay, and heatmap images]
I --> J[Generate snap_diff_report.html Web UI]
J --> K{Change intentional?}
K -->|No| L[Fix UI or code]
L --> D
K -->|Yes| M[Delete baseline file or entire doc/screenshots]
M --> D
C --> N[Push branch to GitHub]
N --> O[GitHub Actions runs tests in CI]
O --> P[Upload screenshot report artifact]
P --> Q[Link report in pull request comment for inline review]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
📝 WalkthroughWalkthroughThe PR updates README.md to reorganize documentation with emphasis on offline git-baseline + CI-for-PR visual regression workflow, including new sections on "Why this gem?", screenshot change handling, Web UI review process, image comparison API, and reworked guidance on flaky tests. Additionally, docs/reporters.md renames an existing section header. Changes
Possibly related PRs
Poem
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
README.md (1)
87-87: Use a pinned ref for the GitHub Action in docs examples.At Line 87,
@masteris mutable. Prefer a version tag or commit SHA so copied CI configs stay reproducible and safer over time.Suggested docs tweak
- uses: snap-diff/snap_diff-capybara/.github/actions/upload-screenshots@master + uses: snap-diff/snap_diff-capybara/.github/actions/upload-screenshots@<tag-or-commit-sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` at line 87, The docs example uses a mutable ref for the GitHub Action: replace the `uses: snap-diff/snap_diff-capybara/.github/actions/upload-screenshots@master` reference with a pinned ref (a specific release tag like `@v1.2.3` or a commit SHA) so the example remains reproducible; update the single `uses:` line string in the README to the chosen tag/SHA.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@README.md`:
- Line 87: The docs example uses a mutable ref for the GitHub Action: replace
the `uses:
snap-diff/snap_diff-capybara/.github/actions/upload-screenshots@master`
reference with a pinned ref (a specific release tag like `@v1.2.3` or a commit
SHA) so the example remains reproducible; update the single `uses:` line string
in the README to the chosen tag/SHA.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 75e12b18-c824-45dd-8f21-b1e9e2ff4899
📒 Files selected for processing (2)
README.mddocs/reporters.md
Summary
Diff.compareusage showing actual return APIContext
Based on 3-reviewer brutal honesty review (Rails dev persona, DevOps persona, OSS maintainer persona). Original README scored 6/10 on conviction — main gaps were value positioning, buried killer feature (Web UI), and cognitive overload from tuning table.
Test plan
🤖 Generated with Claude Code
Summary by Sourcery
Rewrite the README to emphasize value proposition, clarify setup, and highlight the Web UI for reviewing visual regressions.
Documentation:
Diff.compareand expand the Common Questions section for baseline updates, flakiness, and CI differences.Summary by CodeRabbit