Rustyrazorblade Skills

A plugin marketplace by Jon Haddad.

Installation

Claude Code

/plugin marketplace add rustyrazorblade/skills

Then install whichever plugins you want:

/plugin install cassandra-expert@rustyrazorblade-plugins
/plugin install easy-db-lab@rustyrazorblade-plugins
/plugin install spec-flow@rustyrazorblade-plugins
/plugin install dev-skills@rustyrazorblade-plugins

Codex

codex plugin marketplace add rustyrazorblade/skills

Codex exposes skills through $ mentions instead of slash commands. cassandra-expert and easy-db-lab ship Codex manifests; spec-flow is Claude Code only (it depends on Claude Code agents and the Workflow runtime). dev-skills is Claude Code only too for now.

Available Plugins

cassandra-expert

Expert guidance for Apache Cassandra development and operations.

Claude Code:

/plugin install cassandra-expert@rustyrazorblade-plugins

Codex CLI:

Install cassandra-expert from the plugins section:

/plugins

Skills

Skill	Purpose
/cassandra-expert:diagnose	Systematic troubleshooting using USE method, outlier analysis, double loop learning
/cassandra-expert:optimize	Performance tuning, configuration analysis, JVM settings, compaction strategies
/cassandra-expert:data-model	Schema design, partition keys, time-series modeling, query patterns
/cassandra-expert:token-skew	Token ownership skew analysis using correct per-rack metric
/cassandra-expert:training	Interactive, session-based Cassandra training from fundamentals to advanced topics

Agent

The plugin also ships a cassandra-expert agent for open-ended questions that don't fit a specific skill — CQL review, replication, repair, cluster operations, troubleshooting. It reads the bundled references rather than its training data, and it will establish your exact Cassandra version before giving any guidance, because the right answer differs across 4.0, 5.0, and 6.0 (incremental repair on 3.x and UCS on 4.x are the kind of version-blind advice it exists to prevent).

Usage Examples

Diagnose - Troubleshooting Issues

/cassandra-expert:diagnose Read latencies spiking on some nodes but not others
/cassandra-expert:diagnose Compaction can't keep up with writes

Optimize - Performance Tuning

/cassandra-expert:optimize Review my cassandra.yaml settings
/cassandra-expert:optimize What compaction strategy should I use?

Data Model - Schema Design

/cassandra-expert:data-model Design schema for user activity tracking
/cassandra-expert:data-model How should I model time-series data with 90-day retention?

Token Skew - Ownership Analysis

/cassandra-expert:token-skew Analyze this nodetool ring output for data imbalance
/cassandra-expert:token-skew nodetool status shows uneven Owns percentages — is this real?

Training - Interactive Learning

/cassandra-expert:training
/cassandra-expert:training Session 2: Query & Application Anti-Patterns
/cassandra-expert:training LWT         # general topic — matches across sessions
/cassandra-expert:training compaction  # multiple matches: the trainer offers options

For a general topic like LWT or compaction, the trainer lists every session/topic that matches and lets you pick one or say all to go through every match.

Problem-Solving Methodology

• Double Loop Learning - Goes beyond immediate fixes to identify root causes and prevent recurrence
• USE Method - Systematically analyzes Utilization, Saturation, and Errors for CPU, memory, disk, network, storage, and thread pools
• Outlier Analysis - Compares nodes to identify anomalies in latency, resource usage, and behavior
• Configuration Analysis - Reviews system settings, cassandra.yaml, JVM settings, and per-table configurations

Training Sessions

Interactive, instructor-led Cassandra training with pulse checks after each topic:

Session	Topics
Session 1: Fundamentals	Data distribution, keyspaces, types, primary keys, partition storage, collections, UDTs, DML, read/write paths, tombstones, TTL, table options, table patterns (single-key, ordered-map, time-series), batches, LWT, compaction overview, denormalization, prepared statements, consistency levels
Session 2: Query & Application Anti-Patterns	IN() queries, ALLOW FILTERING, token range queries, BATCH misuse, lightweight transactions, counters, in-memory joins, synchronous queries, excessive async, in-memory sorting, aggregations, triggers
Session 3: Schema Anti-Patterns	Huge partitions, hot partitions, too many tables, too many columns, materialized views, unbounded collections, lists, secondary indexes, compaction strategy, large blobs
Session 4: SAI	What SAI is and the partition key rule, creating and managing indexes, querying patterns, SAI vs. denormalization, SASI migration

