hai-stack

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.

Produce an evidence-grounded architecture review or design-decision critique — an architecture map, the painful complexity center, 3-6 chosen review lenses, ranked findings with file:line evidence, why-not alternatives, and a red/blue adversarial check — grounded in John Ousterhout's "A Philosophy of Software Design" (APoSD). Trigger on any architecture or system-design quality question: module/package boundaries, abstraction depth, deep vs shallow modules, information hiding, dependency direction, change amplification, ownership, error boundaries, or split vs merge — including 架构审查, 架构 review, 模块边界, 依赖方向, 抽象太浅, 复杂度太高, 这个设计合不合理, or an APoSD / Ousterhout review. Be pushy: trigger even when they only say "is this structure ok", "these modules feel tangled", "should I split this", or "why does touching X force edits everywhere".

Audits documentation against the actual code, config, schemas, and API contracts and produces a severity-ranked (P0-P3 + needs-evidence) report of every stale or mismatched claim, each with a doc location, a code/contract reference, the impact, and a minimal suggested fix. Use whenever the user wants to verify README/docs/API docs against the implementation, check whether docs fell behind, or confirm setup steps / env vars / endpoints / examples still match the code after a rename or refactor — even on casual asks like "是不是过时了", "README 和代码对不上", "readme 还准吗", "我们改了接口文档忘了更新吧", "audit our docs", or "do the docs still match". Trigger on 文档和代码一致性, 文档是否过时, 文档跟实现不一致, 这个 API 文档还准不准, openapi 和文档对得上吗, verify docs against code, docs vs implementation. For doc-vs-doc internal contradictions with no code comparison, use hai-audit-docs-internally instead.

Audits a document or doc set from the inside and produces a prioritized findings report (P0-P3) of internal conflicts, stale content, terminology drift, duplication, and misplaced or unsupported claims, plus update/move/merge/remove/split decisions and a suggested repair order. Use this whenever the user wants docs sanity-checked or cleaned up for self-consistency without comparing against code, even when they never say "audit": contradictory or duplicate sections, stale assumptions, unclear structure, or a PRD/spec that should hang together. Trigger on casual and Chinese phrasings too: 文档自相矛盾, 文档前后不一致, 文档内部冲突, 审一下这份文档, 帮我审审这个 PRD, 文档体检, "these two sections disagree", "is this spec consistent", "the docs repeat themselves". If the truth source is the code, use hai-audit-docs-against-code instead.

Produces a written goal document before execution starts — a verifiable target, boundary, current state, phased route, per-phase rules, todos with proof, a dry-run, and a Go / No-Go judgment — instead of coding while watching to see if it works. Use whenever the user wants to start, go, implement, ship, build, or move forward; gives a vague intent that needs a concrete goal; asks to break work into phases or todos; or hands over an existing plan plus a target and wants it rewritten and re-anchored around that target. Trigger even when they never say "goal" or "plan": 开始干, 开搞, 我们开始吧, 先别急着写代码先定个目标, 把这个拆成阶段, 拆 todo, 落地方案, 执行计划, 怎么落地, 立个目标, 围绕X重新规划, 重写这个计划, "lets just ship this", "gonna start building now", or just a one-line intent plus "do it". To first decide whether the work is even worth doing, use hai-idea instead.

Evaluates whether an idea deserves attention and returns a clear verdict — Do / Validate first / Reframe / Defer / Kill — with a dimension-by-dimension scorecard, the strongest objection, a stronger reframe, and the cheapest validation test. Use whenever the user wonders if an idea, feature, product, or project is good, worth doing, worth their time, a distraction, or a fake need; wants two or more ideas compared and ranked; or asks whether to build, ship, kill, postpone, or reframe — even when said casually, never as an explicit "evaluate this". Trigger on 想法是不是好主意, 我有个想法, 帮我看看这个想法, 这个点子怎么样, 值不值得做, 值得投入吗, 要不要做, 该不该做, 这个需求要不要接, 是否应该验证, 该不该砍掉, 是不是伪需求, 是不是在瞎折腾, 哪个更值得做, and casual English like "should I build this", "is this worth my time", "worth doing? or kill it".

Produces 3-5 candidate names with one recommended final name, the three-stage reasoning trail behind it (research-stage / top-of-head / final-after-reading), and — for reviews — a priority-ordered rename list with old->new and migration scope. Use when the user asks how to name or rename anything (concept, variable, function, prop, module, type, file, domain entity, event, or abstraction), wants a naming review or audit, or says a name feels vague, stiff, misleading, inconsistent, too long, too generic, or hard to choose — even if they only mention it in passing while reviewing code. Be pushy: trigger on "what should I call this", "better name for X", "this name sucks", "rename this var", "whats a good name", "review my naming". Chinese triggers: 起名, 命名, 取名, 改名, 名字不好, 这个叫什么好, 取个名字, 换个名, 这名字怎么样, 名字太长, 命名规范, 命名审查, 变量名/函数名怎么取.

