app-evolver

App Evolver

改进应用为用户带来的实际成果。提炼可迁移的机制，判断其与当前产品的适配情况，实施已获授权的改进，并通过应用的使用界面验证结果。

将此用作编排 Skill。仓库工程、研究、历史记录访问和发布操作仍由各自现有负责人负责。若目标是 Skill，请使用 skill-evolver；若仅进行竞争对手情报分析，请使用 competitors-analysis；若要制定新的产品规格，请使用现有的需求工作流。不要用其他执行引擎取代这些负责人。

1. 确认应用和未完成的成果

在研究或编辑之前，确认以下内容：

• 确切的应用、仓库/引用、平台，以及运行时或部署标识。
• 用户的原始请求、当前产品契约和当前阶段；区分长期定位与本次选定的工作。
• 面向用户的改进、可证伪的验收证据、已获授权的交付内容、受保护的行为/数据，以及停止条件。
• 是否授权仅分析或实施，以及任何会改变结果的未决产品选择。
• 学习任务的范围。对于广泛的产品或竞争对手学习工作，应在选定单一技术场景进行研究之前，先让已确认的设备和操作人员角色，以及完整的预期用户成果及其影响判断，约束研究问题。针对单项功能或已知缺陷的任务应保持聚焦；不要将其扩展为整份产品报告。

重用用户先前作出的决定；仅在信息缺失或确有未决选择时，才在当前对话中提问。若主机提供提问工具，请使用该工具。说明证据、备选方案、后果和建议。不要通过其他 Agent 代替用户作决定。

对于多个应用，分别确认每个应用的契约和验收路径。在一个应用中成功验证的设计、权限或测量方式，在另一个应用中仍只是未经验证的提案。未经核对同系列移动应用当前的契约，不要将桌面应用的契约套用到该移动应用。

阅读仓库说明和相关领域 Skill。将用于判断的代码固定到不可变引用；另行检查当前运行时/配置。保留其他协作者的工作，并在编辑前协调存在重叠的职责。

恢复任务时，核对最新请求、实际产物和未完成的证据；从第一个尚未达成的成果继续，而不是重放原计划。用户在任务中修正前提、调整关注重点或明确变更范围时，也应进行同样的核对：更新确认信息以符合当前情况，仅撤回依赖于已被取代前提的结论，并复用其他已验证的事实。根据当前已获授权的任务选择下一个研究问题。修正一个示例，并不意味着该示例自动成为整个任务；真正缩小范围时，应立即按缩小后的范围执行，而不是把它当作随口一提。

2. 依据证据明确机会与约束

选择变更前，请阅读证据与适配度。 如果要批评界面层级或整个产品体验割裂，请先使用其结构比较， 再选择局部视觉修复方案。

请先检查现有用户旅程、素材、服务、测试和实现负责人。 在用户提出要求或其环境有此需要时，搜索可用的既有工作和个人收藏。 执行明确要求的研究方向；不要擅自用快速浏览取代深入研究或历史挖掘。 当某个方向的证据足以解决其要回答的决策时，就停止该方向的调查。

仅在明确授权范围内使用历史记录。通过所属索引和精确的会话读取器检索， 保留用户／助手／工具角色及子 Agent 的提示词／结果链接。 排除隐藏推理。明确说明覆盖范围不可用、过时或不完整；不要回退到不受限制的原始历史记录扫描。 将助手的结论视为假设，而非用户认可或当前事实。

对于竞品，除了功能列表之外，还要检查实现和最新的一手证据。使用 competitors-analysis 获取仓库证据，并由可用的研究负责人调查非仓库产品。核实版本，并区分观察到的行为与声明。将源码访问、架构借鉴、代码复用和分发许可视为彼此独立的问题；阅读仓库并不意味着获准复制其实现。

根据目标组合逆向分析 Skill

调查已发布的应用、软件包、二进制文件或运行时行为时，请阅读Skill 组合。根据缺失的证据选择专门 Skill，将其调查结果交回此工作流，并保留当前产品约定、机制决策以及工程／验收负责人。

