Claude Skills by grimaldost

- **Date:** 2026-07-24 - **Status:** ready (DoR passed) - **Audience:** implementing agents + reviewer - **Output artifact(s):** `plugins/humblepowers/skills/experiment-rigor/SKILL.md`; `scripts/{stats,validate,render,from_fathom}.py` and their `test_*.py` under that skill (plus `test_mantis_fallback.py`); `templates/{probe,measurement,decision}.yaml`, `templates/schema.json`, and `templates/SCHEMA.md`; `references/{threats-catalog,small-n-stats}.md`; `examples/rg-2x2/{record.yaml,report.md}`...

Evidence before completion claims: identify the command that would prove the claim, run it fresh in this session, read the full output including exit code, and only then state the result — with the evidence. Use when about to report work as done, fixed, passing, or ready; before committing, opening a PR, or moving to the next task; when relaying a subagent's result (verify the diff, not the report); and when adding a regression test (red-green it: revert the fix, watch it fail, restore, watch...

Use when reviewing a SQL query before it runs in production — catches accidental fan-out joins, non-idempotent MERGE on an incomplete key, missing partition filters on large tables, and NULL-in-aggregate bugs that silently change the result. Triggers on "review this query", "is this SQL safe to run", "check my MERGE statement", "why is this join returning too many rows".

Discipline guardrails for data-engineering work with downstream consumers — activate at the START of the task, before writing code, because silent semantic drift is the dominant risk. Activate on: migrating or porting a pipeline, refactoring a transform, backfilling or replaying history, evolving a schema (add / rename / retype / drop a column), creating a new dataset — or a metadata / catalog / lineage emitter whose output a separate tool loads — that has consumers, designing or reviewing a ...

Modern Python engineering standards and best practices. Use this skill whenever a user wants to: scaffold a Python project, configure tooling (uv, ruff, ty, mypy, structlog, pytest, hypothesis, pydantic-settings, opentelemetry, pip-audit), set up pyproject.toml, src-layout, pre-commit, CI/CD, Docker — for an existing, inherited, or legacy project as much as a greenfield one (assessing and modernizing current setup, not just scaffolding new) — or asks about Python architecture, packaging, test...

Review and update the python-engineering toolchain pins. Run /refresh-stack to detect which pinned tools are behind the latest PyPI release, read the relevant changelogs, and produce a reviewable changeset (stack.toml version bumps plus any guidance edits) for approval. Mechanical bumps are applied on approval; guidance edits are never auto-applied. Manual-only.

Structure an experiment and its write-up so the Methods reconstruct without the conversation and the uncertainty is declared, not hidden — a typed record.yaml across a probe / measurement / decision tier ladder, every load-bearing rule a script that exits non-zero rather than a line of prose. Use when you pre-register an A/B, freeze a plan before running it, write up an experiment or a comparison, add error bars or a confidence interval to a rate, reconcile declared cells against the runs tha...

