gs

name gs description Go-Spring 项目研发托管入口:一句话诉求经 规划(Plan)→ 执行(Execute)→ 交付(Settle)循环,从工具集(起骨架/加接口/重生成/接组件/补测试)中选取组合并落地。在 Go-Spring 项目中开展任一研发任务时触发;由 Plan 判定是否接管,超范围时放手。 version v0.0.1 /gs Skill Go-Spring 项目研发的 PES 控制环 。不是 CLI 外壳,也不是按生命周期排好的流水线,而是: 任何请求先规划,再从独立工具集里选取本次所需能力的组合,执行并验证,最后交付沉淀。 核心认知:一个请求往往需要 多个工具的组合 ,所以无论大小,都先过 PES。工具集保持独立,由 Plan 编排。 PES 控制环 Plan ──确认──▶ Execute ──全绿──▶ Settle ▲ │ └──失败按半径回环─┘ 环节 职责 文档 Plan 判定接不接 + 分解意图 + 选工具 + 排序 + 定验收 plan/plan.md Execute 按序调用工具 + 内建验证 + 失败局部回环 execute/execute.md Settle 交付说明 + 沉淀约定 settle/settle.md 进入本 skill,一律先读 plan/plan.md (判定门在里面);不要凭记忆跳过 Plan 直接动手。 工具集(Execute 按 Plan 选用) 各工具 逻辑独立 、自带前置检查,可被自由组合。 执行前先读对应文档 ,不凭记忆。标「待补充」的为占位工具,骨架已就位、流程待填。 工具 关键词 文档 起项目骨架 新建 / 初始化 / gs init / 切换 layout tools/scaffold.md 新增业务模块(BC) 加模块 / 新增业务域 / 新建 BC / 加 domain tools/add-module.md 待补充 新增 HTTP 接口 加接口 / 新增 API / 改 IDL 加路由 tools/add-http.md 新增 gRPC 接口 加 gRPC / 改 proto 加 rpc tools/add-grpc.md 待补充 新增 Thrift 接口 加 Thrift / 改 thrift IDL tools/add-thrift.md 待补充 新增 WebSocket 入口 加 ws / 长连接推送 tools/add-ws.md 待补充 新增定时任务 加 job / 加 cron / 后台任务 tools/add-job.md 待补充 新增 MQ 消费/生产 加 consumer / 加 producer / 收发消息 tools/add-mq.md 待补充 新增 infra 防腐层 client 调下游 / 接外部系统 / 加 client tools/add-client.md 待补充 新增 infra 仓储 repo 加 repo / 持久化聚合 / 存表 tools/add-repo.md 待补充 重新生成代码 重新生成 / IDL 改了 / gs-http-gen / gs-mock tools/gen.md 接入组件(消费 Starter) 接 Redis / 接 MySQL / 接 Kafka / 加 Starter tools/wire-starter.md 补测试 / 示例 补测试 / 加用例 / 加 example tools/add-test.md 文档润色 润色文档 / 优化 README / 润色 / 改写文档 / polish doc tools/polish-doc.md 创作新 Starter(框架侧) 新建 starter / 集成新组件到 go-spring tools/new-starter.md 待补充 构建/测试( execute/build-test.md )与报错定位( execute/fix-compile.md )是 Execute 的内建验证 ,不是可选工具——任何改动后自动执行,Plan 无需显式排入。通用编译/测试报错以 AI 自身调试能力为主;这两份文档只补 go-spring 生态特有的部分(多 module 定位、生成物过期回 gen 重生成而非手改、四层依赖边界)。 会话状态机 会话进入 PES 后, PES 状态是默认处理框架 ,但不是牢笼: Plan 是可变状态 :用户任何时候可回头调 Plan,调完重新对齐再继续; 失败按爆炸半径回环,不推倒重来 :局部失败只在当前步修复重试,已完成步骤不动;仅当失败证伪了 Plan 前提,才回整体重规划; 离题旁问不破坏状态 :执行中临时问无关问题,答完回到原进度; 保真度可伸缩 :阶段永远走,产物按需生——小需求的 Plan/Settle 可以只是一句话,别为琐事产出规划/交付文档。 共用约定(所有环节与工具遵守) 代码/布局规约(生产代码怎么写、目录怎么分)不在此重复,执行前按需查阅: 编码风格与架构取向(错误包装 errutil 、IoC 启动期注入、Bean 冲突显式化、Starter 优先、子进程 IO 等): coding-style.zh.md 分层边界与目录划分( job / mqsvr 、 api/controller vs api/server/<proto>/handler 等): domain-rules.zh.md 多 module 结构(仓库根无 go.mod ; go build / test / gofmt 下钻到子 module):见项目 CLAUDE.md 以下是 skill 自身的执行约定: 上下文优先 :执行前先读 AGENTS.md / CLAUDE.md / CODING_STYLE.md / 目录约定,不凭记忆假设结构。 前置检查 :所需二进制在 PATH 中、目标目录状态符合预期、外部服务可达;不满足直接终止。 入参校验 :module path、layout、语言、接口名等参数在动手前完成合法性校验,非法值立即报错。 冲突检测 :目标目录/文件已存在等冲突直接终止,不覆盖不删除。 改动收敛 :每次代码改动后跑 gofmt + go test (必要时 go build ),给出验证结论。 变更摘要 :代码/配置/接口/文档改动完成后,输出变更清单 + 验证命令 + 遗留风险。 文档同步(动作,非态度) :同步不靠记忆,靠可检测的触发条件——改了 X 必须动 Y,当轮完成不留事后补。由 Execute 的同步检测内建执行(见 execute/execute.md 第 3 步): 改 .idl / .proto /schema 源 → 回 gen 重生成,禁手改生成物; 改接口签名(method/path/字段)→ 同步接口文档; 改配置键 → 同步配置文档/示例。 理念见 references/doc-code-sync.zh.md 。 参考文档(理念背书,非执行流程) references/ 存放跨环节的方法论结论,供判断时查阅,不排进 PES 序列: 文档 用途 references/dev-doc-chain.zh.md 从需求到交付的四层文档链,与 PES 环的对应 references/doc-code-sync.zh.md 文档与代码同步的三层机制,支撑 Execute 的同步检测