Part 3 — Skills: Deterministic Helpers for Your Workspace

Your workspace has a scope, the Instructions (saved in CLAUDE.md, loaded on every prompt), and the standards from Part 2 stored where you chose to keep them. What you do not yet have is a shelf of named procedures — reusable prompt packs your workspace reaches for by name instead of re-describing the same job every time.

This part builds the first two. Both do narrowly-scoped work the same way every run. One is a procedures clerk that fills out a form — an input-to-artifact generator that turns a short brief into a structured output. The other is a quality inspector that grades incoming work against a rubric — a rules-backed checker that reads one of your standards files and measures a draft against it. Both are Skills: named procedures saved as files your workspace loads on demand.

By the end of Part 3, the Instructions branching tree gains a new pointer: a "For Skill X, ALWAYS read <path>" line for each Skill you build, sending the model to whichever location you chose to keep it. Part 4 introduces the other half of the toolkit — Agents — and shows you when to reach for each.

Pick Up From Here

Part 3 assumes two things from earlier parts. If either is missing, you will feel it immediately — the Skills below depend on them.

From Part 1 — The Hire. The Instructions at your Cowork folder root naming the role, the business context, the audience or counterparties, the voice, and the goals. This is the context every Skill reads before running.

From Part 2 — The Playbook. At least one voice or quality standards file — tone descriptors, vocabulary use/never-use lists, and two or three wrong/right examples — saved wherever you chose to keep your standards in Part 2, with a pointer in the Instructions. The checker Skill in this part has nothing to enforce without a standards file behind it.

If you are jumping in mid-series and have not yet built the Instructions or standards, stop here and go back to Part 1 — The Hire and Part 2 — The Playbook. Both need to be in place before the Skills in this Part have anything to read.

What Are Skills?

You have been giving your workspace tasks by typing prompts into Cowork. Each time you need the same kind of structured output — a brief, a triage, a summary, a scorecard — you write a fresh request from memory. It works. But it is the equivalent of re-writing the recipe every time you cook the same dish.

Skills fix that. A Skill in Cowork is a saved prompt with a name. You write it once, then you invoke it by name whenever you need it. Instead of typing a paragraph explaining what the output should contain, you type the Skill name and hand it the input. Same output shape, every time, in a fraction of the effort.

The difference between a Skill and a one-off prompt is consistency. A one-off prompt produces whatever you happen to ask for in the moment. A Skill produces the same structured output every time because the instructions are locked into a file. Your third run of the Skill looks exactly like your first — only the content differs.

When should you use a Skill versus just asking your workspace directly? Use a Skill for any task you do more than twice with the same structure. Briefs, triages, scorecards, summaries, diligence checklists, outreach templates — anything with a repeatable format. Ask your workspace directly for one-off work: brainstorming, answering a question, analyzing a specific situation.

Your Instructions are the standing context — they tell your workspace everything about the scope. Your standards files are the policies on the wall — they constrain behavior on every task. Skills are the step-by-step procedures. Context frames the work. Standards set the boundaries. Procedures define exactly how to execute a specific job.

What a Skill shelf looks like

Every workspace's Skill shelf is different because the work is different. Your Cowork folder includes the Skills the workspace actually reaches for — not a fixed pair that comes in the box. The first prompt in this part's sidebar interviews you, drafts a candidate Skills list from the role brief, and adds it under a new ## Skills section in the Instructions on your approval. That list is the working backlog for the rest of this part; build each one in turn. The pattern is the same regardless of function:

• A "generator" Skill turns a short input into a predictably-shaped artifact. Same rows, same depth, every run. The input is brief; the output is a structured document.
• A "checker" Skill reads one of your standards files and grades an incoming draft against it. The input is a finished-looking draft; the output is a scorecard plus a line-level critique.

Every workspace gets both shapes of Skill. The names you give them follow your function — Content Brief Generator, Lead Qualifier, Ticket Triager, Vendor Diligence Summariser, Brand Voice Checker, Process Audit Checklist, whatever fits. The rest of this Part walks you through building one of each, using whichever skills you declared in the Instructions.

Skill #1: The Generator — Input to Structured Artifact

