Audit + harden + optimize live Cloudflare zones/domains - read-only sweep of each zone (SSL/TLS mode, HSTS, min TLS, TLS 1.3, Always-Use-HTTPS, Brotli, HTTP/3, 0-RTT, Early Hints, caching, security level, Bot Fight Mode, WAF, DNS proxy/TTL + SPF/DKIM/DMARC hygiene, DNSSEC) -> ok/attention/action report grouped by category -> per-category confirm -> apply via Cloudflare MCP. Use when the user says "harden my cloudflare", "optimize my cloudflare zones", "audit my domains", "check my cloudflare settings", "secure my dns", "harden my dns", "hide my origin IP", "set up HSTS/DNSSEC", "am I leaking my origin", "is my cloudflare config optimal", or "tune cloudflare". For BUILDING on Cloudflare (Workers/Pages/KV/D1/Terraform) use the cloudflare skill instead.

Create a new git branch using a conventional naming scheme. Use when the user asks to create a branch, start a new branch, /git-branch-create, or signals they are beginning a discrete piece of work - "start work on X", "spin up a branch for Y", "let's start Z". Boundary: a request naming an existing issue ("#42", "pick up that issue") is `git-issue-start`'s; filing a ticket without starting work is `git-issue-create`'s. Creates and checks out the branch immediately without asking for confirmation.

Fetch the latest base branch and rebase the current branch onto it, surfacing conflicts clearly. Use when the user asks to sync, rebase, update from main, pull latest changes, or /git-branch-sync. Also trigger on "catch up with main", "rebase onto main", "update my branch", or whenever the user signals their branch is stale vs base. Runs immediately without asking for confirmation.

Groom an open GitHub backlog with `gh` - one read-only sweep, every open issue bucketed into exactly one category (unlabeled, unprioritized, stale, likely duplicate, closeable, blocked, healthy), a per-issue report, per-category confirmation, then batched label / state / comment edits. Use when the user says "triage issues", "groom the backlog", "clean up issues", "/git-issue-triage", "what's in the backlog", "any stale issues", "review my open issues", "the backlog is a mess", "nothing in here is labelled", or otherwise complains about issue clutter. Boundary with `git-issue-create`: that one writes a single new issue, this one only grooms issues that already exist. Boundary with `git-issue-start`: that one picks one issue up and branches, this one never starts work. Destructive - previews everything and confirms per category before touching anything.

Run a task list across parallel Herdr panes - measure the pane budget, split, start one agent per task, brief them, collect results from files, handle blocked workers, clean up. Use when the user says "dispatch these", "run these in parallel", "fan this out", "spin up agents", "/herdr-dispatch", or whenever the `herdr-workflow` instruction sends delegated work to panes. That instruction holds the policy; this is the mechanics. Inspecting or driving existing panes without dispatching work -> the `herdr` skill. Requires HERDR_ENV=1.

Periodic macOS maintenance + optimization - read-only health sweep (pending OS/brew updates, disk health + SMART, memory pressure + swap, battery condition, Time Machine recency, Spotlight indexing state, crash/panic reports, uptime, login-item load) -> ok/attention/action report -> confirmed fixes. Use when the user says "maintain my mac", "mac health check", "tune up my mac", "optimize my mac", "run maintenance", "is my mac healthy", "update everything", "my mac is slow / hot / fan is loud", or wants a periodic once-over. Also covers targeted fixes when a check or the user flags an issue - Spotlight reindex, Launch Services rebuild, DNS/font cache flush, frozen Finder/Dock, runaway process triage. Storage/junk/leftovers/disk-space -> macos-cleanup instead.

Map a problem and understand the codebase before any change exists - ground every question in what the repo says, converge on an outcome, a scope, and an explicit not-in-scope boundary, then hand to `spec-propose`. Use when the user says "explore this", "/spec-explore", "help me think this through", "what would it take to X", "where does X live", "map this out", or opens a design question with no decided shape yet. The thinking stage of the OpenSpec chain `spec-explore` -> `spec-propose` -> `spec-apply` -> `spec-verify` -> `spec-archive`, and the only one that runs fine in a repo with no `openspec/`. Boundary with `grilling`: that stress-tests a decision already made, this one has none yet. Boundary with `diagnosing-bugs`: something broken, failing, or slow is a diagnosis. Boundary with `spec-propose`: scope already clear means skip straight there. Boundary with `architecture`: a technology choice needing an ADR is that skill's. Writes nothing - no artifacts, no branch, no commit, no code.

Draft the OpenSpec change artifacts - `proposal.md`, the `specs/` delta, `design.md`, `tasks.md` - on a fresh branch, install the wave rules that make `tasks.md` parallel-safe, validate, and commit. Use when the user says "propose this", "write the proposal", "spec this out", "/spec-propose", "turn this into an OpenSpec change", "plan this as a change", "decompose this", "what are the tasks for X", or whenever a design discussion has converged and needs artifacts. Wraps `/opsx:propose` and owns only the git seam it ignores - branch first, issue link so the later commit and PR close the ticket, commit after. Boundaries: still working out what the change even is -> `spec-explore`; artifacts already written and ready to build -> `spec-apply`; one indivisible piece of work needing no spec at all -> `git-branch-create`; a tracked ticket rather than a spec -> `git-issue-create`. This skill plans and stops - it never implements.

Check that an OpenSpec change's implementation actually matches its spec, before anything is archived - artifact validity via `openspec validate --strict`, the repo's own verify gate run for real, and scenario-by-scenario conformance against the spec delta. Read-only: it reports, it never fixes. Use when the user says "verify the change", "/spec-verify", "does the code match the spec", "check spec conformance", "is this ready to archive", "did we actually build it", "audit the ticks", or whenever `spec-apply` has ticked the last task. Boundaries - tasks still unticked -> `spec-apply`; verified and ready to fold into the specs -> `spec-archive`; reviewing a diff for bugs rather than for spec conformance -> `/code-review`; something is broken and needs diagnosing -> `diagnosing-bugs`.

Audit and harden the 4 pivoshenko brand sites on Vercel (pivoshenko.dev, pivoshenko.startpage, pivoshenko.wallpapers, pivoshenko.ai), team `pivoshenko`. Read-only sweep -> per-site report (ok/attention/action) -> confirmed fixes. Emphasizes security headers and analytics coverage. Use when the user says "audit vercel", "check vercel hygiene", "harden the sites", "vercel security", "check analytics coverage", "vercel health check", or wants a periodic once-over of the Vercel setup. Delegates perf/cost -> `vercel-optimize`, CLI ops and deployments -> `vercel-cli` (or the `mcp__vercel__deploy_to_vercel` tool).

Draft blog posts and project announcement posts (reddit/HN style) in the Obsidian vault's 06 WRITING. Use when the user says "draft a blog post about X", "write an announcement for <project>", "reddit post for my project", or wants to turn wiki/project material into publishable writing.