Your week-by-week guide — what to do, an optional prompt to think with, and a two-minute reflection. Weeks 0 through 5 are open now; each later week opens here on its start date. Weekly reflections you submit go to the program team and shape office hours and the extension exercises. Shipped something? It belongs on What Teams Built. Joining late? Do Weeks 0–1 first, join your team at the current week, and backfill at your pace. Short on time? Seven minutes on a week’s “Your turn” box keeps the habit alive. And keep a running doc of prompts that worked; that library is yours to leave with.
Support, anytime
Reach out to Preston whenever; office hours run 9–10 AM ET every weekday
Extension exercises
A deeper optional exercise lands here every few Fridays
Nothing required
We are stronger when learning together.
Nothing in this section is required. The weekly prompts below work solo or with a teammate, and each extension exercise stands on its own.
Prompts by week · solo or with a teammate
WEEK 1 — WHAT CLAUDE SEES
The window — What did you put in the window this week that changed what came back?
The guess — Where did Claude guess because context was missing, and how did you catch it?
The gate — Name one thing on your desk that never enters the window. How would you describe the situation instead?
WEEK 2 — THE WINDOW OVER TIME
The signals — Did a chat go stale on you this week: repeating itself, forgetting an early rule, dragging old constraints in? What tipped you off?
The carry-forward — Did you end a chat with the wrap-up prompt and start fresh? What survived the move, and what did you have to re-add?
The task — What real recurring task did you run with a checked file and a five-part brief, and what did the one iteration fix?
Stuck, or it's not landing? Tell us.
A draft that fell flat or a week that didn't click is the most useful thing you can report. It tells us where the program is thin. Email the Innovation Hub at [email protected], bring it to office hours. This is a separate channel from a governance question — no judgment, and it shapes the next week.
What you need, when you need it.
Weeks 0 through 5 are open now. Each later week opens here on its start date — the dates show when your cohort reaches them.
Behind after the pause? Each week takes about 30 minutes. Do Week 2 before Week 3, since 3 builds on 2.
Get into Claude, win once on your own work, and see what it actually is. Week 0 is a guided half hour — no jargon, nothing to turn in. Start on the page below; it walks you in, and the Desktop App Tour covers signing in.
Get in, get one real win on your own work, and meet the machine — what a large language model actually is, learned by doing.
Start Week 0 →The click-by-click walkthrough of signing in and finding your way around the app. Week 0 links you here when you need it.
Take the Tour →What This Program Is — For You
Claude takes on drafts, summaries, and formatting. You keep the judgment, the relationships, and the decisions. The hours it returns go back to scholars and to your own development. This program is not connected to performance evaluation, and your assessment responses never leave the program team. Every AI output at DC CAP has a human owner: you.
The context window — what Claude sees, what never enters it, how to pack it for real work, and your first standing context.
Start Week 1 →Comprehensive guide to Chat, Cowork, Projects, Skills, and Connectors
View Guide →Week 1 showed you the context window in a single message. Conversations pile that context up, and the pile has rules: the window fills, details from the middle fade, and a fresh chat with a good carry-forward beats a marathon thread. This week you manage the window across time and run one real piece of your own work through it properly.
Week 2 is open — start on the Week 2 page. It's the source of truth for this week; the materials below are optional depth.
The Three Horizons
Everyone at DC CAP is climbing the same ladder:
This week is H1 by design. Get reps on your own deliverables. H2 starts in Week 3 when you build your first Project, and deepens in Weeks 4–5 as Skills arrive and capstone design opens. H3 is the capstone — what your unit ships becomes a pattern the whole organization can adopt.
The window across time — when to start fresh, how to carry decisions forward, what memory holds, and one real task run properly.
Start Week 2 →Delegation — choosing what to hand over — is the first of the 4Ds. This week you need two modes: Automation and Augmentation. The full framework is here when you want it.
View Framework →Data classification is the first delegation filter. Know what you can and can't hand to Claude.
View Framework →Should Claude get this task? Four questions before you delegate.
Keep human: individual scholar award decisions, performance feedback on a colleague, and anything where the relationship is the work.
Governance Pulse
Tier check before every task: Tier 1 never enters Claude. Pasted something you shouldn't have? Delete the conversation and tell Preston or Angela within 2 hours.
Pasted something you shouldn't have? Delete the conversation, then tell Preston Magouirk or Angela Cammack within 2 hours. Fast reporting is exactly the behavior we want.
If you lead a team: what tier does most of its recurring work sit in — and where's the biggest gain if you handle that tier well?
Every chat so far started from zero, with you retyping who you are and how we write. A Project ends that: standing instructions plus checked knowledge files that load into every conversation inside it. This week you build one for a real lane of your work.
Week 3 is open — start on the Week 3 page. It's the source of truth for this week; the materials below are optional depth.
The Four Containers
Every Claude move you make falls into one of four containers. The container is defined by what gets reused:
Projects — a place where your standing instructions and checked knowledge files load into every chat, built for one lane of your work.
Start Week 3 →A four-step decision tool for this week's challenge. Describe the work, name what's reusable, pick the container, draft the artifact. Print or fill in the browser.
Start Worksheet →The 4D model and three modalities. Container choice maps directly onto Automation, Augmentation, and Agency.
View Framework →A Project's reference files carry the data rules of whatever you load into them. Know the rules before you build.
View Framework →The job: Stay in genuine, on-brand contact with DC CAP's 13 university partners.
One-shot
"Draft a note to Georgetown's interim dean explaining why our timeline shifted this cycle." The dean is interim. The timeline shift was a one-time event. You'll never write this exact note again.
What's reused: nothing. The discipline: name why it's a one-shot, so you don't accidentally rebuild it next week.
Project — "Partner Engagement"
Stand up a Claude Project loaded with the partner contact list, current cycle dates, two past updates, and the DC CAP voice guide, each checked against the data rules first. Now any partner-related ask runs against the same body of knowledge: a draft email, a meeting brief, a check of what changed since last cycle.
What's reused: the context, across many different tasks, for weeks.
Skill — "Draft a Partner Email in DC CAP Voice"
Write the move down once. When to trigger it (any partner email, any topic). What good looks like (warm, professional, names the relationship, never asks twice). What to avoid (generic openers, formal closers that read cold). Now any teammate can run the same move for any partner — they describe the partner and the topic inline; the procedure stays consistent.
What's reused: the move, across all 13 partners and every topic.
Automation — "Quiet Partner Watch"
Every Monday morning, surface partners DC CAP hasn't touched in 30 days, with a one-line suggested reach-out for each. The trigger fires on its own. The reach-outs still pass through a human — but no one has to remember to look.
What's reused: the trigger. The work runs on a cadence, triggered automatically.
Takeaway: The same job takes four shapes: the Project holds the workspace, the Skill holds the move, the Automation holds the trigger, and the one-shot is the deliberate exception. Teams that pick the wrong container end up rebuilding the same prompt every Tuesday.
Going Deeper — Container Design (previews Weeks 4–5)
The assignment lives on the Week 3 page: build one Project and run three tasks inside it. Want the Weeks 4 and 5 preview? Pick one Claude move from your last two weeks and answer in three steps:
Trade what you built with a teammate, or bring it to office hours. The question worth asking: whose Project should the rest of us copy?
Governance Pulse
The reference files in your Project carry their data rules with them: anyone with Project access has access to that data. Before you build, ask two questions. What is the most sensitive thing I'm about to load? Who should and shouldn't be in this Project? If you lead a team: if your team builds three Projects this month, that's three governance decisions you own.
A Project is a place; a Skill is a method. This week you take a task you've done three times the same way and write it down once — trigger, steps, one example, guardrails — so Claude can repeat it on demand and a teammate can inherit it.
By the end of this week you can: tell a place from a method, write a skill with trigger, steps, example, and guardrails, test it on fresh input, and share it with your team.
Week 4 is open — start on the Week 4 page. It's the source of truth for this week; the materials below are optional depth.
Four weeks of building your own context. This week your team pools it: a shared Project, shared methods, one source-of-truth doc, each with an owner, a refresh rhythm, and the same tier gate on everything that enters. Capstone design opens: pick the workflow you'll build — or keep the weekly-wins path; both count.
Week 5 is open — start on the Week 5 page. It's the source of truth for this week; the materials below are optional depth.
Until now you packed the window by hand. In agentic work Claude packs it itself, searching, opening files, and deciding what to read next — same window, new editor, which is why your oversight scales up: you review what it read, not just what it wrote. This week you pick your capstone scope; a Friday self-deadline helps.
The full Week 6 page opens Monday, August 31. We're refreshing the materials below to match the context-management arc — when the week opens, the Week 6 page is the source of truth.
Build week. You assemble the system you scoped in Week 6: a Project for the place, a skill for the method, a rhythm that keeps it true — with a worked example to borrow from and an unblock guide for the common stalls.
The full Week 7 page opens Monday, September 7. We're refreshing the materials below to match the context-management arc — when the week opens, the Week 7 page is the source of truth.
New here? Your capstone can be one small Skill built from a task you already do — that is the whole job. The eleven-agent system below is a guided tour of how far this goes — read it for the shape, then build at the size that fits your week.
The agent has no expertise. The designer has the expertise.
The Four-Stage Ladder — Smallest Container That Survives the Job
Each rung answers a bigger reuse question, and promotion is cheap. (Week 3 sorted moves into four containers by what gets reused; this ladder orders the build effort. A Skill travels with a person, a Project is a shared place — the ladder ranks effort, not containment.) Start small and move up only when reality demands it.
Builder’s corner. Everything below this line is optional depth for the build-curious: how the Innovation Hub structures big builds. Your Week 7 is the Week 7 page; if file trees aren’t your thing, skip all of this and lose nothing. And if this is exactly your thing: the path past Stage 3 runs through a conversation with the Innovation Hub — bring to office hours a shipped Stage 2 or 3 build, its handoff map (who produces what, who reads it), and the verification gates you would put between the steps. That spec is the entry ticket.
financial_modeling? Open this first — 90-second orientation ▾financial_modeling is DC CAP's strategic finance tool. It combines three live data streams — fundraising estimates (Development), historical-and-projected costs and revenues (Finance), and market projections from Pathstone (DC CAP's investment partner) — into one view of DC CAP's financial position through FY35. Inside the tool, eleven named AI agents work with verification gates between every handoff: fpa-lead routes, fpa-data-engineer ingests, fpa-quant runs the math, fpa-storyteller writes. Names are illustrative; the point is one job per role.
We use it as the worked example because every Stage 4 orchestration shares this shape, and seeing it whole makes Stages 1, 2, and 3 land harder. Most participants will build at Stage 2 or 3 for their team. Stage 4 is study material — one person attempting it would be a win.
Your first move — pick your artifact.
Four real artifacts, one per stage, all grounded in ~/Desktop/BRAIN/projects/financial_modeling/ so every claim is auditable on disk. Pick the stage that matches what you'd build for your team. No homework — read the one that fits.
Stage 2 and Stage 3 — Where Most Builds Live
Skill and Project are the two stages most teams will build. Both have a concrete, file-level shape. A Skill is one expertise pattern any Claude session can load on trigger. A Project is one team's full workflow surface, always loaded inside that Project.
Stage 2
my-skill/ ├── SKILL.md ← name + description (frontmatter) │ + instructions (under 500 lines) ├── scripts/ ← deterministic code (optional) ├── references/ ← docs loaded as needed (optional) └── assets/ ← templates, files for output
Three loading levels — progressive disclosure
The description carries the trigger
Skills tend to under-trigger. Write the description with both what the skill does and the concrete contexts where it should fire. Be slightly pushy: name the user phrases that should fire it. The first thing that ever fails on a skill is usually the description.
DC CAP examples already live in the library: preston-writing, funder-framing, dc-cap-org-intelligence, sf-demo-data, executive-summary-formatter. Each one is a single SKILL.md plus the references it needs.
What preston-writing demonstrates
A maintained Stage 2 skill carries three disciplines beyond "one SKILL.md plus references." The walkthrough shows each one observable on disk:
Each one addresses a real failure mode: generated prose that drifts from the author's voice, rules that lose their grounding, and AI tells a word-list never catches.
Stage 3
My Project ├── System instructions ← role, voice, format, │ scope rule, escalation ├── Reference files ← curated, named, │ anchored top + bottom ├── Governance config ← data tier + restricted │ topics + escalation path └── Workflow doc ← how the team uses it
Loads in full at conversation start
A Project loads its full instructions and reference files at the start of every conversation that lives inside it. A Skill loads on trigger. Inside a Project, you can also chain Skills — the Project sets the surface, the Skills add expertise where needed.
What goes in instructions vs. files
Artifact C (financial_modeling as a Project) walks this end-to-end — a Project that chains preston-writing, data-interpreter, and dccap-brand as Skills, with the FY26 model and IC memo template as reference files. That chained-Skills shape is the most common real-world Project.
The official Anthropic guidance for building Skills lives in the skill-creator skill itself — load it whenever you start a new Skill build. The H3 walkthrough's §5 shows how the same shape composes across eleven agents inside the financial_modeling orchestration.
The plain answer. Choose the smallest container that survives the job. One person, one recurring task — a Prompt is enough. The team does the same thing repeatedly — Skill. Multi-step workflow with files, audience-specific output, and governance constraints — Project. The work crosses roles and needs an audit trail — Orchestration. The upgrade path is cheap: start at the smallest stage that survives the job and promote only when reality demands it.
Where it breaks. People reach for Orchestration because it sounds impressive, then nobody touches it because the Skill version would have shipped weeks ago. Or: people stay at Prompt when the work has clearly outgrown chat — the same instructions get pasted into Claude every Monday morning and nothing accumulates.
The move. Default to the smallest container. The signal to move up: the prompt is getting copy-pasted into team chats, or the team is asking "how do we do this consistently?" Most builds will stop at Stage 2 or 3. That is the right call.
Start small. Promote when the work demands it.
The plain answer. The build encodes your knowledge in a form Claude can apply at scale. If you cannot explain to a teammate, in 90 seconds, what "good" looks like for this job, the spec is too thin. The spec is what carries the expertise. The model carries the execution.
Where it breaks. People ask Claude to "do X like a [job title]" and expect the model to fill in what that job actually entails. The output looks fine on the surface and falls apart at the corners — exactly where the actual expertise would have shown up. The failure mode is always in the spec. The model produced what the spec asked for.
The move. Two reps before you build:
funder-framing, preston-writing, executive-summary-formatter — each one is loadable expertise.The failure mode lives in the spec. The model executes what the spec asks for.
The plain answer. A simple build has one role. A complex one has several, each with one job and an explicit handoff to the next. The signal to split: the role description reads like a small org chart inside a single instruction. The signal to keep it together: the workflow is one person's standard move, end to end.
Where it breaks. People stuff everything into one prompt — the model has to be eight things at once and is none of them well. Or: people split too aggressively and the handoffs eat the gains. Either way, the work suffers because the spec did not decide.
The move. Name each role, what it produces, and what the next role reads. That is the handoff protocol. The financial_modeling tool is the worked example: fpa-lead dispatches, fpa-data-engineer ingests, fpa-quant models, fpa-insight-hunter finds the Pareto, fpa-storyteller writes the Big Idea. Each output a state file the next agent reads. Lead never overwrites; Lead routes.
One job per role. Explicit handoffs between them.
The plain answer. Instructions are the durable spec — role, voice, format, the rules that should hold across every conversation. Reference files are the source material the build can quote. Anything that changes weekly belongs in files. Anything that should hold across every run belongs in instructions.
Where it breaks. Instructions balloon into 2,000-word monologues that bury the most important rules. Or: files get dumped without curation and the model attention-decays through them (Week 2 — lost in the middle is a real cost). Either failure traces to the same root: the designer never decided what was rule and what was source.
The move. Two disciplines:
Instructions are the rules. Files are the world the rules apply to.
The plain answer. Most real builds chain two or three pieces of named expertise. A voice skill. A domain skill. A verification skill. Naming the chain at design time is what makes the build inheritable. A teammate picking it up sees, in one place, exactly which expertise is loaded.
Where it breaks. People build one mega-skill that does everything. It is hard to update, hard to debug, and hard for anyone else to extend. Or: they do not name the chain at all, the build works for the original designer, and falls apart in a teammate's hands.
The move. Write down the chain. A grant draft chains funder-framing + preston-writing. A board brief chains executive-summary-formatter + data-interpreter. (The financial_modeling chain is much larger — the H3 walkthrough has the full list.) Each chained skill is one piece of expertise the build no longer has to invent.
Name the chain. The chain is the inheritance.
The plain answer. Most builds need less than people think. Web search, file read, code execution — each tool adds a surface that has to be governed. Default to the minimum tool set. Add a tool when the workflow cannot run without it. Tools that ship off-by-default ship off-by-default for a reason.
Where it breaks. People enable every tool because "more capability is better." The build then does things they did not intend — sends an email, modifies a file, queries live data — and the team has to clean up. Permissions creep up over time as one-off needs become defaults.
The move. For each tool you plan to enable, write down two answers: what is the worst case if this fires incorrectly? and who catches it before it ships? If either answer is unclear, the tool stays off until you can answer both.
The smallest tool set is the safest tool set.
The plain answer. Good is what your team would call "ready to ship" with you out of the room. Failure modes are the specific ways this build will break — and they fall into three buckets.
Three failure-mode buckets — cosmetic, costly, catastrophic
Where it breaks. People design for the happy path and ship. The first costly failure surfaces something the spec never named — there was no row for it in the failure-mode map because there was no failure-mode map. Or: people over-design for catastrophic failures that the data tier already rules out.
The move. Write the failure-mode map before you ship. One row per failure mode, with the bucket, the early-warning sign, and the gate that catches it. The Audit Picker maps gates to artifact type →
A build without a failure-mode map is a build that ships its failures.
The plain answer. Every build needs three explicit lines: a verification cadence (the audit picker’s light, standard, or full pass), an iteration cadence (how often instructions and files get revisited), and a governance line (which data tier, which escalation path). These three lines decide whether the build survives 12 months or fades in six weeks.
Where it breaks. A build ships with no review cadence. Six weeks later the data has moved, the team has changed, and the outputs are confidently wrong. Or: governance is implicit — "the team knows" — and the first cross-unit reuse leaks something the original team would never have shared.
The move. Write three lines into the build itself:
A build's longevity is the discipline of its cadence.
The eight questions answered against a real production build: eleven AI agents, thirteen expertise references, four verification gates. Study the architecture; nobody is expected to ship Stage 4 themselves.
Open Walkthrough →The session deck. The eight questions live, with the H3 financial_modeling walkthrough as the worked example. Bring your build sketch.
Open Deck →Your Build — A Skill or a Project, for Your Team
Build one Stage 2 Skill or one Stage 3 Project your team will actually use. Bring the draft to office hours. Stage 1 is the warm-up. Stage 4 is study material — if one person ends up attempting it, that's a win.
If you stall on Q2 — "do I have the expertise to spec this work?" — that gap is the most useful finding of the week.
Capstone Bridge — Week 8
Each unit finishes and shares a build its team can run — the Week 8 page walks the ship checks. The capstone window closes Friday, September 25, and the post-program assessment stays open throughout.
Knowing when to stop the ladder is the discipline.
Governance Pulse — Data Tier Sets the Floor, Stage Sets the Ceiling
Tier 4 (public) work runs comfortably at Stage 1 with a light gate. Tier 3 (internal strategy) usually wants Stage 2 with a standard gate. Tier 2 (sensitive partner / operational) requires Stage 3 with explicit governance config and a full gate before any external send. Tier 1 (FERPA / PII) does not touch Claude at all. The data tier sets the verification floor; the stage of build sets the ceiling on how much workflow inheritance the team can take on.
If you lead a team: the stage you pick for your team's build is the stage every workflow at that level inherits. Picking Stage 3 with no governance line is a decision with shape — your team is now operating a Project with no escalation path, and the first time a Tier 2 question lands inside it, that gap shows up in the output.
Finish it, document it, show it. A capstone ships when it works twice in a row and a teammate can run it from the write-up alone. Demos happen wherever your team meets; the post-assessment closes your loop, and the capstone window closes September 25.
The full Week 8 page opens Monday, September 14. We're refreshing the materials below to match the context-management arc — when the week opens, the Week 8 page is the source of truth.
If you are new to this, you are exactly who it is for. A Skill and a Project both make the repeating parts of your work easy for anyone to run. Most builds are small, and a small build your team actually uses is the win.
Week one · Build
Choose one thing your unit does over and over. Turn it into a Skill so anyone can run it. Start a Project to hold your team's shared files and rules. Office hours are open if you want a hand.
Week two · Share
Finish the Skill and the Project, then share them — the Project with your team, the Skill as text a teammate pastes into their own Skills. The test is simple: a teammate opens your build and gets a good result without you in the room.
Before the all-staff · Done
Your build lives where your team already works: a shared Project your team can open, or a Skill shared as text a teammate loads into their own Skills (Week 4 shows how). The showcase is optional. The post-program assessment stays open if you want it.
You already work this way. Over eight weeks we named the five working parts underneath it. Read the map from the floor up: classify the data, pick the skills the task needs, choose how much the AI does, choose what to build, then check the result before it goes anywhere. The full walk is in the new deck below.
These are the two "containers" from Week 3 that live at the team level. One packages how your team does something. The other packages what your team works from. You are making one of each — and a Skill on its own already meets the bar.
A Skill — your team's best move, written down once
Take something your unit does again and again and teach Claude to do it your way. Anyone on the team runs it and gets your best version, every time. Plain sign you need one: you keep pasting the same instructions into chat.
In your world: a student-outreach message, a partner update, a weekly data clean-up, a governance-QA check.
A Project — your team's shared workspace
Put your unit's working files and rules in one place so Claude answers from shared context. Anyone on the team opens it and drafts from the same starting point. Plain sign you need one: people keep re-explaining the same background.
In your world: a funder-update workspace, an analysis Project, an onboarding Project for the next person who joins.
Where to start — pick your lane
The synthesis deck. The five working parts you already run — governance, the 4 D's, the 3 A's, the four containers, the eight questions — and why a Skill and a Project are the team build. Start here.
Open Deck →A finished Skill taken apart — the preston-writing case study. Read it as the template for your own: what goes in, how it stays short, how the team runs it the same way every time.
Open Example →A finished Project taken apart — financial_modeling. What files go in, what rules go in, how the whole team drafts from one shared context instead of re-explaining it.
Open Example →Two minutes to decide whether your task wants a Prompt, a Skill, a Project, or more. The worksheet from Week 3 that answers the first question on the ladder.
Open Worksheet →First check. Before a build goes to your team or the org, confirm it only touches the data tiers your unit is cleared for. The four-tier framework and the escalation path.
View Framework →The advanced lane. Preston's financial_modeling orchestration end to end — three data streams, eleven agents, four verification gates. What a Stage 4 build looks like once it's earned.
Open Deck →The same five-construct check from Week 1. Your baseline is already saved. Retake it whenever you're ready to see your own 8-week growth.
Retake Assessment →The worksheet for your build: what it does, who it's for, the workflow, and the data-tier ceiling. Fill it in as you build your Skill and Project.
Open Template →These Two Weeks — Build It, Share It
Finish the build your unit chose — a Skill or a Project a teammate can run. Run it through the quality questions, confirm the data tier, then share it: the Project to your team, the Skill as text a teammate pastes into their own Skills. Office hours stay open every weekday if you want a hand.
The bar is simple: a teammate opens your build and uses it without you in the room, and ideally anyone in the org can too.
What Carries Forward
The program closes. The work continues. Each build you share becomes a teammate inheritance — the next colleague who runs the workflow opens the Skill or the Project you wrote.
We check in on how the builds hold up over the following months and decide together what becomes a DC CAP-wide pattern.
Governance Pulse — The Last Check Before You Share
Before a Skill or Project goes to your team, run the floor check. Does it only touch the data tiers your unit is cleared for? Have you named the escalation path with real people? Have you run the eight quality questions on what it produces?
Your scope: the build goes out under your name, so the spec is yours to get right. A teammate inherits exactly what you wrote.
You CAN:
Check First:
If your task involves student names, financial details, or partner-specific terms → consult the governance framework
Always:
Review every output before sending. Claude drafts; you own what goes out.