week 3 with claude code (for work)

Every day, there is a new tutorial, a new starter pack, a new repository of skills.md touting “the best” in the industry. I don’t buy it anymore.

When anyone can write a skill in an afternoon, you get a proliferation of content with no governance for what’s actually good. If you work in an enterprise company and are writing a strategy doc, “good” will be based on your organization’s standards and house style. What I’m finding is most of the creators of these skills don’t work with the messiness of enterprise data or have existing standards to work with. They’re building off clean slates — early-stage companies with no baggage, or freelancers building theoretical skills that aren’t grounded in today’s reality. These creators are just really loud marketers.

After trying a few skills myself, I’ve found it’s hard to realistically apply this to my day-to-day. Is that just me? To me, skills are like boilerplates. They may get the bulk of the framework down but a lot needs to get re-worked and adjusted for a polished document that packs maximum meaning and subtext into each word and sentence. I will revise 30-40% of the content because the context of the delivery and my audience is always slightly different.

I think the trick is to treat skills like ML models: benchmark the new one against what you already have, prune what’s stale, and fold in what’s tested and proven.

Which is why I personally recommend everyone to test themselves! Start with something, then benchmark it and use your taste to refine it. You are the expert of your team, your processes, and how your craft fits into the way things actually work at your company.

Now getting off my soap box, here’s how I used Claude this past week:

Note: What works for me isn’t necessarily the correct, de facto way to go! Try for yourself.

How do you codify your taste in writing?

First, I started with my strategy document stored as a markdown copy.

Then I used the prompt:

Given this strategy document <reference to file>, interview me using A/B examples to help refine the style and tone. Present me with two options for a paragraph. First, critique both options. Then ask me which I prefer and why. Use my answers to write a 1-page ‘Essence’ document summarizing my taste in this domain.

By default, Claude Code will visualize the example options in the terminal window and you can step your way through each feedback round directly in chat by just answering Claude’s questions and hitting enter.

Claude generated two variations in each round, and for each round I would use the voice feature to riff on what I liked and didn’t like for each option and why.

Next, Claude would take my feedback and deliver a new set of variations in a new round. For the paragraph I was working on, Claude presented 6 rounds:

1. Narrative vs. Structure

2. Thesis first: Tight vs Supported

3. Synthesis: Evidence density

4. Refined: Sentence rhythm & precision

5. Thesis clarity & closing strength

6. Specific thesis statement

As an example of variations, it presented these two option critiques in Round 2:

Option A: Ultra-concise — four sentences, one framework, done. Any audience walks away knowing the thesis. Risk: it may feel too sparse for a strategy doc where stakeholders expect to see the evidence that led to the conclusion. The research is entirely absent; you’d need to trust that the Problem section carries all the proof.

<revised content underneath>

Option B: Leads with the same clear thesis, then immediately supports it with one tight evidence block before closing. Gives the reader the ‘why should I believe this’ without burying the point. Risk: slightly longer — the research paragraph adds weight but could feel redundant if the Problem section already covers defection data. The customer quotes add texture but lengthen the section.

<revised content underneath>

By the end, it captured my ‘taste’ in a ‘writing essence’ file that I can now reference for every new document I write.

How do you prototype with your product’s real UI without cloning the entire codebase?

When your company has a poly-repo and all you want to do is create realistic prototypes with the design library, cloning the whole thing is overkill. Instead, I made a local copy of the components from the Storybook catalog of UI components so I can quickly whip up lightweight prototypes without worrying about the extra backend dependencies. To do this, I provided a URL and scraped the HTML and CSS for the components to build in my local repo.

How do you turn a brain dump into a ticket an engineer can actually act on?

I logged a few bugs for a testing session and wrote up a test plan. Then I used Claude Code to enrich the tickets with detail and formatting. It’s quite nice to be able to brain dump a soup of thoughts and out comes a highly structured and thoroughly documented ticket with a detailed description, steps to reproduce, expected behavior, and actual behavior, written out for engineers to debug and fix.

I also used it to identify edge cases and acceptance criteria I missed. For example, I’ve been working on a feature that involves spreadsheet upload and extraction. Claude surfaced edge cases I hadn’t considered: browser refreshes during extraction, uploading a spreadsheet with mixed date formats or multiple worksheets in one .xlsx, and race conditions where the screen loads before our experimentation platform can make an assignment call — all valid and realistic test cases I wouldn’t have caught until they broke in production.

How do you separate signal from noise in a flood of internal AI content?

A fun way I used Claude Desktop (not CLI) recently is to search through our Slack for where the high-signal-to-noise, high-volume Claude Code activity was. Where are the super curious, super smart people using it? How are they using it? Because almost everyone is using it and sharing how they’re using it, you get a lot of noise.

I asked Claude to look for channels based on concrete engagement signals such as Slack reaction counts, thread depth, number of follow-up questions it resolved, and cross-channel references. Resources with fewer than 3 community engagement signals were excluded.

A few interesting insights I found when mining Slack:

1. Power users were in Tel Aviv, Israel - a hot spot of innovation and members sharing best practices for AI coding workflows.

2. Our #cmty-claude channel, which is intended to be a community for sharing Claude Code resources, was being used instead as a support channel with a lot of members asking questions about their setup.

It seems the best signal was almost never where you’d expect it. Official channels collected FAQ-style noise while real workflows surfaced organically in team channels.

Next week, I’ll write about turning that signal into something useful — an opinionated onboarding guide to AI tools at work curated across teams and functions.