Research brief

Skill getappniche/aso-skills/skills/research-brief

ASO & app-market research skills for AI agents — Claude Code, Cursor, and any MCP client. Install: npx skills add getappniche/aso-skills

Install

npx -y skills add getappniche/aso-skills --skill research-brief

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

12 days oldThe repository was created 12 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Create a compact shared research brief — the app, its market, competitors, goals, and constraints — that other ASO and market-research skills reference instead of re-asking. Use at the start of a research engagement or when context is scattered across a long conversation.

SKILL.md

2.4 KB, as published. Nobody here has run it

Research Brief

One page that makes every subsequent analysis sharper and cheaper. Build it once, reference it everywhere, update it when facts change.

When to trigger

The user starts a multi-step research effort (discovery → keywords → metadata).
Another skill would otherwise re-ask for basics already mentioned.
The user says some form of "let me give you context about my app".

Workflow

Gather what exists. From conversation history first; then, if the GetAppNiche MCP is connected and the user's app is live, one get_app_detail call fills the factual half (category, price model, rating, scale) — cheaper and more reliable than asking the user to type it.
Ask only for what's missing and material — batch the questions in one message. Typical gaps: target user, business goal (revenue vs. installs vs. validation), markets/languages, budget realities (solo dev vs. funded team), hard constraints.
Write the brief in the fixed format below, marking every unverified statement with (assumption).
Keep it alive. When later research contradicts the brief (a competitor turns out bigger, a keyword unviable), update the brief and say what changed.

Brief format

## Research Brief: <app / working title>
- Product: what it does, for whom, in one sentence
- Stage: idea / pre-launch / live (scale if live)
- Store(s) & markets: apple/google · countries · languages
- Business goal: the one metric that matters this quarter
- Monetization: model + price points
- Competitors: 3–5 named, one clause each on why they're in the set
- Edge: the differentiator we believe in (assumption until validated)
- Constraints: team, budget, timeline, platform limits
- Open questions: what research still needs to answer

Guardrails

One page maximum — a brief nobody rereads is worthless.
Never silently invent facts to fill a field; (assumption) labels are the integrity mechanism other skills rely on.
End by suggesting the natural next skill (discovery for idea-stage, review-mining for live apps with rating trouble, keyword-research before a metadata rewrite).