grimaldost
UserA Claude Code plugin marketplace that codifies engineering craft: disciplined Python and data-engineering practice alongside deliberate session-knowledge workflows, packaged as reusable skills.
Categories
Indexed Skills (26)
refresh-stack
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.
refresh-models
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.
consolidate-knowledge
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", "promote the durable insights", "synthesize my entries into wisdom", or running "/consolidate-knowledge". This is the downstream pass that journaling-sessions feeds — journaling captures raw entries one session at a time, this consolidates many of them across sessions. Not for capturing a single session (use journaling-sessions), not for a one-off summary, and distinct from consolidating your agent memory files.
evaluate-skill
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 description triggering", "build an eval for this skill", or running "/evaluate-skill". Claude Code only — it spawns many headless `claude -p` runs, so it is cost-gated; show the plan first. Not for a one-off manual spot-check, for judging a skill's design qualitatively (that is a fresh-eyes panel, not a behavioral eval), or for listing which skills are installed (that is toolkit-awareness).
feedback-triage
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 reports", "what should this tool fix next", "promote the recurring feedback", or "/feedback-triage". Explicitly invoked maintenance — never run proactively; it reads a whole corpus. If the tool's binding registers its own triage template (e.g. keel's reflection-triage), follow that template. Not for consolidating journal entries into guidance (that is consolidate-knowledge), not for a corpus of one report with no prior triage (nothing to cluster yet — a 1-report delta over an existing baseline IS a valid later pass), not for
review-panel
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 fresh reviewer subagents that are blind to this conversation and to each other, which a review you run while anchored on the same context cannot replicate. Requires spawning fresh-context reviewers (subagents where the harness has them; sequential clean contexts otherwise); always show the plan and rough cost and ask before firing. Not for a quick factual check, a single obvious answer, or a first-pass review of something just created.
tool-feedback
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 naming one tool ("write a dogfooding feedback report for keel") is this skill too, since writing that report IS the skill; route it here rather than drafting the report freehand — and offer once, unprompted, when a session that exercised a registered tool is winding down. Registered tools come from a feedback-targets registry the user supplies — a file at a known path, or a table in loaded context — never hunt the filesystem for targets. Design-only or authoring-only use of a tool still counts as use. Not for feedback on c
verification-before-completion
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 it pass). Claims match their evidence — 'tests pass' means this session's run with zero failures, not a previous run or an expectation; if verification fails, the deliverable is the actual state with output. Prefer wiring recurring checks into pre-commit or CI over re-remembering them. Not for designing what to verify (a test-strategy concern) — this skill governs the moment of claiming, not the shape of the suite.
data-engineering-discipline
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 data contract, reshaping a tool / API response payload a client depends on, writing or changing the tests, fixtures, or expected values that gate a pipeline, generating pipeline code with an LLM, and investigating a consumed dataset that misbehaves — "the numbers changed / look different", or a table/extract that "ran but didn't update / is stale / isn't refreshing / the watermark didn't advance". A hand-authored schema-as-data document counts when code is generated from or validated against it; not when its only consumer
python-engineering
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, testing, type checking, observability, security, async patterns, typing.Protocol, dependency injection, CLAUDE.md, or Cursor rules. Covers hexagonal architecture, functional core/imperative shell, property-based testing, snapshot testing, testcontainers, Trusted Publishers, and Sigstore.
experiment-rigor
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 that happened, separate confirmatory from exploratory outcomes, name the threats to validity, design the 2x2, or ask whether a skill, tier, model, or strategy actually helps and how you would show it rigorously. Covers the small-n refusal (no CLT below 30 — Wilson, Clopper-Pearson, or a within-experiment Beta-Binomial), the design-arithmetic reconciliation (declared cells == disposition == denominators), the plan freeze and its drift gate, the rate that needs both a numerator and a denominator, probe self-labeling, and recor
brainstorming
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 independent subsystems and needs decomposition before any single design is refined. Design before code holds for small work too — a simple project gets a proportionally short design, not an exemption. Hands the agreed design to the planning tool that owns execution (keel for governed series, plan mode or your orchestrator otherwise). Not for work already specified to execution level, and not for discussion turns where the user is thinking aloud and wants assessment rather than artifacts.
choosing-models
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 Haiku enough for this task?" / "which tier should this PR run at?". Scores the task with the bundled rubric, maps score to tier to current model via models.toml, then applies context modifiers (oracle coverage, reversibility, retry economics). Model facts — ids, prices, context windows, API mechanics — belong to the platform's model reference (e.g. the claude-api skill); this skill reads that data and owns only the task-to-tier routing policy. Not for choosing which skill owns a task (that is choosing-tools), not for toolk
choosing-tools
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 their descriptions' positive and negative triggers and loads one only when its expected benefit clearly exceeds its context and anchoring cost; exits in one line when nothing fits, and sets aside a loaded skill plainly when it turns out wrong. Pairs with toolkit-awareness, which answers what is installed — this skill decides whether and when to load it. Not for inventory questions (that is toolkit-awareness) and not for authoring or tuning skill descriptions (that is skill-authoring).
planned-execution
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 warrant keel or convoy. The plan contract is firm: bite-sized steps with exact paths, complete code, exact commands with expected output, and no placeholders — a zero-context engineer could execute it cold. The loop is firm too: per task, a fresh implementer subagent, then spec-compliance review, then code-quality review, re-reviewing after each fix. Not for deciding what to build (brainstorming comes first), not for governed multi-PR series with gates and dependency DAGs (keel and convoy own that), and not for small single-lo
receiving-code-review
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 properly' something nothing calls (grep usage first, propose removal), or when a reply is about to start with 'you're absolutely right'. Order of work: clarify everything, then blocking issues, simple fixes, complex fixes — testing each individually; a pushback that turns out wrong gets a one-line factual correction, not an apology. Not for performing a review of someone else's change (/code-review or review-panel) and not for triaging accumulated feedback reports into a backlog (feedback-triage).
skill-authoring
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-delegating guidance), or when porting a skill from an imperative register to a neutral one. Covers the calibration doctrine — dense concrete triggers, explicit non-triggers naming the owning sibling, plain-declarative bright lines, descriptive failure-mode catalogs without identity pressure, and the shipping requirement of a trigger dataset with sealed holdout plus a correct-usage rubric for rigid skills. The register linter mechanically enforces the detectable subset of the register rules (banners, caps runs, a fixed phrase li
systematic-debugging
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 protocol), and when three or more fixes have failed — treat that as an architecture signal and raise it with the user instead of attempting a fourth. The bright line: no fix before the root cause is identified with evidence; in multi-component systems, log what enters and exits each boundary before theorizing. Hands the reproducing test to test-driven-development and the resolution claim to verification-before-completion. Not for changes whose cause is already proven (just fix them) and not for performance tuning without a defec
test-driven-development
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 have watched fail; code that preceded its test is deleted and redone test-first, because adapting it quietly converts test-first into test-after. Exceptions — throwaway prototypes, generated code, pure configuration — are agreed with the user, not self-granted. Hands red-green evidence to verification-before-completion. Not for designing suite architecture or coverage strategy, and not for diagnosing an unexplained failure (systematic-debugging owns diagnosis and returns here for the fix).
compaction-survival
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 automatic compactions or context-window resets; on asks like "make sure compaction doesn't lose the work", "keep state across auto-compact", "persist the current state so a reset doesn't disrupt this", "this is a long autonomous run", or "resume cleanly after a reset". The anchor is intra-actor state recovery — the same actor re-reading its own working state across a discontinuity. Not for handing work to a fresh context or a teammate (that is context-handoff's inter-actor brief), not for post-hoc capture of what a finished ses
context-handoff
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 backlog / worklist doc for a future session", "subtask", "fork", "spinoff" — when curating a context slice to continue or delegate work elsewhere, or running "/context-handoff". Three modes — SUBTASK (bounded brief, an artifact comes back), FORK (continues independently, nothing returns), and BACKLOG (a persisted repo doc a future session opens to pick up any item). For in-session parallel work where results flow back automatically, prefer the Task tool / subagents — this skill is for handoffs that cross a boundary the harness
corpus-review
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 like "review all the docs before we push", "audit the whole repo for X", "blind review across these N files", "do a pre-push review of everything", or "check the docs still match the code across the project". It orchestrates the audit on the harness's parallel subagent and workflow primitives and ships no engine of its own. Not for a fresh-eyes panel on a single design, spec, or artifact (that is review-panel), not for reviewing one change's diff for bugs and regressions (that is a diff review / code-review), and not for
journaling-sessions
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", "so next time we don't relitigate", "so a future session benefits". Activate proactively when a substantive session is ending after 3+ decisions, findings, or ingested reference items. Covers implementation/decision sessions and end-to-end reference ingestion. Not for quick Q&A or sessions with no novel knowledge; not for consolidating prior journals into higher-level patterns (that is a separate downstream pass).
llm-signature
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 AI boilerplate with provenance trailers. The signature is rendered by a script from live sources, never typed from memory, and the model is listed only in Assisted-By — never as a commit co-author. Not for human authorship credit (real co-authors keep their Co-Authored-By lines).
toolkit-awareness
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 Claude Code, or writing a task spec or definition-of-done that should reference slash commands or quality gates. Produces a live inventory via a scan script rather than relying on a hand-maintained list.
convoy
Two separable capabilities, dispatched separately. (1) Execute an already-settled plan of two or more PR-sized changes as a governed, measured series — a coding agent driven through each task in dependency order under a per-phase budget, each result gated deterministically, repaired on a red gate, the green branches integrated, and a per-spawn economy plus gate summary read back. The trigger is the plan, not convoy's own file: use when a spec, plan or PR manifest already names two or more PR-sized changes; when a wave is about to be implemented PR by PR and someone will want to price or audit it; when the work is hours nobody intends to sit through; when a series.toml exists, or wants scaffolding with `convoy_init`. (2) The deterministic gate STANDALONE — `convoy gate` / `convoy_gate` run a series' checks against a workspace once, no spawn, no orchestration: use whenever work is implemented outside convoy (direct agents, subagent dispatch, a hand-written branch) and its verification should not be the implemen
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.