app-261004/skill/fullstack-task/SKILL.md

name, description

name	description
fullstack-task	辅助 AI 完成全栈开发任务，包括需求拆解、技术选型、前后端实现、数据库设计、API 设计、测试、部署与验收。当用户要求开发功能、修复全栈 bug、设计接口、写数据库模型、做代码审查、搭建项目或交付一个可运行的端到端功能时使用本 skill。

全栈任务助手

何时使用

在以下场景加载本 skill：

• 用户要求“实现一个功能”且涉及前端 + 后端
• 用户要求设计 API、数据库模型、组件结构
• 用户要求从零搭建项目或脚手架
• 用户要求排查跨层 bug（前端 → API → DB）
• 用户要求代码审查、重构、性能优化
• 用户要求生成可运行的端到端交付物

核心原则

1. 先澄清，再动手：需求模糊时必须先确认范围、约束、验收标准。
2. 端到端思考：任何功能都要同时考虑 UI、API、数据、错误、测试、部署。
3. 最小可用优先：先跑通主链路，再优化扩展性和性能。
4. 显式优于隐式：类型、契约、边界、错误码必须明确。
5. 可运行即交付：给出的代码要能跑，不能是伪代码，除非用户明确要求。
6. 不臆造：不确定的库版本、API 行为、字段名，要标注或询问。

工作流程

第 1 步：需求拆解

输出一份简短 spec，包含：

• 目标：这个功能解决什么问题
• 用户故事：谁在什么场景下做什么
• 范围：做什么 / 不做什么
• 验收标准：可测试的条目
• 约束：技术栈、兼容性、性能、时间

如果信息不足，最多问 3 个关键问题，其余用合理默认值并标注。

第 2 步：技术方案

按需确定：

• 技术栈：参考 references/stack-defaults.md
• 数据模型：实体、字段、关系、索引
• API 契约：路径、方法、请求、响应、错误码
• 前端结构：页面、组件、状态、数据获取方式
• 部署方式：环境变量、构建、托管

第 3 步：任务拆分

拆成可独立验证的任务，每个任务：

• 有明确输入输出
• 有验收方式
• 尽量 30 分钟内可完成
• 标注依赖顺序

第 4 步：实现

按 数据 → API → 前端 → 联调 的顺序推进。

实现要求：

• 类型完整，避免 any
• 错误处理明确
• 输入校验（前后端都做）
• 环境变量集中管理
• 不硬编码密钥
• 关键路径加日志
• 命名清晰，避免缩写

第 5 步：验证

至少覆盖：

• 主链路可跑通
• 边界：空值、超长、非法输入、并发
• 错误：网络失败、DB 失败、权限不足
• 构建：build / lint / typecheck 通过
• 测试：关键逻辑有单测，主链路有集成测试

第 6 步：交付

输出：

• 变更文件清单
• 运行方式
• 环境变量说明
• 已知限制
• 后续建议

参考文档

按需加载，不要一次性全读：

• references/stack-defaults.md：默认技术栈与选型
• references/api-design.md：REST / RPC 设计规范
• references/database.md：模型、迁移、索引、事务
• references/frontend.md：组件、状态、数据获取、可访问性
• references/testing.md：测试策略与用例模板

模板

• templates/feature-spec.md：功能 spec 模板
• templates/pr-checklist.md：PR 自检清单

检查清单

交付前必须自查：

• 需求有明确验收标准
• 数据模型有主键、索引、时间戳
• API 有输入校验和错误码
• 前端有加载态、空态、错误态
• 敏感信息走环境变量
• 主链路可端到端跑通
• 构建、lint、typecheck 通过
• 有最小测试覆盖
• README 或交付说明完整

反模式

避免以下行为：

• 直接写代码不澄清需求
• 一次改动跨太多模块，难以 review
• 前端和后端契约不一致
• 忽略错误态和边界
• 把密钥写进代码
• 只测 happy path
• 交付无法运行的片段
• 编造不存在的 API 或字段

输出风格

• 中文为主，术语保留英文
• 先结论后细节
• 代码块标注语言
• 长任务分阶段汇报
• 不确定处显式标注 [待确认]