feature-development
Skill2 starsChanged 2 months agoMITView on GitHub
全栈功能开发顺序：Schema → API Contract → Server Implementation → Validation → Error Handling → Auth → Tests。当实现贯穿数据库、API 到 UI 的完整功能，或一个功能需要同时改后端与前端时使用；覆盖七步固定顺序、每步的硬性要求与可判定产出、契约先行的边界。
9 other projects use a version of this.
Adopted by
Most recently taken up by
- tencentmusic/juggtheir own version, first seen Oct 9, 2026
- rcore-os/tgoskitstheir own version, first seen Oct 8, 2026
- openshift/hypershifttheir own version, first seen Oct 8, 2026
- alexeyleshchenko/fast-mcp-telegramtheir own version, first seen Jul 28, 2026
- leshchenko1979/fast-mcp-telegramtheir own version, first seen Jul 28, 2026
- LooseWireDev/mealforgetheir own version, first seen Jul 4, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- tencentmusic/jugg★ 583same name
- openshift/hypershift★ 551same name
- rcore-os/tgoskits★ 76same name
- leshchenko1979/fast-mcp-telegram★ 50same name
- bordenet/superpowers-plus★ 8same name
- u9401066/template-is-all-you-need★ 3same name
- wchen02/cursor-agent-learning★ 3same name
- alexeyleshchenko/fast-mcp-telegram★ 2same name
- LooseWireDev/mealforge★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- code-reviewSkill
- project-initializationSkill
- task-planningSkill
- verificationSkill
- {{skill-name}}Skill
The file
Files
Feature Development（全栈功能开发顺序）
Purpose
强制按七步顺序实现一个贯穿数据库到 UI 的功能：先固化 Schema 与 API 契约，再写服务端与客户端实现。 产出的是「可对照的契约 + 逐层实现 + 每步可判定产出」，杜绝从 UI 开始猜 API。
When to Use
- 当一个功能需要同时改数据库、服务端接口与前端界面时
- 当前端想先写界面、而后端接口尚未存在时（本 skill 先把接口定下来）
- 当功能涉及鉴权、入参校验或错误路径，需要在实现前明确边界时
- 当需求要跨会话或多人推进，需要一份契约作为前后端共同依据时
When NOT to Use
- 不跨层的改动（纯前端或纯后端）：直接实现，收尾用
verification - 修 bug 而非加功能：改用
debugging-and-error-recovery，定位后最小修复 - 需求本身还没拆解清楚：先用
task-planning拆任务，再按本 skill 顺序执行 - 数据库搭建、环境与迁移基础设施等一次性工作：不属于功能开发顺序
Inputs
- 需求描述与验收标准：缺失或含关键歧义时先问清，禁止按猜测定契约
- 现有 Schema、ORM 与迁移命令：读不到时向用户确认技术栈，不自行假定
- 现有接口风格（REST / RPC、错误结构、鉴权方式）：以仓库已有实现为准，不另起一套
Workflow
1. Inspect
- 读现有 Schema / migration / ORM 模型：确认表结构、命名与既有约束
- 读 1-3 个已实现的同类接口及其前端调用处，记录错误结构与鉴权方式
- 从
package.json与 CI 配置确认迁移、测试与构建命令
2. Plan
- 按 Schema → API Contract → Server Implementation → Validation → Error Handling → Auth → Tests 排出本次顺序
- 契约（路径、方法、入参、出参、错误码）先写成可对照文本，标注每项是新增还是复用
- 发现与现有契约冲突或需求歧义，先问再继续，不带假设定契约
3. Implement
七步顺序执行，每步一句硬性要求 + 一条可判定产出；产出未达成不进入下一步：
- Schema：先定数据结构，再写任何接口代码 → migration / 模型已提交，字段可被查询
- API Contract：接口签名先于实现并冻结 → 契约文档或类型定义存在，前后端引用同一份
- Server Implementation：只实现契约内声明的行为 → 路由可被请求命中并返回契约结构
- Validation：在入口校验全部外部输入 → 非法入参返回 4xx 与字段级错误，且有对应用例
- Error Handling：错误路径与成功路径同样被定义 → 每种错误码都有触发用例，无裸抛堆栈给客户端
- Auth：明确谁能访问本接口 → 未授权请求被拒绝的用例通过，权限判断只在服务端
- Tests：契约字段与错误路径都有断言 → 新增用例先红后绿，覆盖契约全部字段
前端实现只能在第 2 步契约冻结后开始，按契约调用接口，不依赖未声明字段。
4. Verify
- 按契约逐字段核对前端调用与后端返回：无未声明字段被依赖，无实现期私加字段
- 非法入参、未授权、错误码用例全部通过，附输出关键行
- 迁移在干净库上从零执行一次成功，可重复执行
- 按
verification检查阶梯收尾（typecheck / lint / test / build）
Rules
- 禁止从 UI 开始猜 API：前端实现只能在契约冻结之后开始
- 契约变更必须回到第 2 步同步后再继续，禁止实现里悄悄加字段或改语义
- 校验与鉴权必须在服务端执行；客户端校验只是体验优化，不作为安全边界
- 每步的可判定产出未达成时不得进入下一步；用户要求并行时书面记录跳过的风险
- 需求跨多模块时先用
task-planning拆任务，本 skill 只管单个功能的实现顺序
Common Failure Modes
| 症状 | 纠正 |
| 前端先写死了接口返回结构 | 回到 API Contract 步骤固化契约，再改前端 |
| 接口失败也返回 200 + 错误对象 | 对齐仓库错误结构，用状态码 + 错误码表达失败 |
| 校验只写在客户端表单里 | 在服务端入口补校验，并加非法入参用例 |
| 权限判断散落在前端路由里 | 把判断移到服务端，前端只做展示层拦截 |
| 迁移在别的环境跑不起来 | 用项目声明的迁移命令在干净库上从零重放 |
Common Rationalizations
| Agent says | Correct response |
| "UI 先画出来，接口后补" | 先冻结 API Contract，再写界面 |
| "这个接口只内部用，不用校验" | 外部输入一律在入口校验 |
| "鉴权后面统一加" | Auth 在 Tests 之前完成，未授权用例先写 |
| "测试等联调完再补" | 契约字段断言随实现一起提交 |
Verification
- 契约 ↔ 实现 → 逐字段核对通过，无未声明字段被前后端依赖
- Validation / Error Handling / Auth 用例 → 全部通过并附输出关键行
- 迁移命令 → 干净库上从零执行成功
verification检查阶梯 → typecheck / lint / test / build 退出码 0
Exit Criteria
- 七步按顺序执行，每步都有可判定产出
- 前后端引用同一份契约，无实现期私加字段
- Validation / Error Handling / Auth 各有对应测试证据
- 迁移可重复执行，
verification阶梯通过并附命令输出
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.