aso-marketing

ASO 营销 — 应用商店优化全生命周期

一套全面、迭代式的 ASO 工作流，涵盖从分析、规划、执行、验证到报告的整个过程，适用于 Apple App Store 和 Google Play Store。

环境检查

运行此技能前，请确认：

• 项目是移动应用（iOS、Android 或两者）
• 你可以访问应用的源代码或元数据文件
• 你可以读取项目配置文件（build.gradle、Info.plist 等）
• 你可以在项目目录中创建或更新元数据文件

如果任何一项检查未通过，请停止并请求澄清。

编辑前同步仓库（必须）

在现有仓库中创建、更新或删除文件之前，请先将当前分支与远程同步。先运行 dry-run 命令进行预览，然后在执行有破坏性的同步操作前征求用户确认。

# Dry-run preview first
git fetch --dry-run origin
git status

# Then sync (after user confirms working tree is clean or backed up)
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

如果工作树不干净，请先征求用户同意，再执行 stash。如果缺少 origin、无法拉取，或发生 rebase/stash 冲突，请停止并在继续前征求用户意见。

元数据文件备份优先规则： 覆盖任何现有元数据文件（例如 metadata/version/1.0/en-US.json、fastlane/metadata/android/en-US/title.txt）之前，请在同一目录中创建 .bak 副本，或确认该文件已纳入版本控制。未经用户明确确认，绝不删除元数据文件。

子 Agent 架构

此技能采用分阶段流水线 + 审核循环架构。每个阶段都对应 agents/ 中的一个子 Agent：

1. agents/analyzer.md — 阶段 1 分析报告
2. agents/plan-writer.md — 阶段 2 ASO 计划
3. agents/compliance-checker.md — 阶段 3 禁用关键词 + 商标检查
4. agents/executor.md — 阶段 4 元数据变更
5. agents/reviewer.md — 阶段 5–6 审核 + 最佳实践验证

主 Agent 负责协调阶段转换，并在阶段 3 后设置用户审批关卡。

工作流概览

此技能遵循 7 阶段循环。绝不能跳过政策合规检查或计划审批关卡——执行开始前，用户必须先批准符合政策要求的计划。

Phase 1: Analyze → Phase 2: Plan → Phase 3: Policy Compliance Check
  → [User Approval Gate] → Phase 4: Execute → Phase 5: Review
  → Phase 6: Verify → Phase 7: Summarize

开始之前

1. 阅读 references/aso_best_practices.md，了解完整的 ASO 知识库——尤其是“商店政策合规”部分，其中详细说明了 Apple 和 Google 的禁用关键词、商标规则和列表政策限制。
2. 确定用户希望优化哪些应用商店。
3. 确认用户是否已有元数据文件、上线中的商店列表，或是否准备从头发布。

阶段执行

按顺序执行每个阶段。详细说明、模板和检查清单位于参考文件中。为缩小上下文窗口，请在执行相应阶段前阅读对应文件，且只在执行前阅读。

阶段 1：分析

阅读 references/phases-1-2.md（阶段 1 部分）。收集代码库信息，审查现有商店元数据，识别竞争对手，确定基准表现，并生成分析报告。

阶段 2：规划

阅读 references/phases-1-2.md（阶段 2 部分）。制定优先级计划，涵盖目标、目标关键词（主要／次要／长尾）、元数据优化（标题、副标题、关键词、描述、新功能）、视觉素材、本地化、评分策略和时间安排。

阶段 3：政策合规检查

阅读 references/phase-3-compliance.md。逐项检查拟议的元数据字段是否符合以下要求：

• 禁用关键词列表（Apple + Google）
• 商标和竞争对手品牌检查
• 格式规则（不得使用表情符号、全大写文字，遵守字符限制）
• 内容准确性

如果发现任何违规，请静默修改计划并重新运行合规检查。用户最终只能看到合规的计划。

用户审批关卡

合规检查通过后，向用户展示计划和合规报告。在用户明确批准计划之前，不得进入阶段 4。 根据需要反复迭代；每次修订后都必须重新通过合规检查。

阶段 4：执行

阅读 references/phases-4-7.md（阶段 4 部分）。按优先级顺序系统地实施已批准的更改。**覆盖任何现有元数据文件之前，先创建 .bak 备份或确认版本控制已涵盖该文件。**每次编辑后验证字符数限制。

