generated-style-skill-example

name	generated-style-skill-example
description	根据已整理好的用户代码风格报告与代表性代码片段，按该用户本人风格继续写代码。用户要求“按我的风格补代码”“像我以前那样写”“沿用我这个仓库的写法”时优先使用本 skill。先读取 style-profile，再读取 representative-snippets，只应用高置信度规则，并优先服从目标模块近邻文件的现有写法。

模仿用户代码风格

使用前先读取

• references/style-profile.md
• references/representative-snippets.md

适用场景

• 用户要求“按我的风格继续写”
• 用户提供了近邻文件，希望补全模块、函数、类或测试
• 用户希望保持既有命名、控制流、注释和分层习惯

执行顺序

1. 先读取 style-profile，提取目标语言的高置信度规则。
2. 再读取 representative-snippets，优先模仿命名细节、局部变量风格和控制流微习惯。
3. 读取用户提供的近邻文件或目标模块上下文，优先对齐局部结构、命名和调用方式。
4. 样本不足时执行保守补全，并明确说明哪些地方使用了社区常规写法。

仿写决策顺序

1. 近邻文件与目标模块现有写法优先。
2. style-profile 中该语言的高置信度特征次之。
3. representative-snippets 中稳定复现的微习惯再次之。
4. 跨语言共性只用于补充，不覆盖目标语言规则。
5. 最后才使用社区常规写法做保守补全。

跨语言共性

• 优先保持已有项目语境和近邻文件风格，不做无根据的“风格优化”。
• 对复杂逻辑保持可读性优先，必要时使用小函数或显式中间变量。
• 只有高置信度规则才能强约束生成；弱信号只能轻微参考。

分语言模仿规则

Python

• 保持 snake_case 命名，函数长度和辅助函数拆分遵循 style-profile 中的证据结论。
• 先看类型注解与数据结构偏好，再决定 dataclass、TypedDict 或普通 dict 的使用。

JavaScript / TypeScript

• 保持既有 export 风格、状态管理方式和目录分层，不凭空改架构。
• 优先模仿近邻文件中的命名、局部变量风格和控制流，而不是追求“更标准”的写法。

运行时约束

• 不要在运行时重新判断“当前代码属于哪个历史项目、目录或来源簇”。
• 不要依赖完整源码背景或项目名来决定是否模仿某种风格。
• 无法确认来源时，只按近邻文件和 style-profile 中的高置信度规则续写。

证据优先级

• 目标模块近邻文件 > style-profile 的目标语言高置信度特征 > representative-snippets 的局部微习惯 > 跨语言共性 > 社区常规补全。
• 如果抽象规则与近邻源码冲突，优先服从近邻源码。

保守补全策略

• 样本不足时优先遵循目标语言社区常规写法。
• 对非高置信度规则，只做最小风格贴合，不伪造用户习惯。