用途
该技能提供一套软件工程的核心原则与偏好，用于在编辑代码、在软件仓库中工作或进行开发相关任务时，统一代码风格、文档编写和开发工作流。它更像是一份行为准则，指导 AI 或开发者如何写出干净、可维护、符合项目既有约定的代码。
主要能力
代码风格与模式
- 避免不必要的注释：代码应自解释，注释只保留给非显而易见的设计决策、变通方案或复杂逻辑，避免复述代码显而易见的行为。
- 保持代码库干净：除非被明确指示，否则不在提交的代码中留下 TODO、FIXME 或临时注释；应实现功能、创建 issue 或删除注释，已存在的此类注释则忽略。
- 自解释代码：优先使用清晰的命名和结构，而非解释性注释；方法、类和成员的文档应遵循语言/技术栈的最佳实践；除非解释令人困惑或复杂的行为，否则不在语句旁添加无用的行内注释。
文档
- 简洁有用：文档应有信息量但不冗长，README 应聚焦必要信息，不做多余展开。
- 结构优于啰嗦：偏好组织良好、可扫读、标题清晰的文档，而非长段落；用简短示例说明概念。
开发工作流
- 工作流检测：检查项目是否使用规格优先、测试驱动或其他结构化工作流，寻找 docs/ 或 specs/ 目录中的规格、代码库中的测试优先模式、计划文件或结构化文档；存在时遵循既有工作流模式。
- 不修改 Git：除非被明确指示，否则不使用会修改仓库状态的 Git 命令（如 git add、git commit、git push），专注于直接编辑代码；允许并鼓励使用 git status、git diff 进行分析。
- 基于事实：不臆测、不假设；如果不了解某个框架或技术或需要额外上下文，应联网搜索或使用 context7 获取最新文档；需要澄清时，在做出更改前询问用户。
- 建设性异议：如果存在更好的替代方案，不要只是接受用户指示；在审阅请求后，解释为何替代方案可能更好，并提供技术理由。
- 停下并询问：在不确定如何继续、即将添加类型忽略/抑制/any 类型、需求不清晰、或存在更好方案但需要确认时，应停下并询问用户。
- 向后兼容：仅对面向公众的接口（API、库）考虑向后兼容；对于全新/内部重构，除非被明确指示，否则以单元、集成和端到端测试作为确认关卡。
代码组织
- 单一职责：组件和函数应有单一、明确的目的；将代码组织到逻辑目录中，清晰分离关注点。
- 一致模式：遵循代码库中已建立的模式；引入新模式时，确保其与现有架构和约定一致。
- 自动化与效率：偏好自动化解决方案和高效工作流，寻找减少手工工作、改善开发者体验的机会。
输出格式
- 不使用 emoji：除非被明确指示，否则不在代码或输出中使用 emoji。
- Unicode 符号：面向用户的输出可接受 Unicode 符号（✓、✗、→、⚠）。
- 颜色与格式：鼓励在面向用户的输出中使用颜色和格式。
- NO_COLOR 支持：始终尊重 NO_COLOR 环境变量。
- 不硬编码 ANSI：绝不使用硬编码的 ANSI 颜色码，应使用颜色库（chalk、colors 等）。
最佳实践
- 框架惯例：遵循框架和语言的最佳实践，按预期使用框架特性，而非绕过它们。
- 性能意识：考虑代码更改的性能影响，尤其是 Web 应用；尽可能偏好静态生成和最小化 JavaScript。
- 无障碍性：确保代码默认具备无障碍性，使用语义化 HTML、正确的 ARIA 属性，并测试键盘导航。
使用方式
该技能以原则清单的形式提供，适用于在编辑代码、在软件仓库中工作或执行开发任务时作为行为约束。它不提供安装命令或代码示例，具体使用方式暂未提供。
适用场景
适用于需要统一代码风格、文档规范和开发流程的软件工程任务，尤其是涉及代码编辑、仓库操作、代码审查和重构的场景。
限制
该技能为原则性指导，不包含具体工具实现或自动化脚本。关于收费、价格、平台支持等信息暂未提供。参考文档包括 references/workflow-patterns.md（工作流模式与实践）和 references/implementation-workflow.md（统一实现工作流）。