Claims the training makes about what Cassandra actually accepts or rejects are backed by executable verification scripts in plugins/cassandra-expert/skills/training/scripts/, which run against a live cluster and exit non-zero if any claim no longer holds.

Key Recommendations

Opinionated guidance based on real-world experience:

• num_tokens: Use 1 or max 4. Higher is always worse.
• Compaction: UCS on Cassandra 5.0+ — there is no case where STCS is the right choice once UCS exists.
• Read-ahead: Disable it. One of the worst settings you can have enabled.
• Partitions: Keep under 10MB. No downside to smaller partitions.
• Row cache: Keep disabled. Rarely beneficial.

easy-db-lab

Provision and operate AWS lab environments with Cassandra, ClickHouse, Spark, OpenSearch, and installable kits.

Claude Code:

/plugin install easy-db-lab@rustyrazorblade-plugins

Codex CLI:

Install easy-db-lab from the plugins section:

/plugins

Skills

Skill	Purpose
/easy-db-lab:explore	Start here — interactive guided session that provisions an environment if needed, then helps you run tests and explore the cluster
/easy-db-lab:plan	Interactively design a lab workflow and write it to a plan.md
/easy-db-lab:run	Execute a plan step by step in a cluster workspace, confirming each step and journaling as it goes
/easy-db-lab:create-kit	Author a new kit (kit.yaml, K8s manifests, metrics, dashboards, docs) for any database or workload

Agent

An easy-db-lab operator agent handles live-cluster work that isn't a scripted plan — provisioning, configuring, benchmarking, and tearing down clusters via the easy-db-lab binary. Note that Grafana and the rest of the observability stack are only reachable over Tailscale, so the operator always hands you private IPs; public IPs will not work.

Usage Examples

/easy-db-lab:plan benchmark Cassandra 5.0 vs 4.1
/easy-db-lab:plan tune UCS --previous tests/clusters/20240530-143022
/easy-db-lab:run tests/clusters/20240530-143022
/easy-db-lab:run plan.md tests/clusters/20240530-143022 --binary ./bin/easy-db-lab
/easy-db-lab:create-kit valkey

explore takes a free-form topic, or nothing at all:

/easy-db-lab:explore
/easy-db-lab:explore cassandra 5.0
/easy-db-lab:explore clickhouse analytics

Notes

• Skills run from a lab workspace directory; explore will walk you through easy-db-lab init --up if none exists
• Each DC in a multi-DC setup gets its own subdirectory and binary wrapper (<cluster-dir>/dc1/easy-db-lab) with independent state
• plan writes to plan.md in the current directory unless --output says otherwise; run reads the plan from <cluster-dir>/docs/plan.md
• Every command and observation is journaled to <cluster-dir>/docs/journal.md as it happens, and friction is logged to docs/issues.md — this is what lets run resume a plan and plan --previous learn from a past run

spec-flow

A session-driven, multi-agent delivery pipeline over OpenSpec + GitHub. You own the two seams a human should own — defining/prioritizing the work, and final review + merge — and the middle (spec → implement → review → fix → build → docs → PR) runs as agents you invoke turn-by-turn.

Claude Code only:

/plugin install spec-flow@rustyrazorblade-plugins

The pipeline

groom ─▶ activate ─▶ [SEAM 1: you approve the spec] ─▶ implement ─▶ [SEAM 2: you review + squash-merge] ─▶ finalize
  │          │                                              │
refine     design                                  5-lens review panel
(product)  (architect)

Seam 1 — activate stops after committing the OpenSpec change. Nothing is implemented until you approve, and this is where every significant design decision gets made: the architect agent lays out options and trade-offs, and you decide.

Seam 2 — the pipeline only ever pushes the issue branch and opens a PR. It never merges and never pushes to main. You review in GitHub, optionally loop through address, and squash-merge yourself.

Skills

