swingerman

Use when exploring a feature idea before committing, or revisiting a parked one. Triggers — "/engineer.discuss", "/engineer.discuss <slug>", "I have an idea about", "should we build", "let's think about".

Use when a new feature folder must be created for the DAE pipeline, or when discuss promotes/parks an idea. Triggers — "/engineer.feature-init", "create a feature", "start a new feature", "init a feature".

Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".

Use to bring a project into the DAE methodology, or to check an onboarded project for gaps. Triggers — "/engineer.onboard", "onboard this project", "set up DAE here", "adopt the methodology", or when a DAE skill fails because no manifest exists.

Use to propagate DAE state — turning handoff summaries into visible progress. Triggers — "/engineer.progress-log", "sync progress", "update the tracker", "reconcile the tracker", "refresh feature status".

Use to drive a bug fix from first report through close, with a "why didn't we catch it?" loop at the end. Triggers — "/engineer.fix", "a bug came in", "this is broken", "a user reported X", "there's a defect", "we have a regression", "this needs a fix", "another report", "more issues", "still failing", "validation failed again", "another bug", "next defect", "more fixes".

Use to add a third validation layer to the ATDD workflow — after acceptance tests verify WHAT and unit tests verify HOW, mutation testing verifies the tests actually catch bugs. Triggers — "/mutate", "/kill-mutants", "run mutation testing", "mutate my code", "kill mutants", "check test quality", "find surviving mutants", "run stryker", "run mutmut", "run pitest", "are my tests catching bugs".

Use when a feature has ACs and specs and needs an architecture plan before implementation. Triggers — "/engineer.plan", "plan this feature", "plan the implementation", "design the architecture".

Prepare a draft GitHub release for the fluid-level-background-card with user-focused release notes. Use when asked to "cut a release", "do a release", "prepare a release", "draft a release", "write release notes", "ship a version", or "publish a release". Bumps the version + HACS HA floor when needed, then drafts notes written from the user's point of view — features as capabilities with optional video placeholders, and dependabot collapsed into a one-line maintenance summary.

Verify the Fluid Level Background Card shows up and adds correctly in Home Assistant's entity-first card picker (2026.6+). Use when asked to "verify the card picker", "test getEntitySuggestion in the UI", "check the card appears in the picker", or after changing the customCards registration / getEntitySuggestion / getStubConfig.

Set up a fast, calm, focused terminal on macOS. Use when the user asks to "zenify my terminal", "make my terminal nice/pretty/awesome", "set up zsh / shell", "upgrade my terminal experience", "fast track my terminal setup", "just set me up", or "set up starship / oh-my-posh / zinit / wezterm / ghostty / alacritty / kitty". Two modes — guided (walks through choices: terminal app between WezTerm/Ghostty/Alacritty/Kitty/iTerm2/Apple Terminal, prompt between Starship/Oh My Posh, plugins, optional extras) or fast-track (one question — which terminal — then applies opinionated optimal defaults). Writes ~/.zshrc, the chosen prompt's config, and the chosen terminal's config with macOS-specific gotchas already handled (skip `brew shellenv`, skip the deprecated `homebrew/command-not-found` tap, BSD ls vs GNU ls, sub-process PATH, zinit turbo mode for fast startup). Ends with a summary of what was installed plus the most important keyboard shortcuts.