DEV Community: Kate Pond

The Promotion Doc That Writes Itself

Kate Pond — Fri, 03 Jul 2026 00:45:23 +0000

TL;DR: I set up a Claude Code skill that checks in with me about my workday, asks follow-up questions, and saves a structured markdown file I can use as promotion evidence. Here's why it works, and how to build one in about five minutes.

May 6th

On May 6th I had an energy level of 2 out of 5.

I got my Claude Certified Architect exam score back that day: 717 out of 1000. I needed 720. I missed it by three points.

Four lines down in the same entry, my manager had told me: "your leadership is being felt around Artium. You're making a good impact."

Here's the thing about that day: the bad number is vivid and self-evident. 717. Three points short. That number was going to live in my head rent-free for weeks. But the recognition? That quietly evaporates. Left to memory, May 6th is the day I failed the exam by three points. On the page, it's also the day my manager told me my leadership was landing across the company.

The entry keeps the thing I'd lose otherwise.

The Problem With Memory

I've been bad at this for years. At performance review time, I'd stare at a blank document trying to remember what I'd actually done. I'd come up with four things instead of forty. My manager would advocate for me based on what she happened to see, which was never the full picture.

The thing is, I did good work. I just didn't capture it.

A few years ago I tried to solve this with Google Forms, a structured form I'd fill out at the end of each day that fed into a spreadsheet. It worked, kind of. The data was there, but it felt like homework. The form didn't ask follow-up questions. It didn't notice when I was being vague. I had to go somewhere specific to fill it out. And when review time came, I had to go back somewhere else to compile everything, figure out what mattered, and assemble it into something coherent. The friction wasn't just the daily entry. It was the whole chain: capture, retrieve, synthesize, present. I was on my own at every step.

So I built something better.

What I Built

I have a git repository called daily_self_evals. Inside it, every workday gets its own markdown file:

entries/
└── 2026/
    └── 03/
        └── 2026-03-02.md

Each file has YAML frontmatter (date, day, energy level, tags) and sections for what I shipped, the impact of that work, wins, challenges I overcame, recognition I received, and what's next. Here's a representative example of what an entry looks like:

---
date: 2026-02-12
day: Thursday
week: 7
energy: 4
tags: [shipped, cross-team, recognition]
---

# Daily Eval — Thursday, February 12, 2026

## Shipped
Wrapped up the LLM observability integration. Multi-turn conversation
history is now captured and agent tool calls are visible for evaluation.
This had been a gap in the platform for a while.

## Impact
The team called it out as a major win in our retro. Other engineers
can now actually see what the agent is doing across a full conversation,
not just at individual turns.

## Wins
Got the company spotlight award today. Wasn't expecting it.

## Recognition
My manager flagged it in the all-hands. A few people I don't work
with day-to-day sent messages saying they'd been waiting for this.

The Skill

In Claude Code, you can build a custom skill: a saved workflow with a description that tells Claude when to use it. I built one for journaling, and the nice part is I don't invoke it with any special syntax. I just talk to Claude Code the way I'd talk to a coworker:

"Hey, let's make an entry for today."

"Can you record this win I just had?"

Claude recognizes that these match the journaling skill and runs it. (You can also invoke it manually with /daily-eval if you prefer typing a command, but I never do.)

When it runs, Claude first checks if an entry already exists for today. If it does, it reads what's there and asks what I want to add. If it doesn't, it starts fresh. Either way it appends and never overwrites, so I can log something at 2pm and add more at the end of the day, and it all lands in the same file.

Then it asks me questions, one at a time, conversationally:

"What did you ship or move forward today, even if it was small?"

"What effect did that have on your team or the product?"

"Did anyone thank you or give you good feedback?"

It's not a form. It feels more like a five-minute debrief with a colleague who's genuinely curious. When we're done, it writes or updates the file and tells me where it saved it.

Why the Conversational Format Matters

The STAR framework (Situation, Task, Action, Result) is embedded in the question flow without being named. When Claude asks "what effect did that have?" after I describe a task, I think harder. I give better answers than I would in a form. By the time I'm done, each entry reads like something I could hand to a hiring manager or drop into a performance review, because the prompts shaped it that way from the start.

What You Can Do With the Files

Everything is plain markdown with YAML frontmatter. No app. No database. No lock-in.

That means you can:

Export to Word or PDF: pandoc entries/**/*.md -o accomplishments.docx
Import the whole folder into Notion or Obsidian
Ask Claude to summarize three months of entries before a performance review
Paste any entry directly into a promotion packet or 1:1 doc
Push it to a private GitHub repo for a permanent, timestamped record

