القائمة
Explain code. Default is a one-sentence summary plus a mental model. Add `verbose` to also get an ASCII diagram, key details, and a modification guide.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Deep, fan-out research over the codebase to answer a big question (test gaps, how a subsystem works end to end, a risk/security/dead-code audit, "where does X happen everywhere"). The codebase analog of deep web research: parallel explorer agents gather file:line-cited findings, surprising or high-stakes claims are adversarially verified against current code, and the result is a single prioritized report. Use for broad/deep questions that span many files and modules, NOT a one-file lookup and NOT a single-task pre-plan (use /scout for that, /explain for one thing).
Investigate a non-trivial task, then produce the plan for it. Emits a file:line-cited findings report covering current behavior, the route/component boundary it crosses, helpers to reuse and stale docs, followed by a sequenced plan and any blocking open questions. Use before touching an unfamiliar backend route, adding an ingest path, reworking a panel, or any cross-cutting change. The point is to ground the plan in evidence, not memory. Investigates deeply and verifies adversarially by default; never edits files.
Turn a change into a checkable manual test script the owner runs in the app, not prose about testing. Reachability-verified steps grouped by precondition, one observable outcome each, with unreachable actions listed up top and known regressions flagged. Use when the user asks for test steps, a test plan, or how to verify a change by hand. This is the manual counterpart to test-writer (which writes automated pytest / vitest tests).
Trim verbose prose, walls of text, journey narration, and WHAT comments from docs and code without losing vital info. Targets markdown files (README, CLAUDE.md, rules, skills, agents) and, when asked, code comments / docstrings. Applies the "WHY not WHAT" rule, the "describe current behavior not the journey" rule, and the "release notes not implementation rationale" rule from `.claude/rules/project-workflow.md` and `.claude/rules/code-quality.md`. Use after a feature lands and the docs around it have accumulated cruft, or when a file feels heavier than it earns. Always plans before editing.
Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.
Scan changes, commit, push, and create a PR. With confirmation at each step
| name | explain |
| description | Explain code. Default is a one-sentence summary plus a mental model. Add `verbose` to also get an ASCII diagram, key details, and a modification guide. |
| argument-hint | [target] [verbose?] |
| disable-model-invocation | true |
Explain $ARGUMENTS clearly.
If $ARGUMENTS includes the word verbose (for example, /explain my-function verbose), produce all five sections below. Strip the word verbose from the target name when interpreting what to explain.
Otherwise (the default), produce only sections 1 and 2 and stop. Day-to-day that's usually all you need.
What does it do, and why does it exist? One sentence.
An analogy or metaphor that captures the core idea. Relate it to something the developer already knows. One short paragraph.
Draw an ASCII diagram showing the data and control flow. Keep it readable:
Input -> [Step A] -> [Step B] -> Output
|
v
[Side Effect]
Walk through the important parts. Skip the obvious. Focus on:
What would someone need to know to safely change this code? Where are the landmines?