Here's how Week 5 goes
Week 4 ended with a Skill a teammate could inherit; this week your team builds the shared window those patterns live in.
The team window
List what your unit re-explains every week (who the partners are, how renewal runs, what the update looks like) and you have the contents of the team window.
A shared Project
One Project for the lane your team works: a partner portfolio, a renewal cycle, a report you produce together. Its instructions and knowledge load into every teammate's chats there.
Shared Skills
The moves everyone runs: the weekly update, the meeting summary, the branded one-pager. Written once in Week 4's format, run by anyone on the team.
One source-of-truth doc
The facts that change: dates, counts, statuses. A single doc with an owner and a date stamp, loaded wherever those facts matter.
- Pick the container with a teammate: one lane's Project, one Skill, or the source-of-truth doc, whichever your team re-explains most.
- Write it together and run the gate on every line and file: nothing identifying a scholar or family, nothing confidential to a partner or funder.
- Share it with the team. A Project shares from its own page where our workspace allows it. A Skill lives with each user, so share the text: a teammate pastes it into their own Skills, and it runs the same for them.
- Date-stamp it and name the owner before the week ends.
What your team re-explains weekly, written once.
Stale context misleads everyone at once
A wrong line in your own Project costs you one bad draft; the same line in a shared Project costs the whole team, chat after chat.
You rarely catch a stale line by reading it; it reads exactly like a true one. Here is a sample shared doc (the dates and templates are invented; the failure mode is real). Tap the lines that would mislead a teammate today: three of the six are stale.
Found 0 of 3 stale lines.
Your own stale note misleads you once, and you usually catch it because you wrote it.
Show why shared is different →
A shared line carries the team's authority. Teammates load it without questioning it, Claude grounds every draft in it, and nobody feels responsible for fixing it because everybody assumes someone else keeps it current. That last part is the real problem, and it is exactly what the next move solves.
Curation is a job
Every shared container needs one person whose name is on keeping it true.
Design your capstone
Capstone design opens now: pick one recurring workflow in your unit that earns a context system of its own.
Strong picks run on a rhythm (weekly, monthly, every cycle), involve more than one person, and start from the same setup every time. The monthly partner update, the coaching-week summary, and the renewal-season checklist all qualify.
- The workflow: What is it, and how often does it run?
- The people: Who runs it today, and who should be able to?
- The place: What context does it need every single time? That list becomes your Project.
- The method: Which steps repeat run after run? Those become your Skill.
- The proof: What shows it worked, twice in a row?
[Workflow: what it is and how often it runs.] [Who runs it today, and who should be able to.] [The context it needs every time.] [The steps that repeat every run.] [What proves it worked, twice in a row.] Help me design a context system for this workflow: what belongs in a Project's instructions, what belongs in its knowledge files, what belongs in a Skill, and what I should test first.
- Answer the five questions for one real workflow in your unit.
- Click Copy above, paste into Claude, fill the brackets, send.
- Read the design back against your unit's reality. Fix what Claude got wrong; it only knows what you loaded.
- Show a teammate and ask them to poke one hole in it.
Leave the week holding two names
Your workflow, and ideally a build partner. Tell each other this week, out loud or in writing; Weeks 7 and 8 build exactly what you just picked. No partner yet? Office hours are the matchmaking venue, and building solo is a complete path.
What you can do now
You can pool a team's context, spot what went stale, and put a name on keeping it true. Two of the 4Ds carried this week:
Delegation
You chose what the team hands over together: which lane gets a shared Project, which methods become shared Skills, which facts live in one doc.
Diligence
You ran the gate at team scale: an owner on every container, a date on every file, nothing identifying a scholar, small groups out.
This is your own check that the week landed. It stays in your browser — nobody else sees it.
Talk through your capstone pick.
Trade picks with a teammate, or bring yours to office hours, 9–10 AM ET any weekday. Hearing other picks will sharpen yours, and it's a good way to find a build partner. And if your team isn't in this yet: draft the shared container on your own as a proposal. Proposing it is this week's win.
Under the hood
Skip it and lose nothing. Three questions teams usually ask about sharing context.
What loads when a teammate chats inside a shared Project?
The same things that load for you: the Project's instructions and knowledge files enter the window before their first message, alongside their own instructions and whatever they type or attach. Their other chats stay out, and so do yours. The shared material is the common ground every teammate stands on, which is exactly why a wrong line in it spreads: every window in the Project starts from the same text, true or false.
Why does one source-of-truth doc beat five copies?
Five copies drift five ways. Each teammate fixes their own, nobody knows which is current, and Claude grounds each draft in whichever copy that person loaded. One doc with one owner and a visible date gives every window the same facts, and a single fix repairs everyone's next draft at once. The habit that makes it work is loading the doc itself rather than pasting from it, because pasted text stops updating the moment you paste it.
What goes in the shared container, and what stays personal?
Anything a new teammate would need on day one belongs in the shared container: the lane's standing facts, the methods everyone runs, the tone the team writes in. Your personal instructions, your drafts in progress, and context only you use stay personal. A working test: if two people re-explained the same thing to Claude this month, write it into the shared container; if only you ever load it, keep it personal.