jonhill90
- 41 skills
- 0 followers
- 15 hours ago last updated
- ▌ Prd · jonhill90 bundleAuthor 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.
- ▌ Tdd · jonhill90 bundleWrite 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.
- ▌ Spec · jonhill90 bundleAuthor 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.
- ▌ Tmux · jonhill90 bundleUse 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.
- ▌ Linear · jonhill90 bundleManage 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.
- ▌ Notify · jonhill90 bundleSend 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.
- ▌ Primer · jonhill90 bundleOrient 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.
- ▌ Distill · jonhill90 bundleReduce 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.
- ▌ Obsidian · jonhill90 bundleRead, 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.
- ▌ Mechanize · jonhill90 bundleDecide whether a step currently done by AI inference should become a deterministic tool instead - check whether the output is a FUNCTION of the input (mechanize it) or requires judgement (keep AI on it), then run the counter-test before committing. Use when a model has computed, checked, or classified the same thing identically across several turns or ticks, or before scripting a step an agent currently performs by reasoning. Not for checking whether a tool can be trusted once built (verify-the-instrument), whether existing reasoning holds (sanity-check), or whether to adopt someone else's code versus write your own (adopt-or-build) - this decides whether a tool should exist here at all.
- ▌ Github CLI · jonhill90 bundleManage 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.
- ▌ Loop Memory · jonhill90 bundleKeep 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.
- ▌ Create Skill · jonhill90 bundleDesign, 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.
- ▌ Sanity Check · jonhill90 bundleCheck 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. TRIGGER, even when the surrounding work otherwise reads as routine: a number, count, or ratio about to be stated (in a report, a PR body, a closing comment) that you cannot point to a command, log line, or fixture for — an inherited figure is exactly this, not an exception to it.
- ▌ Ask A Council · jonhill90 bundleConvene several harnesses or models against one question, each doing a distinct job it can fail at — different evidence, a different objective, or a withheld conclusion — before an artifact becomes load-bearing and being wrong is expensive. Diversity comes from what each reviewer is given, never from a character it plays. 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 cheap deterministic check settles (run the check first); 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).
- ▌ Loop Contract · jonhill90 bundleDesign 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.
- ▌ Prompt Corpus · jonhill90 bundleTurn a transcript history into a queryable record of decisions — raw prompts, one judgement per prompt, and views that answer "what is still binding", "what did I say that nobody acted on", and "what did I ask that was never answered". Use when adding new prompts to the corpus, when re-running the judging pass, or when answering a question about what the operator has already decided.
- ▌ Safe Deletion · jonhill90 bundleGate destructive file, directory, and live-work operations by verifying the target's actual contents or state match its described purpose before removing or killing it. Use whenever asked to delete, remove, clean up, clear out, purge, or empty files, directories, logs, caches, or artifacts — and whenever a structural or migration change would require killing, force-respawning, or hard-restarting a running process, session, or container.
- ▌ Adopt Or Build · jonhill90 bundleDecide, per component, whether to adopt an existing name, dependency, library, or tool or build it in-house, weighing blast radius over convenience. Use at the point a name or dependency is about to be chosen or recommended — before it is proposed, not after. Not for finding a technology's capability ceiling (research-the-limit), not the mechanism for genuinely different reviewer lenses (ask-a-council, which this skill may call), and not a substitute for attacking the chosen answer (devils-advocate, which this skill invokes as its final step).
- ▌ Close The Loop · jonhill90 bundleConfirm 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.
- ▌ Dispatch Brief · jonhill90 bundleWrite the brief that hands a bounded piece of implementation or verification work to a lane or subagent — name the failure with evidence, require a two-directional mutation test, state which failure direction is worse, forbid weakening a guard to reach green, allow "could not measure" as a real verdict, and make posting the result part of the deliverable. Use when composing a brief for a worker that will fix a bug, add a guard, or verify a claim, especially one dispatched to run unattended. Not for reviewing reasoning that has already been produced (sanity-check), a durable architecture document (spec), deciding whether a repeated step should become a tool (mechanize), or judging whether a check already in place can be trusted (verify-the-instrument).
- ▌ Keep Me Honest · jonhill90 bundlePush 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.
- ▌ Devils Advocate · jonhill90 bundleArgue the strongest honest case against a plan or decision before it is committed, not after. Use before a hard-to-reverse choice is finalized — a build-vs-adopt call, an architecture pick, a plan about to be executed — while the decision can still change. Distinct from sanity-check, which tests whether existing reasoning holds; devils-advocate assumes the conclusion is wrong and builds the opposing case from scratch. Distinct from keep-me-honest, which challenges a claim already stated to the user; devils-advocate runs before anything is said or done. Distinct from ask-a-council, which assigns several non-overlapping lenses to one artifact; devils-advocate is one deliberate opposing pass, not a multi-lens convening.
- ▌ Determine Intent · jonhill90 bundleWork out what the user actually wants — from the literal words of the request and from what they have already told you — before starting the work, and state that reading so it can be corrected. Use before acting on a non-trivial request, especially one that echoes something asked before, one that could be read more than one way, or one that may sit against a goal the user has already stated elsewhere. Not for finding out what has already been said (see determine-signals, which runs on the same "before acting" moment but asks the record, not the goal); not for checking reasoning you already produced (see sanity-check, which runs after); not for confronting a claim the user just made (see keep-me-honest, which reacts to a conflict already visible); not for building the case against a plan (see devils-advocate, which opposes a conclusion, not a request) — this skill runs before work starts and is about the goal, not the record, the method, or a specific statement.
- ▌ Mine Transcripts · jonhill90 bundleMine your own agent transcripts for vocabulary you keep reaching for, to find candidates for the next skill — not to write one. Invokes the external mine_prompts.py extractor, then applies judgement the tool can't — separating a re-made decision from a repeated tool call or repeated boilerplate. User-invoked only, for a deliberate periodic review; never fire this mid-task just because something feels repetitive.
- ▌ Decide By Variant · jonhill90 bundleBuild several genuinely different real artifacts in the real medium with fake data, and let the human pick by looking, instead of asking a taste decision in prose. Use whenever a decision has no objectively right answer — a glyph, a layout, a default, a name, a wording, a sort order — and describing the options in words would cost the human more thought than looking at them would. Run determine-intent first — if the answer is already a known parameter, build nothing. Not for getting different positions from agents on one question (ask-a-council); not for attacking an answer once chosen (devils-advocate runs after a variant is picked, not instead of building one).
- ▌ Determine Signals · jonhill90 bundleFind out what has already been said — in transcripts, issues and PRs, the ledger, the notebook, and vault facts — before asking a question or stating a fact as current, and prefer live system state over any stored record when they disagree. Use before acting on a non-trivial request, right where you would otherwise ask something you could answer by looking, or restate a fact without rechecking it. Not for what the user wants (see determine-intent, which runs on the same "before acting" moment but asks the goal, not the record); not a deliberate periodic transcript sweep for new skill candidates (see mine-transcripts, which is scheduled, not per-task); not for judging whether a check or metric can be trusted once you have its verdict (see verify-the-instrument) — this skill decides which signal source to consult and which one wins when two disagree, not whether a given source's zero result is real.
- ▌ Failing Test First · jonhill90 bundleReproduce 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.
- ▌ Memory Conventions · jonhill90 bundleRead 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.
- ▌ Research The Limit · jonhill90 bundleBefore asserting that a tool, library, or system cannot do something, check a primary source — its own docs, --help, source, or what is actually installed — rather than asserting from memory. Use whenever about to write or say "X cannot do Y", "there is no way to Y", or plan around a limit nobody has actually checked. Not for judging whether a check's verdict can be trusted (verify-the-instrument) or for reasoning with no command or document available to settle it (sanity-check) — this is specifically for a claimed capability boundary that a primary source can confirm or refute.
- ▌ Supervised Lane Loop · jonhill90 bundleRun 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.
- ▌ Dispatching Subagents · jonhill90 bundleDecide 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.
- ▌ Verify The Instrument · jonhill90 bundleCheck 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.
- ▌ Progressive Disclosure · jonhill90 bundleLoad a large corpus, document set, or codebase the way an index is meant to be used — read the index first, pull individual files or facts in on demand as the task actually needs them, and stop once there is enough to act, instead of reading everything up front. Use before reading many files, an entire directory, or a large document set for a task that plausibly needs only a fraction of it.
- ▌ Plan Parallel Execution · jonhill90 bundleTurn a task list into groups several agents can execute concurrently without colliding — derive file ownership mechanically, then supply the judgement a file-intersection cannot: shared resources that are not files, dependencies stated only in prose, and what each group's gate must prove. Use when work will be split across concurrent agents or worktrees, or when reviewing such a plan before it runs. Not for deciding how many agents or what each may see (dispatching-subagents), not for testing whether the plan's reasoning holds (sanity-check), and not for whether a step should be a tool at all (mechanize).
- ▌ Spec Driven Development · jonhill90 bundleWrite a falsifiable acceptance criterion and its mutation check before writing any code, and require the behaviour to be demonstrated — not merely the code to exist — before closing the work. Use when scoping non-trivial work before it starts, when deciding whether a request duplicates something already shipped, or when deciding whether an issue can be closed. Not for planning the steps of already-scoped work (close-the-loop), not for writing the test that implements a chosen criterion (tdd, failing-test-first), and not for confirming an existing check can fail (verify-the-instrument) — this is what happens before any of those three has something to work from.
- ▌ Refuse Invented Identity · jonhill90 bundleRefuse and report unrecoverable when a recovery, resume, restore, or failover path cannot positively confirm which prior identity, session, or state it is restoring — never start a fresh instance under the old label and let it pass as continuous. Use when resuming a session, reconnecting to a worker or lane, restoring from a checkpoint, or reclaiming any id, name, or label after a gap, and the record needed to confirm it maps to a specific prior state is missing, ambiguous, or unverifiable.
- ▌ Durable Fact Before Label · jonhill90 bundleWhen a single operation must write both a durable record and a lighter derived label, lock, or claim that points at it, write the durable fact first and update or release the label second — so a crash between the two steps leaves a stale but harmless label, never a record that must be reconciled by hand. Use when writing or reviewing a completion script, finalize step, lock/claim release, rename-on-success, or reconciler that touches two places that must stay consistent. Not for deciding whether to resume an identity after a gap (refuse-invented-identity, its sibling and not its duplicate) or whether a mechanism has a caller at all (wire-it-when-you-write-it).
- ▌ Wire It When You Write It · jonhill90 bundleShip a mechanism and its caller in the same change, and add the check that fails when a caller disappears — never leave a tested module, script, or gate that nothing invokes. Use when creating any new script, module, hook, workflow, or check, and when reviewing a change that adds one. Not for deciding whether a tool should exist at all (mechanize), whether a tool's verdicts can be trusted (verify-the-instrument), or whether to adopt an existing tool instead of writing one (adopt-or-build) — this is only about the gap between writing a mechanism and something actually calling it.
- ▌ Test In The Consumer Context · jonhill90 bundleRun a check where the thing that depends on it runs — same user, shell, environment, working directory, and privileges — before believing its verdict, and place a check only where it can actually observe its subject. Use before reporting that a command, credential, path, or tool works or fails for something other than your own session, and before siting a check in CI, a hook, or a scheduled job. Not for proving a check can fail at all (verify-the-instrument) and not for checking a claimed capability limit against primary sources (research-the-limit) — this is specifically about the check running somewhere its consumer is not.
- ▌ Derive Independently Then Compare · jonhill90 bundleDerive an answer from the source corpus a second time, without reading the first derivation, then compare — before trusting a conclusion drawn from a large body of transcripts, notes, or documents about what someone wants, prefers, or constrains. Use when a claim about a person's stated intent or a parameter cannot be traced to a quote, or before that claim is reported as fact. Runs before sanity-check and devils-advocate, not instead of them — a reviewer or an opposing case inherits whatever inputs the first pass fabricated, and this is the only one of the three that re-reads the source rather than the write-up. Not ask-a-council (different positions on a shared question, not the same question re-derived from source); not determine-signals (finds what was already checked, not whether what was reported was actually found there).