Diagnoses single-source-of-truth (SSOT) violations and produces a numbered findings report — file:line evidence, honest adjudication (real violation vs idiomatic false positive), severity, and disposition per finding, plus a treatment-recipe table. Covers ten symptom classes: multi-source literals, shape proliferation, word overload, legacy-vocabulary mapping layers, dual-pathway behavior forks, scattered defaults, pure-subset shape pairs, same-name-different-shape types, redundant conversion chains, and re-implemented derivations. Use whenever the user suspects duplicated definitions, drift between layers, redundant converting or re-validating, or inconsistency — even casually: "这两个地方会不会不同步", "加一个 X 要改几处", "这个常量好像定义了两遍", "前后端形状对不上", "形状可以统一吗", "没有单一数据源", "SSOT", "双源", "漂移", "字面量重复", "同名异形", "这个类型转来转去", "转换了好几次", "没必要转这么多次", "到处都在校验/解析这个", "为什么有两个一样的 struct", "check for drift", "single source of truth", "defined twice", "converted back and forth", "do these stay in sync".
Produces a bold, high-altitude direction judgment (格局判断): a sharp thesis on the right target model, a kill-list of what to delete / merge / split / reframe, a Conservative-vs-Clean-vs-Staged options table, a verification path (first proof point + falsifier) that keeps the bold call testable, and a closing payoff ledger (收益账单) showing why the direction is worth its price. Use whenever the user wants to think bigger, open the design space, or challenge a conservative / incremental / over-compatible proposal — proactively, even when unnamed. Triggers: 打开格局, 格局太小, 你格局小了, 拔高一点, 站高一点, 别太保守, 太碎了, 别老想着兼容, 别被重构难度绑架, 大方向; and English "too incremental / too safe", "play it bigger", "greenfield this", "what if there were no legacy". Once the bold direction needs feasibility / landing pressure-testing, route to goudi.
Produces a ready-to-run ast-grep pattern or YAML rule that structurally searches, lints, or auto-rewrites code via tree-sitter AST matching, validated against positive + negative fixtures. Trigger on ast-grep, sg scan, sgconfig, tree-sitter, AST matching, structural search-and-replace, codemod — and ALSO on these tasks unnamed: (1) structural search — "list every call site of X before I refactor", "find async functions that never await", or whenever grep/regex over/under-matches (hits comments/strings, misses formatting variants); (2) batch rewrite — "replace all console.log with logger", "rename this function everywhere", "change this signature at every call site", "migrate this API repo-wide"; (3) guard — "write a lint rule for this", "ban this usage in CI". Chinese triggers: 写 ast-grep 规则, 结构化搜索, 结构化搜索替换, 语法树匹配, 按语法找代码, 找出所有调用 X 的地方, 哪些地方用了这个 API, 重构前先找全调用点, grep 误报太多, 正则匹配不准, 批量改写代码, 批量重命名, 全局改函数签名, 改参数顺序, 升级旧 API, codemod, 写个 lint 规则, 禁止这种写法, 自动改写代码.
Verifies a drifted, patched-over document block by block — against the current conclusions, the codebase, and anything else checkable — then rewrites it around the evidence: blocks that survive verification keep their original wording, blocks that fail are removed (never repaired into a plausible-looking fix), and the result ships as the rewritten document plus a disposition table (keep / delete / undecided, each citing the check) and an open-questions list. Use whenever a document has accumulated messy, doubtful claims through rounds of discussion and the user wants it verified and cleaned, not patched again. Trigger on 重写这份文档, 这文档已经烂了, 文档已经不对了, 逐条核实这份文档, 把不对的内容删掉, 按最新结论重写, 文档跟讨论结论对不上, 别再缝缝补补了, 推倒重写, and English like "rewrite this doc", "verify this doc and strip what's wrong", "this doc has drifted". For a findings report without a rewrite use hai-audit-docs-internally; if the document is a PRD use hai-prd; if it is a plan or goal document use hai-goal.
Produces a severity-rated (高/中/低) Clean Code findings report across 7 dimensions (naming, function size/SRP, duplication/DRY, over-engineering/YAGNI, magic numbers, structural clarity, project conventions), each with a location and a behavior-preserving refactor suggestion — never changing functionality. Use whenever the user asks for a code review, quality check, refactor advice, or code-smell / Clean Code analysis, OR points at a file/function/diff and asks if it is well-written, too long, too repetitive, over-engineered, or poorly named — even casually, and even if they never say "review" ("I just wrote this, look it over", "does this look good before I commit"). Trigger on 代码体检, 代码质量, 重构检查, 代码审查, 这段代码写得怎么样, 帮我看看代码有没有问题, 有没有坏味道, 这函数是不是太长了, 命名规范吗, 魔法数字, 重复代码, 过度设计, and English like "is this code clean", "any code smells", "check this file".
Generate a magazine-quality visual card as a single self-contained HTML file (embedded CSS, Swiss-grid + bold-type design system), then screenshot it to a shareable PNG and hand back both files. Use this whenever the user wants content turned into a visually rich card or shareable image — even if they don't say the word "card." Triggers: make/create/generate/design a visual card, info card, knowledge card, quote card, social card, summary/takeaway/cheatsheet card; 信息卡, 知识卡片, 金句卡, 语录卡, 做张卡片, 设计一张卡片, 把这段内容做成卡片, 把要点排成一张图, 总结成一张图, 小红书封面, 公众号封面图, 朋友圈配图. Prefer this over generic HTML/frontend skills when the goal is one decorative card image. When the content is a multi-section report instead of a single card, use hai-visual-report.
Audit and design entity data models into a field-by-field markdown report: a target-vs-current audit table per entity, a classification of every field (table column / config blob / runtime-computed / remove), a grouped migration change list, and design-decision justifications. Use this whenever the user reasons about what fields an entity should have or where they should live, even if they never say "audit": designing a data model, checking PRD fields against a DB schema, deciding store-vs-compute or column-vs-jsonb, spotting a bloated or over-modeled entity, or planning a schema migration. Trigger even when they just paste a PRD, schema, or Prisma/SQLAlchemy model and ask "are the fields right", "what's missing", "should this be a column or jsonb", "is this field even needed". Also on 实体建模, 数据模型审核, 字段审查, 字段太多了, 这个表设计得对吗, PRD 对齐, 模型设计, 该存还是该算, 列还是配置, 帮我看下这个模型.
Pressure-tests an ambitious proposal and returns a grounded landing judgment (go / shrink / pause / reject / validate-first) with one minimum-viable first move, an explicit cut list, success/failure signals, and a stop rule. Use whenever a discussion has more vision than executable grounding, or the user asks how to land/ship a bold idea, define the smallest first step, scope down, pressure-test feasibility, price risk, or set a stop/rollback rule — even if they never name the skill. Triggers on 苟帝, 落地, 先落地, 怎么落地, 别太飘, 太理想化, 收一收, 砍范围, 可执行, 可验证, 最小可行, MVP, 止损, 回滚, 风险有多大, and on "make this real / be realistic / what do I do first / is this plan feasible" — including right after a geju or architecture session. Use geju instead when the goal is to open the frame and think bigger.