阶段 5：审核

阅读 references/phases-4-7.md（阶段 5 部分）。对每个已更改字段执行审核清单。再次扫描，查找违禁关键词和商标泄露。

阶段 6：依据最佳实践进行验证

阅读 references/phases-4-7.md（阶段 6 部分），并对照 references/aso_best_practices.md。最后检查是否符合政策要求。

阶段 7：总结

阅读 references/phases-4-7.md（阶段 7 部分）。生成最终总结报告（所做更改、元数据对比、合规状态、预期结果、后续步骤、修改的文件）。

步骤完成报告

每次运行恰好输出 5 份报告 — 分母 M 始终为 5：阶段 1、阶段 2-3、阶段 4、阶段 5-6、阶段 7。每份报告均使用 √ 表示通过、× 表示失败。格式和各阶段检查清单见 references/edge-cases.md（“步骤完成报告”部分）。

预期输出

一次完整运行会生成三份产物：分析报告（阶段 1）、ASO 计划 + 合规报告 + 更新后的元数据文件（阶段 2-4），以及总结报告（阶段 7）。各部分的示例请参见 references/expected-output.md。运行随后以最终报告收尾。

最终报告

每次运行结束时（包括中止的运行），都要在步骤完成报告之后附上四行的 Result / Evidence / Uncertainty / Decision 区块；此区块不能替代阶段 7 的总结报告。Result: 后的第一个词必须是 COMPLETE（所有适用的验收标准项均已勾选）、PARTIAL（分析报告已生成，但仍有未勾选项，例如用户拒绝了计划）或 BLOCKED（尚无分析报告）。状态表、示例和填写规则见 references/final-report.md。

示例

输入：一款元数据表现较弱的 iOS+Android 效率应用。

Title (iOS): FocusFlow: Work Timer            (21/30, no primary keyword)
Keywords (iOS): timer,focus,work,productivity (29/100, 71 chars unused)
Short Desc (Android): A simple timer for focused work. (32/80, weak)

阶段 4 后的输出（metadata/app-info/en-US.json）：

{
  "name": "FocusFlow: Focus & Work Timer",
  "subtitle": "Deep Work Sessions & Tracking"
}

关键词字段输出：

pomodoro,concentration,study,productivity,distraction,blocker,habit,goal,task,routine,break,planner

（99/100 个字符，所有违禁词均已清除，且未重复使用标题或副标题中的词语。）完整演练见 references/expected-output.md。

验收标准

如果所有元数据均符合字符数限制、不含违禁关键词或商标、遵守了用户审批关卡，并且生成了所有必需报告，则技能运行成功。完整标准列表见 references/edge-cases.md（“验收标准”部分）。最终报告还必须通过 references/final-report.md 中的四项读者检查；若没有人工审核者的答复，则无法确认人类是否理解。

边缘情况

常见边缘情况（本地没有元数据文件、仅支持单个平台、无法访问竞品信息、尚未发布的应用、主要语言不是英语、用户拒绝计划、草稿中存在违规内容）已记录在 references/edge-cases.md 中。遇到相关边缘情况时，请阅读该文件 — 不要自行变通。

平台专属说明

Apple App Store、Google Play Store 以及跨商店惯例（索引字段、字符数限制、经 OCR 索引的屏幕截图、A/B 测试界面）已记录在 references/edge-cases.md（“平台专属说明”部分）。

跨技能集成

此技能可与 seo-ai-optimizer 配合使用。有关何时组合使用，请参见 references/edge-cases.md（“跨技能集成”部分）。

安全与注意事项

• 未经确认，不得执行破坏性操作。 执行 git pull --rebase 前，先在 Repo Sync 中运行试运行预览，并征得用户确认。执行 git stash 或删除任何文件前，先询问用户。覆盖现有元数据文件前，先创建 .bak 备份，或确认该文件已纳入版本控制。向用户报告每一项失败或错误；不得默默重试。
• 合规检查关卡不可妥协。 绝不向用户提供不合规的计划；未经明确批准，绝不执行。
• 商标注意事项： 第 1 阶段分析中出现的竞争对手品牌名称绝不能出现在拟定的元数据中。