Because the YAML frontmatter includes structured fields like energy level and tags, you can also ask Claude to generate charts and analysis across your entries. Energy level over time. Which weeks had the most wins. How often you shipped versus how often you were blocked. The Google Forms version of this system fed into a spreadsheet that could do exactly this kind of visualization. The Claude Code version can do the same thing, just by asking.

One More Use: When Someone Asks You for Feedback on a Colleague

Peer feedback requests always arrive at the worst time. Someone asks you to fill out a survey about a teammate you worked closely with three months ago, and you stare at the form trying to remember anything specific.

If you've been logging your interactions, you don't have to remember. You can ask your journal: "When did I work closely with [name] and what did I notice?" You'll have the actual moments, the specific things that helped you, the friction you observed. Your feedback becomes something a manager can actually act on, instead of the generic "great to work with, highly recommend" that tells everyone nothing.

The record makes you a better peer, not just a better advocate for yourself.

How to Set This Up

You need Claude Code installed. Then just ask Claude to build it for you. You don't need to create any files manually. Open Claude Code and paste something like this:

"I want to set up a daily work journal to build promotion evidence. Create a ~/daily_self_evals/ project with a CLAUDE.md, an entries/ directory organized by year and month, and a global skill at ~/.claude/skills/daily-eval/SKILL.md. Give the skill a description so you'll recognize when I ask you to make a journal entry or record a win in plain language, and make it invocable as /daily-eval too. When it runs, it should check if an entry already exists for the target date before asking questions, ask one question at a time about what I shipped, the impact, wins, challenges, recognition, and what's next, and save entries as markdown files with YAML frontmatter. All entries should be appendable and never overwrite existing content."

Claude will handle every file. You just review what it built, open a fresh conversation, and tell it you want to make today's entry. (Skills load at the start of a conversation, so open a new one after setup.)

What Happens After a Few Months

I now have a body of evidence I've never had before. Specific accomplishments. Measurable impact. Quotes from colleagues. An energy rating that shows me my own patterns over time: what kinds of days light me up, what kinds drain me.

When it's time to make the case for a promotion, or find a role that's more interesting and pays better, I won't be starting from memory. I'll be starting from a record.

And on the days when I miss a certification by three points and want to believe the whole day was a loss, the record knows better.

One last thing: this system isn't finished. I keep tweaking the questions, adjusting what the frontmatter captures, experimenting with how I ask for summaries. That's part of the point. It's a tool I own and can improve, and the more I use it, the better I get at using it. The version I'm running today is better than the one I started with, and the version I'll be running in six months will be even better.

Inspired by Get your work recognized: write a brag document by Julia Evans, and my earlier experiment with Google Forms for self-evaluation.

Not Enough SMEs or Customers to Make Your Evals? Make Some!

Kate Pond — Thu, 25 Jun 2026 15:07:57 +0000

TL;DR: When you cannot reach real users or SMEs to build eval data, you can build realistic stand-ins instead. Gather everything you actually know about the user into a knowledge base, use Claude Code to synthesize personas from it, have the people closest to the user validate them, then turn the validated personas into agents that generate multi-turn conversations and edge cases for your eval set. The trick is grounding: a persona is only useful if it comes from real evidence and gets checked by someone who knows the user.

If you have been building with AI for a while, you probably remember when personas were how everyone learned to prompt. Something like:

You are Rob Pike, architecting a new service in Go. Be opinionated and concise, and explain the tradeoffs behind your choices. How should I structure the packages?

We all did some version of that.

Then the field kind of moved on. We still hand agents a personality here and there, but persona prompting stopped being the headline move. It started to feel like a beginner trick.

I think personas are coming back. Not for voice and flavor this time, but for something more serious: they are a way to manufacture a stand-in for a human you cannot actually reach. And it turns out that solves a real problem in evals.

The bind

Here is the problem I keep running into.

You need evals. Good evals need data that looks like real usage. And to make data that looks like real usage, you need access to real users or subject matter experts. But a lot of the time, you do not have enough of either, at least not yet.

Maybe the product is early and there are not enough users to learn from. Maybe your SMEs are real but hard to reach, the kind of people who do not have time to sit with you for a thousand test cases.

In my case it is often structural. I do consulting work, and a lot of the time we are building for a company that has its own clients. There is a layer between us and the people who will actually use the thing. I may never get in a room with the end user at all. That is not a budget problem or a laziness problem. It is just the shape of the engagement, and no amount of asking nicely changes it.

The reframe

You do not need real users to start. You need realistic ones. And realistic ones you can build.

The key word is build, because the difference between a useful persona and a useless one is where it comes from. A persona you invent out of your own head is just your assumptions wearing a costume. The whole thing only works if the personas are grounded in the closest real humans you can actually reach.

