Claude Skills 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...

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

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; 信息卡, 知识卡片, 金句卡, 语录卡, 做张卡片, 设...

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

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: 打开格局, 格局太小, 你格局小了, ...

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

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, de...

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

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

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

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

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

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

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, simpl...

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

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: 可视化一下, 做...

深度诊断单个 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 th...

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。