jonhill90-skills

Plugin jonhill90-skills from marketplace jonhill90 in jonhill90/skills. Commands read from the repo's manifest — 4 days ago.

Skills (42)

• adopt-or-build

  Decide, 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 capabilit

• ask-a-council

  Convene 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 fro

• close-the-loop

  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.

• create-skill

  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-by-variant

  Build 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

• derive-independently-then-compare

  Derive 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

• determine-intent

  Work 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 co

• determine-signals

  Find 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

• devils-advocate

  Argue 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 whe

• dispatch-brief

  Write 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 verd

• dispatching-subagents

  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.

• distill

  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 su

• durable-fact-before-label

  When 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

• failing-test-first

  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.

• github-cli

  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.

• keep-me-honest

  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 correctio

• linear

  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.

• loop-contract

  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

• loop-memory

  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

• mechanize

  Decide 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 classifi

• memory-conventions

  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-transcripts

  Mine 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. Use

• notify

  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 w

• obsidian

  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.

• organize-repository

  Decide where code, tests, docs, scripts, config, generated files, and knowledge (notes, research, captured sources) belong, so placement and names stay predictable across projects instead of being re-decided each time. Use when starting a repository or knowledge store, saving something whose home is

• plan-parallel-execution

  Turn 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 w

• prd

  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

• primer

  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.

• progressive-disclosure

  Load 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 ent

• prompt-corpus

  Turn 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 j

• refuse-invented-identity

  Refuse 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

• research-the-limit

  Before 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 ha

• safe-deletion

  Gate 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 whe

• sanity-check

  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

• spec-driven-development

  Write 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 alr

• spec

  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 b

• supervised-lane-loop

  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 dr

• tdd

  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 fixi

• test-in-the-consumer-context

  Run 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 s

• tmux

  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.

• verify-the-instrument

  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

• wire-it-when-you-write-it

  Ship 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 decidi

Similar plugins