Skill	Purpose
/spec-flow:groom	Rough idea → scoped, labeled GitHub issue (scope, testable acceptance criteria, one P0–P3), refined over as many product-manager rounds as it takes
/spec-flow:activate <N>	Worktree + branch → OpenSpec explore+propose → commit spec → stop for your approval (Seam 1)
/spec-flow:implement <N>	After approval: open a draft PR early (keeps CI warm), run the background team (tdd-developer → 5-lens review panel → fix loop → build-engineer → docs) pushing at checkpoints, then mark the PR ready
/spec-flow:address <N>	Pull your PR review comments → fix in the worktree → push → reply per thread
/spec-flow:sync-ci <N>	When CI goes red: pull the failing tests into the branch's local flagged set so the fast local loop guards them until merge
/spec-flow:board	One view of every in-flight issue: stage, priority, PR/CI state, what's next, what's blocked on you
/spec-flow:finalize <N>	After you squash-merge: sync + archive the OpenSpec change, remove the worktree, close the issue
/spec-flow:adopt-tiering	One-time per repo, only where the repo's own policy chooses that split: separate an existing suite into a fast unit tier and a slow integration tier, then open a PR

If the standalone dev-skills plugin is also installed, set SPEC_FLOW_SEAM_VIEW=explain (via /spec-flow:setup) to have activate/implement render both owner seams as an interactive HTML view instead of plain text — see Seam visualization in docs/workflow.md.

Agents

The project-manager is the agent you talk to directly — it runs the board, tracks work in flight, decides what's next, and delegates each stage to the skills and specialists. It coordinates; it never implements and never crosses your two seams.

Agent	Role
project-manager	Orchestrator. Runs the board, decides what's next, delegates every unit of work
product-manager	Refines a rough idea into scope + testable acceptance criteria (consulted once per refinement round during groom)
architect	Turns the refined idea into a design, with trade-offs framed as owner decisions (consulted during activate)
tdd-developer	The implementer. Test-first (red→green→refactor), SOLID
build-engineer	Gets the build clean (format/lint/build), adapting to the project's tooling

Three more agents — reviewer, test-rigor-reviewer, and observability-reviewer — make up three of the five review lenses below.

tdd-developer picks up the bundled style guide matching the project's language (Rust and Kotlin ship today, in plugins/spec-flow/references/) and holds itself to it. tdd-developer and build-engineer are deliberately general-purpose bases: grow them in place with per-language and per-framework practice, and every repo using the plugin inherits the improvement.

The 5-lens review panel

During implement, review is not one reviewer. Five lenses run in parallel each round, their findings merge into one set, a fix round addresses every blocker/major from any lens, and approval requires every lens to approve with no must-fix findings.

Lens	Asks
reviewer	Does the implementation match the spec and the repo's own documented rules? Every #### Scenario: must have a backing test
/code-review	Correctness bugs: logic, boundaries, error paths, concurrency, resource leaks
/security-review	Input validation, auth, injection, secret exposure (self-gates when the diff touches no security surface)
test-rigor-reviewer	Are there antagonistic, regression-exposing tests over the public surface and its observable side effects?
observability-reviewer	Are the new code paths and failure modes diagnosable in prod? No silent failures, no secrets in telemetry

To add or remove a lens, edit the reviewLenses array in skills/implement/implement.workflow.js — the merge/approval loop generalizes over N lenses.

Setup

The consuming repo must provide the two backbones, and state its own test/CI policy:

• OpenSpec — the openspec CLI installed and initialized in the repo
• GitHub — gh authenticated, repo hosted on GitHub
• jq — on PATH. groom builds its create-issue payload with it, and three of the plugin's scripts parse gh output with it. There is no fallback if it's missing.
• spec-flow/TESTING.md — this repo's own test and CI policy. The plugin ships no default and no fallback, so nothing runs until the file exists. /spec-flow:setup proposes one, confirms it with you, and opens a PR. Add .spec-flow/ to .gitignore (per-branch runtime state) and never spec-flow/ — one character apart, opposite meanings, and a trailing-slash pattern with no interior slash matches at any depth, so the undotted form would swallow nested directories of that name too.
• Labels — bootstrap the P0–P3 and status:* vocabulary once per repo (idempotent, safe to re-run). Run it with your cwd inside the target repo, pointing at the script in the plugin:

  bash /path/to/spec-flow/bin/bootstrap-labels.sh

The /code-review and /security-review lenses use Claude Code's built-in skills of the same name; if they aren't available, those lenses degrade to an inline pass.

To land in the PM by default, set it in the consuming repo's .claude/settings.json:

{ "agent": "project-manager" }

