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.
Rewrites text or comments to remove AI writing tics (delve/leverage/robust, tricolons, em-dash overuse, empty intros and closers, cheerleader tone) and make them sound like a human engineer wrote them. **Use after generating any prose Claude wrote: commit messages, code comments, PR descriptions, READMEs, story.md / design.md / spec docs, release notes, Slack/email drafts** — or whenever the user says something "sounds like AI", "is too markety", "is too flowery", or asks you to tighten/dehydrate the wording. Preserves meaning exactly; only the style changes.
Scans all repos in ~/Developer/work/ and ~/Developer/personal/, then creates or updates a context file per repo at ~/.claude/repo-context/<repo-name>.md. Use when the user runs /repo-context.