From AI Chats to a Reproducible ASO Workflow

An ASO specialist exports a keyword report, opens an AI chat, and receives a promising metadata proposal. A second specialist repeats the task in another AI tool with a slightly different prompt. A few weeks later, nobody can answer four basic questions:

• Which data did the AI analyze?
• Which instructions did it follow?
• Why was one proposal approved and another rejected?
• What was ultimately changed in the Store?

The problem is not the quality of the AI model. The problem is that a chat is being used as a system of record.

A more reliable approach is to treat ASO work like a reviewed production workflow. Before analysis, use ASO.dev to prepare the current application baseline through an export or MCP. Then collect the competitors and keywords required by the task, store their sources alongside the prompts, reports, and decisions in Git, and let an LLM analyze those known inputs. Require a human review before the final action.

This turns an isolated AI conversation into a process the whole team can inspect and reproduce.

Terminology: Apple renamed Apple Search Ads to Apple Ads in 2025. This guide uses the current name, while some export names and historical reports may still use “Apple Search Ads” or “ASA.”

Each component should have one clear responsibility.

The flow is deliberately simple:

Current application baseline from ASO.dev
(export and/or MCP)
    ↓
Task research in ASO.dev
(manual and automatic competitor search,
Spy, competitor keywords, organic keyword search)
    ↓
Task branch with data manifest
    ↓
LLM analysis using a versioned prompt
    ↓
Report and metadata proposal
    ↓
ASO.dev MCP and cross-localization validation
    ↓
Pull Request review
    ↓
Manual approval and final action
    ↓
Applied result recorded in Git

Exports and MCP are not mutually exclusive inputs. Before work starts, ASO.dev can prepare the application’s current baseline in either way: an export gives the team a fixed artifact, while MCP can provide supported live data for the selected application. A team can use either route or combine them. When MCP supplies the baseline, record the exact values and capture time in the task so the analysis remains reproducible.

The next layer is task-specific research. In ASO.dev, specialists can add known competitors manually, use automatic competitor discovery, and collect keyword candidates from Spy, competitor analysis, keyword search, and organic keyword discovery. The reviewed outputs from these sources become the inputs to the team’s pipeline. Each input should retain its source, date, Store, country, and filters.

AI chats are useful workspaces, but weak collaboration artifacts.

The app positioning, target market, brand restrictions, and previous decisions are usually spread across messages. A new chat starts without that context, and a different specialist may provide a different version of it.

A screenshot or an unnamed CSV does not establish the export date, market, language, period, completeness, or filters. Without those details, a plausible recommendation may still be impossible to verify.

If every specialist keeps a private prompt, the team cannot review why outputs differ or improve the instructions after a failed analysis.

“Looks good” in a chat does not show which exact title, subtitle, keyword field, bid recommendation, or negative keyword list was approved.

Git does not make the analysis correct by itself. It makes the inputs, rules, output, and decision visible enough to review.

You do not need a large platform project to start. A small private repository is enough:

aso-workspace/
├── README.md
├── AGENTS.md
├── apps/
│   └── my-app/
│       ├── app-context.md
│       ├── exports/
│       ├── reports/
│       └── proposals/
├── prompts/
│   └── metadata-optimization.md
├── workflows/
│   └── metadata-update.md
└── templates/
    └── pull-request.md

The files have different lifetimes:

• app-context.md contains relatively stable product and brand context.
• exports/ contains dated data snapshots or manifests pointing to controlled storage.
• prompts/ contains reusable analytical instructions.
• workflows/ defines required inputs, outputs, review, and approval rules.
• reports/ and proposals/ contain dated task results rather than one overwritten “final” file.

An agent instruction file should be short and enforceable. It should tell the LLM to:

1. read the app context and relevant workflow before starting;
2. identify whether the current app baseline came from an ASO.dev export, MCP, or both, and record when it was captured;
3. identify the source, date, Store, country, language, period, and filters for every selected research dataset;
4. treat the recorded baseline and selected task datasets as the inputs to the analysis;
5. never invent ranking, popularity, spend, conversion, or revenue metrics;
6. separate source data, observations, assumptions, and recommendations;
7. create a new dated report instead of overwriting history;
8. list missing or outdated inputs;
9. stop before any production action and request human approval.

These instructions improve consistency, but they are not a security boundary. Production access must still be limited by the actual tool permissions and the manual approval process.

Suppose a team wants to review the App Store title, subtitle, and keyword field for the United States.

Record the scope before collecting data:

Application: Example App
Store: App Store
Country: United States
Language: en-US
Fields: title, subtitle, keyword field
Objective: improve relevant keyword coverage without changing brand positioning

This prevents the analysis from expanding into unrelated localizations or product claims.

git checkout main
git pull
git checkout -b aso/us-metadata-2026-07

Each branch should represent one reviewable task. Separate source-data updates, prompt changes, and final proposals into logical commits when that makes the review clearer.

Before research starts, prepare the application’s current state through an ASO.dev export or MCP. This baseline can include the supported application identity, Store and localization context, and current metadata needed for the task. An export creates a fixed file; MCP can prepare the same working context directly from the selected application. If MCP is used, save the relevant values and capture time in the task report or manifest.

Then assemble the research data required by the task:

The specialist reviews these results and exports the selected competitors and keywords that should enter the pipeline. Discovery results are candidates, not automatic recommendations: irrelevant apps, brand terms, and weak-intent keywords should be excluded or clearly labeled before LLM analysis.

Add an export-info.md file next to the data:

# Export information

Export date: 2026-07-20
Application: Example App
Store: App Store
Country: US
Language: en-US
Analysis period: 2026-06-20 to 2026-07-19
Current app baseline: ASO.dev MCP, captured 2026-07-20 09:00 UTC
Research sources: manual competitors, automatic competitor search, Spy, organic keyword search

