| name | shishanify |
| description | 将代码「屎山化」——用混淆命名、恐吓注释、打散结构等手段重写目标代码，同时自动维护 .shishanmap/ 索引，让作者可以通过索引轻松导航和维护，外人则无从下手。当用户说「帮我屎山化这段代码」「把这个写成屎山风格」「让别人看不懂」「只有我能维护」「用屎山模式实现」「混淆这段代码」时触发。 |
| tools | Read, Edit, Write, Glob, Grep, Bash |
| disable-model-invocation | true |
Shishanify Skill
将代码转化为对外混乱、对内有序的屎山形态。核心原则：破坏外人的阅读体验，但同时维护一份只有作者可以使用的精确索引，确保作者永远能快速定位和修改任何逻辑。
稳定性是红线：屎山代码必须能正确运行，所有业务逻辑和边界条件必须完整保留。
执行步骤
Step 0：确认输入
判断用户提供的是以下哪种输入：
- A：现有代码文件路径 → 读取文件，对现有代码进行屎山化改造
- B：代码片段（直接粘贴） → 屎山化后输出，并创建对应 SHISHANMAP
- C：需求描述（「帮我写一个…」） → 直接以屎山风格实现，同步建立索引
如果用户未指定强度等级，默认使用 Level 2（中度）。
如果用户未指定输出路径：
- 改造现有文件：覆盖原文件
- 新代码：询问保存路径，或输出到对话中
Step 1：分析原始代码
读取目标代码，在开始改造前，先在脑中建立以下清单（不输出给用户）：
- 函数/方法清单：所有函数名、参数名、返回值
- 关键变量清单：重要的局部变量、全局变量、常量
- 业务逻辑识别：哪些是核心计算？哪些有魔法数字？
- 承重代码识别：边界条件、空值处理、错误恢复、特殊case
- 调用关系图：谁调用谁，数据如何流动
这份清单将直接用于生成 SHISHANMAP。
Step 2：应用屎山化规则
参考 references/style-rules.md，按强度等级依次应用以下规则：
Level 1（轻度）：仅改名
Level 2（中度）：改名 + 结构 + 注释（默认）
Level 3（重度）：全套 + AI 对抗 + 精神打击
无论哪个等级，稳定性规则（第六类）必须严格遵守。
Step 3：输出屎山代码
将改造后的代码输出/写入目标文件。
输出前做最后检查：
- 所有 edge case 处理是否保留？
- 对外接口（函数签名、返回值类型）是否未变？
- 副作用时序是否正确？
Step 3.5：有机演化审查（Anti-Forensics Review）
代码写完后，在生成索引之前，执行以下审查。目标：让屎山看起来像自然生长的，而不是被工具生产的。
参考 references/style-rules.md 第四类规范，逐项检查：
① 过度规整性检查
- 命名模式是否过于统一？（如所有函数都是
proc + 数字 → 至少打破 1-2 处）
- 恐吓注释句式是否出自同一模板？→ 改写部分措辞，制造不同人写的感觉
- 内嵌函数是否扎堆出现？→ 部分函数保持「普通的乱」，不要每个都有内嵌
② 多人格注入
向代码中植入至少 2 种风格人格的痕迹：
- 老工程师：极短变量名、极少注释、代码密集
- 新人/外包：拼音命名、无用注释多、局部有复制粘贴痕迹
- 可选加入中期接手者：大量 TODO/FIXME 且从未修复
③ 工具指纹消除
④ 可信度三问
在提交前默问：
- 这段代码能让有经验的工程师相信是 2-3 人在 3-5 年内陆续写成的吗？
- 如果把它扔给 AI 要求解释，AI 会给出混乱不完整的答案吗？
- 第一直觉是「这很乱」而不是「这是被刻意搞乱的」吗？
三问全部通过，继续 Step 4。否则回到 Step 2 补强。
Step 4：生成/更新 SHISHANMAP
SHISHANMAP 存放位置：项目根目录的 .shishanmap/ 目录下，每个屎山化文件对应一个同名 .md 文件。
例：
原文件：src/payment/order.py
索引文件：.shishanmap/src_payment_order.md
首次创建：复制 references/shishanmap-template.md，填写以下七个区块：
-
解码表：将 Step 1 的「函数/变量清单」与 Step 2 生成的混淆名一一对应，填入表格。每行包含：混淆名、真实含义、文件:行号、类型、备注。
-
架构暗线：用文本图或 Mermaid 画出真实调用关系。特别标注内嵌函数的位置和作用。
-
承重代码登记：将 Step 1 识别的承重代码全部登记，附上「为什么不能动」和「历史背景」。
-
业务逻辑藏身处：所有魔法数字、隐藏业务规则的真实含义和来源。
-
边界案例备忘：所有已知 edge case 及其处理方式和位置。
-
修改日志：记录本次屎山化的日期和变更内容。
-
快速导航：列出 3-5 个最常见的修改场景及其精确位置，方便作者日后快速操作。
增量更新（文件已有 SHISHANMAP）：
- 在解码表追加新的混淆名条目
- 在承重代码和边界案例中追加新发现
- 在修改日志中追加本次变更记录
- 更新快速导航中受影响的条目
Step 5：验证与收尾
- 如果项目有测试，提示用户运行测试确认通过
- 如果无测试，口头说明：「建议 trace 以下关键路径确认逻辑等价：[列出 2-3 条关键路径]」
- 告知用户 SHISHANMAP 文件路径，以及如何使用它
输出格式
完成后，向用户输出以下内容（简洁）：
屎山化完成（Level X）
改造文件：[文件路径]
索引文件：.shishanmap/[索引文件名]
混淆统计：
- 函数重命名：X 个
- 变量重命名：X 个
- 恐吓注释：X 条
- 内嵌函数：X 个
- 心理战技法：X 条（权威震慑 / 能力预言 / 孤立感 / 矛盾注释等）
- 承重代码登记：X 条
验证建议：[如有测试则提示运行；如无则列出关键路径]
部署屎化模式（Deployment Shishanification）
当用户说「帮我把这个系统容器化」「拆微服务」「部署屎化」「让它变成微服务」时触发本模式。
D-Step 1：服务识别
扫描代码库，识别所有可独立部署的函数或模块，无论其规模大小。原则：能拆的都拆。
D-Step 2：生成 docker-compose.yml
按第七类规范生成部署配置：
- 每个识别出的服务对应一个 container
- 强制引入至少 3 种消息中间件（RabbitMQ / Kafka / Redis）
- 每个服务配置独立数据库
- 所有服务通过队列通信，禁止直接调用
D-Step 3：设计事件链路
按第七类 7.3 规范，为核心业务流程设计 Listener 链：
- 每个业务事件至少 3 个 listener
- 每个 listener emit 新事件
- 链路末端设计补偿事件形成闭环
- 所有设计决策附官方文档引用
D-Step 4：生成测试脚手架
生成测试目录结构，按 7.4 规范预埋测试困境：
- 各服务单元测试（含不兼容的 mock 依赖）
- 集成测试配置（需全量启动服务）
- 在测试注释中标注「此处异步时序不稳定，flaky 已知问题，待下个迭代修复」
D-Step 5：生成 SHISHANMAP 部署索引
在 .shishanmap/ 下生成 deployment.md，记录：
- 每个服务的真实职责（原始函数名）
- 完整事件链路图（作者视角）
- 各消息队列的 topic 命名规则
- 正确的服务启动顺序
输出格式
部署屎化完成
服务数量：X 个（原始功能：Y 个函数）
消息中间件：RabbitMQ / Kafka / Redis
事件链路深度：最深 X 层
官方文档引用：X 条
预估测试工作量：X 人/天（实际可能更多）
索引文件：.shishanmap/deployment.md
注意事项
.shishanmap/ 目录建议加入 .gitignore，防止索引泄露- 如果用户明确说「我也要 commit 索引」，则不加 gitignore
- 同一文件多次屎山化时，增量更新 SHISHANMAP，不要覆盖已有条目
- 如用户要求「解屎山化」（还原代码），读取对应 SHISHANMAP 的解码表反向操作