A generator Skill turns a short input into a predictably-shaped artifact. Same rows. Same depth. Every run. Before you build one, decide what a good artifact looks like — the fields that, if left blank, would produce vague or off-target work downstream.

The field list depends on the function. Your Instructions skill list names the generator and the fields it produces. Common shapes to have in mind:

• A qualification scorer produces per-criterion ratings with evidence, a total, a classification, a recommended next action, and one clarifying question when information is thin.
• A triage card produces a reported issue, a severity classification, a category, an impact summary, an affected surface, reproduction steps, a suggested owner, and a yes/no field for whether the item can be deflected.
• A diligence summary produces a subject name, a category, a spend or scope band, a posture assessment, a renewal or review date, open redlines, risk flags, and a one-sentence recommendation.
• A screening card produces a fit signal, a coverage read against required criteria, a coverage read against preferred criteria, a constraint check, a recommended next step, and one clarifying question for the submitter.

Every field exists because skipping it leads to a predictable failure mode downstream. No audience segment produces generic tone. No severity produces triage latency. No risk flags produce contracts that renew before anyone looks. The common pattern: a field for every question whose absence creates a later problem.

Build the Skill

The easy path: /skill-creator. Cowork ships with a built-in Skill called /skill-creator whose job is to build other Skills. Commands starting with / are saved helpers you type into the chat — like a shortcut. Open a new conversation in your Project and type /skill-creator. It interviews you — what the Skill should do, what it reads, what it writes, what standards it loads, and where to save the resulting files — then writes the Skill folder at the location you picked and registers the "ALWAYS read" pointer in the Instructions. That is the fastest route to a working Skill and the path the rest of this series defaults to.

The manual path — once, deliberately. The first time you build a generator Skill, build it by hand. The field-by-field walkthrough is the teaching moment for what lives inside a Skill, and once you have felt the shape of it, /skill-creator becomes a tool you can evaluate rather than a mystery.

Open your Cowork project. Navigate to Skills and create a new Skill. Name it after the generator entry from the Instructions skill list (e.g. content-brief, lead-qualifier, ticket-triage). In the skill prompt field, paste a prompt with this skeleton.

Here is the prompt text you paste into the Skill. The parts in angle brackets (like <artifact-name>) are placeholders — swap them for your own wording before saving.

Generate a structured <artifact-name> for the input provided.

INPUTS
- <input shape — e.g. "Topic in one sentence", "Inbound lead
  email", "Ticket text and customer metadata">

ARTIFACT FORMAT
Produce the following sections in this exact order:

## <artifact-name>: [short identifier drawn from the input]

### <Field 1>
<One paragraph describing exactly what belongs here and what does
not. Cite the source of truth — Instructions section or
standards file.>

### <Field 2>
<Same.>

### <Field N>
<Same. One section per field in the skill definition.>

RULES
- Pull role-specific standing context (audience, voice, goals,
  thresholds) from the Instructions and any standards files the
  Instructions point at. Do not ask the user to provide what is
  already saved in those files.
- Every field is testable — the reader of the finished artifact
  should be able to locate each field's content without guessing.
- If a field's source is silent or thin, ask one clarifying
  question rather than guess. Generic output is a Skill failure,
  not a user failure.
- If the input is too broad for a single artifact, say so and
  recommend how to split it.

Save the Skill where you chose to keep it during the build interview, then add a pointer to the Instructions so the model finds it on every invocation. The branching tree the Instructions now describe looks something like this — your actual file names and locations are whatever you picked:

The Instructions (saved in CLAUDE.md, loaded on every prompt)
├── For voice/quality standards, ALWAYS read <your-standards-file>     ← from Part 2
└── For the <generator-skill-name> Skill,
       ALWAYS read <your-skills-folder>/<generator-skill-name>/SKILL.md ← new this Part

The Instructions stay lean. They name what exists and where to find it; the standards file and the Skill file each hold their own detail. When the model is asked to run the generator Skill by name, it follows the pointer in the Instructions, reads the Skill file, and executes.

Test It

Invoke the Skill with a real input from the workspace's live work. Feed it one of the inputs your function actually consumes — an inbound enquiry, a ticket, a candidate submission, a vendor brief — and see what the Skill returns.