The method

Here is what I actually did.

1. Build a knowledge base. I create a repo and fill it with everything I have learned about the end user. Meeting notes from discovery calls. Transcripts, when the client is comfortable being recorded. Research I have done on my own from public sources. Anything that tells me something true about who this user is and where they get stuck. The point is to triangulate across sources instead of leaning on a single conversation.

2. Point Claude Code at it and generate personas. I use Claude Code to read across the whole knowledge base and synthesize a small set of basic personas. Not a chat window, a repo. That matters, because the personas are coming out of a curated body of evidence rather than one prompt and a vibe.

3. Have the client validate them. This is the step that does the real work, and it is the one I would not skip. I send the personas back to the client to correct, enrich, and push back on. Sometimes the client has a UX research team and real user data to check against. Sometimes the client just knows their customer in their bones from working with them for years. Both are legitimate. The human who cannot sit for a thousand eval cases can still look at five personas and say, no, this one would never do that. That validation is what turns the personas from my guesses into the client's real knowledge, captured and structured.

4. Turn the personas into agents that exercise the product. Once a persona is validated, it goes back in the repo and becomes something I can use on demand. I can tell Claude Code, use this persona and hold a multi-turn conversation with the chatbot the way this user would. Out the other side I get user-phrased turns, full multi-turn conversations, and edge-case inputs. Those become cases in the eval set.

I want to be honest about how simple this was. The first version was basic. I was not doing anything clever. And it still gave us genuinely interesting outputs, the kind of conversations and edge cases we would not have thought to write by hand.

Where this breaks

A validated persona is a proxy, not ground truth, and it is worth being clear-eyed about that.

The personas are only as good as the evidence underneath them and the client's willingness to correct them. If your discovery was thin, your personas will be confidently wrong, and a confidently wrong eval is worse than no eval. They will also tend to miss the genuinely weird stuff, the inputs no one anticipated, because they are built from what people already expect their users to do. Real humans are stranger than any persona you will validate in a meeting.

So I do not treat this as a replacement for real user data. I treat it as a way to start before you have it, and as a complement once you do. The day real users show up, you check your personas against them and find out how close you got.

Who should try this

If you are building an AI product and you are stuck on evals because you cannot get to your users yet, this is worth an afternoon. You do not need a research team or a big budget. You need whatever real signal you can gather, a place to put it, and a willingness to let the people closest to the user tell you where you got it wrong.

Start small. One knowledge base, a handful of personas, one validation pass, one multi-turn conversation generated from a persona you trust. See what comes out. You can make it fancier later, or you may find, like I did, that the basic version already earns its keep.

Now I am exploring whether the same personas can serve as a regression harness for product improvements. More on that if it pans out.

“Where Tech Meets Planet: A Quickstart Glossary for Climate Tech - Curious”

Kate Pond — Thu, 24 Apr 2025 05:13:12 +0000

🌿 Start Here: What Is Climate Tech?

Climate tech refers to technologies that reduce greenhouse gas emissions or help people adapt to the effects of climate change. That includes:

Software for tracking carbon emissions
Hardware like smart sensors or solar panels
Tools that help protect biodiversity and ecosystems
Platforms that connect people to climate action and jobs

But it’s not just for scientists or environmental orgs, it needs designers, devs, analysts, writers, community builders, and dreamers.

🧠 What’s That Mean? — A Tiny Climate Glossary

Carbon Accounting

Tracking how much carbon a product, company, or activity emits.

Think of it like a budget, but for the atmosphere.

Mitigation vs Adaptation

Mitigation = slowing down climate change (e.g. reducing emissions)

Adaptation = dealing with its effects (e.g. flood-proofing cities)

Regenerative

A step beyond “sustainable.” It means designing systems that restore, not just maintain.

Greenwashing

When something is marketed as eco-friendly... but it’s mostly vibes. Learn to spot it.

📌 Communities & Resources

Communities to Join

Job Boards & Learning

Want to listen instead?

Volts

🔍 Where Tech Meets Planet: Examples

Tech Skill	Climate Use Case
Backend Dev	APIs for emissions tracking platforms
UX Design	Interfaces for electric grid visualization
Data Analytics	Mapping climate risks by neighborhood
AI/ML	Forecasting wildfires or extreme heat
Storytelling	Helping people care, not just understand

💬 Let’s Connect

I used to be a park ranger. Now I’m a software engineer building systems that (I hope) make the world a little better. If you're curious, overwhelmed, excited, or unsure, I'm happy to chat.

🌱 Find me at The Pond's Edge
💌 Message me on LinkedIn