- 小Bug修复不要进行回归测试，只有新功能设计时或代码重构时才进行回归测试。临时回归测试用完就删。
- 如果发现任何测试代码混入 Git，立即将其删除；禁止将测试代码提交到 Git。
- 未经用户明确授权，禁止新增、修改、删除或重命名任何 README 和 文档
- 若在temp目录创建文件记得及时清理
- 界面相关代码优先模仿Piliplus，减少独创风格
- 禁止私自修改编译产物位置。临时文件放Temp文件夹，及时处理旧的备份文件
- 禁止将源码打包入产物
- 禁止私自添加影响应用兼容性的设置(如添加额外校验字段)
- 写代码前必须思考：这么写用户体验是否更好？这个界面设计是否符合常识，是否美观？这么写是否符合正常程序设计逻辑？行业内类似程序的代码是如何实现的？
- 如果UI中一个地方可以不添加文案，那么就不要添加文案。如果一个文案能更简短，那就不要写太长
- UI中禁止出现技术细节：应用是给用户用的，而用户只需要看懂一个功能怎么用就行
- 若用户提出的要求有可以完善的地方主动进行汇报
- 任务执行前必须汇报计划，执行中若需要增加/修改/删除(包括设计功能的依赖项，修复顺手发现的漏洞，采取妥协方案，遇到网络或系统错误等)必须汇报，必要时Ask用户(若回答超时则默认执行)。
- 当为应用程序设计一个常见功能时，优先上Github搜索大项目的设计，避免出现设计缺陷。查看其他项目代码时将其Clone到本地
- 执行任务结束后主动提出下一步推荐操作
- 更新日志保存简洁，如：修复检验问题导致的备份导入失败。不要把技术细节长篇大论写入任何文档
- 开源项目优先访问其中国镜像站，若出现网络波动(常见握手失败，连接重置)重试即可。
- 若项目设计中安装了新工具，立即将其配置到系统PATH中，避免其他时候重复下载。
- 若任务足够简单，不要创建子智能体
- 任务完成后提交代码(包含用户进行的更改)
- git提交前必须确认用户是teikengstudio
- 针对 issue 提出的问题进行修复时，commit 标题必须包含对应的
#编号。 - 处理结束后必须关闭对应 issue，无论是否修复成功；如实说明处理结果与验证状态。
- 完成一项任务后立即提交推送，以与其他人完成工作同步
- 开发时基于dev分支，发行新版时将dev合并入main
- 若处理PR，将其目标分支修改为dev后合并