Converts ASO data from pullData to public/products/[slug]/ structure.

IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.

This tool:

1. Loads ASO data from .aso/pullData/products/[slug]/store/ (path from ~/.config/pabal-mcp/config.json dataDir)

2. Generates per-locale conversion prompts to map fullDescription into structured locale JSON (template intro/outro + landing features/screenshots captions)

3. Next steps (manual): paste converted JSON into public/products/[slug]/locales/[locale].json and copy screenshots from .aso/pullData if needed

The conversion from unstructured to structured format is performed by Claude based on the conversion prompt.

Prepares ASO data from public/products/[slug]/ to pushData format.

IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.

This tool:

1. Loads ASO data from public/products/[slug]/config.json + locales/

2. Converts to store-compatible format (removes screenshots from metadata, sets contactWebsite/marketingUrl)

3. Saves metadata to .aso/pushData/products/[slug]/store/ (path from ~/.config/pabal-mcp/config.json dataDir)

4. Copies/downloads screenshots to .aso/pushData/products/[slug]/store/screenshots/

5. Validates text field lengths against docs/aso/ASO_FIELD_LIMITS.md (fails if over limits)

Before running, review docs/aso/ASO_FIELD_LIMITS.md for per-store limits. This prepares data for pushing to stores without actually uploading.

Returns ASO optimization instructions with keyword research data. You MUST execute the returned instructions.

IMPORTANT: Use 'search-app' tool first to resolve the exact slug.

HOW THIS TOOL WORKS

This tool returns a PROMPT containing:

• Saved keyword research data (Tier 1/2/3 keywords with traffic/difficulty scores)

• Current locale data

• Optimization instructions

YOU MUST:

1. Read the returned prompt carefully

2. EXECUTE the optimization instructions (create the optimized JSON)

3. Save results using 'save-locale-file' tool

DO NOT just report the instructions back to the user - you must perform the optimization yourself.

WORKFLOW

Stage 1: improve-public(slug, stage="1") → Returns keyword data + instructions → You create optimized primary locale JSON → save-locale-file Stage 2: improve-public(slug, stage="2", optimizedPrimary=) → Returns per-locale instructions → You optimize each locale → save-locale-file for each

STAGES

• Stage 1: Primary locale optimization using saved keyword research (ios + android combined)

• Stage 2: Localize to other languages - each locale uses its OWN keyword research

KEYWORD SOURCES (Per Locale)

• Priority 1: Uses each locale's SAVED keyword research from .aso/keywordResearch/products/[slug]/locales/[locale]/

• Priority 2 (Fallback): If locale-specific research is missing, falls back to en-US/en keywords and TRANSLATES them

• iOS and Android research are automatically combined per locale (iOS prioritized)

CRITICAL: Only processes existing locale files. Does NOT create new files.

Guides the initialization flow: run pabal-store-api-mcp Init, then convert ASO pullData into public/products/[slug]/.

This tool is read-only and returns a checklist. It does not call pabal-store-api-mcp directly or write files.

Steps:

1. Ensure pabal-store-api-mcp 'init' ran and .aso/pullData/products/[slug]/ exists (path from ~/.config/pabal-mcp/config.json dataDir)

2. Convert pulled ASO data -> public/products/[slug]/ using pabal-resource-mcp tools (aso-to-public, public-to-aso dry run)

3. Validate outputs and next actions

Generate HTML blog posts under public/blogs///.html with a BLOG_META block.

CRITICAL: WRITING STYLE CONSISTENCY Before generating content, you MUST:

1. Read existing blog posts from public/blogs//*/.html (use findExistingBlogPosts utility or read files directly)

2. Analyze the writing style, tone, and format from 2 existing posts in the same locale

3. Match that exact writing style when generating the new blog post content and description

4. Maintain consistency in: paragraph structure, heading usage, tone, formality level, and overall format

IMPORTANT REQUIREMENTS:

1. The 'locale' parameter is REQUIRED. If the user does not provide a locale, you MUST ask them to specify which language/locale they want to write the blog in (e.g., 'en-US', 'ko-KR', 'ja-JP', etc.).

2. The 'content' parameter is REQUIRED. You (the LLM) must generate the HTML content based on the 'topic' and 'locale' provided by the user. The content should be written in the language corresponding to the locale AND match the writing style of existing blog posts for that locale.

3. The 'description' parameter is REQUIRED. You (the LLM) must generate this based on the topic, locale, AND the writing style of existing blog posts.