Produces a PRD recommendation, draft, or document-level diagnosis: decides whether a PRD is even needed (vs a goal, design doc, or task), drafts one from a product problem, audits/repairs an existing PRD for drift and unverifiable acceptance, or judges whether to split / merge it. Use whenever the user mentions a PRD, product requirements, requirements doc, or spec — writing, rewriting, refining, auditing, scoping, or splitting/merging one — even if they never say "PRD". Be pushy: trigger on casual asks like "turn this into a spec", "draft requirements for X", "is this PRD too big", "this PRD is a mess", "do we even need a PRD for this", "one PRD or two". Also on 写 PRD, 帮我写需求文档, 需求文档, 产品需求文档, PRD 拆分, PRD 合并, 这个 PRD 要不要拆, PRD 粒度, 帮我改需求文档.

Audits whether each requirement, workflow step, role, field, state, module, layer, abstraction, or rule deserves to exist and returns a razor verdict: a Keep/Merge/Defer/Delete/Replace/Prove-first classification of every concept, the strongest survival argument for anything cut, and a concrete cut/proof list. Use whenever the user wants to apply Occam's razor, simplify or trim a PRD / architecture / workflow / data model / state machine, challenge whether something is necessary, or spot fake requirements, premature abstractions, or over-engineering — even if they never say "razor." Trigger on 用奥卡姆剃刀, 剃刀一下, 砍需求, 砍掉没用的东西, 收一收复杂度, 这个字段/状态/模块/分层有必要吗, 这个抽象是不是多余, 是不是伪需求, 是不是过度设计, 这步能不能去掉, 这些角色/状态是不是太多了, and English like "is this over-engineered", "do we really need this layer", "this feels bloated, what can we delete", "too many fields".

Generates a complete, self-contained multi-section HTML report — header + one-line verdict, Mermaid structure map, decision matrix, risk/proof table, and next-move block — from an idea, requirement, PRD, goal, review, architecture topic, plan, or proposal, and returns the generated file path. Use whenever the user wants content turned into a visual report, visualized page, HTML report, webpage version, dashboard, or slides/PPT-like web artifact — and trigger even on casual phrasings: 可视化一下, 做个可视化, 做成网页, 做个网页版, 把这个评审做成网页, 做成一页 HTML, 输出 HTML, 做个汇报页/展示页, 做成 PPT 样子的网页, 弄个好看点的报告, 整理成一份报告页面, 带 mermaid 图的报告, render this as a page/webpage, make it visual/interactive, turn my analysis into slides-like html, dashboard of this. When the user wants a single shareable card instead of a multi-section report, use create-visual-card.

Produces a structured diagnosis report on one React component's design: a 7-dimension scorecard (consumer API, data flow, testability, extensibility, performance, mental model, boundaries & contracts — each scored 1-5 with code evidence), design highlights, and P0/P1/P2 recommendations with effort estimates, every score grounded in line-by-line reading. Be pushy: trigger whenever the user points at a component directory or .tsx file and asks about its design, quality, props/API, or re-render behavior, even casually — 组件诊断, 组件体检, 架构审查, 设计分析, 组件评审, 组件 API, props 设计, 组件要不要重构, "这个组件设计得怎么样", "帮我看看这个组件", "为什么每次都 re-render", "useEffect 写对了吗", "props 设计合理吗", "review this React component", "is this component well designed", "audit this component", "should I refactor this component".

Produces a restructured, consistently formatted, professional-looking README (or similar markdown project doc such as CONTRIBUTING.md, docs/index.md, 项目说明.md) plus a short change summary — content untouched: nothing added, nothing removed, only structure and formatting fixed (heading hierarchy, lists, code blocks, tables, spacing). Use whenever the user asks to beautify, tidy, reorganize, reformat, format, or fix a README — and be pushy: fire even when the user just dumps a messy README and says 太乱了 / 看下 / 帮我弄一下, without ever saying "beautify". Triggers: 美化 README, README 美化, 整理 README, README 排版, README 格式化, README 太乱了, 看下我这个 README, beautify README, fix/format/clean up/tidy/polish/reformat README, reorganize readme, my readme looks messy/ugly, make my README look professional.

Drives implementation through a strict red-green-refactor loop and produces a filled-in test-evidence report (target behavior, the failing RED test + why it failed for the right reason, the minimal GREEN implementation, the refactor decision, and verification commands). Use whenever the user implements a feature, fixes a bug, changes or protects behavior, refactors, or asks to add/write a test or unit test — even when they never say "TDD". Trigger on TDD, test-driven development, test first, red-green-refactor, tdd this, do it test first, add test coverage, unit test for this; and on 红绿重构, 先写测试, 用测试驱动开发, 写测试, 加测试, 补个测试, 单元测试, 给这个写个测试, 测一下, 帮我测; plus the regression-safety intent — refactor without breaking behavior, 确保不回归, 别改坏了, 保证行为不变.