Review code for overengineering and avoidable complexity, then write an HTML findings report. Use when the user asks whether code is too abstract, too layered, too generic, prematurely extensible, hard to follow, or more complex than the problem requires.
Use when implementing, changing, refactoring, reviewing, or accepting any code, config, build, migration, script, UI, API, dependency, or test change that needs strict executable proof instead of grep, source-text checks, snapshots-only assertions, import-only checks, or manual verification.
Audit and improve GitHub repository hygiene using evidence from local files, package manifests, dependency metadata, and GitHub settings. Use when the user asks for best practices, repo cleanup, repository hygiene, project health, package.json or dependency hygiene, monorepo health, npm/package publishing readiness, GitHub setup, maintainer readiness, contribution workflow, security posture, CI checks, issue or PR templates, branch protection, Dependabot, CodeQL, licensing, release readiness, or open-source/private repository governance.
Explain confusing ideas in extremely plain language, using simple references, analogies, examples, and step-by-step breakdowns. Use when the user asks to dumb something down, simplify, explain like they are new to the topic, make a problem easier to understand, turn dense writing into plain English, unpack jargon, or create beginner-friendly explanations for technical, business, academic, legal, medical, financial, or code-related material.
Research and implement a code change from an existing issue, ticket, or issue-like artifact. Use when the user says "$from-issue", asks Codex to work from a GitHub issue, local markdown issue, tracker ticket, bug report, feature issue, or AFK implementation ticket, and expects codebase research, linked PR verification, blast-radius analysis, targeted questions, a patch, verification, branch push, and pull request creation.
Slowly walk codebases and related project evidence to diagram data flow, workflows, dependencies, integrations, and connections between systems; record findings; verify each edge; and recommend fixes for breaks, edge cases, missing links, and disconnects. Use when the user asks to create, audit, validate, or troubleshoot architecture diagrams, workflow diagrams, integration maps, service maps, data lineage diagrams, sequence diagrams, system dependency maps, or cross-system debugging reports.
Review code changes for avoidable tech debt through function scope, naming, and file organization. Use when the user wants to know whether a change fits the existing codebase, introduces shallow abstractions, uses misleading names, or places code in the wrong module or directory.
Turn an architecture discussion, design conversation, rejected proposal, or selected refactoring direction into a complete Architecture Decision Record. Use after a conversation has clarified context, decision, alternatives, tradeoffs, consequences, or an architecture choice that future contributors should not re-litigate.