Clonerrr

View saved version →

---
name: audit-app-listing
description: Audit an app's App Store or Google Play listing against its competitors with Clonerrr's App audit and turn the findings into a prioritised plan. Use when the user asks for an app store optimisation (ASO) review, why their listing is not converting, feedback on their title, keywords or screenshots, or what their recent reviews say.
---

# Audit an app's store listing

Clonerrr's App audit reads a public App Store or Google Play listing, finds the apps it competes with, and grades the listing, keywords, screenshots, recent reviews and paid ads against them.

What the user asks for comes first. If they only want one section, or a shorter answer, give that.

## Steps

1. **Get the store link.** The audit needs the app's App Store or Google Play link. If the user gave only a name, ask for the link; do not guess one.
2. **Run it.** Call `run_app_audit` with `store_url`. A new audit takes a minute or two and is worked through a few steps per call:
   - While `status` is `running`, call `run_app_audit` again with the same `store_url`. Tell the user once that it takes a minute or two.
   - If it is still running after eight calls, stop, give the user `report_url` and say the report finishes filling in on its page.
   - An audit finished in the last three days comes back at once; `audited_on` says when the listing was read.
3. **Answer from the findings** once `status` is `done`:
   - The store score and each section's score, then the `headline`.
   - The `priorities`, in the order given, each with what to change and why.
   - A link to `report_url`, where every section is laid out in full with the competitors side by side.
4. **Go deeper on request.** Each entry under `sections` has the detail: the listing's checks with a grade and a fix, the searches with today's rank, the screenshots' first three to test, the complaints in recent reviews, and ad ideas. Useful follow-ups you can write yourself: a new title and subtitle from `title_to_test` and `subtitle_to_test` (30 characters each on the App Store), a rewritten description opening, screenshot captions. For an ad idea, call `get_ad_template` with its `built_on.id` and write the script.

## What not to infer

- Ranks come only from `searches`. A search with no `rank` means the app was not in the results read (`looked_at_top`), not that it can never rank.
- Use only the numbers in the result. Do not estimate downloads, revenue or conversion rates.
- The paid ads section reads Clonerrr's library, which is a sample. Never say a competitor does not advertise; say none of its ads are in the library.
- A score is a comparison with the competitors found for this audit, not an absolute grade.

## When it cannot run

- The link is not an App Store or Google Play listing: say the audit covers those two stores only.
- The tool says the day's limit is reached: tell the user and suggest trying tomorrow. Do not retry in a loop.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: find-app-ads
description: Find real video ads that mobile apps ran on Facebook and Instagram and explain why they work, from Clonerrr's ad library. Use when the user asks for app ad examples or inspiration, what an app or a category advertises with, which hooks or ad formats last, or a breakdown of one app ad.
---

# Find app ads that kept running

Clonerrr's library holds real video ads from mobile apps, taken from Meta's Ad Library. Each has the number of days it ran, why it works, and its scenes in order. An advertiser stops paying for an ad that does not work, so days running is the signal to rank by.

What the user asks for comes first. If they want a different format, fewer ads or no links, do that.

## Steps

1. Call `search_ad_templates` with short keywords, not a sentence: an app's name (`coinsnap`), a category (`category: "Health & Fitness"`) or one plain word for the kind of ad (`testimonial`, `demo`). With nothing to go on, call it with no query: it lists the longest-running ads and every category the library has.
2. Show up to five ads. For each: the app, how long it ran, the opening line in quotes, the scene structure (Hook → Demo → CTA) and its `url` as a link. Say "run not recorded" when `days_running` is absent.
3. When the user picks an ad, or asks why one works, call `get_ad_template` with its `id`. Explain it scene by scene: what the scene is for, the words on screen and spoken, how it is shot. Then say which parts belong to that app (`specific_to_this_app`) and which any product could reuse (`carries_over`).
4. When several ads are on the table, say what the long-running ones have in common. That pattern is usually what the user came for.

The video itself plays on the ad's page, so link to it rather than describing it as attached.

## What not to infer

- Days running is the only performance figure. Never state or estimate spend, installs, click rates or revenue.
- The library is a sample. An app with no ads in it may still advertise: say the library has none of its ads, not that it runs none.
- Take lines, timings and structure from the tool results only. If a field is absent, say it was not recorded.
- The ads belong to the apps that ran them. Describe and learn from them; do not present one as the user's own or as endorsed by that app.

## When nothing matches

Say the library has no ads for that search, name the categories it does have (they come back with every result), and offer the closest ones. If the user wants ads built for their own app, use the write-app-ad workflow.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: write-app-ad
description: Write a video ad script for the user's mobile app on the structure of a real ad that kept running, from Clonerrr's ad library. Use when the user asks for an ad script, ad concepts, hooks, a creative brief or a UGC brief for their own app or product.
---

# Write an app ad on a structure that already worked

The fastest way to a good ad is to rebuild one that held up: keep its scenes, pacing and the move its hook makes, and put the user's product in it with new words.

What the user asks for comes first. If they name the ad to build on, the length or the tone, follow that.

## Steps

1. **Know the product.** With an App Store or Google Play link, call `find_ad_templates_for_app` with `store_url`. Without one, ask once what the app does, who it is for and its category, then call it with `app_name`, `category` and `description`. Do not guess a store link from a name.
2. **Pick the ads.** Read each candidate's `why_it_works`: it says what a product needs for the structure to fit. Offer two or three whose every scene this product can fill truthfully, one line each on why, with its `url`. Skip this when the user already chose an ad.
3. **Read the ad.** Call `get_ad_template` for the chosen `id`.
4. **Write the script** as a table with one row per scene of the original, in the same order and at about the same length:

   | Time | What we see | On-screen text | Voiceover |
   |---|---|---|---|

   - Replace everything in `specific_to_this_app` with the user's product: its screens, its result, its name. Keep what is in `carries_over`.
   - The hook makes the same move as the original's (a question, a bold claim, a live demonstration) in new words about this product.
   - A voice says about 2.5 words a second, so a 4-second scene has room for about 10 spoken words. Keep each caption to about 7 words.
   - Name and show the app by the middle of the ad. End on one plain call to action.
5. **Add what makes it shootable:** two alternative hooks, and a shot list of what to screen-record or film for the scenes that show the product.
6. Link the ad the script is built on.

## What not to do

- Do not copy the original's lines, or name or show the original app. Its structure is reused; its words and brand are not.
- Make only the claims the store listing or the user supports. No invented numbers, ratings, awards or testimonials.
- Do not promise results. A structure that ran a long time for one app is a good bet for another, not a guarantee.
- If no candidate fits, say so and say which scenes break, rather than forcing the product into one.

Referenced files: 1 — file references are metadata, not package contents.