Your productivity stack

The earlier courses each gave you a piece. This one is the assembly. The headline: do not sit down to “build a stack” in the abstract. Sit down to do real work, and let the stack emerge from it.

What to start with

Pick the work that already fills your time, not the work you wish you were doing. The instinct is to spec out a perfect productivity system: weekly reviews, deep-work blocks, every aspirational habit captured as a skill. Skip that. Look at the actual last week and find the things that:

• You do frequently. The more iterations you get, the more your skill compounds. A skill you run weekly will be far better in two months than a skill you run twice a quarter, because you have edited it ten times.
• You find draining. The work that costs more than it should: triaging your inbox, drafting the same kind of update, pulling together a recurring summary you would rather not write.
• Requires context from multiple systems. The Slack thread plus the Notion doc plus the email chain. Anywhere Cowork can do the cross-source assembly you currently do by tab-switching.
• You could simply do faster or better with help. Not “automate away” but “get to a sharper version sooner.”

The reflection is the most important step. Spend ten minutes listing the things from your last week that match. Cross out anything you only do once a quarter. From the rest, pick the two or three that feel most worth investing in.

Keep skills small and modular

A skill is a module. You cannot lift part of one skill into the next. That makes the size of a skill a real design decision. A skill that does too many things is hard to compose; a skill that overlaps with another forces you to maintain the same instructions in two places.

The most useful skills tend to be single-purpose and broadly applicable. A few that work well as starting points:

• Your writing style. If you write anything public (LinkedIn posts, blog drafts, customer-facing docs) and have a recognisable voice, this is one of the highest-value skills you can write. Reused by every other skill that produces text. A “blog writing” skill, by contrast, is narrower and harder to compose with anything else.
• Your communication style. Same idea for internal messages: how you phrase Slack updates, how you respond to questions, how long you tend to make things.
• Meeting prep. Worked through in the meeting prep course. Keep it focused on briefings; do not also load it up with note-taking, action-tracking, or follow-up email drafting.
• Prioritisation help. A skill that takes a list of things on your plate and helps you sort them. Reusable across weekly planning, post-meeting follow-ups, and ad-hoc “what should I work on next?” moments.

The pattern: identify the move, name it, write it tight enough that it does one thing well.

Build skills from real work, not from a starter pack

You met this in the patterns course: the right time to write a skill is at the end of a real Cowork session, not at the start. Open Cowork, do the work for real, then ask Claude to turn what you just did into a skill. Save it. Use it next time. Iterate.

The most common failure mode is the opposite: a stack that fills up with skills that sounded useful in theory and were never actually used. A skill that has never been run is a skill that has not been pressure-tested. A starter pack can give inspiration; it should not be the bulk of what is in your folder.

Be light with bootstrap context

Bootstrap context is genuinely useful, but the point of the profile is to tell Claude where to find things, not to be a summary of your whole organisation. A short profile that points at the right sources beats a long profile that tries to capture everything.

Two rules of thumb:

• If a document already exists, link to it from the profile rather than copying its contents in. A running one-on-one doc with your manager, a project Notion page, a strategy memo. Claude can read the source when a skill needs it. The source stays current; the profile does not have to.
• If something is not captured anywhere and is unlikely to change, it can live in the profile. Your role, your team, your terminology. If it changes weekly, link to wherever it actually changes.

A long profile is one you will not maintain, and one Claude will sometimes get wrong. A short profile that points at the real sources is one you can leave alone for months.

Keep it alive

A stack stays useful only if you keep editing it. Most personal AI setups die quietly: someone builds an impressive set of skills, uses them for two weeks, drifts, and three months later the stack is stale and they are back to typing prompts in chat.

A small ritual is enough:

• After each scheduled run, glance at what the skill produced. If something was off, take a minute to update the skill while the example is fresh.
• Once a month, look at which skills you actually used. Delete the ones that have not run in four weeks. A short stack of skills you use weekly beats a long stack of forgotten ones.
• When something new starts taking fifteen minutes a week, add a skill for it. The stack grows with your work, not ahead of it.

Stay accountable for what the stack puts out

The strongest version of this track is one where Cowork makes you sharper and lets you tackle more, and what goes out into the world is still genuinely yours. The weakest version is the opposite: a stack that confidently sends Slack replies on your behalf, forwards summaries to colleagues you have not actually read, or moves data from one tool to another so it can be ignored in two places instead of one.

It is genuinely tempting to cross that line. The first time you think “could a skill just respond to my Slack messages for me?” the answer feels obvious. Resist it. Auto-replies that nobody really wrote add noise, not signal. Pulling content from one source and posting it as a message in another usually adds maintenance, not understanding. Both feel like productivity wins in the moment; in practice they make the people around you (and often you yourself) slower, not faster.

Two questions worth asking before you ship any new skill:

• Does this help me find signal without increasing the noise everyone else has to wade through?
• Does it solve a real problem without creating a bigger one (a wrong message sent on your behalf, a confidential summary forwarded to the wrong audience, a decision made on autopilot you would later have to defend)?

The agent cannot enforce this. It is a mindset and a series of design decisions you make every time you add to the stack. Done well, you end up with something that genuinely amplifies you. Done badly, you end up automating yourself into a worse version of the same job.

Reflect

• Of the skills you have built so far, which one will still be in your stack a year from now? Why that one?
• Was there a skill you almost wrote that would have crossed the signal-versus-noise line? Write it down so you remember why you said no.

Once you mark this course complete, the Personal productivity track is done and you can claim the track certificate.