Shark Artist: Great White Theme — A VS Code Theme Built With AI Agents, for AI Agents

Most VS Code themes start with a mood board and end with a JSON file. This one started with a question: what would a theme look like if it were built by AI agents, enforced by AI agents, and designed to style AI agents?

Shark Artist: Great White Theme is a six-variant VS Code color theme inspired by the visual language of great white sharks — deep ocean blues, dorsal slate grays, ventral off-whites, and sea teal accents. But the real story isn’t the palette. It’s how four custom Copilot agents enforce every color decision across 173 workbench keys per variant, verify WCAG AA contrast on every syntax token, and — as of version 0.5.0 — style the agentic coding experience itself.

TL;DR: Great White Theme ships six accessible variants (dark, light, storm, frost, and two high-contrast), with every syntax token verified at 4.5:1 contrast ratio or higher. It was developed using custom Copilot agents that enforce cross-file sync and accessibility audits, and it’s one of the first themes to intentionally style VS Code’s Copilot ghost text, inline chat, and agent file icons.

The Shark Metaphor: Design Philosophy

A color theme needs a point of view. Too many themes are arbitrary collections of “colors that look nice together.” Great White Theme anchors every decision in a single visual metaphor: you are coding at the bottom of the ocean, and a great white shark is circling overhead.

That metaphor drives the entire palette:

