Power User capstone: build a Project and a Skill, then prove they work

What this capstone asks

Two deliverables, demonstrated live, on one coherent strand of work:

A Project with genuine working knowledge (real reference files and standing instructions) that Claude draws on across chats without re-pasting.
One Skill for a task you repeat inside that work, built as a reusable bundle and triggered by plain language.

Then you run both on a real example, check the output against its sources, and score yourself. The point isn't to show the features exist; it's to show you can assemble Claude around a real job so it starts each conversation already equipped, and automates the repetitive part reliably. That combination, a workspace that remembers plus a task that packages itself, is the heart of being a Power User.

Keep to the Phase 0 privacy rules throughout: no confidential or personal data in a personal account, and nothing goes out externally without a human check. If your own work has anything sensitive, build the whole capstone in the Fernway world instead; the brief below gives you a complete, safe version.

The project brief

🛠 Try it now: Your capstone project (90 to 150 minutes, spread over a few sessions)

Build a Project and a Skill for one strand of work, and demonstrate both.

1. Choose the strand of work. Pick something real and recurring that you own: a weekly report, an onboarding, a client you serve, a recurring analysis. If you'd rather practise safely, use Fernway: run the new-starter onboarding, using the project brief, the remote-working policy, the org chart and the meeting notes.

2. Build the Project. Create it, add two to four reference files as project knowledge, and write standing instructions that set the audience, the tone, and at least one hard rule, for example, "when you rely on a fact, name the file it came from; if something isn't in the files, say so rather than inventing it."

3. Identify the repeated task inside it. Find the job you'd do again and again within this work: formatting notes into a house digest, drafting a standard welcome email, turning data into a fixed report shape. That's your Skill.

4. Build the Skill. Write a SKILL.md with a clear name and a description phrased in the words you'd actually use to ask for the task, followed by step-by-step instructions. Add a template or example file if the output has a fixed shape. Zip it, upload it under Settings / Customize → Skills, and toggle it on (code execution enabled).

5. Demonstrate both, live, on a real example. Open a chat inside the Project and run a genuine task that uses the project knowledge. Then, in the same work, describe the repeated task in plain language and confirm the Skill fires and produces the house-format output, without you pasting any instructions.

6. Verify, then write it up. Trace the load-bearing facts in both outputs back to their source files or input, and correct anything wrong. Then complete the short write-up below and score yourself against the rubric.

Suggested approach

Build in the order above and resist the urge to skip step two's instructions or step four's description; those two pieces of wording are where most of the value hides, and they're the parts people rush. Write the Project instructions as if briefing a careful new colleague, and write the Skill's description around the exact phrases you'll use when you ask for the task, or it won't trigger when you need it.

Keep both small and real. A Project with three well-chosen files beats one stuffed with twenty; a Skill that does one repeated task reliably beats an ambitious one that tries to do everything. Demonstrate on a genuine example, not a toy one, because the demonstration is the evidence. A Skill that fires on a real request and produces checked, usable output is worth far more than a description of what it could do.

Above all, verify before you call it done. A Project makes answers feel authoritative and a Skill makes them feel automated; both are exactly the conditions under which checking slips. The write-up below asks you to name where you kept a human check for precisely this reason.

The write-up template

Copy this and fill it in; one page is plenty.

Capstone write-up

Strand of work: the recurring job, in one line
Who does it / how often: e.g. Maya, weekly onboarding
Project knowledge added: the reference files, and why each earns its place
Project instructions, key rules: audience, tone, and the hard rule(s) you set
The repeated task the Skill handles: the job you packaged, in one line
Skill description (the trigger): the words that make it fire
Live demonstration (Project): the real task you ran inside it, and what it drew on
Live demonstration (Skill): the plain-language request, and that it fired without pasted instructions
How I verified: the load-bearing facts you traced to source, and anything you corrected
Where a human still checks: the step you kept for yourself, and why
What I'd do next: widen it, add a Skill, or refine the instructions, and why

Self-assessment rubric

Score yourself honestly, and be ready to point at evidence for the level you claim.

Basic. You built a Project with some files and a Skill that exists, and you can describe them. But the Project instructions are thin, the Skill's description is vague or you're not sure it triggers reliably, or you demonstrated only one of the two, and you didn't verify the output against its sources.
Good. You built a Project with well-chosen knowledge and specific standing instructions including a hard rule, and a Skill whose description fires on natural phrasing. You demonstrated both live on a real example, and you traced the load-bearing facts back to source and corrected any errors. Your write-up names where a human check stays.
Excellent. All of "good", plus: your Project instructions and Skill description are tuned enough that the outputs are reliably on-voice and correctly formatted without nudging; you showed the Skill firing on more than one phrasing or input; you were explicit about what the Skill guarantees (the shape) versus what it never guarantees (the truth of the content); and your write-up makes a clear, honest case for the next step, including any limit or risk you'd watch. Someone reading it could rebuild your setup and trust your judgement about where oversight belongs.

The gap between "good" and "excellent" is almost entirely verification and honesty, meaning how clearly you separate what the tools made reliable from what still needs a person, not how clever the setup is.

Evidence note

📎 Evidence note: Capture it as portfolio evidence

Keep the whole capstone as one piece of evidence: a screenshot of the Project's knowledge list and instructions, your SKILL.md, a chat showing the Project answering a real task straight from its files, a chat showing the Skill firing on a plain-language request, and your completed one-page write-up with the rubric score. Add a single headline line at the top, for example, "Built a reusable Claude onboarding Project plus an Ops Digest Skill; both demonstrated live and verified against source, with a human check kept on every fact that reaches a new starter." That headline plus the artefacts is exactly what you'd show a manager, and it demonstrates the full Power User skill: you can assemble Claude around real work, automate the repetitive part, and prove you did it responsibly.

Common mistakes

Demonstrating with a toy example. A Skill fired on "test test" proves nothing. Run both the Project and the Skill on a genuine task from the real strand of work. The realistic demonstration is the evidence.
A Skill description that doesn't trigger. If it fires only when you word the request just so, it'll sit unused in real work. Test several natural phrasings and widen the description until it catches them.
Overloading the Project. Twenty loosely related files make answers vague. Keep the knowledge tight to this one strand of work; start a second Project rather than stuffing the first.
Skipping the write-up's "where a human checks" line. If you can't name the step you kept for yourself, you haven't finished thinking about the risk. That line is where the judgement shows.
Over-trusting because it's both organised and automated. This is the capstone's central trap. A well-stocked Project and a reliable Skill make output feel doubly authoritative (rich context, consistent format) which is precisely when it's easiest to stop checking. The Skill guarantees the shape, the Project supplies the context, but neither guarantees the facts: Claude can still misquote a policy, blur two roles, or format a wrong figure immaculately. Trace the load-bearing facts to source every time, especially before anything reaches a new starter, a manager, or a customer. Demonstrating that you did this is what separates a champion from an enthusiast.

Keeping current

Projects and Skills gain capability regularly, and the surfaces around them (connectors, browser and Office add-ins) move faster still. The durable skill you've built here outlasts all of it: assemble the tool around a real strand of work, package the repetitive task, demonstrate on something genuine, and verify before you trust. When you revisit this setup, re-check each feature against its current help article and the Claude release notes, since limits and mechanics shift. Accurate as of 13 July 2026.

By the end, you'll be able to…

Why it matters