Asa Laws
Director of Technology & AI, Baysora
If you’ve been using Cowork for a while, you’ve probably noticed a pattern. You run an intake review, draft a client email, or summarize a meeting — and it goes well. Then next month you do it again, and you spend the first few minutes re-explaining the same context: what kind of client this is, what format you want, how your firm handles this type of work.
That setup cost is a signal. It means you’re doing something repeatable, and you haven’t yet told Cowork how to do it.
Skills are how you fix that. A skill is a saved set of instructions that encodes how Cowork should approach a specific task — the inputs, the process, your quality bar, examples of what good output looks like. Once it’s built, you invoke it by name. The setup cost drops to zero. Anyone on the team can run it and get consistent output without knowing anything about how it was built.
The difference between a one-off Cowork session and a skill is the difference between explaining something once and explaining it permanently.
What a Cowork skill is, and isn’t
A skill isn’t a saved prompt. It’s closer to onboarding documentation for a specific task — context, process, examples, quality standards, edge case handling — packaged so Cowork can apply it consistently every time.
A saved prompt gives Cowork a structure to fill in. A skill gives Cowork judgment. A well-built skill handles variation in inputs, recognizes when something is outside its scope, and produces output that meets your standard without you monitoring the run.
—
Building one: a worked example
We’ll use tax organizer intake review throughout. When clients return their organizer and supporting documents, someone needs to go through everything: confirm what’s present, flag what’s missing, extract key figures, and note anything unusual — before the return gets touched. It happens for every client, every year, at volume. The judgment calls are real. It’s a natural first skill for most tax practices, and the process of building it looks the same regardless of which task you start with.
1. Describe the process
Open a Cowork session and start documenting how you produce this deliverable — inputs, decisions, order of operations, what the finished product looks like.
The obstacle most people hit: accounting expertise is largely tacit. Ask a senior manager how they review an intake and you’ll get “I go through it and see what’s there.” That’s not a process — it’s expertise so internalized it’s become invisible.
Three approaches depending on where you are:
If you can articulate it, write it down in the Cowork session. If you can’t, let Cowork interview you — tell it: “I am documenting how to do an organizer intake review — interview me to extract my process” and answer the questions it asks. If you’re still not sure what to say, share five examples of your completed intake reviews and ask Cowork to infer the process you were following. Correct that draft. You’re editing, not starting from scratch.
For organizer intake, a good Step 1 output sounds like: “I pull up last year’s return and work through each income source — W-2s, 1099s, K-1s, Schedule C and E activity. For each one: is there a corresponding document this year? If not, is there a plausible reason, or is this a gap to flag? Then I look for anything new. A first-year 1099-R might mean an early withdrawal and a penalty, or just a rollover — I note it without assuming. The output should be specific enough that a colleague could pick it up and know exactly what to follow up on.”
2. Build a curated example library
Share four to seven real examples with Cowork: the raw inputs you started with and the completed intake reviews you produced. Skills trained on examples outperform skills trained on instructions alone.
The common mistake: sharing only your best work. Cowork needs to understand what good output looks like and what it doesn’t. Include two or three anti-examples — outputs that missed the mark — and, in the same session, ask Cowork to help you annotate each one. It will ask what went wrong; your answers become the annotations. “Missed a missing 1099-DIV because the prior year amount was small — completeness is the standard, not materiality.” “Flagged three items as ‘needs clarification’ without saying why — the output needs to be specific enough that a colleague can write the client email without asking.”
Every idiosyncratic choice in an unannotated example gets learned as a rule. The annotation conversation is how you separate what’s intentional from what’s incidental.
Size has real tradeoffs. More examples mean better coverage of variation but higher token cost on every run. The quality jump from zero to three examples is large. From six to fifteen, the cost usually outweighs the gain. Aim for four to seven, each earning its place: a simple W-2 client, a moderately complex client with investment income, a business owner with K-1s, and two anti-examples.
3. Extract your success criteria
In the same Cowork session, share your annotated examples and ask: “Based on these examples and annotations, what do all the good outputs share? Draft a rubric I can use to evaluate this skill.”
This step is the most commonly skipped — and the most consequential. Without a rubric, you’re iterating toward “feels better,” which is different from iterating toward a standard. You might improve one dimension while quietly degrading another without noticing. A rubric makes each iteration directional: you’re testing against specific criteria, not a feeling.
For organizer intake, the rubric Cowork will help you surface might be: every prior-year income source is accounted for (present or explicitly flagged); missing items describe the specific concern, not just the gap (“1099-R present last year, none this year — confirm whether distribution was taken”); new documents are noted; language is client-appropriate throughout; the output is actionable enough that a different person could run the follow-up without asking.
The act of building this rubric surfaces ambiguities in your own process you didn’t know existed. What counts as “missing” versus “late”? Is a document flagged the same way if you’re confident the income source went away versus unsure? These are judgment calls you make automatically. The Cowork conversation makes them explicit — and that clarity has value regardless of AI.
>The rubric comes after the examples, not before. Most practitioners can’t define quality in the abstract — they recognize it when they see it. The examples are how you surface what you already know.
4. Test and iterate
Take a live intake, invoke the skill in Cowork with the real documents as input, and score the output against your rubric. Note what it gets right and what it misses. Adjust the instructions in the session and run it again.
One client isn’t enough. You risk overfitting the skill to that client’s document set or complexity level. Use at least three test cases — a simple client, a moderately complex one, a business owner with K-1s — before calling the skill ready.
Keep a change log in the session. Not just “I changed X,” but “I changed X, expected Y, got Z, which was better or worse because…” That discipline separates productive iteration from random tinkering.
One more step most people skip: have a colleague invoke the skill blind. Give them access and a real intake they haven’t touched. If the output meets the rubric without your guidance, it’s working. If they need to compensate for gaps in the instructions, you’ve found your next iteration.
5. Generalize — focused, not exhaustive
Once the skill is reliable on your test cases, identify the edge cases. What happens with a new client — no prior year return to compare against? A first-year K-1 from a new partnership? Foreign accounts?
The instinct is to add instructions for everything. Resist it.
Skills degrade when edge cases accumulate. Instructions get longer and harder to navigate. Clauses start to conflict. Cowork spends more time adjudicating exceptions and less time doing the core task well. This is the most common failure mode — you keep adding cases until the skill is technically more comprehensive but actually less reliable.
For each edge case, ask: is this a variation of the same process, or a different process? A client with a new K-1 is a variation — one additional instruction handles it. A new client with no prior year is a different process; the comparison logic doesn’t apply. That earns its own skill.
The practical test: if handling the edge case requires “unless X, in which case Y, but only if Z,” you’re looking at a separate skill. Ship the focused version first. The edge case skill is v1.1, not a prerequisite for v1.0.
6. Create the skill
When your process description, examples, rubric, and edge case handling are solid, tell Cowork directly: “Let’s use everything we’ve documented to create a skill. Here is the process description, the examples, the rubric, and the edge cases — build a skill I can invoke by name.” Cowork will assemble the components and propose a structure for you to review and refine. You’re not writing the skill from scratch; you’re handing over material built across the previous steps.
Name it after the task, not the tool — “Organizer Intake Review” not “Claude Intake Helper.” Assign it a version number and note the date and test cases used to validate it.
Write a short “how to use this” note for colleagues who didn’t build it — what inputs it expects, what it produces, what it doesn’t handle. A skill only you can use is a personal tool. A skill the team runs consistently, with a shared understanding of its scope and limits, is institutional infrastructure.
—
The real value
Building a skill isn’t about AI efficiency. It’s about knowledge management.
When you document your process in step one, you’re capturing expertise that would otherwise leave with a senior person. When you build your example library, you’re creating a training resource more specific than any generic onboarding guide. When you define the rubric, you’re establishing a quality standard that applies across your practice — not interpreted differently by each person who touches a project.
The skill is the artifact. The process of building it is where the organizational value lives.
—
Where this goes next
V1 skills work. They also have a ceiling, and you usually find it in the same place: Cowork is spending time reading and parsing when it should be analyzing.
For organizer intake review, that means processing a scanned document package and a prior-year return simultaneously — before the actual review even starts. That’s slow, token-heavy, and the most error-prone part of the run. It’s also unnecessary. The prior-year income sources could be extracted and structured before the skill runs. The document list could be pre-organized. The skill would receive clean inputs instead of raw files, and the output would be faster and more reliable.
That’s the idea behind a mapping layer — a pre-processing step that structures inputs before the core skill touches them. It’s one of a few directions we’re building toward in Cowork.
Reference libraries let skills pull from stable data — client history, entity lists, engagement-specific notes — rather than including that context in every prompt. As the library grows, the skill gets smarter without getting slower or more expensive.
Chained sub-skills keep complex deliverables from becoming monolithic. An intake review that also drafts the client follow-up email is two skills running in sequence inside Cowork, not one skill trying to do everything. Each component stays tight and is easier to improve independently.
Feedback loops formalize what most teams are already doing informally. When a reviewer notes specific misses against the rubric, that feeds the next version of the skill. Improvement becomes systematic rather than ad hoc, and the skill compounds over time.
We’ll cover each of these in depth in future posts. For now, build the v1.
—
Where to start
Open Cowork. Pick the task that costs your team the most time and follows the most predictable process. Organizer intake review is a natural first choice for tax practices, but so is IRS notice response drafting, client email drafting from meeting notes, or engagement letter prep.
Start with step one. Tell Cowork what you’re documenting and let it interview you.
Every firm has expertise. Most of it lives in people’s heads and leaves when they do. A skill changes that — not in one move, but one task at a time. The practices doing this now aren’t running AI initiatives. They’re solving one specific problem, building one skill, and moving to the next. Over a year of that, you end up with something most firms don’t have: a practice that can teach itself.
—
Download the skills
We’ve packaged two Cowork skills to go with this article.
[Organizer Intake Review] — the worked example from this post, ready to install. Drop in a prior year return and this year’s document package and get a structured intake summary. A working v1 you can use today and customize to your firm’s standards.
[Accounting Skill Builder] — the framework from this article as an interactive Cowork skill. Tell it which task you want to automate and it walks you through every step: extracting your process, building the example library, defining your rubric, testing, and creating the finished skill.
To install: open Cowork, go to Settings → Skills, download the above .zip files and extract, then drag the `.skill` file in. The skill will be available immediately.
New to Cowork? Anthropic’s free [Introduction to Claude Cowork] course is the fastest way to get up to speed before building your first skill.
