القائمة
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
End-to-end autonomous feature flow. Runs /feature-plan for the interactive story + Q&A phase, then subagents orchestrated from this session handle implementation, code review, fixes, linting, full test runs, coverage top-up, commits, and PR creation for every repo involved. Use when the user wants the whole plan-to-PR flow handled hands-off — even if they just say "do the whole thing", "plan and ship it", or "auto feature X". Does NOT run /feature-done; the feature folder stays active until PRs merge.
Apply fixes from a feature code review, batched by file, with test verification. Use after /feature-code-review — or any time review-fixes.md exists and the user wants the findings addressed, even if they just say "fix it" or "apply the review". Unchecks Action Required in story.md for every criterion whose findings were resolved, closing the review cycle before /feature-done.
Review implemented feature code by delegating to /review-code with feature context. Uses story.md acceptance criteria as the requirements source. Outputs structured findings to review-fixes.md for follow-up with /feature-code-fix.
Reviews implemented code from 3 perspectives in parallel — behavior verification against the spec, contextual review, and pattern consistency & code minimization (can the solution be smaller / share existing logic without hurting readability). Use when asked to review code, a completed implementation, or when another skill delegates a code review step.
Audits SwiftUI accessibility in the Lilium / BookNotes app against Apple's Human Interface Guidelines AND the project's own conventions (the mandatory .accessibilityLabel + dot-namespaced .accessibilityIdentifier on every interactive element), then reports findings with file:line, severity, and a concrete fix — and offers to apply them. Covers VoiceOver semantics, Dynamic Type, 44pt touch targets, color/contrast (incl. velvet-on-purple traps), Reduce Motion, and the .keyboard-toolbar / container-collapse AX-tree gotchas, with an optional live pass that drives the simulator via idb to confirm identifiers actually resolve. Use this WHENEVER the user wants to check, audit, review, or improve accessibility / a11y / VoiceOver / Dynamic Type support for a SwiftUI view, screen, or diff — even phrased as "is this screen usable with VoiceOver?", "did I miss any accessibility labels?", "make this view accessible", "check the new sheet for a11y", or "audit accessibility before I open the PR". Also trigger it proactively
Adds, reviews, or improves code comments so they explain intent and rationale rather than restating mechanics. **PROACTIVELY invoke in either of these cases: (1) you are about to write, modify, or extend a comment in any source file — including inline comments added during feature work or bug fixes; (2) you are modifying code that has a comment within a few lines above, below, or attached to it (doc comment, inline note, TODO, invariant, workaround marker) — because the edit may invalidate, contradict, or outdate that comment.** Also invoke whenever the user asks to comment code, review comments, or clean up noisy comments. Run it BEFORE committing any change that touches comments OR code adjacent to comments.
| name | explain-code |
| description | Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" |
| argument-hint | ["file path or description of code to explain"] |
| disable-model-invocation | false |
| allowed-tools | Read, Grep, Glob, Bash |
When explaining code, always include:
Keep explanations conversational. For complex concepts, use multiple analogies.
