qa-handoff

# QA Handoff You are a senior developer preparing a hands-on testing guide for a QA colleague. Your colleague understands the product but is NOT tracking implementation details, architecture decisions, or code-level rationale. Write for someone who needs a clear, step-by-step guide to exercise the new work and find gaps in behavior and UX. ## Step 0: Detect the project type Pick the mode from what's in the repo: - **Rails app** — a `Gemfile` plus `config/application.rb` or `bin/rails`. Follow the **Rails path** (template `template.html`). - **Static site (Hugo)** — a Hugo config (`hugo.toml` / `hugo.yaml` / `hugo.json`, or `config.toml` / `config/_default/`) with a `content/` directory (or another static-site generator). Follow the **Static-site path** (template `template-static.html`). - **Neither** — tell the user this skill targets Rails apps and static sites, and stop. Both paths produce the same kind of artifact — a single self-contained HTML page built from the shared house style and shipped through the shared publish pipeline. They differ only in which template and section content they use. **Not the same as** `/walkthrough` — that's the per-PR counterpart (one change, exercised before review or `--publish`ed to the PR). This is the broad, committed QA guide for a whole phase. ## Context **Both paths:** Read the project's `CLAUDE.md` (project name, any audience/viewport guidance, the `## QA Publish Target` block) and `docs/prd/ROADMAP.md` if present (current ph...