Known limitations:
- automatically discovered competitors have not all been reviewed;
- revenue data is not included.

The limitations are part of the dataset. The LLM must not “complete” them with assumptions.

The task given to the AI assistant can remain compact because the details already live in the repository:

Read AGENTS.md, apps/my-app/app-context.md,
workflows/metadata-update.md, the recorded current app baseline,
and the selected 2026-07-20 US research datasets.

Use prompts/metadata-optimization.md.

Analyze the current title, subtitle, and keyword field.
Create a report and a metadata proposal.
Clearly identify missing data and assumptions.
Do not perform any production action.

The expected result is not only a proposed string. It is a reviewable report containing:

• data provenance;
• relevant keyword clusters;
• current metadata coverage;
• proposed fields;
• rationale for each change;
• rejected alternatives;
• risks and unresolved questions.

After the analytical proposal exists, use ASO.dev MCP to confirm the intended application and validate supported metadata fields. Checks may include field length, required values, localization, formatting, duplicates, and consistency with the selected app.

For App Store metadata, open Cross-localization for the target country. It shows the primary and additional locales indexed together in that storefront. Repeating a word in the title, subtitle, or keyword field of another indexed locale does not strengthen indexing and can waste limited metadata capacity.

MCP exposes this check in a machine-readable form. Call get_editor_data with the target country (and asoOnly: true when only the title, subtitle, and keywords are needed). ASO.dev selects the relevant cross-locales and returns a validation result that identifies cross-locale warnings or errors, including the affected locale, field, and related locale or field. Record the country, validated locale set, and unresolved duplicate warnings with the proposal.

AI Companion runs locally. The AI can inspect and edit supported metadata in the local ASO.dev workspace, but the final save remains manual. This keeps validation close to the real application state without turning a prompt into permission to publish.

The Pull Request should answer the questions a reviewer actually has:

• Which export was used?
• What fields are in scope?
• What changed and why?
• What country and cross-locale set did MCP validate?
• Which duplicate warnings link two locales or fields?
• Which warnings remain?
• What requires explicit approval?

A review should compare the proposal with the source data, brand rules, Store restrictions, and the exact diff. Approval applies to the proposed version in the Pull Request, not to any future AI-generated variant.

After a human saves the approved metadata, update the task record with:

• the final applied values;
• the application and localization;
• the person who approved the change;
• the application date;
• any difference between the approved proposal and the applied version.

That final record closes the loop between analysis and production.

The same review model works for Apple Ads analysis, with a different execution path.

Export the relevant campaigns, ad groups, keywords, search terms, match types, bids, impressions, taps, installs, spend, conversions, and negative keywords. Record the reporting period and any attribution limitations.

The LLM can classify search terms into decisions such as:

• scale;
• keep collecting data;
• add as Exact;
• consider as Negative;
• increase or decrease bid;
• pause after specialist review.

Every recommendation should include the evidence and sample-size limitation behind it. The approved campaign action is then applied through Apple Ads or another explicitly authorized interface and recorded in the repository.

Do not imply that metadata MCP automatically provides complete campaign analytics or campaign-management access. The analytical export and the operational tool remain separate unless a supported integration explicitly says otherwise.

Branches isolate tasks without hiding work from the team:

aso/us-keyword-research-2026-07
aso/de-localization-2026-07
aso/review-analysis-2026-07
apple-ads/us-search-terms-2026-07
workflow/metadata-approval-v2
prompt/competitor-analysis-v2

Avoid having multiple specialists overwrite the same report. Let each task produce a dated draft, then create one approved version through review. If two specialists test different prompts, preserve both inputs and outputs so the team can compare the method instead of debating screenshots from separate chats.

Prompt and workflow changes should also go through Pull Requests. A prompt is part of the analytical method. When a rule changes, record the observed problem, affected tasks, new rule, and how the improvement will be evaluated.

Git history is durable, which is useful for decisions and dangerous for secrets.

Never commit credentials, private keys, access tokens, personal data, or unnecessary financial information. A .gitignore entry does not remove a secret that has already been committed.

Raw exports do not always belong in Git either:

• Small, sanitized CSV files can be committed when repository access is appropriately restricted.
• Large or sensitive exports can stay in controlled object storage. Commit an immutable reference, checksum, export metadata, and access instructions instead.
• Define retention and deletion rules before storing user-level or commercially sensitive data.

Use least-privilege access for every operational interface. An instruction such as “do not publish” is helpful, but actual permissions, confirmation steps, and audit logs provide the real control.

The safe default is:

1. analyze;
2. propose;
3. validate;
4. review;
5. approve;
6. apply manually;
7. record the result.

A team can adopt this workflow without migrating every old report.

Start with one application, one market, one recurring metadata task, and one reviewed prompt. Run the workflow twice. After the second cycle, improve only the instructions that created real confusion or review work.

The goal is not to create more process. The goal is to preserve enough context that another specialist can understand and reproduce a decision without reopening the original AI chat.

Before merging an ASO or Apple Ads task, confirm that:

• the application, Store, country, language, and period are explicit;
• the analytical dataset or immutable reference is identified;
• missing data and assumptions are visible;
• the prompt and workflow are versioned;
• the report separates evidence from recommendations;
• supported metadata was validated against the intended app and target country;
• duplicate words across the relevant cross-locales were reviewed;
• no credentials or sensitive data entered Git history;
• a human reviewed the exact proposed version;
• the final applied result will be recorded.

When those answers live in the repository, AI stops being an isolated assistant and becomes part of a reviewable ASO workflow.