Makes Claude Code genuinely good at designing knowledge-graph answer experiences with cosmos.gl on top of DuckDB-WASM, Mosaic, and vgplot. Owns the SceneDirective adapter, the three-picker ControlDock (Position, Weight, Edges), and the recipe library that turns novel ideas into usable images.
Cosmos-Pro hub: routes to the right cosmos.gl + Mosaic specialist (architect, data, render, chart, critic) and surfaces the right skill (foundations, mosaic-duckdb, recipes, scene-directive, performance) for the task at hand.
Run the compound learning pipeline for cosmos-pro. Save the session log, run Bayesian confidence updates, and present the review queue with auto-captured claims about cosmos.gl, Mosaic, vgplot, SceneDirective adapter behavior, performance pitfalls, and color/token discipline.
Plans a cosmos.gl scene from a problem description. Default entry point for any cosmos.gl design task. Refuses to plan until three questions are answered: question shape, upstream data availability, view scope. Produces a structured plan covering position/weight/edge layers, vgplot charts, Mosaic Selections, and SceneDirective phasing. Routes to cosmos-data, cosmos-render, cosmos-chart for implementation, and to cosmos-critic for review. Trigger on: "plan a cosmos.gl scene", "design this graph view", "what view should I build", "I want to show", "knowledge graph view of", "explorer screen for", or any open-ended cosmos.gl design request. <example> Context: User wants a knowledge-graph answer view user: "I want a view of my reading history clustered by topic with a timeline filter" assistant: "I'll use the cosmos-architect agent to plan the scene — layers, charts, Selections, and phasing." <commentary> Open-ended cosmos.gl design request — architect plans before any code is written. </commentary> </example> <example> Context: User asks which layers to combine user: "I have SBERT positions and Leiden cluster labels — how should I show both?" assistant: "I'll use the cosmos-architect agent to design the layer composition." <commentary> Layer composition decision — architect maps question shape to layer combo and routes to clustering-force recipe. </commentary> </example> <example> Context: User describes a feature ambiguously user: "Build me an explorer screen for the Theseus knowledge graph" assistant: "I'll use the cosmos-architect agent to plan the screen — but first I need answers to three questions." <commentary> Underspecified design request — architect refuses to plan without question shape, data inventory, and scope answered first. </commentary> </example>
Authors a single vgplot chart (histogram, timeline, strip plot, dot plot, heatmap) bound to a named Mosaic Selection. Takes the selection name, data column, and intended interaction (brush, click, hover) and produces the vgplot spec. Simple charts are 20-line answers; complex ones (two-axis timeline with independent brushes) are longer. Always follows the binding rule: vgplot charts publish via intervalX/intervalY and consume via from(table, { filterBy }). Trigger on: "vgplot chart", "histogram for cosmos", "timeline brush", "GraphHistogram", "GraphTimeline", "GraphSearch", "build a histogram", "add a brush", "strip plot of", or any single-chart authoring request. <example> Context: Plan calls for a year histogram with a brush user: "Build the year histogram with a brush that filters the graph" assistant: "I'll use the cosmos-chart agent to author the vgplot histogram bound to yearFilter." <commentary> Single-chart authoring — cosmos-chart writes the vgplot spec. </commentary> </example> <example> Context: GraphTimeline.tsx is a stub user: "Fill in GraphTimeline with a brushable timeline" assistant: "I'll use the cosmos-chart agent to write the timeline." <commentary> Stub-fill task — cosmos-chart authors the chart. </commentary> </example> <example> Context: User wants a two-axis interaction user: "I need a timeline where you can brush both x and y independently" assistant: "I'll use the cosmos-chart agent to compose the two-axis brush." <commentary> Complex chart — cosmos-chart composes intervalX + intervalY against separate Selections. </commentary> </example>
Reviews cosmos.gl + Mosaic + vgplot work after implementation. Runs every VERIFY check across the five cosmos-pro skills (foundations, mosaic-duckdb, recipes, scene-directive, performance). Flags performance smells, hardcoded colors, recipe drift (new code that duplicates an existing recipe's intent but reinvents it), SceneDirective contract violations, and Mosaic Coordinator multiplication. Invoked explicitly by the human (/cosmos-critic) or automatically at the end of any task touching files in src/components/theseus/explorer/ or src/lib/theseus-viz/. Trigger on: "review cosmos.gl work", "cosmos-pro critic", "audit explorer", "verify cosmos.gl integration", "lint cosmos.gl scene", or after any cosmos-render, cosmos-data, or cosmos-chart task completes. <example> Context: cosmos-render just finished writing a renderer user: "Review the renderer I just wrote" assistant: "I'll use the cosmos-critic agent to run all VERIFY checks against the new code." <commentary> Post-implementation review — critic runs the verify suite. </commentary> </example> <example> Context: User suspects a perf regression user: "The graph feels janky after the last change" assistant: "I'll use the cosmos-critic agent to run the performance VERIFY checks." <commentary> Diagnostic — critic runs the perf VERIFY checks first, since most cosmos.gl bugs are perf bugs. </commentary> </example> <example> Context: PR touches src/components/theseus/explorer/ user: "I just modified CosmosGraphCanvas" assistant: "I'll use the cosmos-critic agent to verify the change against all five skill VERIFY suites." <commentary> Auto-trigger condition — explorer changes always warrant a critic pass. </commentary> </example>
Wires the data layer for a cosmos.gl scene. Given a plan from cosmos-architect, writes the DuckDB-WASM loading code, the Mosaic Coordinator setup, the table schemas, and the Selection graph between charts. Outputs TypeScript and SQL, not prose. Reads the actual Theseus Django API schema (via theseus-mcp or by grepping research_api/apps/notebook/models.py) to derive table columns from the Object and Edge models — does not invent columns. Trigger on: "wire the data layer", "set up DuckDB", "Mosaic Coordinator setup", "table schemas", "Selection graph", or any task that converts a scene plan into the data infrastructure. <example> Context: cosmos-architect produced a plan; data layer not yet wired user: "Implement the data layer for this plan" assistant: "I'll use the cosmos-data agent to write the DuckDB init, Coordinator, table schemas, and Selections." <commentary> Plan-to-data-layer translation — cosmos-data outputs concrete TypeScript and SQL. </commentary> </example> <example> Context: User wants to add a new filterable column user: "Add a 'tension_count' column the histogram can filter on" assistant: "I'll use the cosmos-data agent to extend the schema and wire the Selection." <commentary> Schema + Selection extension — cosmos-data territory. </commentary> </example> <example> Context: Coordinator-multiplication bug user: "Filters in this view aren't propagating between charts" assistant: "I'll use the cosmos-data agent to audit the Coordinator setup." <commentary> Likely two Coordinators on the page; cosmos-data diagnoses and consolidates. </commentary> </example>
Writes the cosmos.gl rendering layer: the canvas component, the CosmosGraphClient that bridges Mosaic and cosmos.gl, and the applyDirective adapter that translates Theseus SceneDirectives into cosmos.gl setter calls. Consumes a plan from cosmos-architect and the data layer from cosmos-data. Output is component file(s). Follows every rule from cosmos-foundations and cosmos-performance, runs the VERIFY checks from those skills after writing. Trigger on: "implement the cosmos.gl renderer", "write CosmosGraphCanvas", "write CosmosGraphClient", "implement applyDirective", "render the SceneDirective", or any task that produces the cosmos.gl rendering code. <example> Context: Plan and data layer ready; renderer needs implementing user: "Implement the renderer for this scene plan" assistant: "I'll use the cosmos-render agent to write CosmosGraphCanvas, CosmosGraphClient, and applyDirective." <commentary> Renderer implementation — cosmos-render produces the component files. </commentary> </example> <example> Context: Migration from @cosmograph/react user: "Replace CosmographCanvas with the @cosmos.gl/graph version" assistant: "I'll use the cosmos-render agent to migrate the renderer to the open-source engine." <commentary> Migration task — cosmos-render rewrites against @cosmos.gl/graph directly. </commentary> </example> <example> Context: Adapter needs a new SceneDirective field handled user: "applyDirective needs to handle the new annotations field" assistant: "I'll use the cosmos-render agent to add the annotation handler." <commentary> Adapter extension — cosmos-render owns applyDirective. </commentary> </example>
Canonical cosmos.gl v2 API and the mental model for it as a GPU force-simulation engine, not a generic graph library. Auto-loads when working with cosmos.gl. Trigger on: "cosmos.gl", "cosmosgl", "@cosmos.gl/graph", "force graph", "WebGL graph", "setPointPositions", "setLinks", "setConfig", "setConfigPartial", "setPointClusters", "simulationRepulsion", "Float32Array", "PointShape", "graph.destroy", "@cosmograph/react migration", or any question about cosmos.gl configuration, data contract, or event model.
Data layer for cosmos.gl: DuckDB-WASM ingestion, Mosaic Coordinator and Selections, MosaicClient subclassing, vgplot grammar, and the binding model that wires vgplot charts to the cosmos.gl graph through shared Selections. Trigger on: "DuckDB", "DuckDB-WASM", "Mosaic", "@uwdata/mosaic-core", "Coordinator", "Selection", "MosaicClient", "vgplot", "intervalX", "intervalY", "cross-filter", "data layer", "Parquet", "registerFileBuffer", or any question about loading data into cosmos.gl or wiring chart filters.
How to keep cosmos.gl smooth at 50K+ points: Float32Array reuse, batched setter calls, label budgeting, simulation warmup, GPU memory budget, capability detection (iOS EXT_float_blend, Android OES_texture_float), and instance lifecycle. Most cosmos.gl bugs are performance bugs dressed as visual bugs. Trigger on: "cosmos.gl performance", "janky animation", "missing nodes", "flashing colors", "Float32Array reuse", "label performance", "GPU memory", "graph.destroy", "WebGL fallback", "iOS Safari graph", "Android low-end graph", or any cosmos.gl perf question.
Bank of runnable annotated cosmos.gl + Mosaic recipes for archetypal design questions. Each recipe encodes a tested configuration with tuning notes, failure modes, and explicit "when to use" / "when NOT to use" sections. Trigger on: "cosmos.gl recipe", "force graph example", "pinned positions", "cluster centers", "histogram + graph", "drag to reshape", "rectangle selection", "fit view", "loading state", "fallback to 2D", "GPU heatmap overlay", "hover detail panel", or any request for a working cosmos.gl configuration for a known design pattern.
Translation layer between Theseus's TF.js-driven scene intelligence and cosmos.gl's config surface. Owns the SceneDirective contract, the applyDirective adapter, the construction phasing (Galaxy, Filter, Build, Crystallize, Explore), and the pending-state visual for missing layer data. Trigger on: "SceneDirective", "applyDirective", "scene intelligence", "construction phase", "Galaxy view", "Crystallize", "active_position_layer", "active_weight_layer", "active_edge_layers", "focus_node_ids", "highlight_node_ids", "pending state", or any work that translates a Theseus directive into cosmos.gl setter calls.
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Most Claude Code plugins give you a set of slash commands and some domain knowledge. These plugins do something different: they learn.
Each plugin in this repo is a domain-specialized engineering intelligence that accumulates knowledge across sessions, grounds itself in real library source code (not training data), and coordinates with a companion chat skill on Claude.ai. The plugin implements. The chat skill plans. Over time, the plugin gets better at its job because it tracks what works, what doesn't, and what it's still uncertain about.
This is the two-surface architecture: one surface for thinking, one for building.
A typical plugin contains four layers:
Specialist agents and slash commands. Each plugin ships with 3 to 7 agents that handle specific subtasks. UI-Design-Pro has a design critic, a component builder, an accessibility auditor, an animation engineer, and a visual architect. Django-Engine-Pro has agents for model design, ORM optimization, migration planning, and MCP server exposure. Agents compose in defined sequences: you always run the stack detector before the component builder, always run the design critic after.
Source-code references. Plugins include install.sh scripts that shallow-clone real library repos into a local refs/ directory. When UI-Design-Pro needs to know how Radix handles focus restoration, it greps the actual Radix source, not its training data. When D3-Pro needs to verify a scale constructor's API, it reads the Observable source directly. This matters because training data goes stale. Source code doesn't.
Skills and decision frameworks. Static knowledge: inheritance decision tables, ORM anti-pattern catalogs, polymorphic rendering rules, animation physics constants. These encode the expert judgment that doesn't change between sessions.
An epistemic knowledge layer. This is the part that learns. Each plugin maintains a knowledge/ directory containing typed claims in JSONL, confidence scores, session logs, and (for some plugins) SBERT embeddings. Claims start as drafts. After review, they become active. Active claims carry Bayesian confidence that updates based on session outcomes: when a suggestion informed by a claim gets accepted, confidence rises; when it gets rejected, confidence drops. Over time, each plugin develops its own body of verified, weighted knowledge about its domain.
Each plugin here has a counterpart: a chat skill that runs on Claude.ai (or Claude Desktop). The division of labor is deliberate.
The chat skill handles planning, reasoning, and decision-making. When you're deciding between DRF and Ninja for an API, or choosing an inheritance strategy for a model hierarchy, or evaluating whether a component needs polymorphic rendering, the chat skill walks you through the tradeoffs and produces a structured handoff document.
The Claude Code plugin handles implementation and learning. It takes the handoff document, builds the thing, greps real source code when it needs to verify an API, logs what it tried, and updates its knowledge base with what it learned.
The chat skill never sees knowledge/claims.jsonl. The plugin never produces planning documents. Each surface does what it's good at.
| Chat Skill (Claude.ai) | Claude Code Plugin |
|---|---|
| Decision frameworks | Slash commands and agents |
| Tradeoff analysis | Source-code grepping |
| Structured handoff docs | Implementation and testing |
| Domain reasoning | Session logging and learning |
| Static (expert knowledge) | Dynamic (knowledge that evolves) |
Every plugin with a knowledge/ directory runs the same protocol:
Session start: Read manifest.json for current state. Load active claims sorted by confidence. Check tensions.jsonl for unresolved conflicts in the task's domain. Surface tensions before making decisions, not after.
During work: Track which claims informed each suggestion. Note when the user accepts, modifies, or rejects a recommendation.
Session end: Write observations to session_log/. Flag contradictions as tension signals. Note recurring patterns the knowledge base doesn't yet cover.
The knowledge types are borrowed from Theseus (a separate epistemic engine project):
Current knowledge stats across the fleet:
| Plugin | Total Claims | Active | Avg Confidence |
|---|---|---|---|
| UI-Design-Pro | 140 | 135 | 0.667 |
| Django-Engine-Pro | 111 | 29 | 0.75 |
npx claudepluginhub travis-gilbert/claude-marketplace --plugin cosmos-proMobile app development specialist: PWA retrofitting, React Native architecture, offline-first sync, mobile API design, touch optimization, and mobile visualization adaptation.
Makes Claude Code extraordinarily good at transforming websites into applications: converting page-based Next.js sites into app-like experiences with persistent layouts, command palettes, and background sync; wrapping them in Tauri desktop shells with native OS integration; and producing architecture handoffs for native Swift/AppKit macOS apps.
Git and deployment automation with verification at every step. Staged file review, conventional commits, pre-commit checks, push with CI/CD detection, and post-deploy health verification.
Next.js specialist with two tracks: Development (feature implementation with source-verified APIs) and Diagnostic (error tracing through the framework's actual source code).
Makes Claude Code extraordinarily good at building D3 visualizations that are mathematically accurate, physically believable, and aesthetically grounded in the Mike Bostock / Observable canon.
Complete creative writing suite with 10 specialized agents covering the full writing process: research gathering, character development, story architecture, world-building, dialogue coaching, editing/review, outlining, content strategy, believability auditing, and prose style/voice analysis. Includes genre-specific guides, templates, and quality checklists.
Comprehensive skill pack with 66 specialized skills for full-stack developers: 12 language experts (Python, TypeScript, Go, Rust, C++, Swift, Kotlin, C#, PHP, Java, SQL, JavaScript), 10 backend frameworks, 6 frontend/mobile, plus infrastructure, DevOps, security, and testing. Features progressive disclosure architecture for 50% faster loading.
Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.
Intelligent draw.io diagramming plugin with AI-powered diagram generation, multi-platform embedding (GitHub, Confluence, Azure DevOps, Notion, Teams, Harness), conditional formatting, live data binding, and MCP server integration for programmatic diagram creation and management.
Comprehensive startup business analysis with market sizing (TAM/SAM/SOM), financial modeling, team planning, and strategic research
v9.44.1 — Patch release for Gemini environment/version detection and qwen auth gating. Run /octo:setup.