Turn an idea into an agreed design before implementation — explore project context, ask clarifying questions one at a time, propose two or three approaches with trade-offs and a recommendation, present the design in sections for approval, and record the agreed design. Use when the user proposes a feature, component, behavior change, or project whose requirements or shape are not yet pinned ('let's build', 'I want to add', 'how should we approach'), or when one request bundles several independ...

Choose which Claude model and effort a task should run on — a capacity-dispatch step when work is about to be delegated or priced. Use when spawning subagents or workflow agents, when authoring a governed multi-PR series file (e.g. a convoy series.toml governance block, and per-PR tiers where the engine supports them), when a planning tool asks for a per-task tier (a route-and-budget phase, per-role picks in an execution plan), when sizing a review panel's model ladder, or when deciding "is H...

Decide which installed skill or tool, if any, should own a task — a fit-ranking dispatch step at task starts and direction changes, not a per-message ritual. Use when starting substantive work that more than one installed capability could plausibly own, when unsure whether a discipline skill (TDD, debugging, data-contract guardrails) applies to the work at hand, when two skills seem to claim the same job, or when the user asks "which tool/skill should handle this". Ranks candidates against th...

Turn an agreed design or spec into a complete implementation plan and execute it task by task with fresh subagents and two-stage review — the midweight lane between direct implementation and a governed PR series. Use when a feature needs a multi-step plan with review checkpoints but not series machinery: 'write the implementation plan for this spec', 'execute this plan task by task', 'plan then build this', 'run docs/plans/<file>', or when work has outgrown a single TDD loop but doesn't warra...

Evaluate incoming review feedback technically before acting on it: read all items, restate or ask about anything unclear before implementing any of them, verify each suggestion against the actual codebase, push back with evidence when a suggestion is wrong for this code, and skip performative agreement entirely. Use when processing review comments from a human or an automated reviewer, when feedback seems technically questionable or context-blind, when a reviewer proposes 'implementing proper...

Review and update the choosing-models tier data. Run /refresh-models to detect lineup drift against the platform's current model list, read the release notes, and produce a reviewable changeset (models.toml lineup edits plus any guidance edits) for approval. Mechanical lineup changes are applied on approval; threshold and doctrine edits are never auto-applied without calibration evidence. Manual-only.

Author and revise Claude Code skills with calibrated trigger descriptions and eval-gated quality — the description is a trigger surface that competes on fit, not an advertisement that competes on volume. Use when creating a new skill, when an existing skill over- or under-triggers and the description needs rework, when adding negative space ("not for X — that is Y") or example trigger phrasings, when deciding whether a skill body is rigid (bright-line constraints) or flexible (judgment-delega...

Root-cause-first debugging in four phases — investigate (read the full error, reproduce, check recent changes, instrument component boundaries), pattern-match against working examples, test one hypothesis at a time, then fix the cause with a failing test. Use when any bug, test failure, or unexpected behavior lacks a proven cause, when a fix is being proposed before the data flow was traced, when the previous fix didn't work, especially under time pressure (guessing is slower than the protoco...

Red-green-refactor discipline for features and bug fixes: write one minimal failing test, watch it fail for the expected reason, write the least code that passes, refactor only on green. Use when implementing any feature or bugfix, when fixing a bug (the reproducing test comes first and the fix follows), when tempted to backfill tests after the code, or when a new test passes on its first run and therefore proves nothing yet. The bright line: production code is written only against a test you...

Maintain a persisted, re-readable control anchor so a long autonomous run survives context compaction without losing the plot — one file holding the mission, a plan pointer, a live cursor (done / in progress / next action), invariants, last-known-good state, and exact resume steps, updated after each step and re-read at the start of each turn. Use when starting or driving a multi-hour or multi-phase autonomous task, a self-driving loop, or any unattended run that will cross one or more automa...

Use when a body of captured journal entries from many sessions should be distilled into durable, higher-level guidance — cluster related entries, synthesize the one generalization each cluster supports, promote only the reinforced and specific ones into long-lived guidance, and reconcile supersession when newer evidence overrides older. Triggers on "consolidate my journals", "what patterns emerged across these sessions", "distill these notes into guidance", "what have we learned over time", "...

Author a paste-ready, self-contained brief that hands work to a fresh context — a new Claude Code session, a spawned task, a teammate, or an issue ticket. Use whenever current work must be packaged so a receiver with zero shared context can take it cold — "package this up for a fresh session", "bundle this for another agent", "write a standalone brief / a self-contained handoff", "spin this off", "hand this off", "offload this", "branch off", "new session for this", "author a persisted backlo...

Audit a large file corpus — dozens to hundreds of docs, configs, or mixed code-plus-docs-plus-tests — by fanning out blind reviewers over partitions, adversarially verifying every high-severity finding before acting on it, fixing in disjoint file partitions, and re-auditing with fresh eyes until the findings converge. Use when reviewing or auditing a whole repo's documentation, a release's doc set, an entire plugin or package, or any file set too large for one reader to hold at once; on asks ...

Use when you want to behaviorally evaluate a Claude Code skill — measure whether it auto-activates on the prompts it should and stays quiet on near-misses (trigger recall and specificity), whether its output actually satisfies its own discipline (correct-usage), and whether it beats the no-skill baseline (with/without) — producing a scorecard with confidence intervals. Triggers on "evaluate this skill", "test my skill", "does my skill fire", "measure or benchmark skill performance", "is my de...

Triage a tool's accumulated dogfooding feedback reports into a leverage-ordered improvement backlog — reconcile what already shipped, cluster findings by underlying cause rather than symptom, assign each cluster a disposition (attack this tool, route out to the tool that owns it, or decline), apply a promotion gate (reinforced across reports, specific, actionable), and emit a triage document with a status-tracked promotion table. Use on "triage the feedback backlog", "cluster the feedback rep...

Capture knowledge from a work or reference-reading session into structured, separable, retrieval-ready entries for a long-term memory store. Use when the user says "journal", "log this", "wrap up", "session summary", "capture what we learned", or "create registries for everything" — and equally on any request to preserve what was worked out for the future, even about one specific topic — phrasings like "record the decisions/dead ends", "note the reasoning", "don't lose this", "before I forget...

Sign agent-assisted work with a machine-generated provenance signature: an Assisted-By git trailer naming the exact model that wrote and orchestrated the change, and an Agent-Stack trailer naming the harness and plugin versions it ran on. Use when committing or writing a PR body in a project that adopts the signature, when asked to sign a commit with the model / add model attribution or an LLM signature, when asked which model or tool stack produced a change, or when replacing Co-Authored-By ...

Use when the user has iterated on a design, plan, spec, architecture, code, or prose over several rounds and can no longer judge it cleanly, before a high-stakes or hard-to-reverse decision, or when they ask for "fresh eyes", "a second opinion", "red team this", "poke holes in this", "sanity-check this independently", "am I anchored" / "too close to this", "critique this from different angles", or run "/review-panel". Prefer this over reviewing the artifact yourself — its value is convening f...

Write a per-session dogfooding feedback report for each registered in-development tool the session exercised — what worked, friction, misses with the phase that should have caught them, vacuous gates, and severity-tagged proposed changes with stable finding IDs — saved into that tool's own feedback directory. Use when the user asks for feedback on their tools ("write the feedback reports", "tooling feedback", "dogfood report", "capture the friction with keel / convoy") — a direct imperative n...

Know what skills, agents, commands, and hooks are installed in the current Claude Code environment, and reference them well in prompts and specs. Use when answering "what tools/agents/commands/hooks do I have" (including narrower inventory questions like which hooks are configured), determining which installed skill owns or is responsible for a given concern — a scoring rubric, a schema, project conventions — so you point at the owner instead of duplicating it, planning work that will run in ...