The plugin deliberately ships no root settings.json with an agent field — that would hijack the main thread of every project that installs it. Opting a repo in is your choice, per repo.

Naming (1:1:1:1)

Every stage can recover the others from the issue number alone:

GitHub issue  #N  (slug derived from the title)
git branch        issue-N-slug
git worktree      .claude/worktrees/issue-N-slug
OpenSpec change   slug
pull request      body contains "Closes #N"

Worktrees are long-lived — one per issue, across many stages and sessions — so several issues can be in flight at once. /spec-flow:board reports across all of them.

An issue's stage is carried entirely by its label, so any session can pick up where the last one left off:

status:  ready ──▶ spec-review ──▶ in-progress ──▶ in-review ──▶ addressing ──▶ (merged)
          groom      activate        implement      (PR open)      address       finalize
                   + YOU approve                   + YOU review    ⟲ loop      + YOU merged

"What's next" is simply the highest-priority issue carrying status:ready.

Notes

• Session-driven, not cron. implement runs as a background Workflow that notifies on completion, but it's in-session — closing the session pauses the work. address is invoked by you when you return; nothing polls.
• Test policy — the repo's, never the plugin's. spec-flow ships no default and falls back to nothing. The consuming repo states what runs locally, what runs in CI, whether CI is a test gate at all, and what gates merge, in its own spec-flow/TESTING.md; implement hands every agent a pointer at that file and reports the exact commands that ran. A repo with no test suite and no test-running CI is a valid policy, not a degraded one. /spec-flow:setup seeds the file, and every entry point stops with a message naming the fix until it exists.
• Issue and PR numbers always carry a description — #85 (field identity), never a bare #85.

Overriding a bundled agent

Agents resolve bare-first with a namespaced fallback: the workflow tries reviewer before spec-flow:reviewer. If your repo defines an agent with the same name in .claude/agents/, yours wins — a deliberate way to specialize a reviewer or the developer for a repo's stack.

See plugins/spec-flow/docs/workflow.md for the full design.

dev-skills

Language developer agents plus generic development skills. Standalone; useful in any repo, with or without spec-flow.

Agents

Agent	Purpose
rust-dev	Rust developer. Reads the bundled Rust style guide, works test-first with a stated escape hatch, and runs nextest with a token-frugal recipe
cargo	Cargo expert. Owns Cargo.toml, workspaces, features, profiles, dependencies, MSRV, and .config/nextest.toml. Never writes application or test code

java-dev, kotlin-dev, and gradle join them later.

Skills

Skill	Purpose
/refactor [target]	Behavior-preserving change, in any language. Produces a plan you approve, then holds the calling agent to a standing contract: triage a failing test from the spec, never edit it to go green, revert instead of grinding
/tech-debt [path]	Repo-wide structural audit: review agents find SOLID, duplication, and layering problems, rank the 10 most impactful, drop anything already an open issue, and walk you through the rest one at a time. You decide per finding whether to file it
/ide-explain <issue-N | base-ref> [docs...]	Render an IDE-style HTML view — an issue with its comments and linked issues, a diff, docs, or any combination
/walkthrough [what to walk through]	Render a diagram-first, ordered-step presentation — how something works, a tech-debt review, recommendations, a performance analysis
/prose-review [target] [--fix]	Grade comments, commit messages, PR descriptions, and release notes against prose-style.md. Reports by default; edits only with --fix

ide-explain and walkthrough render one self-contained HTML page each: no server, no CDN, opens over file://.

Claude Code:

/plugin install dev-skills@rustyrazorblade-plugins

Working with spec-flow

The two plugins pair, one-directionally. dev-skills has no dependency on spec-flow.

• Set SPEC_FLOW_DEVELOPER_AGENT=rust-dev and /spec-flow:implement spawns rust-dev instead of its own bundled tdd-developer. Leave it unset and spec-flow behaves exactly as it did before.
• Set SPEC_FLOW_SEAM_VIEW=explain (via /spec-flow:setup) and activate/implement call ide-explain at both owner seams. See Seam visualization in plugins/spec-flow/docs/workflow.md.

See plugins/dev-skills/skills/ide-explain/SKILL.md and plugins/dev-skills/skills/walkthrough/SKILL.md for the full CLI and manifest schemas.

License

Apache 2.0