sky-map-team Sky Map — Respond to Play Store Reviews
Overview
This skill fetches unanswered Google Play reviews, drafts empathetic replies grounded in the troubleshooting guide, presents them for approval, then posts the approved replies.
Never post a reply without explicit user approval.
Package name: com.google.android.stardroid — this is a single Play Store listing shared by
both stardroid-v1/ and stardroid-v2/ (v2 is designed to ship as an update
to the same listing). Reviews may describe behavior from whichever
build is currently live in production — don't assume from this skill's location that reviews
are about v2 specifically. This is a copy of v1's skymap.respond-reviews skill kept in sync in
both module trees since the review stream and troubleshooting docs are shared, not per-module.
Step 1 — Fetch reviews
Live reviews (default)
Use mcp__google-play-reviews__list_reviews with unansweredOnly: true.
Always use server-side filters to avoid fetching huge result sets. Fetching without filters can return thousands of reviews and hit token limits.
Apply any filters the user provides:
- Star rating — no server-side filter available; fetch with other filters first, then filter client-side by
review.starRating - Keywords / topics — always pass as
searchText— use the server to narrow results before they reach the client. For multiple topics (e.g. "compass or location"), make two parallel calls with differentsearchTextvalues. - Language — pass as
language(BCP-47 code) - Date range — pass as
startDate/endDatefor historical reviews; filter client-side byreview.lastModifiedfor live reviews
Historical reviews (CSV dumps)
If the user asks for reviews older than what the Play API returns (typically ~7 days), or
explicitly references "historical" / "old" reviews, read the CSV files directly — this is
faster and more flexible than the MCP server's list_historical_reviews (which is redundant).
CSV files live at ~/Code/production/stardroidreviews/reviews/ and are named
reviews_com.google.android.stardroid_YYYYMM.csv. Use grep, find, or direct file reads to
filter by date range, keyword, star rating, language, etc.
Caveat: The CSV is a static snapshot. Reply status reflects the export time — replies posted after the CSV was generated will not appear, so some "unanswered" results may already have replies. Treat results as candidates and note this limitation to the user.
Step 2 — Classify each review
For each review, classify the issue before drafting. Use the most specific matching class — the sub-classes below have different response framing.
| Class | Signals |
|---|---|
| compass-inaccurate | "wrong direction", "points wrong way", "inaccurate", "off by X degrees", "compass" |
| compass-calibrated-still-wrong | "I calibrated it but it's still wrong/inaccurate", "figure-8 doesn't help", "calibrated 50 times" |
| compass-broke-after-update | "worked before the update", "broke after update", "used to work fine", "last update ruined it" |
| map-frozen | "doesn't move", "stuck", "frozen", "won't track" |
| jitter | "jittery", "shaky", "jumpy", "wobbles", "stutters", "jerky" |
| location | "wrong location", "wrong city", "Polaris near horizon", "latitude", "permission" |
| time/timezone | "wrong time", "time zone", "off by hours", "clock" |
| very-negative | 1–2 stars with no specific technical complaint, "useless", "garbage" |
| positive | 4–5 stars with no complaint |
| other | anything else |
Step 3 — Draft the reply
Read @../troubleshooting-llm.md before drafting any complaint reply — it contains response
framing, ordered steps, and phrases to avoid for each complaint class. Also read
@../troubleshooting.md for the full technical detail. You only need to read these if there are
complaints or issues — not needed for purely positive reviews. Both files live at the repo root
(stardroid/), one level up from either stardroid-v1/ or stardroid-v2/ —
they describe user-facing symptoms and are not tied to either codebase's internals.
Base all advice strictly on what those documents say — do not invent steps, settings, or
explanations not found there. DO NOT SPECULATE that changes in Android APIs or updates to Sky Map
might have been the cause. If in doubt, ask me. Replies need to be limited to 350 characters.
Complaint replies
- Open with genuine empathy (1 sentence). Use "sorry to hear" phrasing — not "sorry" in a way that implies fault. We didn't cause the compass hardware issue.
- Give the relevant fix from troubleshooting.md, concisely.
- When the issue is hardware (compass bias, missing gyroscope) be clear and firm: Sky Map can only work with what the sensor provides. Don't soften this to the point of implying Sky Map might fix it.
- Do not suggest toggling Magnetic Correction — it only adjusts for magnetic vs. true north offset and is unlikely to help with typical compass accuracy complaints.
- Do not suggest reinstalling, clearing data, or waiting for a Sky Map update — none of these fix a hardware compass issue.
- Do not blame Android or firmware updates — don't speculate about what changed on the user's device.
- For users with a persistent/consistent compass offset: suggest the manual compass offset in Settings → Sensor Settings (Experts).
- Mention that some phones simply have bad compass hardware — this is worth noting when calibration repeatedly fails or the error is consistent across environments.
- When referencing Diagnostics: it shows the sensor's calibration status, not accuracy. A sensor showing "High" calibration can still point in the wrong direction.
- Close with an offer to help further (point to Diagnostics + email).
- Make sure you vary the wording of the replies, even when addressing similar complaints.
Positive replies
- Warm and gracious, 2–3 sentences.
- YOU MUST Vary the tone — don't use the same template for every positive reply.
- A light sky/star pun is welcome but never forced.
- Thank them by name if possible.
Language
- Write the reply in the reviewer's native language (use
review.reviewerLanguage, or infer from the review text if absent). Use US English for English reviews unless you know it's another English locale. - Always provide an English translation for the user's review as well as your response.
- If the reply contains a pun that only works in the native language, explain the pun in English.
Step 4 — Present proposals for approval
Show each proposed reply in this format:
---
Review #N ★★★☆☆ [language] [date]
Reviewer: <name>
Original: "<review text>"
[English translation of review: "<translation>" — only if original is not English]
Proposed reply (<language name>):
"<reply in native language>"
English translation of reply:
"<English translation>"
[Pun explanation: <explanation> — only if applicable]
---
After showing all proposals, ask: "Shall I post these replies? You can approve all, approve specific ones by number, or ask me to revise any."
Step 5 — Post approved replies
Only after the user approves (all or specific ones), use mcp__google-play-reviews__reply_to_review
to post each approved reply.
Confirm how many replies were posted when done.
Rules
- Propose first, post after approval. No exceptions.
- Do not invent troubleshooting advice. If a complaint doesn't match anything in troubleshooting.md, say so honestly and offer the Diagnostics + email fallback.
- Do not translate the user's approved edits — if the user rewrites a reply in English, post their version as-is.
- Historical CSV reviews can be replied to — the CSV contains the full review ID, which is all
reply_to_reviewneeds alongside the package name.