dotfiles

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.

Investigate a bug, write a failing test, then implement and review a fix. Use when the user runs /bugfix with an optional ticket number and description.

Verify a feature is complete and archive it by moving it to ~/.claude/features/done/. Use whenever the user says a feature is finished, done, or ready to close — even if they don't say /feature-done explicitly. Checks that all acceptance criteria are implemented and reviewed in story.md before moving, so nothing gets archived with loose ends.

Create a new feature plan. Use this whenever the user wants to start building something new — even if they haven't said /feature-plan explicitly. Drafts a user story with acceptance criteria (with Implemented/Reviewed/Action Required tracking), runs discovery Q&A, has a subagent review and tighten the criteria for full story coverage, seeds an empty design.md for implementation-level decisions, and saves everything under ~/.claude/features/. Both /feature-implement and /ralph read the output directly.

Implement a feature directly from its story. Use whenever the user is ready to start coding — even if they just say "start building", "let's go", or "implement it". Reads story.md (user story, discovery, acceptance criteria, repos, open questions) and design.md (prior implementation decisions), implements the feature using its own judgment for task ordering, writes tests ad-hoc, marks acceptance criteria as implemented, and appends to design.md whenever a non-obvious implementation decision is made.

Set up and launch a true Ralph Wiggum loop for a planned feature. Generates a PROMPT.md that is piped to the agent every iteration — the agent sees its own previous work through the filesystem and decides what to do next. No pre-decomposed tasks. Requires /feature-plan to have been run first. Use whenever the user wants to build something with the ralph flow — even if they just say "use ralph" or "ralph loop".

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?"

Reviews an implementation plan from 6 perspectives in parallel — technical feasibility, security, performance & scalability, maintainability & architecture, test coverage, and design pattern consistency. Use when asked to review a plan.