ai-development-workflow
Skill0 starsChanged 9 days agoMITView on GitHub
用于跨阶段、跨工作区及多会话的 AI 协作开发,涵盖任务分工、结果回传、监控核查、验证与交接;不用于日常单次编码或无需协调的任务。
In this repository3 other files it gives its agents.
- generate-refactor-docsSkill
- git-flowSkill
- identitySkill
The file
Files
AI Development Workflow
用最少的协调成本,使需求、实现、验证和交接始终指向同一基线。按任务需要取用以下规则,不把所有任务展开成完整流程。
先选组织方式
先读项目已有工作流与最新用户决定,判断工作区、依赖、风险和独立验证需要;复用项目的分类和需求/契约机制。项目采用或要求 OpenSpec 等机制时才沿用,不自行引入统一门禁。
| 条件 | 选择及代价 |
| 单仓小改、短周期、低依赖 | 未设统筹时用单执行会话,直接实现和比例验证;用户要求统筹时仍按下述分工交执行会话产出 |
| 少量独立工作,用户选择亲自衔接 | 用户协调独立会话;上下文隔离清楚,用户承担依赖和授权转述成本 |
| 多工作区、有阶段依赖或需独立验收 | 可建议单统筹+按需执行会话;减少用户协调,增加交接成本和统筹单点风险 |
先核对用户选择和实际工具能力。采用统筹时始终按固定分工执行:统筹负责查询、协调、下发和验收管理,代码、设计、业务方案及其他实际交付物由执行会话产出;统筹可整理任务包、维护协调记录和汇总验收结论,不代替执行者制作业务交付物,也不重复询问是否采用此分工。执行者是否必须独立主会话按用户选择和实际工具能力确定,不由分工推定。角色按缺口启用,不默认全开前端、后端、产品、设计、测试和文档角色;不设固定审查人数或分数。
执行者首次接单前读取本技能及任务适用引用、项目规则和技能;复用时核对是否已加载以及相关变化,不要求每次重读全部资料。任务包提供可访问入口,不依赖会话继承上下文。
执行者专注于已明确的任务类别,统筹按类别匹配任务,不因会话空闲、历史复用或工具可用而混派不同类别的任务;自验不能代替约定的独立复验。独立成项的文档梳理、编写或修订优先交文档执行者;开发保留实现配套文档的维护职责,专业内容判断及确认仍由对应专业负责人承担。具体职责和产物归属见协作引用的“执行者类别与任务匹配”。
采用由统筹或用户协调的多执行会话分工时,开发实现默认按“专业类别+项目实际工作区”分别指派,同专业、同工作区、同阶段优先复用合适的未归档会话;不能仅因专业相同、会话空闲或改动关联,就合并多个项目的实现写入。跨项目合并须核对用户明确授权,具体边界见协作引用的“开发执行会话的工作区边界”。执行会话的工作区绑定按本次任务实际范围核对:单工作区任务绑定对应实际工作区,跨项目任务不要求绑定其中某个项目;专项测试同样适用,具体见协作引用。普通单执行会话任务不因本条自动升级组织方式。
本 Skill 不授予创建会话、委派、消息、分支或 worktree 等操作权限,授权边界见下文。没有多会话工具或权限时,统筹交付人工任务包供用户转交,不自行兼任执行者;未设统筹的单执行会话仍可按阶段执行。不要把独立主会话当作具备子 Agent 的继承、通知或上下级保证。
多会话默认下发后交还用户,仅在用户明确要求时持续跟进;轮次出口、回传与超期检查按协作引用执行。涉及多项目、多工作区、多会话,或需核验执行会话绑定、任务类别边界时,读取 协作与交接。评估或执行会话接替、接管、归档时,再读取 接管与退出;上下文退化按具体迹象评估,不以聊天长度直接切换。环境受限、使用 Mock、多方验收或准备切换发布时,读取 验证与阶段出口。
维护一条可定位的基线
复用现有任务、文档或聊天记录;只补影响决策的缺项:
- 当前目标和非目标、输入资料及版本、验收点、涉及项目、实际工作区与负责人;多项目时分别定位分支和项目间依赖。
- 最新用户决定的来源、覆盖的旧决定、影响的设计/契约/代码/用例、待同步责任人。
- 依赖、已确认的任务顺序及交付节点或日期(如有)、已授权动作与限制、交付条件、当前停止点。
更新基线不等于在途任务已采用最新决定;协作时按协作引用的变更同步规则核实。文档链接或 ID 只证明可定位,不能证明正文已核对或同步。同步外部文档另核授权、最新内容和准确操作前快照。保留来源链,避免交接摘要抹掉用户后来的纠正。设计先行或代码先行按本次决定,注明当前权威基线、同步方向和接受后待同步项,不默认设计稿始终领先。
需求→设计→接口→代码→用例→证据应能互相定位,无需复制成多套表。复用已有组件、主题和设计依据,先核锁定版本的公开能力与实际数据来源;能力缺口明确降级或待决策,不凭设计补造接口能力。可访问性或质量检查不能自动变成新增视觉、业务或权限规则。缺少预期且会改变行为时再澄清。
跨接口版本或迁移时,分别标明生产者契约和消费者适配版本,不编造冻结版本。对齐字段/类型/空值、错误、身份来源和资源归属、写入及顺序语义、样例与兼容差异;Mock 绑定所测路径的版本。就绪以本次依赖路径为范围:受影响的生产者与消费者已核对实施所需内容、版本及兼容取舍,阻断性分歧已关闭,或已有按项目机制及授权确认的适配安排;文档齐全或一方未回应均不代表就绪,无关接口无需冻结。就绪才并行依赖实现,未就绪可做独立准备。
按授权推进到可证明的出口
复用已明确授权,常规实现选择不重复询问。方案批准、本地开发、提交/推送/合并、部署、配置发布、远程主机变更、直接 DB 写、真实 API 写和消息发送的授权范围分别核实,不能相互推定。任何流程建议均不能降低系统、用户、项目或工具边界;服务操作人和自动化策略取决于本次授权。
对明确未授权的写操作,先说明目标环境、具体动作和影响,再取得所需授权;“测试”“修复数据”“恢复环境”不是写入权限。暂停和等待不会自动扩大或恢复授权。
按实际验证方式和覆盖范围报告结论;环境受限与证据边界见验证引用。
阶段结论写清:已证明范围、当前版本和证据、未闭合项及负责人、下一动作与准入条件。idle、turn 结束、代码交付或方案高分均不等于业务完成。若使用评分,只评价约定维度的方案成熟度;阻断未关闭不能靠总分放行,更不能据此声称软件正确。
小改在影响范围验证并查看最终差异后直接交付;协作阶段按约定验收出口收口。仅对变化和具体风险补验,不为流程重复全部历史。
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.

