By name: code-investigation-workflow description: 当用户要求先研究代码、排查代码、看清楚现状、判断某个组件/函数/manager/文件是什么性质、该不该改、该怎么改，或用户指出“不要我说一下你才注意一下”“主动发现所有问题”“顺着代码查完整”时使用。该 skill 只规定代码调查方法，不承载具体架构、拆分、命名、MVP、UI 或 owner 规范；具体判断必须转交对应专项 skill。
Code Investigation Workflow
目标
在给出代码判断或修改方案前，先把相关代码链路查完整，避免只看用户点名的一行、一个组件或一个调用点。
本 skill 只管“怎么查”。它不定义“什么是好代码”。具体规范继续由 writing-beautiful-code、mvp-view-logic-decoupling、classic-software-design-principles、kernel-branch-owner-architecture、frontend-interaction-quality、frontend-style-encapsulation、文件组织类 skill 等承接。
调查顺序
- 明确用户问题的判断对象：组件、函数、文件、manager、状态、事件、工具链路，还是展示交互。
- 读取对象本体，标出它实际做了什么，而不是只按名字判断。
- 查所有调用方和被调用方，至少覆盖：
- 谁给它传数据和 action；
- 它把数据和 action 传给谁；
- 是否存在同类调用点、同类参数搬运或同类 owner 连接。
- 沿相关事实走一段完整链路：
producer -> owner/state -> adapter/container -> UI/consumer。只查到局部时，结论必须标注为阶段性。 - 扫同一文件、同一 owner、同一责任链中的相邻同类问题；用户点名的问题通常只是入口，不是边界。
- 再加载专项 skill 做规范判断：
- 代码审美、拆不拆、抽象力度：
writing-beautiful-code。 - 前端 MVP、business/UI 边界、store/manager/presenter：
mvp-view-logic-decoupling。 - owner、生命周期、职责边界：
classic-software-design-principles。 - kernel/branch、manager/presenter/store owner：
kernel-branch-owner-architecture。 - 样式或交互：对应 frontend skill。
- 代码审美、拆不拆、抽象力度：
- 输出结论前说明：已查到哪些证据、还有哪些没有查、推荐改什么、不改什么。
主动发现检查
回答“它是什么组件/该不该改/该怎么改”前，至少问自己：
- 这个对象是纯展示、业务容器、adapter，还是 owner？证据是什么？
- 它的 props / 参数里有没有只是路过的业务 action 或 snapshot？
- 相同 action、状态或转换逻辑是否在多个调用点重复出现？
- 调用方是否只是 layout/page/中间层，却在组装业务字段？
- 如果改这里，最近的真实 owner 是谁？是否应该直接连 owner？
- 如果不改这里，是否有更近、更上游或更下游的同类问题需要一起处理？
输出要求
给用户的结论必须包含：
- 对象性质：用代码证据说明它实际是什么。
- 链路范围：说明查了哪些调用方、被调用方或同类点。
- 专项规则：说明最终判断由哪个专项 skill 或原则承接。
- 当前建议：明确是改、不改、还是先补调查。
如果用户已经指出我漏查同类问题，必须联动 learning-from-failures 判断是否需要补强触发词或执行步骤。