Claude Skills by xiaohei-info

Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.

Design one-off HTML artifacts (landing, deck, prototype).

Author/validate/export Google's DESIGN.md token spec files.

This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.

Humanize text: strip AI-isms, audit AI tells, and add real voice.

Generate project ideas via creative constraints.

54 real design systems (Stripe, Linear, Vercel) as HTML/CSS.

Dark-themed SVG architecture/cloud/infra diagrams as HTML.

ASCII art: pyfiglet, cowsay, boxes, image-to-ascii.

Generate flat, minimal light/dark-aware SVG diagrams as standalone HTML files, using a unified educational visual language with 9 semantic color ramps, sentence-case typography, and automatic dark mode. Best suited for educational and non-software visuals — physics setups, chemistry mechanisms, math curves, physical objects (aircraft, turbines, smartphones, mechanical watches), anatomy, floor plans, cross-sections, narrative journeys (lifecycle of X, process of Y), hub-spoke system integratio...

Use when the user requests diagrams, flowcharts, architecture diagrams, ER diagrams, UML / sequence / class diagrams, network topology, ML/DL model figures (Transformer/CNN/LSTM), mind maps, or any visualization. Also use proactively when explaining systems with 3+ components, complex data flows, or relationships that benefit from visual representation. Best suited when the diagram needs custom styling, rich shape vocabulary, swimlanes, or exportable images (PNG/SVG/PDF/JPG). Generates .drawi...

Hand-drawn Excalidraw JSON diagrams (arch, flow, seq).

Infographics: 21 layouts x 21 styles (信息图, 可视化).

Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters", "hexagonal architecture", "use case boundary", "onion architecture", "screaming architecture", or "framework independence". Also trigger when decoupling business logic from databases or frameworks, defining module boundaries, or debating where to put business rules. Covers compo...

Use when architecture work hinges on DDD-style domain modeling: subdomains, bounded contexts, context relationships, aggregate boundaries, and how those decisions shape overview or detailed design artifacts.

Use when an architect must start at the demand-research stage, turn a business problem into a researchable architecture problem, and preserve the full lifecycle-stage doctrine for what to ask, what to answer, and what the business-research document must contain.

Use when an architect must decide which architecture lifecycle stage to enter next, route to the correct stage methodology skill, and apply the merged lifecycle backbone as one coherent delivery chain rather than as separate old and new skill systems.

Use when an architect in the deploy-and-ops stage must produce or review the 部署架构图 / 物理架构图 so that physical topology, deployment boundaries, and run-stage assumptions are visible during handoff.

Use when an architect must run the deployment-and-operations handoff stage, preserve the full lifecycle-stage doctrine for deploy/ops, and turn completed design into physical topology, rollout, operations, monitoring, emergency, and rehearsal deliverables.

Use when an architect in the solution-design stage must produce or review the 业务解决方案架构图 and needs the fully merged specialist method directly inside the new lifecycle family instead of via a legacy wrapper skill.

Use when an architect in the solution-design stage must produce or review a 业务流程图 that explains roles, steps, and handoff order without collapsing into system architecture, technical architecture, or detailed-design flow logic.

Use when an architect must run the solution-design stage after demand research, preserve the full lifecycle-stage doctrine for this stage, and turn business research into solution-design outputs such as business flow, domain model, solution architecture, risk controls, and milestone framing.

Use when an architect in detailed technical design must produce or review the 关键流程图 or 状态机 and needs the fully merged branch-complete core-flow specialist method directly inside the new lifecycle family.

Use when an architect must run the detailed-design portion of technical

Use when an architect in detailed technical design must produce or review the 技术架构图 and needs the fully merged technical-architecture specialist method directly inside the new lifecycle family.

> **定位**：工具无关、系统无关、场景全覆盖的架构图绘制指令集。可加载于任意 AI Agent，指导其在任何技术领域（后端、前端、数据、云原生、安全、DevOps、AI/ML、IoT、区块链等）产出专业、一致、可读的架构图。 > **目标受众**：架构师、研发工程师、技术负责人。 > **回答的核心问题**： > 1. 功能通过什么技术栈实现？如何选型？ > 2. 项目/服务的逻辑分层与物理结构是什么？ > 3. 服务、进程、任务、调用链路如何协作？ > 4. 稳定性、扩展性、安全性、可观测性如何保障？ > **推荐工具**：Excalidraw / Draw.io (diagrams.net) / PlantUML / SVG/HTML / Lucidchart。Agent 应根据场景自行选择最合适的工具，或按用户指定工具输出。 ---

Use when an architect in overview technical design must produce or review the 系统功能架构图 and needs the fully merged functional-architecture specialist method directly inside the new lifecycle family.

Use when an architect must run the overview-design portion of technical design, preserve the full lifecycle-stage doctrine for shared technical-design entry and overview design, and define goals, alternatives, functional layering, system structure, risk, and overview-level design boundaries before detailed design begins.

Use when an architect in overview technical design must produce or review the 系统架构图 and needs the fully merged system-architecture specialist method directly inside the new lifecycle family.

Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.

Use when architecture or backend work needs pre-code structural guidance from design patterns, or post-code cleanup guidance from refactoring and code-smell-driven improvement.

Manage software complexity through deep modules, information hiding, and strategic programming. Use when the user mentions "module design", "API too complex", "shallow class", "complexity budget", "strategic vs tactical", "deep module", "information leakage", or "pass-through method". Also trigger when reviewing interface designs for simplicity, evaluating whether an abstraction is pulling its weight, or choosing between general-purpose and special-purpose approaches. Covers deep vs shallow m...

Design scalable distributed systems using structured approaches for load balancing, caching, database scaling, and message queues. Use when the user mentions "system design", "scale this", "high availability", "rate limiter", "design a URL shortener", "system design interview", "capacity planning", or "distributed architecture". Also trigger when estimating infrastructure requirements, choosing between microservices and monoliths, or designing for millions of concurrent users. Covers common s...

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.

Use when writing, reviewing, or refactoring code in any language to apply industrial-grade development norms abstracted from the Alibaba Java Development Handbook. Covers naming, type safety, exceptions, logging, concurrency, databases, project structure, testing, and security with language-agnostic principles and single-language examples.

Apply meta-principles of software craftsmanship: DRY, orthogonality, tracer bullets, and design by contract. Use when the user mentions "best practices", "pragmatic approach", "broken windows", "tracer bullet", "software craftsmanship", "technical debt prevention", "prototype vs tracer bullet", or "code ownership". Also trigger when evaluating build-vs-buy decisions, designing estimation approaches, or choosing between reversible and irreversible architectural decisions. Covers estimation, do...

Throwaway HTML mockups: 2-3 design variants to compare.

Top-level entry point for the software development skill family. Routes to the right sub-skill for design patterns, refactoring, DDD, worktree governance, kanban splitting, container supervision, project governance, runtime ops, and web routing.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation