技能介绍

它解决什么问题

团队协作写代码时，问题往往不是代码本身写不出来，而是纪律散架：依赖注入位置随意、日志格式各模块不一致、目录结构没人遵守，变更发生时找不到可查的文档。temporal 工作流和模块化服务变多之后，调用链路和错误处理策略更容易丢失上下文。code-standards 的目标不是生成代码，而是把"开工前的工程纪律"固化下来：先补文档，再动手。

核心能力与工作方式

技能在以下时机触发：用户要求写代码、实现功能、创建模块，创建或修改 temporal 工作流，新增 service、activities、models。开始编码前必须完成两件事：

更新 item.md：记录项目流程、主要类与函数（含输入输出）、temporal/api 调用链路，只记录主要函数的调用关系
查阅目录结构：新建文件时先读同目录的 directory-structure.md，确定文件应该放在哪里

随后按清单逐项检查：

所有依赖必须在文件开头注入；日志统一使用 src/infrastructure 中的格式
常用组件（数据库连接、Temporal 客户端、日志器）在 src/infrastructure 中建类统一管理，示例覆盖 MySQL、PostgreSQL、MongoDB、Redis、Presto/Trino，使用方式是复制示例文件后从 config 读取参数
temporal/ 和 modules/ 目录中，每个 workflow 的 activity 和 service 都要定义成类
环境变量与全局常量统一在 config/ 文件夹注入；哪些放进 .env 文件，每次新增都得询问用户
次要函数命名加 _ 前缀，且不记录在 item.md 中；pydata 数据校验只给主要函数定义，以减少代码量
item.md 的流程步骤用表格标注：类/方法、输入输出、文件位置、错误处理

适用边界与注意点

这套规范是为 temporal 工作流加 Python 风格目录结构的项目设计的。如果你的仓库不区分 src/infrastructure、config/、temporal/、modules/ 目录，前几条检查项需要自行适配。它只约束动手前的流程与代码约定，不负责生成代码或测试。依赖注入位置、日志格式、函数命名属于硬性约定，执行检查清单时逐项勾选，能直接定位违规项。