Art & Design

Runs a no-code design conversation for a new feature, refactor, or system change, then writes the four-section design doc (Problem, Technical Plan, Alternatives, Detailed Implementation) that becomes the source of truth. Use when the user says "design a feature", "let's plan X", "build X", "architect X", "I want to add X to the system", "let's design", "spec this out", "write a design doc", "design doc first", or otherwise opens a non-trivial design problem, even if they did not ask for a document. Implements Phases 1 and 2 of the Elephant-Goldfish Model (EGM). Hand the finished doc to /egm-review. Not for one-line fixes or questions about how existing code works.

Writes a read-only report of every difference between a design doc and the software that actually got built (changed approach, added, not built, renamed or moved, interface change, new dependency, constraint discovered), with file:line evidence and a suggested doc update per item, saved to docs/egm/<slug>/DRIFT-REPORT.md. Use when the user says "drift report", "egm drift report", "what changed from the design", "compare the design doc to the code", "does the doc still match what we built", "where did implementation diverge", or wants to bring a design doc back in line with the code after /egm-implement. Never edits the doc or the code. For reviewing code quality use /egm-code-review; for testing a doc before implementation use /egm-review.

Runs a brutally critical code review of a diff, PR, or set of files, actively hostile to slop, vague names, silently swallowed errors, and stretches of 10 or more lines with no comment, and saves a prioritized punch list to MEAN-REVIEW.md so the next pass can check what was fixed. Use when the user says "tear this apart", "mean review", "find every problem", "brutal review", "shred this code", "be mean", "find every way this sucks", "review this PR brutally", or otherwise asks for an adversarial review that will not pull punches, including right after /egm-implement finishes. Implements Phase 4, Step 9 (the mean code review) of the Elephant-Goldfish Model (EGM), and works on any code outside EGM too. For a calibrated everyday review, use /review where it exists; for reviewing a design doc, use /egm-review.

Commit current changes, push the branch, and open a PR against main or a stacked base branch. Emits a local HTML review walkthrough with diagrams when the change is broad (multiple non-UI modules, schema changes, or a large end-to-end feature). Use when the user wants to commit their changes, push a branch, or create/open a pull request.

Legal compliance setup for any website, app, SaaS, or startup, in any tech stack. Covers Terms and Conditions, Privacy Policy, Cookies Policy and cookie consent, register-form consent checkboxes, traceable consent records (proof of when and how each user accepted), Refund policy, data minimization, image and media rights, and local law checks (Latin America, United States, and others). Interviews the user about the business, market, and tech, then writes a reviewable draft of legal documents and code changes before anything is applied. Use this skill whenever the user mentions terms of service, privacy policy, cookies, cookie banner, GDPR, LGPD, CCPA, Habeas Data, consent, refund or return policy, "derecho de retracto", legal pages, launching or going live, preparing a startup or MVP for production, or asks if a project is "legal" or "compliant", even if they do not say "compliance".

Optimize, review, compare, or iteratively revise AI user prompts and system prompts using workflows adapted from linshenkx/prompt-optimizer. Use for requests such as tối ưu prompt, sửa prompt, đánh giá prompt, improve this prompt, and reusable prompt templates for writing, coding, websites, research, or images. Do not trigger on ordinary task execution or translation unless prompt optimization is requested.

Reconsiders a project or shelved idea against current capabilities, proposes three ambitious outcomes, and designs an experiment for the hardest uncertainty. Use when asked "what more is now feasible", "is this worth attempting now", "revisit this shelved idea", or "think bigger about this project".

How SwiftUI decides what to re-render — identity, lifetime, dependencies — and how to write views that update efficiently, especially SwiftUI hosted in UIKit cells (UIHostingConfiguration) and views rebuilt from streaming or generated content. Use when writing or reviewing SwiftUI views for performance, fixing views that lose state, flash, re-render too often or reload images, choosing ForEach identifiers, hosting SwiftUI in collection/table view cells, or debugging layout that changes when views are wrapped. Based on WWDC21 "Demystify SwiftUI" and WWDC23 "Demystify SwiftUI performance", plus lessons verified in practice.

