Skip to main content
Reviews tell you what users want in their own words. Appeeky Spec writes them next to your listing, so you and your coding agent can read them before the next change, and answer them through a pull request like any other change. Reviews come from the store connections in Appeeky, so every reviews command that talks to a store needs APPEEKY_API_KEY and your apps connected in Appeeky. reviews list and reviews reply only read the repo.

​
Pull reviews

Pulling again adds new reviews and replaces ones the user edited or you answered. Nothing is lost between pulls. The daily workflow from init --ci and the Docker daily routine run reviews pull for you.

​
Where they are stored

Each line of a monthly file is one review: id, store, rating, title (App Store only), body, author, where (the App Store territory, or the Google Play language), version, date and reply when there is one. summary.md is rewritten on every pull. For each store it has:
  • reviews, average rating, share of 1–2 stars and unanswered reviews for the last 30 days, the 30 days before, and everything pulled
  • star counts, and ratings for the last five versions
  • up to five low ratings still waiting for a reply, with their ids
  • Words users use that your listing does not: words and two-word phrases that come up in three or more reviews and appear in none of your listings, with how many came from 1–3 star reviews
That last table is often the most useful part. A phrase like “fan sounds” in nine reviews is a keyword to check with suggest, or a feature to build. It filters English filler words only, so reviews in other languages show more noise.

​
Read them

Add --json to any command for output an agent can read.

​
Reply from the repo

A reply is a small YAML file. Draft it, review it in a pull request, then send it.
The review has to be in the repo already, so run reviews pull first. The review line is there for whoever reviews the pull request. You can edit text by hand. The stores limit reply length, and reply warns right away when a draft is over: Then commit the replies on a branch and open a pull request:

​
Send replies

Merging the pull request sends them: the push workflow from init --ci and the Docker push routine run reviews push --yes, and the pull request report lists every reply that goes out, with any that are too long. You can also send them yourself at any time, with or without a pull request:
push sends every reply still marked status: draft, then marks each one status: sent with sentAt, so it never goes out twice. Commit that change. If any draft is over the store’s limit, nothing is sent until you shorten it. --yes sends without asking. Without a terminal (in CI or a script), pass --yes; otherwise nothing is sent.

​
Ratings in verify

verify reads the pulled review files to compare the average rating (rating) and the share of 1–2 star reviews (low_ratings, lower is better) before and after each push. A window with fewer than five reviews is skipped, because a handful of reviews says nothing about a change. You can also use either one as an experiment metric.

​
How agents use them

Your coding agent reads summary.md and the monthly files like any other file. Ask it things like “what are people complaining about since 3.1?” or “draft replies to the unanswered 1-star reviews”. In the weekly review, the appeeky-reviews specialist reads the reviews, their summary and competitors’ low ratings. It returns what users ask for, a listing change that answers it, replies to draft and product requests the app cannot answer yet. Replies to draft go into the brief as work for a person. The weekly agent is never allowed to run reviews push. Related: Competitors and market data · Specialists and the weekly review · Commands