onsager

The end-to-end spec-issue-driven dev loop for Onsager — spec → branch → implement → PR → merge → closure. Use when asked "how do I start work", "what's the process", "SDD loop", "spec-driven development", "how do we ship a change", "from scratch what do I do", or when you're about to begin a non-trivial change and haven't yet decided how to split spec/PR. Delegates to `issue-spec` (spec writing) and the global `pre-push` (pre-push checks) and `pr-lifecycle` (post-push) skills. This skill carries Onsager's overlay for `pre-push` / `pr-lifecycle` — the check gate, merge-collision patterns, CI-failure table, and the bundled GitHub-ops reference + audit script.

Enforce shadcn/ui component usage in apps/dashboard, the "avoid manual input" UX principle, AND the mobile chrome rules — pages declare title/back/actions via usePageHeader (one global mobile bar; a single primary action stays inline, two or more collapse to a `⋯` overflow menu; no per-page sticky headers); html/body never scroll (rubber-band disabled, the app shell's <main> is the only scroll container); account/avatar lives in the sidebar footer; "create" and navigation are unified in a global ⌘K command palette (CommandPaletteProvider) — no chrome `+` button, no FABs. Linkable fields (repo owner/name, installation IDs, project slugs, URLs) must be solved with OAuth pickers or deep-links-out, never typed inputs. Native HTML form and interactive elements (input, select, button, textarea, checkbox, radio, dialog, etc.) are forbidden — use the shadcn/ui primitives under @/components/ui instead. Trigger when editing or creating .tsx files under apps/dashboard/, when adding forms/buttons/inputs/selects/modals to