Deep ocean blues (#0b1120, #1a2a3a) form the editor background — the ocean floor where you do your work.
Dorsal slate grays provide the UI chrome — the shark’s back, designed to disappear against dark water.
Ventral off-whites power the light theme — the shark’s belly, cold and clean, evolved to blend with the surface light above.
Sea teal accents mark interactive elements — the color of shallow tropical water cutting through the deep.

Then there’s the constraint that gives the theme its edge: “Danger is the only warmth.”

Warm colors — coral (#c44f5f) and amber (#d9a441) — are reserved exclusively for errors, warnings, and diff-removed indicators. You will never see red or orange used for a keyword, a string, or a decorative accent. If you see warmth in this theme, something needs your attention. That’s a deliberate design decision borrowed from the shark itself: in a cold-water world, the only flash of warm color is the thing that can hurt you.

This constraint cascades through every variant. The dark theme is the ocean floor. The light theme is the shark’s belly. Storm is overcast surface water. Frost is polar ice. The high-contrast variants push the same palette to WCAG AAA territory for users who need it.

Accessibility First: Not an Afterthought

Accessibility in VS Code themes is usually an afterthought — or an outright lie. Plenty of themes claim “high contrast” while shipping token colors at 3:1 ratios against their backgrounds. Great White Theme takes a different approach: every syntax token color is WCAG AA contrast-verified at a minimum 4.5:1 ratio, and this is enforced by automated tooling, not eyeballed.

The project includes an audit.js script that validates contrast ratios programmatically. It checks every foreground token against its background across all six theme files and flags failures. This isn’t a one-time check — it runs as part of a monthly self-improvement GitHub Actions workflow that audits coverage, identifies contrast regressions, and opens draft pull requests when something drifts.

Each variant defines 173 workbench color keys — not just syntax tokens, but scrollbar tracks, badge backgrounds, tab borders, minimap highlights, bracket match outlines, and dozens of other surfaces that most themes leave to VS Code’s defaults. If you’ve ever used a theme where the minimap gutter was invisible or the diff editor was unreadable, that’s a coverage problem. Great White Theme audits for it.

Bracket pair colorization uses six ocean-derived colors instead of VS Code’s defaults, and the full terminal ANSI palette is tuned to match each variant. Semantic highlighting is explicitly supported for TypeScript, Python, Rust, and Go — so readonly variables, type parameters, and function declarations get distinct, meaningful color treatment rather than falling back to generic syntax scoping.

Built by Agents: The AI-Assisted Development Workflow

Here’s where it gets interesting. A six-variant theme with 173 workbench keys per variant means over a thousand color values that need to stay synchronized. Change a bracket color in the dark theme? It needs to be reviewed and potentially mirrored across the light theme, storm, frost, and both high-contrast variants. Adjust a semantic token for TypeScript readonly variables? That change touches all six files and the semantic token definitions.

Doing this manually is how themes accumulate drift. I built four custom Copilot agents to prevent it:

@theme-editor is the primary authoring agent. It understands the six-file structure and enforces that every token change is mirrored appropriately across all variants. It also runs WCAG contrast checks inline — if you propose a color that fails 4.5:1 against the variant’s background, it flags it before the change lands. This agent is the front line against both drift and accessibility regression.

@theme-auditor runs deeper audits — full contrast sweeps, workbench key coverage analysis, and semantic token completeness checks. It’s the agent you invoke when you want a comprehensive health report, not just a per-change check.

@theme-learnings-clerk is the one I’m most proud of. It manages a .learnings/ directory with structured mistake tracking: ERRORS.md, LEARNINGS.md, and FEATURE_REQUESTS.md. When something goes wrong — a contrast failure ships, a workbench key is missed, a publishing step breaks — the clerk logs it with context. These learnings have promotion rules: patterns that recur get promoted from observations to enforced checks in the audit pipeline.

@release-manager handles the release checklist — version bumps, changelog entries, marketplace metadata, and the multi-step VSCE publishing process that is surprisingly easy to get wrong.

Together, these agents form a feedback loop: the editor prevents mistakes, the auditor catches what slips through, the clerk remembers what went wrong, and the release manager makes sure the fix actually ships.

The Learnings Directory: Structured Mistake Tracking

The .learnings/ pattern deserves its own callout because it’s applicable far beyond theme development. The idea is simple: mistakes are data, and data should be queryable.

Each file in .learnings/ follows a structured format with timestamps, categories, and resolution status. When the @theme-learnings-clerk logs an entry, it includes what happened, why it happened, and what was done about it. Over time, these entries build a project-specific knowledge base that the agents can reference.

Two examples from the Great White Theme learnings that surprised me:

VS Code file icon themes are mutually exclusive. When I built an agent-focused icon theme (to give AGENTS.md and .learnings/ files distinct icons), I initially created a “sparse” theme that only defined the new icons. The result? Every other file in the workspace lost its icon entirely. VS Code doesn’t merge icon themes — if you activate one, it replaces the other completely. The fix was adding generic fallback definitions for all standard file types. This is the kind of lesson that wastes hours if you don’t document it.

Experimental workspace directories need root-level gitignore rules. I had a .midjourney-workspace/ directory for design exploration that I tried to exclude with a partial gitignore pattern. It didn’t work reliably across tools. The learning: experimental local directories need a full root-level gitignore entry, not a nested or partial exclusion.

These feel small in isolation. Accumulated over dozens of development sessions, they become a genuine competitive advantage — especially when agents can reference them.

From 0.1.0 to 0.5.0 in Five Days

The changelog tells a compressed story of how modern tooling — and a willingness to ship early — can accelerate theme development:

0.1.0 was the initial scaffold: dark and light variants with a basic palette. Functional, but generic.

0.2.0 brought the shark-ocean palette refresh — the deep blues, dorsal slates, and the “danger is the only warmth” constraint. This is where the theme found its identity.

0.3.0 was the quality reckoning. The audit script revealed seven colors that failed WCAG AA contrast. All were adjusted. Workbench coverage expanded to 173 keys per variant. The self-improvement GitHub Actions workflow went live, and the .learnings/ directory was formalized. This version transformed the project from “a theme” to “a theme with infrastructure.”

0.3.1 through 0.3.4 were the humbling releases — publisher setup issues, icon rendering bugs, and GitHub Actions YAML debugging. The kind of yak-shaving that every extension developer knows intimately. Each fix got logged in .learnings/.

0.4.0 expanded from two variants to six: Storm and Frost joined the lineup alongside High Contrast Dark and High Contrast Light. The agent-enforced sync workflow proved its value here — adding four new variants without the agents would have been a week of manual cross-referencing.

0.5.0 is where the meta angle crystallized. This release added agentic workflow visibility: custom colors for Copilot ghost text, inline chat panels, chat input styling, agent file icons, and AGENTS.md syntax highlighting. A theme built by agents, now styling the agent experience itself.

What Makes This Different

There are thousands of VS Code themes. Here’s what Great White Theme is actually doing differently:

Accessibility is enforced, not claimed. Automated contrast auditing on every token, across every variant, with CI integration. Not a badge in the README — a script you can run yourself.

Six variants from a single design system. Dark, light, storm, frost, and two high-contrast variants all derive from the same shark-ocean palette, not six independent color choices glued together.

Agent-assisted development as a first-class workflow. Custom Copilot agents aren’t a novelty here — they’re load-bearing infrastructure that prevents drift across a thousand+ color values.

Structured mistake tracking. The .learnings/ directory pattern turns debugging sessions into durable project knowledge.

Agentic workflow styling. As of 0.5.0, this is one of the first themes to intentionally design the Copilot and agent experience — ghost text opacity, inline chat colors, agent file icons — rather than leaving it to VS Code defaults.

Install It

From the VS Code marketplace:

Open Extensions (Ctrl+Shift+X)
Search for “Shark Artist Great White Theme”
Click Install
Open Command Palette (Ctrl+Shift+P) → Preferences: Color Theme
Choose your variant: Great White (Dark), Great White (Light), Great White (Storm), Great White (Frost), Great White (High Contrast Dark), or Great White (High Contrast Light)

Or install directly from the VS Code Marketplace.

The source is open on GitHub — including the audit scripts, the agent definitions, and the .learnings/ directory. If you’re interested in the agent-assisted development workflow as a pattern for your own projects, that’s the place to start.

Next Steps

Try it: Install the theme and give it a week. The “danger is the only warmth” constraint is subtle but changes how you scan code.
Audit your own themes: The audit.js contrast-checking approach works for any VS Code theme. Fork it.
Adopt the .learnings/ pattern: Even without agents, a structured mistake-tracking directory beats scattered comments and forgotten Slack threads.
Build your own Copilot agents: If you maintain anything with cross-file invariants — theme files, design tokens, configuration matrices — custom agents that enforce those invariants will save you hours of drift-hunting.

The best tool for the job is the one that knows what you got wrong last time. That’s what the agents do, and that’s what the .learnings/ directory remembers.