hylarucoder
@hylarucoder
Public Skills
ast-grep-rule-crafter
by hylarucoder
Produces a ready-to-run ast-grep YAML rule that searches, lints, or auto-rewrites code via tree-sitter AST patterns, delivered with positive + negative fixtures and an exact validation command. Use for lint rules, codemods, code modernizations, and API migrations with auto-fix. Trigger whenever the user mentions ast-grep, sg scan, sgconfig, tree-sitter patterns, AST matching, structural search-and-replace, or a codemod — and ALSO when they describe the task without naming the tool, e.g. "find every call to X and rewrite it", "replace all console.log with logger across the repo", "write a lint rule for this pattern", "upgrade all usages of the old SDK", or "migrate this API everywhere". Chinese triggers: 写 ast-grep 规则, 结构化搜索替换, 批量改写代码, 代码迁移规则, codemod, 写个 lint 规则, 语法树匹配, 自动改写代码.
clean-code-reviewer
by hylarucoder
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
by hylarucoder
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 (for multi-section reports use hai-visual-report).
entity-model-auditor
by hylarucoder
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 — each field run through five cuts (exist? store or compute? column or config? system or content? what form to store?). 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 or backend types, deciding store-vs-compute or column-vs-jsonb, judging whether a field is redundant, spotting a bloated/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
by hylarucoder
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, and a verification path (first proof point + falsifier) that keeps the bold call testable. 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.
goudi
by hylarucoder
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
by hylarucoder
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 whenever the user asks about architecture or system-design quality: module/package boundaries, abstraction depth, deep vs shallow modules, information hiding, dependency direction, change amplification / blast radius, ownership, error boundaries, or whether to split / merge / combine modules — including 架构审查, 架构 review, 模块边界, 依赖方向, 抽象太浅, 复杂度太高, 这个设计合不合理, or an APoSD / Ousterhout / "philosophy of software design" review. Be pushy: trigger even when they only say "is this structure ok", "these modules feel tangled", "should I split this", "review my system design", or "why does touching X force edits everywhere", not just when they say "architecture review". For naming use hai-naming; for whole-repo refactor hunting use improve-codebase-architecture; for a single React component use component-diagnosis.
hai-audit-docs-against-code
by hylarucoder
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
by hylarucoder
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-goal
by hylarucoder
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.
hai-idea
by hylarucoder
Evaluates whether an idea deserves attention and returns a clear verdict — Do / Validate first / Reframe / Defer / Kill — with a dimension-by-dimension scorecard (pain, audience, leverage, timing, cost, risk, proof path), 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, too vague, risky, low-value, a distraction, or a fake need; wants two or more ideas compared and ranked; or asks whether to build, ship, kill, postpone, reframe, or turn it into a goal or PRD — even when they only say it casually and never ask for an evaluation. Trigger on 想法是不是好主意, 我有个想法, 帮我看看这个想法, 这个点子怎么样, 值不值得做, 值得投入吗, 要不要做, 该不该做, 这个需求要不要接, 是否应该验证, 该不该砍掉, 是不是伪需求, 是不是在瞎折腾, 哪个更值得做, and casual English like "should I build this", "is this worth my time", "worth doing? or kill it".
hai-naming
by hylarucoder
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, module, type, file, product surface, domain entity, event, workflow state, 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", and when every candidate feels awkward (usually a design- boundary problem, not a vocabulary one). Chinese triggers: 起名, 命名, 取名, 改名, 名字不好, 这个叫什么好, 取个名字, 换个名, 这名字怎么样, 名字太长, 命名规范, 命名审查, 变量名/函数名怎么取.
hai-prd
by hylarucoder
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 粒度, 帮我改需求文档.
hai-razor
by hylarucoder
Audits whether each requirement, workflow step, role, field, state, module, layer, abstraction, or rule deserves to exist and returns a razor verdict: an evidence table, a Keep/Merge/Defer/Delete/Replace/Prove-first classification of every concept, the strongest survival argument for anything cut, the complexity that must be preserved, a concrete cut/proof list, and — for full audits — before/after Mermaid diagrams plus an HTML report. 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".
hai-tdd
by hylarucoder
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, 确保不回归, 别改坏了, 保证行为不变.
hai-visual-report
by hylarucoder
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 (including typos like html repot / viz report). Prefer this over create-visual-card when the content is multi-section and needs structure, tradeoffs, route, risk, and evidence rather than a single shareable card.
react-component-diagnosis
by hylarucoder
深度诊断单个 React 组件的架构设计质量，产出一份结构化体检报告：7 维度评分卡（使用者 API、数据流、可测试性、可扩展性、性能、心智模型、边界契约，每维 1-5 分 + 代码证据）、设计亮点、按 P0/P1/P2 分级且标注工作量的改进建议——所有评分基于逐行读代码后发现的具体问题（useMemo 依赖、useEffect cleanup、类型断言、每帧重复计算等），而非扫一眼目录得出的表面评价。当用户请求组件诊断、组件设计审查、架构分析、组件体检、组件 API/props 设计评估时使用，即使没说出"诊断"二字也应主动触发：用户指向一个组件目录或 .tsx 文件问"这个组件设计得怎么样"、"帮我看看这个组件"、"这个写得怎么样"、"是否需要重构"、"为什么每次都 re-render"、"useEffect 写对了吗"、"props 设计合理吗"，或用英文说 "review this React component"、"is this component well designed"、"audit this component"、"should I refactor this component" 时，都应触发。触发词：组件诊断、组件体检、架构审查、设计分析、组件评审、组件 API、props 设计、组件要不要重构、component diagnosis、component review、react component audit。
readme-beautifier
by hylarucoder
README 美化器。接收结构混乱、格式不统一的 README（或同类 markdown 项目文档如 CONTRIBUTING.md、docs/index.md、项目说明.md），输出结构清晰、标题层级正确、列表/代码块/表格格式一致、视觉专业的完整版本，并附一段改动摘要——内容不增不减，只改结构和格式。当用户请求美化、整理、排版、格式化、修复 README，或只是把一份杂乱的 README 丢给你说"太乱了""看下""帮我弄一下"时使用，即使没有明确说"美化"二字。触发词：美化 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。
clean-code-reviewer
by hylarucoder
Analyze code quality based on "Clean Code" principles. Identify naming, function size, duplication, over-engineering, and magic number issues with severity ratings and refactoring suggestions. Use when the user requests code review, quality check, refactoring advice, Clean Code analysis, code smell detection, or mentions terms like 代码体检, 代码质量, 重构检查.
ast-grep-rule-crafter
by hylarucoder
Write AST-based code search and rewrite rules using ast-grep YAML. Create linting rules, code modernizations, and API migrations with auto-fix. Use when the user mentions ast-grep, tree-sitter patterns, code search rules, lint rules with YAML, AST matching, or code refactoring patterns.
doc-consistency-reviewer
by hylarucoder
文档一致性审核官，检查代码实现与文档说明的一致性。当用户请求审查文档与代码的一致性、检查 README/docs 是否过时、验证 API 文档准确性时使用此技能。适用于：(1) 审查 README 与实现一致性 (2) 检查 docs/ 目录文档是否过时 (3) 验证 API/配置文档准确性 (4) 生成文档一致性报告。触发词包括：文档审查、doc review、文档一致性、documentation consistency、检查文档过时、verify docs。