RyanMKrol
UserRyan Krol's personal Claude Code plugin marketplace — incl. ralph-harness (per-task-model, CI-gated autonomous build loop).
Categories
Indexed Skills (16)
implementation-harness-fix-scope-gaps
Internal fix-side companion to `implementation-harness-pre-loop-checkin`'s check (e) — invoke this when a pre-loop-checkin report (or the owner directly) flags scope-authoring WARNs from `check-task-scope.sh` and wants them triaged. Not meant to be run blind/standalone without a reason — it's the follow-up step after warnings are already known. Fans out one cheap-model subagent per WARN to independently judge real-gap vs false-positive against the spec's own prose, auto-applies confident real gaps to that task's `scope` array, and asks the owner only about genuinely ambiguous cases. This MUTATES `.harness/tracking/TASKS.json` (scope arrays only) and pushes to main. Requires the harness scaffolded.
implementation-harness-create
Use when the user wants to set up the autonomous implementation harness (the Ralph-style single-loop TASKS.json builder) in a project ��� phrases like "scaffold the harness", "add the build loop to this repo", "set up the implementation harness", "install loop.sh / supervise.sh". Runs a short interview (project name, purpose, stack, the format/lint/test/build Definition-of-Done commands, build artifacts, CI workflow name, cold-start difficulty floor (cheapest tier), optional empirical run/backtest check), copies the verbatim harness files in, and writes the personalized CLAUDE.md, ci.yml, .gitignore, harness.env, README.md, and an initial TASKS.json. Leaves the project ready to run .harness/scripts/supervise.sh.
implementation-harness-customize
Use when the user wants to discover and set up the implementation harness's customization features — phrases like "customize the harness", "what can I customize", "set up the hooks / guard / preambles", "harness feature walkthrough", "implementation-harness:implementation-harness-customize". Walks the `custom/` extension-point catalog one feature at a time: explains each, and for the ones the user wants, activates the opt-in file (.example → real) and helps DRAFT its content. Also invoked by create (all features) and upgrade (only features new since the install) so users always meet the features. Requires a scaffolded `.harness/`.
implementation-harness-evaluate-fit
Use when the user wants to check whether an already-installed harness is well-tuned to THIS project and fix any mismatches — phrases like "evaluate the harness fit", "does the harness suit this project", "check in on the harness", "tune the harness to the project", "the facets/floor look wrong for this repo", "/evaluate-fit". Runs a full multi-agent DEEP DIVE of the project (stack, module structure, risk profile, deploy/notify story, secret + visual surfaces), reads the CURRENT harness config, then produces ranked, evidence-backed recommendations across the ONLY customizable surfaces — the `custom/` overlay, `harness.env` knobs, and `facets.json` (`layer` vocabulary + `policy`) — and, on your approval, applies them. It NEVER edits harness mechanism (scripts/docs/dashboard) — an install stays fork-free and upgrade-clean. Ideal after a harness was scaffolded against an empty/young repo, or after the project has grown. Requires a scaffolded `.harness/`.
implementation-harness-report-issue
Use when the user wants to report a bug or problem with the implementation-harness PLUGIN itself — phrases like "report a bug", "file an issue", "something's wrong with the harness", "the loop is broken / crashing", "report this upstream", "/report-issue". Captures the current session context, auto-detects the environment (plugin version, loop variant, bash/OS, tool presence), pushes the user for logs / terminal output, scrubs secrets, does a quick real-bug-vs-misconfiguration plausibility check, shows the FULL draft, and only on explicit confirmation files a GitHub issue on the plugin's home repo (RyanMKrol/claude-skills) via `gh`. Works with OR without a scaffolded `.harness/`. NOT for the user's own project backlog (use capture-idea / add-to-backlog) — this reports the harness itself.
implementation-harness-upgrade
Use when a project already has an installed `.harness/` and the user wants to pull in newer harness changes shipped by this plugin — phrases like "upgrade the harness", "update my harness", "pull in the latest harness changes", "is my harness up to date", "/upgrade-harness". Reconciles the installed `.harness/` against the plugin's bundled reference: refreshes plugin-owned mechanism files and adds new `harness.env` knobs, REPORTING first and asking before every change, and NEVER touching the backlog, worklog, ledgers, or the user's config values. Commits AND PUSHES the result by default once applied — unless told otherwise this conversation or by the project's own CLAUDE.md, in which case it leaves the change uncommitted as before. Also ADOPTS legacy or hand-forked installs (no version marker, hand-maintained since install, or a pre-plugin hand-ported harness) — classifying each difference as plugin-newer vs local-bespoke vs conflict before anything is overwritten. Requires a harness already scaffolded (use i
implementation-harness-add-to-backlog
Use when a project already has the implementation harness (.harness/docs/HARNESS.md, .harness/scripts/loop.sh, .harness/tracking/TASKS.json present) and the user wants to draft or extend the task backlog — phrases like "add tasks", "write the backlog", "turn this feature into tasks", "plan the next phase for the loop". Runs a focused interview that turns a feature description into atomic, dependency-ordered .harness/tracking/TASKS.json task objects following the HARNESS.md §8.1 schema (dependsOn / scope / design / verify / facets + a per-task `spec` Markdown file), with difficulty auto-tuned from facets, gate / needs-human markers, appended without disturbing existing tasks.
implementation-harness-capture-idea
Use for a quick, zero-ceremony capture of a feature idea, bug report, or improvement into the project's ideas inbox — phrases like "note this idea", "add this to the ideas list", "capture this for later", "/idea ...". Does NOT interview, decompose, or touch TASKS.json — it just appends one JSON row to .harness/tracking/IDEAS.jsonl (a committed inbox) for a later implementation-harness-convert-ideas sweep. Requires the implementation harness to already be scaffolded (.harness/docs/HARNESS.md present).
implementation-harness-convert-ideas
Use when the user wants to process the ideas inbox (.harness/tracking/IDEAS.jsonl) into real TASKS.json backlog tasks — phrases like "convert the ideas", "process the ideas inbox", "turn the ideas into tasks", "/convert-ideas". Sweeps the WHOLE inbox at once: dedupes near-duplicate ideas, converts each idea (or cluster) in PARALLEL via one sub-agent each, relays any genuine open questions back through a real AskUserQuestion, then runs a single locked consolidation pass that allocates real task ids, writes per-task specs, and removes converted ideas from the inbox. Requires the implementation harness to already be scaffolded.
implementation-harness-loop-prepare
Use when the user wants to get the harness ready for the NEXT unattended loop run in ONE command — phrases like "prepare the loop", "set up the next run", "get the backlog ready to run", "/loop-prepare". Chains the existing skills IN ORDER, inline in this conversation: review-failed (only if the last run left failed/blocked tasks) → convert-ideas (only if the ideas inbox has rows) → pre-loop-checkin (always) → fix-scope-gaps (only when the check-in WARNs and the owner says yes). Every sub-skill runs FULLY — all of its questions and guardrails — nothing is streamlined away. Ends at the GO/NO-GO verdict; it NEVER starts the loop. Requires the harness scaffolded.
implementation-harness-loop-recover
Use to recover the autonomous build loop after it was MANUALLY interrupted (Ctrl-C / killed) and may have left inconsistent state behind — phrases like "the loop got interrupted", "clean up after the loop", "recover the harness", "/loop-recover". Diagnoses AND fixes orphaned tasks, stale locks, a dirty tree / leftover loop worktree, revert-cycle damage, and ledger noise, then leaves the loop restartable. This MUTATES committed state (TASKS.json status, outcomes.jsonl) and pushes to main — it does the correcting the stopped loop can't. Requires the harness scaffolded.
implementation-harness-pre-loop-checkin
Use for a read-only GO/NO-GO check of the harness backlog BEFORE starting an unattended loop run — phrases like "is the backlog ready to run", "check before I start the loop", "pre-flight the harness", "/pre-loop-checkin". Reports needs-human blockers, session hygiene (dirty tree / running loop / lock), dependency short-circuits, and per-task definition quality (facets, spec, scope), then a plain GO / NO-GO verdict. Strictly READ-ONLY — it never edits, commits, or pushes anything. Requires the harness scaffolded.
implementation-harness-review-failed
Use when the user wants to review the harness's failed or blocked backlog tasks and turn what went wrong into better-specified follow-up tasks — phrases like "review the failed tasks", "why did these tasks fail", "fix the blocked backlog items", "/review-failed". Sweeps every task with status "failed" (owner overturned a false success) or "blocked" (the loop gave up) that hasn't already been reviewed, one investigation sub-agent per task in parallel, then a single locked consolidation pass that authors the follow-ups, closes out every reviewed "blocked" task (via mark-failed.sh) so it stops sitting in the dashboard's Human Tasks bucket forever, AND marks every investigated task reviewed (tracking/reviews.json) so a future sweep never re-investigates it. Reuses the ideas-pipeline machinery (consolidate-ideas.sh + the pending-tasks / pending-questions relay); never touches IDEAS.jsonl. Requires the harness scaffolded.
implementation-harness-update-ladder
Use when the user wants to add, swap, or remove a rung on this project's difficulty/tier ladder — phrases like "add a model to the ladder", "update the tier ladder", "add haiku to the ladder", "change the escalation ladder", "/update-ladder". Interviews for which model and whether it's a SWAP (replace a model at a fixed position) or an INSERT/REMOVE (changes rung count, shifts positions), handles models with no effort parameter (e.g. Haiku) via `effort: null`, and walks the correct migration path for each — the "Bumping the base model" runbook for a swap, or a no-ledger-migration note for an insert/remove (plus a reminder to raise `exploreProbabilityPM` so a newly inserted rung doesn't sit inert on already-calibrated work, and `exploreCooldownN` so a rejected rung eventually gets rechecked instead of staying excluded forever). Requires the harness scaffolded, and harness version >= 1.45.0 for the effort-less-rung path / >= 1.47.0 for downward exploration / >= 1.48.0 for the recheck cooldown (older installs do
go
Use when the user wants to update all their Claude Code marketplaces and plugins in one go — phrases like "update my plugins", "update all my marketplaces", "refresh my plugins", "sync my plugins", "freshen up my plugins", "/freshen-up:go". Runs `claude plugin marketplace update` (refreshes every configured marketplace from its source) then `claude plugin update` for every currently-installed plugin, via the `claude` CLI's own scriptable subcommands — NOT the interactive `/plugin` session commands, which have no bulk "update all" option. Reports exactly what changed version. Does nothing else — no project files touched, no other side effects.
build
Build a rich Anki deck for one lesson of a "Japanese for Busy People" textbook from a USER-PROVIDED EPUB. Use when the user asks to build/redo a JBP lesson deck — e.g. "build lesson 2", "make the Anki cards for lesson N of Japanese for Busy People", "do the next JBP lesson", "rebuild lesson X". The user MUST supply the textbook EPUB (nothing about its location is hard-coded). Extracts vocabulary, Word Power sets, Key Sentences, and grammar example sentences; crops textbook illustrations onto cards; writes kana, romaji, and usage hints; then presents an AUDIT TABLE for review. A SECOND phase generates per-card audio with ElevenLabs TTS (kana → MP3) once the content is approved and a voice is chosen.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.