Skip to content

coryking/coryking-plugins

Repository files navigation

coryking-plugins

A Claude Code marketplace for people who drive a fleet of agents and want to know what the hell those agents actually did.

Three plugins, one install command. The one I get the most mileage out of, by a mile, is cc-explorer — my window into the pile of Claude Code transcripts I'd otherwise never read back. I use it to:

  • Carry session context across conversations — pull what one session knew into wherever I'm working now.
  • Run design and code reviews with a session that lived the work — clone a past session into a subagent and put it on the review.
  • Mine my chat history for insights and data — find the decision, the realization, the moment things turned, even when I've forgotten which project it happened in.
  • Watch how agents actually use the tools I write — see which MCP tools land, which fail, and where a subagent went sideways.
  • Interrogate old sessions instead of grepping their transcripts — ask a past conversation what it meant, not just what it said.

The rest of the toolbox grew out of the same itch: tools to mine a project's history for evidence, to review the code these agents write, and to write better MCP servers.

/plugin marketplace add coryking/coryking-plugins

That registers the marketplace. Then enable whichever plugins you want (/plugin). Jump to Install for the full path — including the one env var the session-interrogation feature genuinely needs.


What's in the box

Plugin What it's for The headline thing
project-mining Read your own history back cc-explorer (the star) + an evidence-mining orchestrator + an attention-reflection report
engineering-loop Review code before you ship it Parallel multi-persona code review, slimmed down for solo work
mcp-authoring Write MCP tools the model actually picks up An opinionated reference on tool descriptions

cc-explorer ships inside the project-mining plugin, but it's the headliner — enable that plugin for cc-explorer alone and ignore the rest if that's all you want.


cc-explorer — talk to your chat history instead of grepping it

The big one. The tool I get the most mileage out of, period.

cc-explorer is a FastMCP server that parses the JSONL conversation logs in ~/.claude/projects/ and exposes them as MCP tools. When the plugin is enabled, Claude Code starts it automatically — the tools just show up in the palette, no shell commands, no pip install, uv handles the deps.

Here's the thing about chat history: keyword search finds what was said, but the thing you actually want is usually why. Those are different problems. cc-explorer is built for both.

Find a conversation when you've forgotten where it happened. Search every project at once — worktrees flattened, subagent bodies included — narrow to a session, read the exact turn at full fidelity. The progression is search_projectsgrep_sessionread_turn, coarse to fine. I reach for this constantly with questions like "when did we realize the cat-gym was hollow?" — a why question that plain grep keeps whiffing on because the realization never used the words I'd search for.

See what your subagents actually did. This is the part nobody else gives you. list_session_agents shows every agent a session dispatched; get_agent_detail hands you one agent's full prompt, result, and tool trace; audit_session_tools rolls up per-tool counts, error rates, and retries across the whole session so you can answer "are my agents using my tools right?" — and catch the build/review/integration subagent that quietly failed and lied about it.

Reconstruct where your attention went. get_activity_timeline rolls every project's transcripts over a time window into a turn-count grid plus pre-computed rollups — how many sessions ran at once, the peaks, hands-on vs. autonomous time. It's the deterministic backbone the attention report (below) reads on top of.

Convert a past session into a subagent and put it to work. This is the one I'm proudest of, and it's the thing I tell colleagues about first: cc-explorer can take a prior session, clone it, and reconnect it as a subagent — and then you talk to it. Ask it what it meant. Ask it to synthesize its own arc. Or hand it a job: it still carries everything that session knew, so it makes a sharp reviewer for a design or code review on the work it lived through. The way I described it when I was inventing it: "a converter that can take something and move between an agent you can latch onto and interrogate and an agent that can be converted into a session I can attach to... the reason I want this is to let an agent attach to some other one and get it to answer questions about itself." Use it as an oracle, not just keyword grep — pull the why from the horse's mouth. (rewind_transcript truncates a cloned artifact back to an earlier turn so you can replay from a known point; delete_conversions cleans up the forks when you're done.)

⚠️ Session interrogation requires agent teams. Cloning a session is harmless without it, but resuming the cloned subagent (SendMessage) only exists when the calling session was started with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Without it you get "no transcript to resume." Quick check: if SendMessage is in your toolset, you're good. See Install for the one-line settings change.

Every cc-explorer tool is read-only except the conversion tools, and the conversion tools refuse to touch anything but their own artifacts — a real session or a dispatched subagent is never mutated, period.

The rest of the project-mining plugin

cc-explorer is the spine, but the same plugin ships two higher-level tools built on top of the idea that your transcripts are a corpus worth mining.

project-mining — turn a project's history into evidence

Point it at a project and a lens"find where I demonstrated technical leadership", "find struggles that became breakthroughs", "what does this thing actually do" — and it produces a rich, source-cited narrative you can carve into resume bullets, interview stories, performance-review evidence, or just self-understanding.

