agentleFS
openJiuwen-aiopenJiuwen-ai/agent-core/.agents/skills/jw-coding-flow/SKILL.md

jw-coding-flow

Skill464 starsChanged 10 days agoApache-2.0View on GitHub

串联 openJiuwen AI coding 的需求澄清、设计、开发、检视、转测资料与交付,识别当前阶段并维护阶段交接。适用于完整特性流程或需要协调多个阶段的任务。

2 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

jw-coding-flow

识别用户目标、授权范围、已有设计及当前代码状态,从实际进度接入:

需求澄清 → jw-design → 设计确认 → jw-dev → jw-review → 交付
                                     └→ jw-testing(按需撰写转测文档)

强制要求

  • 改动代码必须经过 jw-dev:实现特性、修复缺陷、重构、补写测试等任何改代码的任务,动手前读取 jw-dev 并按其流程执行:验收场景、实现与测试、spec / feature / bugfix 维护、提交计划确认。 不得跳过 jw-dev 直接改代码。
  • 大特性或较大范围改动必须先经过 jw-design:开发前评估改动规模,命中下列任一情况即应先用 jw-design 形成设计文档,经用户确认后再进入 jw-dev,并按设计生命周期归档。 触发 jw-design 前必须先询问用户:说明评估结论与命中的条件,得到用户明确同意后才进入设计阶段; 用户不同意时按其指示直接进入 jw-dev 或调整范围。判定条件:

    • 新增用户 / 模型可见的能力、工具或公开 API,或改变已有公开契约、spec 不变量;
    • 跨多个模块或跨 swarm / core 仓库,或涉及 schema、持久化、协议、事件等数据形态变化;
    • 存在需要取舍的备选方案,或预计拆成多个提交 / 多个开发单元。

    未命中的日常明确修复可直接进入 jw-dev,不补造设计。评估结论(需要或不需要设计、理由)在进入开发前告知用户。

阶段路由

  • 目标、范围或关键方案未明确:先询问用户是否进入设计阶段,同意后使用 jw-design,形成可评审的方案。 用户只要求计划或设计时停在该阶段;进入实现必须符合用户已给出的授权。
  • 已有确认方案或明确的开发任务:使用 jw-dev,执行实现、测试与开发记忆维护。 日常明确修复可以直接接入,不为齐全流程补造设计文档或批准记录。
  • 进入检视:读取 jw-review。固定本地改动或已确认提交范围,核对需求与设计契约、 agent-core 技术定位、模块 AGENTS/spec、基线与候选的行为差异、实际调用链、兼容性、失败恢复及测试证据,输出问题、覆盖范围与复查条件。
  • 检视发现实现偏差回开发,发现方案缺口回设计;受影响的验证结论在修复后重新确认。
  • 需要转测资料或整理测试报告时,使用 jw-testing,根据实际实现、 spec 与已有证据编写转测文档。该能力可从开发交接直接接入,文档撰写不代表实际执行测试或验收通过。
  • 交付报告实际完成范围、测试结果、检视状态、遗留与后续动作;代码完成、测试通过、检视通过、 用户验收和已合并分别记录,不互相替代。

交接与持续记忆

设计交给开发:稳定设计标识、确认结论、范围、契约、验收场景、未决问题。 开发交给检视:实现范围、设计偏差、受影响 specs、测试证据与风险。 开发交给转测文档撰写:目标版本、实际范围、验证证据、执行环境、已知缺陷与待确认项。 转测文档状态由 jw-testing 独立管理,其本地输出不进入设计索引。 设计管理字段保留在设计中,评审按日期修订。设计是开发前方案资产,开发后的实际实施、 决策、偏差与验证结果归档至 features;开发计划引用设计管理字段,维护执行安排。 故障证据写入 bugfix,不向设计回填开发事实,不另造重复状态台账。 每阶段只读取所需 skill 与 reference,不把全部模板一次性载入。

决策与验证的交接规则

  • 新建记录前按 决策归属与替代 查找已有维护位置,说明续写、新决策或局部/完全替代;不按提交数复制文档。
  • 设计定义可观察验收条件;开发按 行为证据 核对模型/用户可见内容、真实入口和实际副作用。
  • 检视与转测引用候选版本、适用范围和重验条件;候选、依赖或前提变化时只沿用已核实仍有效的证据。
  • 有复用价值的修复按 防错模式提炼 更新所属模块规则/spec 并链接 bugfix,不把局部事故自动变成全仓禁令。

以上规则复用 design/spec/feature/bugfix 和已有交接记录,不新建全局状态台账或另设阶段。

上下文与影响分析按 因果流程与资料可信度 执行: 按任务选择模块、路径、关键符号和跨边界流程,核实旧资料版本并区分事实、推断与缺口。 交接分别说明已盘点、已理解、已检视、已验证的范围;验证后同步本次影响的既有资料,不要求先建库或补齐全仓。

实际文档在 .agents/agent-docs/,命名与存放遵循各阶段 skill。 提交、推送、PR、分支和 worktree 遵循仓库及用户约定;本流程不扩展授权。 不自动启动多代理,不运行格式化或静态检查。

文档元数据与索引

遵循 作者、设计关联与索引规则:受管文档以 frontmatter 标注 Git author,移除 owner;新 F 平铺在 features/,F/B 显式声明 designs。 写作/修改后自动运行文档同步工具刷新索引;检视只报告缺口,不改写待审资料。

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.