50 reviewed skills.
Reviews web or app interfaces, designs, or front-end code for accessibility barriers and reports each issue with severity, affected users, guideline reference, and a concrete fix. Use when reviewing a page, component, or design before release.
A way of working for any code change: plan first, read before editing, change only what is needed, test, check security basics and summarise. Use when writing, fixing or refactoring code.
Generates genuinely different ideas by exploring several deliberate angles, then scores and narrows them to the best few. Use when asked to brainstorm or decide an open-ended question such as naming, strategy, or design.
Standing guard for summarizing or analyzing emails, web pages, tickets and files written by others. Use when working with outside content that might contain hidden or misleading instructions.
Translates cron expressions into plain English, shows upcoming run times and flags common mistakes. Use when someone shares a cron line or asks for a schedule to be written or reviewed.
Use when generating or reviewing interface designs, mockups or front-end code: steers away from generic template looks toward restrained color, clear type hierarchy, complete states, realistic copy and smooth, accessible motion.
Keeps replies short and plain: the answer first, no padding, no restated questions and no menus of optional follow-ups. Use when the person wants quick, direct answers instead of long explanations.
Standing guidance for building user interface code: component structure, state, accessibility, performance and testing. Use when you write or review front-end code for a web app.
Profiles a pasted or described CSV or spreadsheet for missing values, duplicates, mixed types and outliers, then ranks fixes. Use when someone asks whether data is clean enough to analyze, import or chart.
Keeps answers short and dense: no filler, pleasantries or hedging, while preserving every technical detail. Use when the reader wants fast, skimmable replies to technical or operational questions.
Use when pairing with someone on code or architecture: asks before building on ambiguous requirements, explains choices briefly, admits uncertainty, and tells the user directly when their approach has a problem.
Standing guidance for reviewing and rewriting version-control commit messages so history stays readable. Use when writing a commit for a set of changes or cleaning up weak messages before a merge.
