Turn a dirty working tree into a clean pull request against `main`: survey every change, group the files into Conventional Commits by blast radius (one concern per commit), run the gate, branch off `main`, capture a visual for any user-visible change, push, and open the PR. Trigger when the user says "/create-pr", "create a PR", "open a pull request", "commit and PR these changes", "group these into commits and ship them", or has a dirty working tree they want landed. Stops at "PR open"; building images and deploying to prod is a separate flow.
Workspace Rust guardrails. Trigger on the sharpest moments: a change that adds `unsafe`, `unwrap`, `expect`, or `panic!` outside `main()`/tests; introducing a new public API, error type, or module; reaching for a different web framework, ORM, or async runtime (we standardize on Axum + SeaORM + Tokio); or wiring a new binary's `main()`. Read [`docs/rust-programming.md`](../../../docs/rust-programming.md) before acting — it is the authoritative reference.
Embed a local screenshot or GIF into a GitHub PR (or issue) body so it actually RENDERS on github.com, driven from the CLI — no drag-drop, no committing the file, no image-hosting branch, no release/tag. It uploads the `/tmp` capture to GitHub's native `user-attachments` CDN via the `gh-image` extension (which borrows your logged-in github.com browser session) and returns a real `https://github.com/user-attachments/assets/…` URL to drop into the body. Trigger as the embed half of [[create-pr]] Step 6 (after [[web-preview]] captures the visual), when a reviewer comment on a PR asks for a "live walkthrough"/screenshot during [[review-pr]], or any time you have a `/tmp` image that must appear in a PR/issue body or comment. This is the LOCAL/`gh` path for hosting and embedding a capture. Capture lives in [[web-preview]] — a walkthrough defaults to a GIF of the real interaction (§5), a still (§3) only for a genuinely static change; this skill only hosts + embeds it.
Run the `web` app locally against the KIND dependency stack and look at it in a real browser — the canonical "spin up web, drive Chrome, capture to /tmp, verify" loop. Trigger whenever asked to run, preview, screenshot, or visually verify `web` / a page / a UI change, to "open the design page", "check it in chrome", or to prove a front-end behavior (syntax highlighting, a toast, a layout, a keyboard shortcut) actually renders. A PR walkthrough defaults to a GIF of the real interaction (§5); a still is only for a genuinely static change. This is the browser half of the local loop; `kind-local-dev` is the cluster half it builds on. Skip for pure logic/unit work — `cargo test` uses testcontainers and needs no cluster.
Local Kubernetes-in-Docker (KIND) workflow for the navigator workspace — cluster lifecycle, ingress, port-forwarding, the "host runs `web`, deps run in cluster" iteration pattern via the `navigator` CLI. Trigger when running any `navigator` orchestration subcommand (`dev up`, `dev down`, `dev deploy`, `dev kind up`, `dev kind down`, `dev e2e`, `dev logs`, `dev worktree-env`), editing `k8s/kind-config.yaml`, debugging an in-cluster service from the host, or onboarding the cluster from a fresh machine. Also trigger before installing a different local-Kubernetes flavor — we standardize on KIND. Also trigger before proposing to run, preview, screenshot, or manually exercise the app, or before any action that runs on the user's machine (cluster, browser, or cloud commands) — those resolve to this KIND loop, and the move is to propose the commands for the user to run.
Address a requested pull-request comment against the real code at the PR head. Read the thread, source, and covering test; reproduce behavioral claims in the right KIND-backed environment; apply only the minimum valid fix; prove it; then reply and resolve that thread. Trigger when the user asks to address or review a PR comment, a Greptile finding, or a named review thread. For a request covering several comments, repeat this narrow action for each one without combining their scopes.
Twelve-perspective review pattern for the people the firm serves ("The Client Council") — the demand-side sibling of the engineering `/council` (the people who *build* Neon Law Navigator) and the `legal-council` (the counsels who *draft* it). Each voice fuses a zodiac stance with a real client walking in the door across the firm's practice areas — Libra the prospective client at the threshold chairs (weighs whether to hire a lawyer at all, then closes on "does this make me walk in and stay?"), Aries the tenant facing eviction names the fire, Pisces the overwhelmed person who almost didn't reach out guards access-to-justice, Capricorn the elder planning their legacy thinks in decades, Leo the wronged client who wants to sue tests the firm's featured litigation practice, and so on. Use it when building Neon Law Navigator — intake flows, questionnaire prompts, pricing copy, portal UX, onboarding — to pressure-test "does this actually serve the human who shows up?" Trigger when the user says "client council", "cu
Authoring rules for client-facing marketing copy on neonlaw.com — firm pages under `web/content/marketing/`, the views under `views/src/pages/`, and any public surface where the firm advertises services (LinkedIn posts, YouTube content, talk titles when speaking *for the firm*). Trigger when adding or editing any of those files, drafting a hero line, naming a new service tier, writing a service description, or quoting a fee. Three load-bearing rules: (1) market only the firm's own value, never compare to or characterize "other lawyers / traditional firms"; (2) no hyperbole or unsubstantiable superlatives; (3) attorney-advertising compliant across the firm's bar admissions (CA, NV, WA) — no guarantees of results, no certification claims for SOC 2 / HIPAA, SLAs are service commitments not outcome promises. Skip for non-marketing surfaces (internal docs, code comments, ADRs) and for already-binding documents (signed retainers, filed pleadings) — those are reviewed by the attorney of record, not by this skill.