Your Personal Claude Workspace

One Project, three Skills, a knowledge base, and a one-page README a teammate can adopt without asking you a question.

What you ship

A Claude Project configured for one workflow you already do every week. The Project has a system prompt, at least one attached knowledge file, and three Skills — each one handles a distinct step in the workflow. Alongside the Project, you write a one-page README that tells a teammate what the workspace is for, what each Skill does, and how to install it. When you are done, that teammate can clone the setup and start using it the same day without a walkthrough call.

The deliverable is not a demo. It is a tool you open on Monday morning.

Why this project

Every course in this track teaches a piece: Projects hold context, Skills encode procedures, file attachments carry knowledge. This capstone forces you to put all three together around work you already do. That constraint — a real workflow, not an invented one — is what makes it stick.

A synthetic demo teaches mechanics. A workspace you actually open teaches decisions: what belongs in the system prompt versus an attached file, where one Skill ends and the next begins, what a teammate needs to know versus what Claude already handles. Those decisions only surface when the workflow is real.

The test is not whether you finish. The test is whether you open it the week after.

Pick your real workflow first

Pick something you do at least twice a month, with consistent inputs and consistent output expectations, where you currently re-explain context to Claude each time. Three categories that reliably produce usable workspaces:

Knowledge work — synthesizing meeting notes into action items, reviewing documents against a standard, drafting responses to a recurring question type (vendor intake emails, budget requests, client proposals).

Content review — checking drafts against a style guide, screening job applications against a rubric, auditing pages against an SEO or accessibility checklist.

Customer-facing communications — answering a support queue with consistent tone and policy, drafting responses to sales inquiries using known pricing and objection scripts, writing follow-up emails after a defined trigger.

Pick the one that costs you the most re-explaining today. That is your workflow.

What the workspace contains

The Project — a system prompt (one paragraph, two at most) that defines Claude's role, the output format, and the quality bar. Stable. It should not need editing month to month.
Attached knowledge — one or two files with context that does not change week to week: your style guide, pricing sheet, rubric, policy document. If a file needs updating weekly, paste it into the conversation instead of attaching it to the Project.
Skill 1: Input processor — takes raw input (a draft, a note dump, an email thread) and structures it so Claude and you can work with it. This Skill is invoked first in the workflow.
Skill 2: Core worker — runs the primary task against the structured input: reviews, rewrites, scores, extracts, drafts. This is where the workflow's actual judgment lives.
Skill 3: Output formatter — takes the result of Skill 2 and produces the final artifact in the format you hand off: a summary table, a formatted email, a scored rubric, a Slack message. This Skill ends the workflow.
The README — one page, plain text or markdown: what this workspace is for, how to install it, one line per Skill, one worked example showing real input and real output.

Build sequence

Name the workflow, not the tool. Write one sentence: "This workspace helps me [verb] [input] into [output] every [cadence]." If you cannot write that sentence cleanly, you have not picked a specific enough workflow. Do not proceed until you can.
Draft the system prompt. Open a scratch chat — not the Project yet. Write the role, the output format, and the quality bar. Test it against two real examples from your backlog. The system prompt is ready when both examples produce output you would actually send.
Identify and prepare the knowledge file. Find the document Claude keeps needing — the style guide, the rubric, the pricing sheet. Copy it into a clean markdown or plain-text file. Cut anything confidential and any section Claude has never used. Save the file; you attach it in step 4.
Create the Project. In Claude Desktop: New Project. Name it after the workflow, not after yourself ("Vendor Email Triage," not "My Workspace"). Paste the system prompt, attach the knowledge file, run one test conversation. Observable criterion: baseline behavior is correct before you add any Skills.
Write Skill 1 (input processor). In ~/Library/Application Support/Claude/skills/, create a markdown file with a trigger phrase and instruction block. The Skill takes messy real input — a forwarded email chain, a note dump — and returns it structured. Test it inside the Project. Observable criterion: the output is something you could hand to Skill 2 without editing.
Write Skill 2 (core worker). Same directory. Reference the attached knowledge by name in the instruction block so Claude knows where to look. Test it with Skill 1's output. Observable criterion: you would act on this output directly — send the email, approve the candidate, flag the issue.
Write Skill 3 (output formatter). Takes Skill 2's result and produces the handoff artifact. Test the full three-Skill sequence with one real example from your backlog. Observable criterion: the output is in the format you use in the actual workflow, with no reformatting needed.
Write the README. One page. One-sentence workflow description from step 1. Install steps (where the system prompt goes, where the Skills files go, how to attach the knowledge file). One line per Skill on when to invoke it. One worked example: real sanitized input, real output. If the README runs past one page, the extra content belongs in the system prompt or a Skill, not here.
Share it. Send the README and Skills files to one teammate. Ask them to run one task without asking you anything first. Every question they come back with is a gap in the README. Update it. This is the only feedback loop that matters.

Success criteria

You open the workspace the week after you submit it and use it for real work — not to demo it.
A teammate installs it from the README without a walkthrough call.
The README is one page. Longer means the scope is too broad.
Each Skill has a distinct job. Swappable outputs mean they overlap.
The system prompt has not changed since step 4. Weekly edits mean the workflow was not stable enough to warrant a Project.

Common ways this goes wrong

You picked a workflow that is too broad. "All my writing work" is not a workflow. "Reviewing guest post pitches against our editorial criteria" is. A broad system prompt tries to cover everything and ends up calibrated for nothing. Recovery: pick one task inside the category and build that. The narrow version outperforms the broad version every time.

Your Skills overlap and conflict. When Skills step on each other, the sequence produces inconsistent results and you stop trusting it. Recovery: before writing any Skill, write one line describing what it returns. If two descriptions sound similar, those Skills have the same job — collapse them into one.

Your README assumes context the teammate does not have. You know what "the rubric" means. Your teammate does not. The README test: give it to someone who has never seen the workspace and watch where they stop. Every stop is a sentence you need to add. One round of real feedback costs thirty minutes. Skipping it costs your teammate an hour of confusion.

Stretch goals

Add a fourth Skill for exceptions. Every workflow has an edge case. Write a Skill for the most common one. Name it explicitly so teammates know when to reach for it.
Version the knowledge file. Add Last updated: YYYY-MM-DD at the top of every attached document. Update it when the content changes. This one habit prevents the most common failure in team workspaces.
Log your rejections. Note every output you did not use. After four weeks, if the same failure appears three or more times, add one constraint to the instruction that caused it.

What good looks like

You open it knowing which Skill to invoke, and the output comes back in a form you hand off without touching it. The system prompt is not clever — it is accurate. The Skills are not impressive — they are reliable. The README does not explain why you built it; it explains how to use it. When a teammate runs their first task, they do not come back with a question. Not beautiful, not comprehensive — just correct for the one workflow it was built for, and used.