Explore AI Agent Skills & Claude Prompts

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.

clean-code-reviewer

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".

create-visual-card

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.

entity-model-auditor

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 对齐, 模型设计, 该存还是该算, 列还是配置, 帮我看下这个模型.

geju

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.

schedule Updated 13 days ago

goudi

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.

hai-architecture

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".

hai-audit-docs-against-code

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.

hai-audit-docs-internally

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.

hai-idea

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".

hai-naming

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: 起名, 命名, 取名, 改名, 名字不好, 这个叫什么好, 取个名字, 换个名, 这名字怎么样, 名字太长, 命名规范, 命名审查, 变量名/函数名怎么取.

hai-prd

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 粒度, 帮我改需求文档.