Review the output against three questions. Are the field values specific? "Manual tracking costs 6-8 hours per week" passes; "Supply chain visibility is important" fails. Is the next-step field actionable? The reader should know exactly what to do next. Did any field come back empty when the workspace's standing context should have filled it? That is an Instructions gap, not a Skill gap — patch the context, not the prompt.

Iterate

Your first Skill output will not be perfect. Skills improve the same way any process does — through testing and adjustment. If a field comes back too vague, add a constraint: "Every entry in this field must include a specific number, timeframe, or named entity." If a recommendation keeps proposing options your role does not actually have (channels you do not publish to, assets you have not produced, stages your pipeline does not include), add the approved list to the Instructions and have the Skill refuse anything off-list. If the Skill repeatedly asks for information the Instructions already contain, add a line to the Skill reminding it that the Instructions are authoritative for those fields.

Each time you refine the Skill prompt, run it again with the same input and compare outputs. Save your test input and first output so you can compare later versions against it — this is the fastest way to see whether a change improved the result.

The Faster Way — /skill-creator

You just built a Skill by hand. That process matters because you now understand what goes into a Skill — the field design, the constraints, the testing loop. You know what makes a Skill prompt specific versus vague, and why each field exists.

Now here is how to build Skills faster. Cowork's /skill-creator builds Skills through a guided conversation. Instead of writing a Skill prompt from scratch, you describe what you want the Skill to do and /skill-creator asks questions to fill in the details — what inputs the Skill needs, whether it should pull context from the Instructions, how to format the output, and where to save the Skill files. After four or five questions, it generates a complete Skill prompt shaped by your answers. You review it, approve, and the prompt saves the Skill at the location you picked and adds the "ALWAYS read" pointer to the Instructions.

From this point forward, new Skills lead with /skill-creator. You know what a Skill prompt contains, why each section matters, and how to test and iterate. That knowledge means you can evaluate what /skill-creator generates and fix anything it gets wrong. You can always drop back to manual authoring for unusual logic, conditional outputs, or complex multi-step workflows where a guided conversation cannot match writing the prompt yourself.

Skill #2: The Checker — Draft Against a Rubric

Same pattern, different surface. Here is what changes.

The generator Skill produces an artifact from a short input. The checker Skill grades an incoming document against a standards file. It reads the standards file the Instructions point at on every run and scores the draft against the dimensions that file names. The output is not a draft — it is a scorecard plus a line-by-line critique.

The checker pairs with whatever standards file defines the rubric for the artifact it's grading — a voice standard, an escalation-standards file, a control-framework standard, a scoring rubric. The through-line: the quality of the checker is the quality of the standards file behind it. A standards file with three adjectives and no examples produces a checker with almost nothing to work with. A standards file with specific descriptors, use/never-use lists, and wrong/right pairs produces feedback like "line 4 uses 'leverage' which is on the never-use list — try 'use' instead."

Standards Fitness Comes First

A standards file readable by a human can still be too vague for a Skill to enforce. A Skill can only flag what the standards file names explicitly — no banned-word list means no bans to enforce, however strong your taste. Before building this Skill, re-open the standards file it will read and check it against six fields:

1. Descriptors (3-5 adjectives describing the target).
2. Behaviors or traits (how the output should behave, not just sound).
3. "Use" list (preferred terms, structures, or moves).
4. "Never use" list (banned terms, structures, or moves).
5. Wrong/right examples (at least two pairs, drawn from real work).
6. Structural rules (length, ordering, active voice, lead style, required elements).

Any dimension you leave blank will silently pass every check. The checker does not know to enforce what the standards file does not name.

Build with /skill-creator

Open your Cowork project and type /skill-creator. The block below is the prompt you send to /skill-creator — the angle-bracket parts (the standards file path, the input artifact type, the dimension list) are placeholders the prompt resolves by reading the Instructions and asking you a few targeted questions before saving.

Build a skill called "<Checker Name>" that reviews incoming
<artifact type — e.g. written content, sales collateral, support
responses, process descriptions> against my standards.

Inputs:
- A draft artifact (any format within the artifact type)
- Optionally, the brief or ticket that produced it

What it does:
1. Read the standards file the Instructions point at for this
   Skill (the path the Instructions name as the rubric source)
