jonhill90/jonhill90-skills

Convene several harnesses or models against one question, each given a distinct lens it can fail on, before an artifact becomes load-bearing and being wrong is expensive. Use when the failure modes genuinely differ in kind — a single reviewer's prompt would only catch what its own lens looks for. Not for a question a command settles (just run it); not for one reviewer's prompt (sanity-check owns that); not for dispatch mechanics or isolation boundaries (dispatching-subagents owns those); not for trusting a verdict already returned (verify-the-instrument owns that).

Confirm you have everything needed to finish a change before starting it — what to implement, how it will be tested, and which rules govern it. Use before non-trivial work, when reviewing a plan for completeness, or when preparing a PR that needs planning evidence.

Design, create, and validate portable Agent Skills with effective triggers, concise instructions, and reusable scripts, references, or assets. Use when adding a new skill, substantially restructuring an existing skill, or validating a skill's structure, frontmatter, links, and bundled scripts.

Decide whether to delegate work to subagents, set each one's isolation boundary, and verify their output with external evidence. Use when considering fanning work out to parallel agents, orchestrating multiple agents, or reviewing whether a multi-agent result can be trusted.

Reduce a large body of source material to the smallest thing a reader can act on, at the cost of proportion — not a shorter version of everything, a decision about what matters. Use when asked to distill, or when the request is "what do I do about this" rather than "what does this say"; not for a summary that must preserve proportion.

Reproduce a bug with a failing test before fixing it, and keep the test in the suite. Use whenever asked to fix a bug, defect, regression, wrong output, or incorrect behavior in code.

Manage GitHub via CLI including pull requests, issues, workflows, actions, releases, and repositories. Use when working with GitHub, gh commands, GitHub Actions CI/CD, PRs, issues, releases, or repository management.

Push back when the user's stated belief, plan, or framing conflicts with what you actually observed, instead of agreeing to keep the exchange smooth. Use when the user asserts something as settled fact that your own evidence contradicts, asks you to confirm or bless an opinion, reacts to a correction by restating the original claim, or frames a question so the easy answer is agreement. Not for checking your own reasoning before you report it (see sanity-check) and not for judging whether a test, tool, or metric can be trusted (see verify-the-instrument) — this skill is about what you tell the user, not about what you privately verify first.

Manage Linear issues, teams, and projects via the Linear CLI. Use when the tracker is Linear specifically — reading or filing Linear issues, Linear sprint workflows, creating a branch or PR from a Linear issue, or managing Linear teams and projects. Not for GitHub Issues or other trackers.

Design a loop before running one - name its trigger, verification, two stop conditions, terminal states, and the weakest mechanism that holds it. Use when designing or reviewing unattended or repeating agent work - a schedule, a cron/routine, "keep going until X", a babysitting loop. Not for a fixed sequence of known steps (write a script instead) or a single task that just runs long - repetition, not duration, is the trigger.

Keep the run state a repeating or long-running loop needs between iterations — a progress file, decision log, known-failures list, run receipts, and a handoff note — on disk instead of in context. Use when work spans sessions or scheduled runs, a run must not redo what a prior run did, or context is filling before a handoff. Not for durable facts about the user (memory-conventions) or a one-off single-session handoff with no recurring loop behind it.

Read and write durable agent memory in the personal Obsidian vault at $AGENT_MEMORY_VAULT. Use at session start to recall context, when the user states a lasting preference, decision, or fact, or when asked to remember, recall, or forget something.

Mine your own agent transcripts for vocabulary you keep reaching for, to find candidates for the next skill — not to write one. Ranks terms by frequency and by whether they're explained the same way every time, separating a re-made decision from a repeated tool invocation. User-invoked only, for a deliberate periodic review; never fire this mid-task just because something feels repetitive.

Send a short, structured message to a human on a configured outbound channel (Telegram first, iMessage as a Mac-only fallback) from the terminal, so a stalled or escalated agent loop can reach someone who's away from the machine. Owns sending only, not escalation policy — the caller decides what's worth interrupting a human for. Dry-run by default; sending requires an explicit flag and a real send failure exits non-zero. User-invoked only — call this deliberately from a caller that has already decided to notify (e.g. a supervisor's escalate state), never automatically because a task felt important.

Read, write, search, and manage notes in Obsidian vaults using the official Obsidian CLI. Use when working with Obsidian notes, vaults, knowledge bases, daily notes, tasks, or personal wikis.

Author or review a Product Requirements Document — the problem being solved, who it's for, the goals and explicit non-goals, and the success criteria a stakeholder would use to judge whether the problem is actually solved. Use when asked to write, update, or review a PRD, or to define what a product or feature should do and why before any technical approach is chosen. Not for how it will be built — that is spec, which a PRD hands off to once the problem and goals are settled. Not a general project plan or pre-flight checklist — see close-the-loop for that.

Orient in an unfamiliar codebase by inspecting repository instructions, structure, documentation, manifests, key files, Git state, and recent work. Use when starting work, switching repositories, or needing a concise architecture overview.

Gate destructive file and directory operations by verifying contents match their described purpose before removing anything. Use whenever asked to delete, remove, clean up, clear out, purge, or empty files, directories, logs, caches, or artifacts.

Check reasoning with a second mind — dispatch a reviewer whose prompt is built for the specific question, with a lens it can fail on and evidence required for every finding. Use before acting on a plan, decision, diagnosis, or rationale whose cost of being wrong is high and whose only support so far is your own reasoning.

Author or review a technical specification — architecture, interfaces, data flow, and the implementation approach engineers will build against, plus the trade-offs behind the choices made. Use when asked to write, update, or review a technical spec or design doc, or to decide how something will be built once what it should do is already settled. Not for defining what a product should do and why, or who it's for — that is prd, which a spec is written against. Not an in-session pre-flight checklist for a single change — see close-the-loop for that.

Run a long-lived supervisor loop over one or more worker agent lanes — recurring health gate, a named defect family as the work seam, and verification standards that let work merge without the human reading diffs. Use when supervising agents across many hours or days, when a recurring cron prompt drives an agent, or when deciding whether a lane's PR is safe to merge.

Write a failing test for new behavior before implementing it, then implement only enough to pass, then refactor — red, green, refactor for code that has never worked yet. Use when building a new feature, function, endpoint, or component from scratch and no prior bug is being reproduced. Not for fixing a bug, defect, regression, or wrong output in existing code — that is failing-test-first, which owns the bugfix case specifically; defer to it whenever a prior working state exists to reproduce a break against.

Use tmux safely from an agent with explicit pane targeting, state inspection, verified input delivery, response polling, recovery, and multi-agent supervision. Use when an agent CLI, TUI, REPL, authentication flow, or other interactive command must retain terminal state across tool calls.

Check the measuring device before trusting what it reports — prove a check can actually fail before believing it passed, and prove a fix is load-bearing before believing it worked. Use right before acting on a test result, review, metric, or another agent's claimed finding. Not for writing the check or running it the first time — that is ordinary testing, not this.