Single-pane dashboard for Op Doc, skills, connectors, and live state.
Most people treat AI like a search box. I treat it like a co-worker with a written Operating Doc, role-specific personas, persistent memory, and a couple dozen specialized skills I built to extend its reach.
This dashboard is the live control surface for that system. Same file I open on my desktop and phone to remind myself what's available, fire workflows, check memory, and review the rules I co-authored with Claude.
Interactive picker. Tells me whether a task is Trivial, Standard, or Full-tier — and what that means for how Claude responds.
The elicitation flow that fires on Full-tier work, with compression rules and a flow diagram.
Standing rules — what Claude labels, what overrides exist, how confidence is reported.
Every skill in the system — custom-built, Anthropic library, workflow shortcuts. Click any for triggers and details.
External tool integrations — Gmail, Calendar, Notion, Spotify, Cloudflare, browsers, computer-use, more.
Role-specific lenses (Sheldon, House, Hitch, Jocko, Chief). Each has its own logic and voice.
Reusable prompt library — copy a structured prompt and paste it into a fresh chat.
Snapshot of current auto-memory: feedback rules, project status, references.
The dashboards and sites that make up the operating system — public surfaces and private dashboards, with system-fit context for each.
Scheduled reviews, the amendment log, snapshot routines.
The full story — origin, architecture, the Anthropic features that power it, and lessons learned.
Data analyst, 8-11 years experience, based in Cincinnati. This system started as a way to stop re-explaining myself to a fresh chat every day. It turned into a deeper experiment: what happens when you treat a human + AI partnership like an org you're designing — with rules, roles, memory, and review cycles?
Beyond the day job, I build. Five live consumer applications — a digital movie library that aggregates ratings across four APIs, a music listening tracker that polls Spotify on a cron, a meal planner that turns weekly menus into grocery lists, a job-search SaaS in flight, and a personal site that hosts the latest revision of my resume. Four private operational dashboards that run my own life — message triage across SMS, email, and LinkedIn; journaling that bridges a Remarkable tablet and AI-aware search; an application tracker that doubles as interview prep input; and this operating system that holds the rest together. Every one of them on free-tier infrastructure. If a problem in my life repeats, I build a small system around it.
If you're a recruiter or hiring manager who landed here from my resume or LinkedIn, this is what I mean when I say I work with AI. Not "I use ChatGPT for emails." This. The Artifacts tab is the portfolio view. How it was built is the depth.
Inside my Claude session, these fire skills directly. Here on the public site, they copy the trigger phrase to your clipboard so you can see exactly what the command is. The skills themselves only execute on my machine — that's where the memory, files, and connectors live.
Claude\Context\01_Core\.Those are real paths in my OneDrive. They're load-bearing for me; for you they're just labels.
The Artifacts tab is the portfolio view — every live application and private dashboard, each with a system-fit explanation and a "More details" expander. "How it was built" is the narrative — origin, architecture, the five problems that were genuinely interesting to solve. The other tabs are the working surfaces; they make more sense after one of those two.
If two rounds cover everything, run two. Don't pad to feel thorough.
Every clickable option must be a thing Evan might actually pick. If only two real options exist, show two.
If the opener makes goal and stakes clear, collapse Round 3 into a single confirmation. Don't re-ask what's already been answered.
If a round isn't earning its keep on this specific request, name it and skip it. Compliance theater is worse than honest skipping.
Don't ask questions Claude doesn't actually need answered.
Before each clarifying question, the test is: would the response change if Claude knew the answer?
"It would be nice to know" doesn't qualify. The bar is "Claude genuinely can't proceed without this."
Why this rule exists: protocol rounds have a real cost (time, friction, context-shifting). Each question must justify that cost. Asking for "nice to have" context erodes the value of the protocol — it becomes ceremony instead of useful elicitation.
Conversation enters or exits the protocol.
A branch point. Follow the labeled arrow.
A protocol step that runs as a turn in the conversation.
Protocol short-circuits — go straight to output.
Did the request hit a Full-tier trigger (money, career, published, standing rules, foundational, irreversible, "this matters")? If no → Standard or Trivial response, no protocol. If yes → continue.
Did Evan say "just respond" or "skip the protocol"? Did the opener already include tier, mode, triggers, goal, and stakes? Are we mid-Full-tier on a follow-up turn? Any of these → skip the protocol, go to output.
Claude pre-populates its read of tier, mode, and which triggers fired. Evan confirms or corrects.
Claude reflects back what it understood Evan is actually asking for. If unclear, Evan corrects before Round 2.
Money asks magnitude and reversibility. Career asks stage and who's affected. Published asks audience. Etc. Only triggers that fired generate questions.
What does Evan want to walk away with (goal)? What's actually on the line (stakes)? Plus an open "anything else I should know" field.
Conditional. Only runs if a previous answer surfaced something that materially changes the response, or if a load-bearing assumption is still unstated. The stopping rule above governs whether the question runs.
If round count exceeds 4 without convergence, the protocol has stopped helping. Exit, name what's being skipped, proceed.
The actual response — tier announcement, mode, confidence labels, citations, pre-mortem, two-pass review.
Claude offers options: pressure-test, missed angle, change format, expand a section, or ship. Loop until ship.
Hard on bad ideas. Neutral on neutral ones. Supportive on good ones.
Say "hold" or "update" and why.
Trivial → Standard → Full. If unclear, default to higher tier.
Confidence and assumptions are part of the answer, not subtext.
No percentages. False precision hides bad calls. Threshold for flagging: anything below High.
"Holding because…" or "Updating because…" so the change is visible as earned vs. performed.
If it's not a real option, don't include it.
If a rule isn't earning its keep on this task, say so. Compliance theater is worse than honest skipping.
Permanent standing question on every non-trivial answer.
State the strongest version of the position first, then attack that version.
Empirical or quantitative claims need an inline source. Speculation flag is its own citation.
First pass: best answer. Second pass: hostile reviewer. Revise. Ship.
"If this fails 12 months from now, what's the most likely reason?" Then address it.
"What would guarantee failure?" Then avoid those things.
Write the prior before the research. The delta is the calibration signal.
Captured at render time. Grouped by type.
operating system or op system in chat to re-render with current state.All standing files live under your portable Claude\Context folder. Live (ephemeral) auto-memory lives separately in AppData.
snapshot memory for a portable backup.operating system in chat. The skill reads current state from disk and rebuilds the artifact.Claude\Context\01_Core\Skills\<new-skill-name>\SKILL.md with YAML frontmatter (name, description with trigger phrases) followed by the skill body — instructions Claude follows when triggered.references\ for supporting files (templates, scripts, data).build-skill (Evan's Skill Builder — enforces the four-gate Skill Build Spec) or update-skill for modifications. The Anthropic plugin's skill-creator still supplies package_skill.py if you want to package directly..skill bundle via Customize → Skills.SKILLS array in the operating-system artifact template (name, oneLine, triggers, runPhrase, whenToUse, optimal, gotchas, example).operating system. The Skills tab now shows the new card.Claude\Context\01_Core\Skills\persona-protocol\SKILL.md.persona-protocol via Customize → Skills.PERSONAS array in the operating-system artifact template.operating system. Personas tab + Live State KPI both update.CONNECTORS array in the operating-system artifact template (manual curation — auto-detect is a v2 enhancement).operating system. Connectors tab + Live State KPI update.CONNECTORS array.operating system.Auto-memory updates automatically as Claude saves info during conversations. It's stored under AppData and is session-bound.
Periodic snapshots via the memory-snapshot skill copy the live auto-memory to Memory_Snapshots\YYYY-MM-DD\ — portable backup. Run weekly (Sunday recommended) or before any major Op Doc review.
Dashboard's memory view reflects state at render time. Re-render via operating system to refresh.
Claude\Context\01_Core\Operating_Doc.md.operating system. The Op Doc version, last-amended, and recent amendments all refresh from the source.When to refresh:
How to refresh:
operating system, op system, or close variant in chat.operating-system skill fires. It reads current state from disk (Op Doc, MEMORY.md, skills folder) and rebuilds the embedded data.mcp__cowork__update_artifact to replace the rendered HTML.Scenario: you add a new Notion connector, create a new "Researcher" skill, add a new "Skeptic" persona, and document the changes as a constitutional amendment.
CONNECTORS array in the artifact template.Claude\Context\01_Core\Skills\researcher\SKILL.md. Package + upload via Customize → Skills. Add researcher to the SKILLS array.persona-protocol\SKILL.md — add Skeptic persona, update tables, repackage + upload. Add skeptic to the PERSONAS array.Operating_Doc.md — add amendment entry covering all three additions, bump version to v1.5, update top-of-doc metadata.snapshot memory to capture state before the next batch of work.operating system in chat.Source path: Claude\Context\01_Core\Skills\operating-system\references\artifact_template.html
SKILL.md: Claude\Context\01_Core\Skills\operating-system\SKILL.md
When the operating-system skill fires, it reads the template, customizes the embedded data (version, memory, amendments, etc.) for the current state, and renders. Edit the template directly to change the structure or visual style; edit the data customization step in SKILL.md to change what gets pulled in at render time.
Filesystem-only changes are invisible to Claude's skill loader. Always package + upload.
If a Write or copy fails with permission-denied, retry after a few seconds, or write via bash heredoc to /tmp first then copy back.
If wc -c or tail shows truncated content, cross-check with the Read tool before assuming corruption.
Adding a connector in Customize doesn't automatically update the dashboard — the CONNECTORS array in the template is hand-maintained for now.
The artifact's amendment count reflects what's in the embedded AMENDMENT_DATA array, which currently shows the 3 most recent. The Op Doc may have more historical entries — refresh the array if you want the full count.
In March 2026 I noticed I was solving the same coordination problem over and over. A fresh Claude chat didn't know my goals, my voice, my rules, or my work history. Every conversation burned the first ten minutes re-establishing context. So I sat down with Claude and we co-authored an Operating Doc — a document defining how we'd work together. Principles, decision tiers, what Claude must label versus assume, when to ask versus proceed, how to handle disagreement.
That document is the spine of the whole system. Over the next few months it grew layers: a memory system that survives sessions, a skill library that extends Claude into specific domains, a connector mesh that wires Claude to my real tools, named personas for different thinking styles, and this dashboard as the control surface. Everything runs on free-tier infrastructure or tools I already paid for. The Operating Doc is markdown. The skills are markdown. The memory is markdown. Plain English first, technical details after.
If you've never built one of these, here's the full system in six steps.
Could be in Cowork (the desktop app where most of this work happens), in Claude Code (the CLI for coding work), or in plain Chat. Each surface has different capabilities, but the same operating system loads underneath.
Behind the scenes, Claude reads the Operating Doc and the current memory file before your first message gets answered. Tier system, hold-or-update rule, confidence labels, anti-Potemkin clause — all loaded before the first reply.
For anything non-trivial, the response opens with the stakes tier (Trivial, Standard, or Full) and the working mode (Explore, Decide, Draft, Critique, Execute). You see how Claude is approaching the task before the work starts.
Each skill has trigger phrases. Say "build a skill" and the build-skill skill activates. Say "Hey Sheldon" and the precision-and-structure persona takes over. Claude doesn't run every skill on every message — only the ones that fit the ask.
When you give Claude new feedback, share a fact about a project, or correct an approach, the memory system writes a structured entry to a markdown file. The next conversation reads that file at start. Context compounds across sessions instead of starting from zero every time.
Skills, connectors, personas, prompts, amendments, current memory — all rendered as a single browsable page. When the system gets too big to remember, the dashboard is where you look.
Read top to bottom. The OneDrive\Claude\Context\ folder is the canonical source — everything in the middle row is a markdown file (or set of files) that lives inside it. Claude and this dashboard are both readers of those files; you are the author. Edits loop back into the next conversation.
↺ Your edits to the files flow back into the next conversation — the loop closes here.
Everything Claude needs to operate well comes from three places. Each source has its own update cadence and its own kind of authority.
The rule set. The Operating Doc defines how Claude should think, decide, and respond. Skills define what Claude can do in specific domains — job search, finances, data work, voice consistency, dozens of personal-system tasks. Both are markdown. Both are versioned. Both are amended through a deliberate process, not edited in place without trace.
Why it matters: Claude doesn't have to guess what I want — the rules are written down. When the rules change, the change is logged. The system gets predictable without getting rigid.
Auto-memory is Claude's built-in file-based store — user facts, feedback rules, project status, references to external systems. Memory snapshots are periodic copies into a portable folder that survives across machines. Each entry has a type (user, feedback, project, reference), a description, the reason it exists, and how to apply it. Memory isn't journaling — it's load-bearing context.
Why it matters: the next conversation starts where the last one ended. I never have to re-explain.
Connectors are MCP servers and built-in integrations that let Claude touch real services — Gmail, Calendar, Notion, Slack, Spotify, Cloudflare, the browser, the desktop. Personas are named thinking lenses I activate by name when I want a specific mode of analysis. Both expand what Claude can do without bloating every conversation with capability descriptions.
Why it matters: capability is loaded on demand. Skills and connectors only activate when a trigger fires, so a casual chat doesn't pay the cost of every possible tool.
Quick tour through the layers. Each card has the technical name on top and the plain-English explanation underneath.
Claude (Anthropic). Currently Claude Opus, Sonnet, and Haiku — different tier models for different stakes. The underlying intelligence layer that everything else rides on.
What this is: Claude is Anthropic's family of AI models. It does the actual thinking. The Operating System around it tells it how to think, what it can do, what it should remember, and how it should communicate.
Cowork + Claude Code + Chat. Three different surfaces for talking to Claude — Cowork for desktop file work, Code for coding, Chat for everything else. Same operating system loads in each one.
What this is: a "client" is just an app for talking to the AI. Different clients are better for different kinds of work. Cowork has access to my OneDrive folders, so it's where most of the file-touching work happens. Code is built for development. Chat is general purpose.
Anthropic Skills. Loadable instruction packages that activate on trigger phrases. Some come from Anthropic's public library; most are custom-built for my specific workflows.
What this is: a skill is a small markdown file that tells Claude how to do a specific task. When you say a trigger phrase, Claude loads that skill's instructions and follows them. Lets the same Claude be expert at dozens of different things without carrying every instruction in every conversation.
MCP (Model Context Protocol). The open standard for connecting Claude to external tools and services. Gmail, Calendar, Notion, Slack, Spotify, the browser, the desktop — all wired in via MCP.
What this is: MCP is the wiring standard for AI tools. Instead of every service needing custom integration code, MCP gives them all a common interface. Claude can use any MCP-compliant tool the same way.
OneDrive + plain markdown. Everything lives in OneDrive\Claude\ as plain text. Synced across machines, versioned by OneDrive, readable by any text editor or AI tool.
What this is: the whole operating system is files. No database. No proprietary format. If Anthropic shut down tomorrow, I could open the same files in any other AI tool. Files as the universal interchange format.
Cloudflare Pages. This dashboard, the resume site, and three other personal apps all deploy to Cloudflare Pages. Static hosting plus the option to add Workers for backend logic. Free tier covers everything.
What this is: Cloudflare Pages is a hosting service for static sites. Push your code, Cloudflare deploys it globally. No servers to maintain. Pairs with Cloudflare Workers when you need backend logic — same platform, same auth, same deploy command.
Claude's built-in memory is tool-specific. Move from Cowork to Code to Chat and you start from zero each time. That defeats the whole point of accumulating context. The fix was a discipline more than a feature: every load-bearing fact, rule, or decision lives in a plain markdown file in OneDrive. Any tool can read those files. The Operating Doc, the skills, the memory snapshots, the project files — all of them are files-first. The tool-specific memory is the convenience layer; the files are the canonical layer.
The takeaway: portability is a property of the storage format, not a feature of the tool. Pick a format every tool can read and you stop being locked in.
Default AI behavior is to agree. Push back on a Claude response and it usually folds. That makes the AI useless for any task where you need an honest second opinion. The Operating Doc has a Hold/Update rule: when challenged, Claude must say either "Holding because…" or "Updating because…" and give a real reason. Capitulation without a reason is forbidden by the rules. The result is that disagreements either resolve in genuine consensus (Claude changes its mind because I gave it new information) or surface a real tension (we still disagree, and now we know why).
The takeaway: if you want AI to push back, you have to write the rule that requires it to. Default behavior is to agree, so the system has to override that default explicitly.
Some of my dashboards are public — the resume site, the movie tracker, the music tracker, this Operating System artifact. Some are private — message triage, personal journals, active job applications. I wanted a single architecture that could surface both kinds of artifacts without leaking private data to the public site. The fix was a render-time visibility tier: every artifact has a tier flag (public or showcase), and the rendering code checks the host context. In my private Cowork view, all artifacts get clickable links. On the public site, private artifacts render with a lock label and a "view-only showcase" badge — visitors see what each thing is and how it fits, but the contents stay behind the wall.
The takeaway: the same data model can serve very different audiences if you separate the rendering from the storage. One source of truth, multiple render paths.
A long document of rules tends to become a museum piece — written once, never followed. The Operating Doc has an Anti-Potemkin clause: if a rule isn't earning its keep on a specific task, Claude is supposed to say so and skip it, not perform compliance theater. Combined with a scheduled amendment process (monthly reviews for three months, then quarterly), the doc stays alive instead of going stale. Rules either justify themselves over time or get amended out. The doc has versioned its way to v1.7 over a few months. Every amendment is logged with the reason it was made and what would prove it wrong.
The takeaway: the rules need a review cycle. Without one, they ossify. With one, they evolve.
Most note systems become graveyards — entries pile up, nothing connects, search returns too much to be useful. The memory system here has a strict structure: every entry has a type (user, feedback, project, reference), a description that tells future Claude when to reach for it, a "why" that explains the reason it exists, and a "how to apply" that says what to do with it. Memory isn't a log of what happened. It's a set of rules for future behavior. The structure forces the entry to be load-bearing or not get written at all.
The takeaway: memory is only valuable if it changes future action. A structured entry format keeps the system from filling up with stuff nobody acts on.
The transferable pattern is small: (1) write one page of plain-English rules for how you want to work with AI, (2) use that document for a week, (3) notice what you keep re-explaining, (4) turn each repeated explanation into a skill or a memory entry or a clarification of the rules. Iterate. The dashboard came years into this for me — it was never the goal, just the visualization that emerged once the system was big enough to need one. Start with the rules. The structure follows.
The Operating Doc began as a conversation with Claude in March 2026. The first draft was about three pages. The current version is around twenty pages with a versioned amendment log going back to v1.0. Every layer on top of it — the skill library, the memory system, the connector mesh, the personas, this dashboard — was added when a specific pain point made it necessary, not as part of a master plan. The Anti-Potemkin clause means anything that stops earning its keep gets struck. The system is what's left after several rounds of that pruning.
This dashboard is one HTML file. No framework, no build step. The data arrays (skills, connectors, personas, prompts, artifacts) get updated by skills that rewrite the file in place. A sync script copies it to a deploy repo. Wrangler ships it to Cloudflare Pages. Total deploy time under a minute. Same file serves both my private Cowork view and the public site you might be reading this on — an inHost check at runtime decides which features to expose.
If you want to see the system change over time, the Operating Doc's Amendment Log is the best record. Every meaningful change is logged with the reason it was made and what would prove the change wrong.