没有可用的个人收藏时，请直接使用公开的 Skill 路由。 如果存在经授权的个人收藏夹集成，请用它寻找其他机制或框架候选项；采用前请核实其实际 Skill 源码。没有该集成不会影响使用公开路由。这是参考资料组合：其中不捆绑任何第三方 Skill 或引擎，也不授予安装、配置 MCP 或执行目标的权限。

3. 确定要迁移的内容

对于每种可能改变下一步操作的机制，请记录：

决策输入	必要答案
证据	确切的来源／引用，以及观察到的正常、失败或恢复行为
用户收益	哪项当前用户体验会改善，以及如何证伪
现有等效方案	应用已有的功能，以及差异所在
适配性和成本	契约、生命周期、数据、默认值、依赖项和运维成本
处理意见	采用、改造、拒绝或需要核实，并说明决定性原因
下一步证据	能消除剩余不确定性的最小探查或用户旅程

即使尚未发现现有缺陷，也要保留有积极价值的机会。 不要为了证明机会合理而捏造故障。拒绝与当前契约相矛盾的机制；保留有用部分，但不要照搬竞品的整套架构、商业模式或较弱的保障。某类参数尝试失败，并不意味着要无限尝试；应明确说明哪些结构上全新的证据足以支持再次尝试。

用户要求组建团队时，使用宿主实际提供的协作工具，并按需分配职责明确且范围受限的角色：产品适配性、实现／生命周期和独立质疑。提供原始需求、确切证据、明确的职责分工及可证伪的探查。在执行者核查来源或运行探查前，将发现视为假设。未获此类授权时，仅进行必要的最低限度独立审查，不要启动研究或评估的多路并行。

自行解决可通过研究查明的不确定性。只有在用户偏好、互斥的产品选择或缺少授权时才询问用户；不要询问代码或只读探查即可查明的事实。缺少可选研究方向，不会阻碍已获授权的独立工作；缺少关键契约，则必须暂停依赖它的变更，直到契约得到确认。

4. 实现最小有用增量

编辑或启动验证前，请阅读实现与验收。 对于用户请求的领域角色或分散的决策策略，在选择新增组件或迁移调用方之前，请参照 领域角色提取。

将实现工作交由代码库实际采用的工程工作流和领域负责人处理，而非 Skill Creator。如果无法使用可选 Skill，请在授权范围内遵循可访问的代码库说明并使用适用工具；不要自动安装私有依赖项，也不要谎称已运行相关检查。

按用户收益和依赖关系安排工作。保护既有行为、来源溯源、持久化、身份和恢复路径。如果产品契约要求可独立完成，就不要让可选工作进入必经的热路径；应根据此应用的工作负载和测量结果设定其限制。不要照搬无关应用的超时或设备策略。

完成用户要求的实现和必要验证；用户要求优化应用时，不要止步于计划或建议。仅分析类请求必须保持只读。遵守有关部署、生产环境写入、支出、发布和破坏性操作的授权边界。

5. 验证、纠正并交付

验证预期使用者的结果，以及受保护的健康场景。区分源码检查、合成测试、真实运行时流程、打包／安装行为、生产状态和人工采用情况。某一层的证据不能证明另一层。应在结果被使用的地方进行回读。

证据未通过时，检查原始信号，寻找能推翻当前判断的证据，并纠正根本原因或错误的判定标准。只有在相关输入或假设发生变化后才重试。使用健康和失败输入校准新的防护措施／检查；统计已检查的项目，并证明能够检测到预期的不良行为。不得仅为让检查通过而削弱产品保证。

通过既定且获授权的工作流完成仓库交付。仅更新现有产品 SSOT 中已变更的事实。按要求将可复用经验保留在其所属的 Skills 中；不要自动创建记忆文件、钩子或新流程。

报告变更内容、原因、落地位置、已通过的用户结果证据，以及尚未验证的事项。如果声明的结果取决于用户的判断，请请求人工验收；绝不可代替用户将其标记为通过。获授权的结果及必要证据齐备后即停止。如果只剩外部条件尚未满足，请说明未完成的结果和确切的恢复条件。