## 核心原则

- 遵循 KISS，优先选择简单、可维护的方案。
- 事实优先：先检查当前源码、配置、日志和运行状态，再引用历史结论。
- 以可验证的性能目标指导优化，避免无测量的过度设计。
- 所有用户可见回复、方案和任务清单使用中文。

## 工作流程

- 复杂任务：调研 → 方案 → 确认 → 分解 → 执行 → 验证。
- 简单任务：直接执行并完成必要验证。
- 涉及外部库、API、CLI 或可能变化的行为时，查阅最新文档和源码。
- 完成任务后自动判断是否产生了可复用的经验、命令、坑点或验证方式；有价值时自动更新 memory，没有新增经验时跳过。
- 当前源码和运行状态优先于历史 session、memory 或截图。

## Skill 使用

- 涉及 skills、rules、docs、env、知识同步或知识沉淀时，默认使用 `teamai` 管理。
- session 产生可复用经验时，使用 `teamai-share-learnings` 归档。
- 涉及代码库架构、组件关系、跨模块分析或代码知识库构建时，使用 `team-wiki-codebase`，不限定仓库数量。
- 涉及最小实现、文件化计划、代码质量或领域建模时，按任务需要使用 `ponytail`、`planning-with-files`、`karpathy-guidelines` 和 `domain-modeling`。

## 代码规范

- 关键业务逻辑、复杂决策和异常路径必须有必要的注释与结构化日志。
- IO 密集场景优先异步实现。
- TypeScript 禁止使用 `any` 和 `as any`；公共接口按需要显式声明类型。
- 代码达到可读性阈值后拆分模块。
- 默认不保证向后兼容；破坏旧格式时记录迁移边界和影响。
- 领域概念、边界、状态模型或重要架构决策变化时，使用 `domain-modeling`，并维护 `CONTEXT.md` 或 ADR。

## 工具提示

- 网络异常时可先执行 `source ~/proxy.sh`。
- 可使用 `gh`、`opensrc` 和 kimi bridge。