johnfink-skills

Plugin johnfink-skills from marketplace johnfink in johnfink8/skill-repo. Commands read from the repo's manifest — 1 month ago.

Skills (11)

• agentic-llm

  Use whenever the user is building, debugging, or extending code that puts an LLM in a loop — calling tools, taking multi-step actions, deciding what to do next. Triggers include words like "agent", "agentic", "tool use", "tool calling", "ReAct", "autonomous", and code that loops over `messages.creat

• autonomy

  Use whenever you're about to ask the user to manually click, refresh, reproduce, or paste output — and when starting any new project, to plan verification infrastructure up front. Don't punt verification to the user when tools exist that let you do it yourself. Triggers on debugging from a user-repo

• code-style

  Use while writing or reviewing Python or TypeScript, for the style choices a formatter and type-checker can't make: whether a comment/docstring should exist (the #1 trap: over-commenting — default to none), naming that carries the meaning, import policy (relative-preferred in Python, named-exports i

• commit-preferences

  Use whenever writing a git commit message, drafting a PR title, or generating release notes. Enforces a terse, informal commit-message style — hints at the diff rather than restating it, no trailers. Apply on every commit, including auto-generated ones after edits.

• e2e-testing

  Use when (a) authoring a new e2e/browser test (selector choice, set-up strategy, what to assert), (b) investigating a flaky test, (c) deciding whether e2e is the right tier for a behavior (vs. unit/integration), (d) reviewing existing e2e tests for design issues, or (e) anyone is about to reach for

• failure-displacement

  Use whenever you're about to write or are reviewing code that handles a thing that could be missing, wrong, or fail — a config read, an env var, an external call, a deploy/CI step, a parse, a type that doesn't line up, an error path. Triggers when you reach for a default/fallback (`?? `, `|| []`, `.

• formatting-standards

  Use when (a) setting up a new project and choosing/configuring a formatter, (b) someone is proposing a manual formatting override or arguing about style, (c) reformatting legacy code or deciding whether to bundle reformatting with unrelated changes, (d) deciding line-length / import-order / quote-st

• pytest-methodology

  Use when (a) creating a new test file or test case, (b) making a test DESIGN decision (parametrize vs. duplicate, fixture vs. inline, what to mock vs. integrate, splitting a test that asserts multiple behaviors), (c) writing a failing test to reproduce a reported bug, or (d) reviewing tests for qual

• shell-discipline

  Use when (a) you've re-derived session state more than once (sourcing a venv twice, re-reading an env file, re-running `pwd`/`git status` for info you already have), (b) the same permission prompt has come up more than once for one tool (`sed`, etc.), (c) you've worked around an env-level problem at

• trial-data-discipline

  Use whenever the user is designing, running, or iterating on empirical trials — probes, evals, A/B tests, fixtures, recording rigs, or any code that captures human-in-the-loop data (mic recordings, screen captures, prompted-response sequences). Apply this skill even when the user doesn't say "trial"

• type-safety

  Use when (a) a type error needs fixing, (b) `Any`/`any`/`unknown`/`object` or any cast (`as`, `as unknown as X`, `cast`, `# type: ignore`) is about to be written or has appeared in code being reviewed, (c) you're designing the shape of data crossing a boundary (API, service, frontend↔backend, third-

Subagents (2)

• code-style-reviewer

  Adversarial reviewer for CODE STYLE in Python and TypeScript — the choices a formatter and type-checker can't make: comment/docstring necessity (its prime target is LLM-default over-commenting), naming that carries meaning, import policy, organize-by-capability file/folder structure, idiom, and sile

• fail-loud-reviewer

  Adversarial reviewer that hunts FAILURE-DISPLACEMENT bugs — code that makes a function, command, or deploy *appear* to succeed by hiding a broken condition (silent fallbacks, optional-skips in all-or-nothing operations, swallowed errors, over-broad catches, late validation, coerce-to-fit casts, wide

Hooks (3)

• SessionStart

  cat ${CLAUDE_PLUGIN_ROOT}/rules/house-rules.md

• PreToolUse

  python3 ${CLAUDE_PLUGIN_ROOT}/hooks/bash-anti-patterns.py

• PreToolUse

  python3 ${CLAUDE_PLUGIN_ROOT}/hooks/pre-push-review.py

Similar plugins