Delete local git branches whose remote tracking branch is gone or whose changes are already merged into the base branch. Use when the user asks to clean up branches, prune branches, delete stale branches, or /git-branch-cleanup. Also trigger on "tidy git branches", "remove old branches", "I'm done with these branches", "branch graveyard", or whenever the user complains about local branch clutter. Reports what will be deleted and asks before deleting anything.
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.
Run git commit using Angular conventional commit format (header + footer only, no body). Use when the user asks to commit, create a commit, /git-commit, or save changes to git. Also trigger on "snapshot this", "save my work", "check in changes", "wrap up", "ship this locally", or whenever the user finishes a logical unit of work and the tree is dirty. Boundary with `git-pr-create`: this skill owns only the explicitly local framing - bare "ship this" / "ship it" / "send for review" means the work should leave the machine, which is `git-pr-create`'s flow. Stages relevant files and commits immediately without asking for confirmation.
Open one standalone GitHub issue with `gh` - duplicate-checked first, conventional title, repo-template-aware body, auto-resolved labels. Use for every issue-filing request however casual: "open an issue", "file a bug", "make a ticket", "/git-issue-create", "track this", "note this down", "we should fix X later", or whenever the user describes a defect or wanted capability that is clearly not being built right now. A raw `gh issue create` skips the duplicate search, label resolution, and body caps this skill owns. Boundary: work starting now goes to `git-branch-create`; an issue that already exists goes to `git-issue-start`. Creates the issue immediately without asking for confirmation.
Take a GitHub issue from open to a checked-out branch - assign it to you, mark it in progress if the repo has such a label, derive a conventional branch name from its `type: *` label, branch off the detected base. Use for "start issue 42", "work on #42", "/git-issue-start 42", "let's do 42", "pick up that issue", "take the oauth issue", "I'll take this one", or whenever the user points at a tracked issue and is about to write code for it. Resolves an issue named by title via `gh issue list --search`. Boundary: with no issue in play it is `git-branch-create`'s, and this skill delegates naming and base detection to it. Assigns and branches 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.
Open a GitHub pull request for the current branch using `gh` - conventional title, repo-template-aware body, auto-derived labels, push if needed. Use for every PR-creation request however casual: "create/open/raise a PR", "PR this", "send PR", "/git-pr-create", "ship this", "ship it", "send for review", "ready for review", "publish this branch", or whenever the user signals work on a feature branch should leave their machine. A raw `gh pr create` skips the push, label derivation, title format, and safety rules this skill owns. Boundary with `git-commit`: an explicitly local framing ("commit this", "save my work", "ship this locally") stops at a commit. Pushes the branch and opens the PR immediately without asking for confirmation.
Implement an OpenSpec change's tasks in parallel - read the task queue, plan file-disjoint waves, dispatch one agent per task into its own worktree, verify, tick the checkbox, commit, repeat. Use when the user says "apply the change", "implement the change", "run the tasks", "work the tasks in parallel", "fan out the change", "dispatch the spec", "/spec-apply", or hands over an OpenSpec change and expects code written for it. Wraps `/opsx:apply`, whose loop is strictly serial, single-agent, and git-blind. Boundaries: artifacts missing or incomplete -> `spec-propose`; every task already ticked and the result needs checking -> `spec-verify`; a finished change ready to fold into the specs -> `spec-archive`; a plain GitHub issue with no OpenSpec change behind it -> `git-issue-start`.
Fold a completed OpenSpec change into the project's specs, commit the move, and open the PR - the last link in the spec chain. Wraps `/opsx:archive`, which is git-blind. Use when the user says "archive the change", "archive that spec", "/spec-archive", "fold this into the specs", "close out the change", "it's done, land it", "finish the spec", or points at a change whose tasks are all ticked and whose code is verified. Gates on real task progress before archiving anything. Boundary: tasks still unticked -> `spec-apply`; applied but not proven green -> `spec-verify`; opening a PR with no change to archive -> `git-pr-create`; retiring a whole capability rather than completing a change -> that is a new change, so `spec-propose`. The PR's `Resolves:` line comes from the branch-to-issue link `spec-propose` set. Never merges the PR it opens.
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`.
Write and edit blog posts for pivoshenko.dev - interrogate for raw material, outline as a dependency graph, confirm sections, draft section-by-section, run the local anti-slop edit passes (references/anti-slop.md), ship as MDX. Use when the user says "write a blog post", "draft a post about X", "edit/revise/improve this article", "tighten this draft", "turn this into a post", "publish to my blog", or shares notes/an experience meant for pivoshenko.dev. The goal is bespoke practitioner writing, not generic AI prose.
Remove AI-writing tells from any prose, normalize punctuation to plain ASCII (em/en dash -> plain punctuation per the replacement order, curly quotes -> straight, ellipsis char -> "..."), and raise headings to Title Case. Use when the user says "humanize this", "make it sound human", "de-AI this", "this reads like ChatGPT", "remove AI patterns", or when editing/reviewing any prose (doc, README, PR description, commit message, email, post) that shows AI tells. The general-purpose de-AI pass for any prose, in any format, unless a more specific writing workflow already owns the piece. Skips agent-instruction files (CLAUDE.md, AGENTS.md, context.md, llms.txt, cursor rules) unless the user aims it at one - their terse fragment style is the working format, not a tell.
Obsidian Flavored Markdown syntax reference - wikilinks, embeds, callouts, properties/frontmatter, tags, comments, block IDs. Use when creating or editing .md files in an Obsidian vault, when linking or embedding notes, when writing callouts or note frontmatter, or when the user mentions wikilinks, backlinks, block references, or Obsidian notes. Also use before hand-writing Obsidian syntax from memory - the extensions here are not standard markdown and the near-misses (markdown links to vault notes, wrong callout keywords) fail silently in the app.
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.
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).
Deep-clean macOS - user/system junk (caches, logs, trash, iOS backups), leftovers from deleted apps, dev-tool junk (brew, docker, Xcode, npm/pnpm/uv/cargo caches, stale node_modules), disk-space breakdown + login-items audit. Use when the user says "clean my mac", "free up disk space", "disk is full", "what's eating my storage", "remove app leftovers", or any macOS storage/cleanup complaint. Health checks, updates, tune-up ("optimize/maintain my mac") -> macos-maintenance instead. Always scans read-only first, reports sizes, deletes only after explicit per-category confirmation.
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.
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.
No description published for this entry.