All authors

Claude Skills by grimaldost
github.com/grimaldost29 skills0 installs47 views
- Specs- **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_sealore_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}...Votes: 0GitHub stars: 2
- Verification Before CompletionEvidence 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...Votes: 0GitHub stars: 2
- FixturesUse 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".Votes: 0GitHub stars: 2
- Data Engineering DisciplineDiscipline 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 ...Votes: 0GitHub stars: 2
- Python EngineeringModern 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...Votes: 0GitHub stars: 2
- Refresh StackReview 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.Votes: 0GitHub stars: 2
- Experiment RigorStructure 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...Votes: 0GitHub stars: 2
- BrainstormingTurn 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...Votes: 0GitHub stars: 2
- Choosing ModelsChoose 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...Votes: 0GitHub stars: 2
- Choosing ToolsDecide 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...Votes: 0GitHub stars: 2
- Planned ExecutionTurn 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...Votes: 0GitHub stars: 2
- Receiving Code ReviewEvaluate 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...Votes: 0GitHub stars: 2
- Refresh ModelsReview 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.Votes: 0GitHub stars: 2
- Skill AuthoringAuthor 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...Votes: 0GitHub stars: 2
- Systematic DebuggingRoot-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...Votes: 0GitHub stars: 2
- Test Driven DevelopmentRed-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...Votes: 0GitHub stars: 2
- Compaction SurvivalMaintain 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...Votes: 0GitHub stars: 2
- Consolidate KnowledgeUse 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", "...Votes: 0GitHub stars: 2
- Context HandoffAuthor 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...Votes: 0GitHub stars: 2
- Corpus ReviewAudit 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 ...Votes: 0GitHub stars: 2
- Evaluate SkillUse 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...Votes: 0GitHub stars: 2
- Feedback TriageTriage 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...Votes: 0GitHub stars: 2
- Journaling SessionsCapture 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...Votes: 0GitHub stars: 2
- Llm SignatureSign 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 ...Votes: 0GitHub stars: 2
- Review PanelUse 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, before handing a design, assessment or recommendation you wrote to someone who will act on it, 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 r...Votes: 0GitHub stars: 2
- Tool FeedbackWrite 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...Votes: 0GitHub stars: 2
- Toolkit AwarenessKnow 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 ...Votes: 0GitHub stars: 2
- Verification Before CompletionEvidence 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...Votes: 0GitHub stars: 2
- ReferencesUse with, or in place of, the default quartet; rename to the specific skill. Fire on the assembled skill (description, body, references, scripts) rather than on one edit, so the lenses can judge how the parts fit. - **Trigger-surface auditor** — read the description as the only thing a router sees. Does it fit the work the skill does, with positive triggers that name real phrasings and negative triggers that name the near misses? Which sibling skills collide with it, and which one wins on an ...Votes: 0GitHub stars: 2