Karo Zieminski spent nine days breaking Claude Cowork before writing this guide:

I’ve seen enough of shallow tutorials that simply rephrase the official docs to know I wanted to do something different. So I rebuilt some of my workflows from scratch, tracked what failed, measured what saved time, and mapped 56 practical tips into the resource I wish existed when I started.

I appreciate her methodical breakdown of the app, especially when to use which flavor of Claude, which for me TBH, has been an issue.

Zieminski’s nice breakdown of the differences between Claude Chat, Cowork, and Code.

The guide barely talks about prompting. It’s almost entirely about the pre-work: dedicated folder structures, global instructions via CLAUDE.md, chunked skills, delegation patterns that define end-states instead of steps. The distinction Karo draws between Chat skills and Cowork skills:

Skills in Chat were useful. Skills in Cowork are operational. They shape autonomous work. Your brand guidelines skill doesn’t just influence a reply. It governs every file Claude creates. Your writing guidelines skill doesn’t just shape a draft. It governs every article Claude writes autonomously.

Zieminski on skill architecture:

Chunk your skills instead of building one giant skill that tries to handle everything. I’ve tested both approaches and the results from one giant skill were much worse. For example, I use three separate writing skills instead of one: an overall voice skill, a corporate writing skill, and a newsletter writing skill. Each handles its own context. Claude never confuses who I’m writing for.

If you’re already using Claude Cowork or just Cowork curious, bookmark this one.

Thariq Shehzad, on the Claude Code team at Anthropic, has switched from markdown to HTML as his default agent output format. The reasoning is more honest than a format-war argument would suggest, because it’s about what humans will actually read. He opens by acknowledging what markdown was for:

Markdown has become the dominant file format used by agents to communicate with us. It’s simple, portable, has some rich text capability and is easy for you to edit. Claude has even gotten surprisingly good at using ASCII to make diagrams inside of markdown files. But as agents have become more and more powerful, I have felt that markdown has become a restricting format.

Then the pivot:

As Claude is able to do more complex work, it is also writing larger and larger specs and plans. In practice, I’ve found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read, Claude can organize the structure visually to be ideal to navigate with tabs, illustrations, links, etc.

When the spec gets long enough that you stop reading it, you’ve quietly moved from review to rubber-stamp. Shehzad’s answer isn’t to ask Claude for shorter specs. It’s to make the artifact something a human will actually open, scroll, and share. A controllable, shareable artifact is most of what made personal computing legible in the first place; HTML is the format that already does it.

He puts the trade-off honestly when the obvious objection comes up:

While markdown often uses fewer tokens, I’ve found that the added expressiveness of HTML and the much higher likelihood of me reading it means I get overall better output. With the 1MM context window in Opus 4.7, the increased token usage is not really noticeable in the context window.

And the close is the real argument:

The real reason I use HTML is that I feel much more in the loop with Claude. I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I am happy to say instead that I feel more in the loop than ever before when using HTML.

Claude skills are structured markdown files that tell Claude how to handle a specific type of task. It is—as the name suggests—a new skill Claude or any AI agent can “learn.” Each one defines a role for Claude to adopt, the inputs it needs, a step-by-step workflow, and a quality bar for the output. You can build them for anything—research synthesis, writing, code review, design critique. Once loaded, Claude follows the workflow instead of improvising.

Nick Babich, writing for UX Planet, put together 10 skills aimed at product designers. The three I’d reach for first are the UX Heuristic Review, the Design Critique Partner, and the Competitor Analysis Generator. All three give a solo designer a structured second opinion on demand: a heuristic eval against Nielsen’s 10, a senior-level design critique, or a competitive feature matrix.

Babich’s skill format is clean and worth studying even if you end up building your own from scratch. (Hint: or use Claude Code to write its own skills.)

David Hoang, writing for Proof of Concept, proposes a squad model for tackling a company’s hardest, most ambiguous problems:

The squad: a forward deployed engineer, a forward deployed designer, and a researcher. Three people. That’s it. They operate like a startup-within-the-company, deployed against a specific, ambiguous problem. […] This is a product discovery team with teeth — they don’t just produce insights and hand them off. They produce working prototypes and validated direction. […] Three people don’t need standups, retros, or Jira boards. They need a shared problem and a whiteboard.

No PM. The shared problem replaces the roadmap, and a researcher replaces the product manager. Hoang borrows the concept from Palantir’s Forward Deployed Engineers and extends it to design. His argument: AI tools have given designers enough technical leverage to prototype at engineering speed, so the designer who finds the problem can build the first cut of the solution.

A three-person team with AI tools in 2026 can cover the ground that used to require a ten-person cross-functional team. That’s the direct result of collapsing the build cost of exploration.

Hoang argues that the rotation model matters as much as the squad composition. Four to eight weeks, then disband. The team doesn’t calcify into a feature factory. Designers rotate through the company’s hardest problems instead of sitting on the same product team filing tickets for years.

Although, my counter to that would be designers sitting in the same problem space will gain deeper knowledge and context. Rotation could be counterproductive if not handled deliberately.

I wrote about this whole family of files in my recent newsletter: DESIGN.md, SKILL.md, SOUL.md, the markdown artifacts you write so an agent can read them. Nick Babich has the practitioner walkthrough for the DESIGN.md flavor of it, specifically the version that Google Stitch reads when it generates a screen. He describes the format directly:

DESIGN.md is a markdown file with two layers: YAML front matter that contains machine-readable design tokens (exact hex values, font properties, spacing scales) and Body that features a human-readable design rationale.

The two-layer split is right. The YAML is the part the agent can’t argue with: primary: "#d97706" is #d97706. The body is where you tell the agent why, and it has to be written like prose, not a config file. Babich’s philosophy section is where I’d point a designer who’s about to write their first one:

Unlike a traditional specification that often has very specific details that designers should follow when crafting a new design, DESIGN.md is less prescriptive in its nature. It creates a solution foundation for AI tools (colors, typography, corner radius) while providing enough freedom to alter the format for domain-specific needs. Another thing is that DESIGN.md is a living artifact, not a static config file. It should evolve as your design evolves.

The “less prescriptive” line is counterintuitive. You’d think the whole point of feeding rules to an agent is to be more prescriptive, not less. But Babich is right about the shape: pin down the tokens, leave the application loose, refine the file as the agent surfaces edge cases you didn’t think about. These files hold what we used to keep in our heads and call taste, and you don’t write taste like a requirements doc. You write it like a brief, and you keep editing it.