The trick is that evidence is rarely labeled with the lens's vocabulary. "Systems thinking at scale" isn't found by grepping "systems thinking" — it's the architecture decision in dispatcher.py plus the session where you said "wait, this won't hold at 50k events an hour." Making that inferential leap — from abstract frame to concrete observable — is the whole point, and it's why you ask a model instead of grep.

Under the hood it's an Opus orchestrator that runs an alignment conversation with you first (it will ask questions before dispatching — that's a hard gate, because a sharp lens is where all the quality lives), then fans out researcher agents across three corpora: the process (chat + git), the codebase (source + docs), and the output (what the running system actually produces). Findings get woven, not stapled.

activity-reflection — the herding tax

A report on how your attention actually got spent across the fleet over a window: pulled-in vs. delegated, and what kind of pulled-in — drift-response babysitting vs. genuine design vs. clean dispatch. It dispatches an analyst agent with an isolated context (so your priors don't contaminate the classification) that pairs the deterministic get_activity_timeline map with calibrated transcript reads, because raw turn-counts systematically over-count herding. Chain it week over week and you get a trend line on whether the fleet is buying you leverage or robbing your attention.


engineering-loop

A deliberately slim fork of EveryInc's compound-engineering plugin — the parts that compound for a solo operator, with the team-scale scaffolding stripped out. Upstream ships ~36k tokens of ambient context shaped for a content-company AI team with issue queues and Slack and a full plan→work→review→compound methodology. Most of that doesn't apply when it's just you and a long-lived codebase, and the token tax is real.

What's left is the stuff that actually earns its weight:

  • /el:review — parallel multi-lens code review. Several reviewer personas run at once (correctness, testing, maintainability, simplicity, security, performance, reliability, an adversarial pass, and more), each returns structured findings, and a merge/dedup pipeline collapses them into one confidence-gated report. Several models looking through different lenses still catch what one pass misses.
  • /el:claude-md-doctor — diagnoses your CLAUDE.md / .claude/rules instruction surface for bloat, scar tissue, and wrong-mechanism content (a procedure that should be a skill, an "always do X" that should be a hook). It produces a decomposition map and a 10-minute checklist and then stops — it does not rewrite your instructions, by design. The thesis it's testing: intervenability, not automation, is the valuable part.
  • Curated research agents — single-purpose system prompts for "scan the prior art before deciding" and "what are the current best practices for X," with the right epistemics baked in.

See engineering-loop/README.md for the full persona roster and the slimming ledger (what got dropped, demoted, or freed up vs. upstream), and engineering-loop/NOTICE for provenance.


mcp-authoring

If you build MCP servers, you've hit this: the model ignores your tool, or picks the wrong sibling, and you can't tell why. Usually it's the description — which is simultaneously a spec and a prompt, and deserves the same attention as a system prompt. (97.1% of surveyed MCP tools fail at least one component of a good description. It's not just you.)

The tool-descriptions skill is an opinionated reference distilled from the MCP spec, Anthropic's tool-use guidance, FastMCP idioms, and the empirical "smelly descriptions" research — covering descriptions, server instructions, parameter schemas, output schemas, annotations, and recoverable error design. It's eat-your-own-dogfood: it's how cc-explorer's own tools got written.


Install

Inside Claude Code, register the marketplace:

/plugin marketplace add coryking/coryking-plugins

Then open /plugin, pick the plugins you want, and enable them. Restart Claude Code so the plugin content and MCP server load.

That's the whole story for everything except one feature.

Turning on session interrogation (one env var)

cc-explorer's marquee trick — cloning a past session into a subagent you can talk to — needs the agent-teams runtime, which is gated behind an experimental flag. Add it to settings.json (project .claude/settings.json, .claude/settings.local.json, or ~/.claude/settings.json) and restart (env is read at session start):

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Everything else — search, grep, agent forensics, the activity timeline, the converter's write side — works without it. Only the resume path (SendMessage) needs it. If SendMessage shows up in your toolset, you're set.

Requirements

  • Claude Code CLI
  • uv — for the cc-explorer MCP server's Python deps. Claude Code launches the server via uv run, which resolves everything; no manual venv, no pip install.

Going deeper

INSTALLATION.md covers manual installation, local development against a live repo checkout (there's no native editable-install for plugins yet — it documents the workaround), version-bump bookkeeping, and the gotchas that'll bite you.


License

MIT. The engineering-loop plugin includes content derived from EveryInc's compound-engineering plugin, also MIT — see engineering-loop/NOTICE.

About

Claude Code plugin marketplace for people who drive a fleet of agents and want to know what the hell those agents actually did — session forensics, parallel code review, MCP authoring

Resources

License

Stars

1 star

Watchers

0 watching

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages