菜单
Android 功能需求的完整交付流程：需求分析 → 不确定点确认 → 技术方案 → 编码实现。用于新增功能、实现模块、开发页面、重构 Android 功能等任务。根据复杂度选择流程深度，避免无意义确认，也避免需求不清时直接编码。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/sunqing37/ai-rules --skill android-feature-workflow命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
资深 Android 开发专家，提供符合现代安卓开发（MAD）标准的代码和架构指导。当用户提到 Android 开发、Kotlin、Jetpack Compose、Coroutines、Flow、StateFlow、ViewModel、Activity、Fragment、Material Design、Material 3、Hilt、Koin、Gradle，或需要实现 Android 功能、构建 UI 组件、设计应用架构、审查代码、重构项目、配置依赖注入、设置构建系统、编写测试、优化 Compose 性能、处理生命周期问题、实现导航，或寻求 Android 最佳实践建议时使用此 skill。
资深 Kotlin 后端工程师，提供生产级的 Ktor/Spring Boot 代码和架构指导。当用户提到后端开发、Kotlin 服务端、REST API、Ktor、Spring Boot、微服务、数据库设计、MySQL、Redis、协程、高并发、分层架构、Clean Architecture、DDD、Controller、Service、Repository、Swagger、API 文档，或需要实现后端功能、设计 API 接口、构建微服务、优化数据库查询、处理并发问题、编写单元测试（JUnit、MockK）、生成 API 文档、审查后端代码、修复 bug、分析日志、排查性能问题、设计缓存策略、实现限流熔断时使用此 skill。提供完整可运行的生产级代码，包含分层架构、异常处理、参数校验、单元测试和 Swagger 注解。
代码审查 Skill，当用户要求审查代码、提交 PR review、检查代码质量时使用。提供结构化的审查意见。
基于 SOC 职业分类
正在显示 SKILL.md
| name | android-feature-workflow |
| description | Android 功能需求的完整交付流程：需求分析 → 不确定点确认 → 技术方案 → 编码实现。用于新增功能、实现模块、开发页面、重构 Android 功能等任务。根据复杂度选择流程深度，避免无意义确认，也避免需求不清时直接编码。 |
收到功能需求后，根据复杂度选择合适流程。目标是：先理解，再实现；简单任务不拖沓，复杂任务不盲写。
| 需求类型 | 流程 | 示例 |
|---|---|---|
| 琐碎改动 | 直接 Phase 4，并简短说明 | 改文案、调颜色、加日志 |
| 小功能 | Phase 1 → Phase 4 | 加一个按钮点击事件、补一个参数 |
| 中等功能 | Phase 1 → Phase 2 → Phase 4 | 新增列表页、接入一个 API |
| 复杂功能 | Phase 1 → Phase 2 → Phase 3 → Phase 4 | 新模块、架构变更、跨模块功能 |
判断标准：如果你对“该怎么做”有任何关键不确定点，就不要直接编码。
用以下结构梳理需求，将模糊描述转化为明确待办：
## 需求理解
- 一句话目标：[用户要什么]
- 涉及的用户场景：[谁、在什么情况下、做什么操作]
## 功能拆解
- [ ] 子功能 1：...
- [ ] 子功能 2：...
## 边界与约束
- 需要支持的 Android 版本范围：
- 需要适配的屏幕/设备类型：
- 性能要求（如响应时间、内存）：
- 与现有功能的交互：
对于琐碎改动，Phase 1 可压缩为一句话。
只有存在影响实现方向的关键不确定点时才进入本阶段。
确认模板：
我对需求的理解如下：
✅ 明确的部分：
1. ...
2. ...
❓ 需要确认的部分：
1. [问题] — 我倾向于 [方案A]，因为 [理由]。还是你希望 [方案B]？
2. [问题] — 有两种做法：
- A: [描述] → 优点：... / 缺点：...
- B: [描述] → 优点：... / 缺点：...
建议选 [X]，原因是 ...
关键原则：
确认完成后，输出实现方案：
## 技术方案
### 架构层面
- 采用的架构模式：[MVVM/MVI/沿用现有架构/...]
- 新增/修改的模块：
### 实现计划
| 步骤 | 文件 | 改动说明 | 风险点 |
|------|------|----------|--------|
| 1 | | | |
| 2 | | | |
### 关键设计决策
- [决策1]：选择 X 而非 Y，因为 ...
对于简单需求，Phase 3 可简化为一句话说明。
按 Phase 3 的计划逐步执行：
实现完成后输出：
## 变更摘要
- ...
## 验证方式
- ...
## 后续建议
- ...
对于直接修改代码的任务，避免输出大量无关解释，重点说明可验证结果。