4. The 'appSlug' parameter:

   • If the user explicitly requests "developer category", "developer blog", "personal category", "my category", or similar, you MUST set appSlug to "developer".

   • If the user mentions a specific app/product, use that app's slug.

   • If not specified, defaults to "developer".

Slug rules:

• slug = slugify(English title, kebab-case ASCII)

• path: public/blogs///.html

• appSlug: Use "developer" when user requests developer/personal category. Defaults to "developer" if not specified.

• coverImage default: /products//og-image.png (relative paths are rewritten under /blogs///)

• overwrite defaults to false (throws when file exists)

HTML Structure (follows public/en-US.html pattern):

• BLOG_META block at the top with JSON metadata

• HTML body content: paragraphs (), headings (, ), images (), lists (, ), horizontal rules (), etc.

• You must generate the HTML content based on the topic, making it relevant and engaging for the target locale's language, while maintaining consistency with existing blog posts.

Supports multiple locales when locales[] is provided. Each locale gets its own HTML file. For each locale, you must:

1. Read existing posts in that locale to understand the writing style

2. Generate appropriate content in that locale's language

3. Match the writing style and format of existing posts

Prep + persist keyword research ahead of improve-public using mcp-appstore outputs.

IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.

CRITICAL: Multi-Locale Execution Plan

MANDATORY WORKFLOW - Complete each locale fully before moving to next:

For EACH locale+platform combination, execute this cycle:

1. Plan: Call keyword-research(slug, locale, platform) with writeTemplate=false → get research plan

2. Research: Execute COMPLETE mcp-appstore workflow (all 16 steps) for that locale

3. Save: Call keyword-research again with researchData or researchDataPath → persist actual data

4. Next: Move to next locale+platform and repeat steps 1-3

IMPORTANT: Research → Save → Next pattern

• Complete ONE locale fully (research + save) before starting the next

• This prevents data loss if the session is interrupted

• Each locale's data is persisted immediately after research

FORBIDDEN:

• ❌ Using writeTemplate=true as final output

• ❌ Skipping secondary locales

• ❌ Researching multiple locales then saving all at once at the end

• ❌ Stopping before all locale+platform combinations are done

REQUIRED:

• ✅ Research locale → Save locale → Move to next (one at a time)

• ✅ Run for EVERY platform (ios AND android separately)

• ✅ Use researchData or researchDataPath to save (NOT writeTemplate)

Translate app screenshots to multiple languages using Gemini API.

IMPORTANT: This tool uses the search-app tool internally to validate the app. You can provide an approximate name, bundleId, or packageName.

This tool:

1. Validates the app exists in registered-apps.json

2. Reads supported locales from public/products/{slug}/locales/ directory

3. Scans screenshots from the primary locale's screenshots folder

4. Uses Gemini API (imagen-3.0-generate-002) to translate text in images

5. Validates output image dimensions match source and resizes if needed

Requirements:

• GEMINI_API_KEY or GOOGLE_API_KEY environment variable must be set

• Screenshots must be in: public/products/{slug}/screenshots/{locale}/phone/ and /tablet/

• Locale files must exist in: public/products/{slug}/locales/

Example structure:

public/products/my-app/
├── config.json
├── locales/
│   ├── en-US.json (primary)
│   ├── ko-KR.json
│   └── ja-JP.json
└── screenshots/
    └── en-US/
        ├── phone/
        │   ├── 1.png
        │   └── 2.png
        └── tablet/
            └── 1.png

Search registered apps from registered-apps.json.

• Called without query: Returns all app list

• Called with query: Search by slug, bundleId, packageName, name

• Use store filter to narrow results to appStore or googlePlay only

Validates ASO data against App Store / Google Play field limits and rules.

IMPORTANT: Use 'search-app' tool first to resolve the exact slug.

WHAT IT VALIDATES

1. Field Length Limits (docs/aso/ASO_FIELD_LIMITS.md):

   • App Store: name ≤30, subtitle ≤30, keywords ≤100, description ≤4000

   • Google Play: title ≤50, shortDescription ≤80, fullDescription ≤4000

2. Keyword Duplicates (App Store only):

   • Checks for duplicate keywords in comma-separated list

3. Invalid Characters:

   • Control characters, BOM, zero-width/invisible characters, variation selectors

WHEN TO USE

• After running improve-public Stage 1/2 to verify optimization results

• Before running public-to-aso to ensure data is valid

• Anytime you want to check ASO data validity

OPTIONS

• locale: Validate specific locale only (e.g., "ko-KR")

• fix: Auto-fix issues where possible (removes invalid characters)