Code review, debugging, architecture, testing and docs. 12 reviewed skills for engineering.
Engineering prompts and skills help with the written side of building software: reviewing a change, narrowing down a bug, weighing an architecture choice, planning tests and documenting what you built. Paste in the actual code, error or constraints, and ask for reasoning you can verify. Run and test anything it suggests before it goes near production, and leave secrets and customer data out of what you share.
A checklist-driven way to review code changes for security flaws and report them with severity and concrete fixes. Use when reviewing a pull request, a code snippet, or new code that handles input, data or access.
Steers coding work toward the smallest correct change: reuse what exists, avoid new dependencies and speculative abstractions, never cut safety. Use when writing, reviewing or refactoring code where over-building is a risk.
A way of working for any change that touches user-facing text. Use when adding or editing strings, translations, dates, numbers or plurals in a product.
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.
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.
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.
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.
Requires real evidence before a software change is reported as finished: build and tests run, the change exercised directly, at least one edge case tried, and results shown. Use when you implement, fix or verify code and can run checks.
Use when you have just written or changed code and before presenting it: runs a focused second pass for the mistakes generated code commonly contains, fixes what it can, and reports what was fixed and what needs the author's attention.
Use when you are about to commit a non-trivial technical or business decision, claim something is safe or correct, or change something hard to undo. Runs a short, bounded adversarial review of the decision before it stands.
Standing approach for reviewing code: rank findings by impact, explain why, and suggest a fix. Use when asked to review code, a change or a pull request.
