If you’ve found your way to this post, I’m guessing you write in some capacity and that, when you do, generative AI is somewhere in the process. I do this too, so I know how cumbersome the process can be. The draft might come back nice and tidy, but it likely strips your voice completely… and adds a healthy amount of em dashes along the way. That’s why I set out to make something better.
Earlier this year, I left my engineering job and started as a technical copywriter here at Temporal. I was most excited to use both my engineering knowledge and technical problem solving skills in my new role, so when I got familiar with my new team and our needs, the problem we faced felt like the perfect opportunity for me to contribute.
Our content team needed ways to turn the knowledge from engineers and other technical folks in the org into published blog posts. We have an internal program here called “Voices of Temporal” (or VoT for short) that helps these team members turn their thoughts into expert content.
The problem was helping our busy engineers create content as easily as possible while also maintaining quality and adhering to our content guidelines. We understood that an engineer bringing a piece of writing to a copywriter might seem a bit intimidating. Let's face it, asking someone to review your writing as an engineer can be nerve-wracking, especially when it’s the first time. So we wanted a low stakes, conversational first step that these folks could turn to.
Instead of trying to build something that could spit out a blog post on demand, I wanted something that could fit into the way our content team operates: helping someone figure out whether they have a great idea, sharpen it, and know when the writer just wants a light edit.
I started with a Claude project, then built a version for ChatGPT. Finally, I turned the project into a Claude Skill.
The assistant had to read the room#
Jumping right into the development process, I faced an obvious problem: people don’t show up needing the same kind of writing help.
Someone might have a vague idea and need help figuring out whether there’s actually a post in it. Someone else might already have an outline and simply want help tightening the angle.
That meant the assistant couldn’t have one default behavior. When brainstorming, it needed to ask questions and help surface the core idea, audience, format, and takeaway. Once a writer had a good draft, it needed to back off and act more like an editor. That split eventually became explicit in the prompt through a separate Editing Mode.
The assistant needed to be ready to shift between various responsibilities, and more importantly figure out what kind of help the writer was asking for.
AI is a little too eager to help#
The first versions of the prompt seemed effective, until I started scrutinizing them through my testing process.
During this time, it felt like I was back to being an engineer again. I’d make a change, run some kind of prompts through it, see what broke, identify the root cause, and start all over again. Now I’m not saying this was like writing unit tests, but close enough to bring back some nostalgia.
What bugged me was that it kept rewriting way too much. It would turn a perfectly normal sentence into marketing copy that our audience of engineers would never want to read. And don’t get me started on its unhealthy obsession with words like “seamless”, “game-changing”, and em dashes along with a slew of other phrases and styles.
In the prompt I was developing, I banned certain words, sentence structures, and added rules for the usual AI habits that make everything seem polished. The key lesson here was that restraint has to be baked in.
Also, I didn’t want the assistant to hand someone a completely rewritten document and ask them to trust it. To counteract this, I had it produce an interactive redline instead, complete with a legend (shown in Figure 2) that gives context to the edits.
The assistant explains why it flags something, suggests alternatives, and brings details that need to be verified to the writer’s attention so they can have the final say.
Figure 1: Seeing what changed, and what still needs a human to check it.
Why I built different versions#
Once the core conversational behavior was working, I had another problem: where should this thing actually live?
The Claude project came first. It gave us a dedicated home for the assistant, with the prompt and supporting context already baked in. Claude also gave me the chance to turn the editing experience into an interactive HTML artifact instead of keeping everything inside the chat.
Figure 2: Claude’s editing workspace, with the draft and redline edits side by side.
But from personal experience building mobile apps, only building for Claude felt a little like shipping an app for iOS while neglecting Android users. Tons of people at Temporal already worked in ChatGPT, so the assistant needed to meet them there too.
That led to the ChatGPT Project, and the main differences with this were just the interface and underlying model. And, unsurprisingly, the same prompt didn’t always behave the same way. A rule that worked perfectly in Claude might need more hand-holding in ChatGPT, and vice versa.
Then came the Claude Skill, which solved a different problem altogether. I probably wouldn’t have built the Skill at all if Mason Egger, Senior Solutions Architect at Temporal, hadn’t put that battery in my back.
As he put it: “Projects are great, but a Skill is the way to go. It allows you to easily bundle multiple rules, tools, MCP connections, and everything else someone would need to use it. They’re easier to use, distribute, and update. This will easily allow you to keep everyone using the same tool as the brand voice and guidelines change.”
Here are some of the differences between the two: Projects give us a central hub for our workspace, while Skills let us bring the content team’s guidance into a conversation we were already having. With Skills, you don’t have to leave your existing context, open a dedicated workspace, and start over. This was a priority to incorporate, because we couldn't expect people to organize their work around our assistant. The assistant has to fit around them.
And, thankfully, people actually used the thing.
Figure 3: A Slack message from Shy Ruparel, Senior Developer Advocate at Temporal, about how the Skill improved his workflows.
Here’s what it looks like#
After the AI writing assistant was shared throughout different internal Slack channels, using the assistant started feeling like a consistent workflow for our VoT writers.
They were able to start with little more than a topic and a hunch. Here’s how easy it was to start working through an idea:
Figure 4: A topic and a hunch are enough to get the conversation started.
After one follow-up, the assistant had already moved from “a post about Worker Versioning” to a much more specific argument.
Figure 5: One follow-up later, the assistant starts turning a broad topic into a story.
Finding the angle is less than half of the work. Once someone has a draft ready for edits, the assistant changes to Editing Mode.
Figure 6: The assistant flags a rule, and lets the writer decide whether the original content stays in the draft.
Here it caught one of the style patterns I’d explicitly instructed it to watch for. Instead of rewriting the sentence without a trace, it flags the problem and gives the writer a few ways to handle it. Once the writer is happy, they can take the edits they want and move the draft back into the writing environment they prefer.
Figure 7: The assistant lets you take your finalized draft to wherever you prefer to write.
The Claude Skill makes that workflow much more portable. Here’s how easy it is to call a Skill:
Figure 8: GIF showing how easily the VoT skill is called
Build the assistant your team needs#
I don’t think the takeaway here is that everyone should copy our approach.
The turning point for me was forcing myself to spell out how our writing process actually works. By understanding our team’s workflows, I was able to translate that into rules for an LLM to uphold.
That’s why I’d encourage people to build their own version around the way their team operates. Your assistant should probably have different rules and aim to resolve different annoyances.
If you build your own, start with the workflow and then incorporate the model. Figure out where people need help, and where they don’t. Also, don’t forget about the decisions that should stay with a human editor. Then, test around edge cases relentlessly. If testing doesn’t make you frustrated at some point, you probably haven’t pushed it hard enough.
If you build something similar, I want to hear how it affects your team’s day-to-day. And another thing! If you have amazing projects to share, preferably around Temporal and AI, showcase them in Temporal’s Community Slack. I’d even love for you to discuss your work through the Temporal Blog. You can submit your idea here: Google Form.