Concentric corners in SwiftUI (iOS 26+): ConcentricRectangle, containerShape, Edge.Corner.Style.concentric(minimum:), and a reusable corner scale so nested shapes — a photo in a card, a card floating on a map, a thumbnail in that card, a hero image near the screen edge — share their corner centers instead of looking pinched or flared. Use when choosing corner radii, nesting rounded views, adopting Liquid Glass shapes, fixing corners that look "off" inside containers, or building a design system's radius tokens. Based on WWDC25 "Get to know the new design system" and the iOS 26 SDK.

Research any open-source GitHub repository using DeepWiki AI-powered documentation. Use when the user asks about an external project, framework, or library hosted on GitHub, or when you need to understand how an open-source project works internally — its architecture, APIs, patterns, or design decisions. Do not use for private repos not accessible through DeepWiki.

>- Write the plan for a Clanker Ship ticket, following the team's plan instructions. Use when the person asks to plan, design or write up how to do a ticket such as WEB-31. Fetches the team's live instructions with get_agent_instructions, saves the plan with update_ticket, and waits for approval before implementing.

Generate a comprehensive Product and Technical Requirements Document (PRD-Project) with visual Mermaid diagrams through an interactive two-step workflow. Use when the user asks to create a PRD, plan any software/web/mobile/AI/game project, write specifications, or design system architecture.

>- Orchestrates the full feature lifecycle: Refine → Design system → Architecture → Build → Verify production readiness. Use when starting a story, implementing a feature end-to-end, or closing out work before PR. The parent coordinates child skills — it does not duplicate their rules.

>- Design-system guidance in three modes: PLAN (prospective reuse and abstractions before build), BUILD (apply those standards while implementing), REVIEW (audit branch diff against them). Use in feature-development phases 2, 4, and 5; or standalone for inline styles, sx, custom CSS, one-off cards, or pattern-library scope. Formerly pattern-library-refactor.

Production Go playbook. Use when writing or reviewing Go: errors, goroutines, byte payloads, parsers, and switches on external input. Worked cases are in references/bad-vs-good.md. Do not use for JavaScript, TypeScript, or API-contract design.

Guides systematic refactoring to align features with established patterns, remove duplication, and improve code reuse. Includes DataGrid/pattern-library, typing, fetch pagination, view-model vs override-prop guidance, and MUI sx-first layout (avoid deprecated Box style shorthand props). Use when refactoring features, consolidating duplicate code, extracting shared utilities, or aligning patterns across similar features.

Production data-access playbook for the N+1 query problem. Use when code queries a database inside a loop, an ORM lazy-loads a relation per row, or a list endpoint is fast at 5 rows and slow at 50. Worked cases are in references/bad-vs-good.md. Do not use for HTTP contract design or for Go/JavaScript language style.

Spec-driven feature work that freezes obligations instead of the plan: one human-reviewed plan with EARS criteria, path, entities, interface and one-way doors, then proof-backed checks, then build, then an independent Verifier. Use when the user says "tlc-spec-lean", "plan feature", "specify feature", "write the checks", "build this plan", or "verify work". Do NOT use for standalone design documents unattached to a feature, architecture decomposition analysis, or work that already has a task list or checklist to execute.

Design or review REST/RPC API contracts that are consistent, evolvable, and hard to misuse. Use when defining new endpoints, reviewing an API surface, or resolving naming/versioning/error-shape questions.

Design or review polished, accessible interfaces inspired by Apple Human Interface Guidelines. Use for web, native, and responsive product UI; do not copy Apple proprietary interfaces or assets.

Design secure Supabase and PostgreSQL architectures including schema, RLS, authentication, migrations, and query performance. Use when planning or reviewing a Supabase-backed application.

Rigorous, severity-ranked review of a diff, PR, or file. Use when you want a thorough check of correctness, security, performance, design, readability, and test coverage with actionable feedback.

>- Comprehensive operational framework and design intelligence for modern UI/UX design, design systems, visual hierarchy, design tokens, component architecture, high-density financial terminal aesthetics, accessibility (WCAG 2.2 AAA/AA), mobile ergonomics, data visualization, and complete interface revamps. Use this skill whenever auditing, designing, refactoring, building, or restyling user interfaces, dashboards, design systems, layouts, forms, data tables, animations, and micro-interactions.

>- Comprehensive guide and operational framework for software engineering standards, clean code, low-level design (LLD), high-level architecture (HLD), distributed systems, API contracts, database indexing, capacity planning, and architecture decision records (ADRs). Use this skill whenever designing, evaluating, refactoring, reviewing, or scaling software architectures, backend services, database schemas, APIs, or performance-critical systems.