2. Analyze the input against each dimension named in that file:
   - <Dimension 1 — e.g. tone alignment, severity correctness,
     control coverage>
   - <Dimension 2 — e.g. vocabulary use/never-use>
   - <Dimension 3 — e.g. structural requirements>
   - <Dimension N — one per dimension named in the standards file>
3. Score each dimension as PASS, WARN, or FAIL
4. For every WARN or FAIL, provide:
   - The specific line or passage that triggered the flag
   - Why it fails (which standard it violates)
   - A suggested rewrite or fix that preserves the meaning

Output format:
- Overall verdict (PASS / NEEDS REVISION / FAIL)
- Dimension-by-dimension breakdown with PASS/WARN/FAIL
- Line-level feedback table: original | issue | suggested fix
- Summary: 2-3 sentences on the biggest gaps and what to fix first

Do not invent standards. Only check against what is written in
the standards file. If a dimension is not covered in that file,
skip it and note that the standards do not address it.

Cowork walks you through a few questions about scope, inputs, outputs, and where to save the Skill. Accept project-wide scope, skip trigger setup for now, confirm the output format, and pick a storage location when asked (Memory, Rules, or Other — you name the location). Cowork generates the Skill, saves it where you said, and writes a "For the checker, ALWAYS read <path>" pointer into the Instructions.

Test It — Bad Content First

A checker is only useful if it catches real problems. Test it with input that is deliberately wrong for the function — a draft that violates the standard on purpose. Hype adjectives with no named outcome. A response that opens with corporate apology language and misses the stated severity trigger. A process description missing owner, cadence, or the named control it is supposed to satisfy. An assessment full of vibes-language with no behavioural evidence. Whatever maps to the kind of violation the standards file forbids.

A well-built checker returns an overall FAIL, a dimension breakdown that localizes the failures, a line-level feedback table with fixes, and a two-or-three-sentence summary telling you the single biggest gap to close first. Every flag points to a specific standards violation, and every suggestion gives you a concrete fix. Compare that to reading the draft yourself and thinking "something feels off." The checker tells you exactly what is off and how to fix it.

Test It — Good Content Second

A checker that flags everything is as broken as one that flags nothing. You stop trusting it and you stop pasting drafts in. Feed the Skill a clean draft — on-voice, within the use list, specific numbers, structurally correct — and watch it return mostly PASS ratings. If anything comes back as WARN or FAIL, treat each flag as a calibration question: is this a real violation, or is the standard written too strict for the input it has to grade? A well-calibrated checker passes clean drafts and only flags actual violations.

The sequence you are setting up is: Input → Generated Artifact → Checker → Revise → Ship. Drafting and grading are different modes of thinking. Let the draft be messy. Clean it up in the checker pass. The two-step approach produces better work because each step focuses on one job. Part 5 of this series wires both Skills into a pipeline that flows without manual triggering.

What Just Changed

Two new Skill folders landed wherever you chose to keep them, and two new pointers landed in the Instructions:

• The generator Skill — built once by hand so you understand the shape of a Skill definition, then cloned forward with /skill-creator.
• The checker Skill — which reads one of your standards files and grades drafts against it.

You also internalized the Skills-vs-Agents distinction and the test that goes with it: if you can draw the output on a whiteboard before the task starts, build a Skill; if you need someone to figure out what the output should look like, commission an Agent.

The Instructions branching tree now points outward to your standards (from Part 2) and to your Skills (from this part). Part 4 adds another branch: pointers to your Agents.

What Is Next

Each Skill works on its own. Both run in seconds and produce the same structured output every time. But neither one plans — they execute procedures you already knew how to draw on a whiteboard. That is the ceiling of Skills.

In Part 4 — Agents, you build two autonomous specialists — the exact pair depends on your role, but the pattern is the same: one that turns a brief or a goal into a plan, and one that turns an approved plan into a set of executed artifacts. These are tasks you cannot template — they require judgment, synthesis, and decisions about information you do not have yet. The same test applies in reverse: the moment you cannot pre-draw the output, you are reaching for an Agent, not a Skill.

Further out, Part 5 wires Skills and Agents together into a pipeline, and Part 6 puts that pipeline on a recurring schedule — tools that run without you triggering them.