Welcome to the DC CAP AI Program
Enter your full name to begin or resume your onboarding progress. Your progress syncs across devices.
Please enter your full name to continue.
Your week-by-week guide — what to do, the AI Fridays discussion prompt, and a two-minute reflection. Week 0 is open now; each later week opens here when it is ready.
Starting Week 2
Your invite arrives with your cohort start date
35 Minutes
Structured session time
Optional, Highly Encouraged
We are stronger when learning together.
Check your calendar for the recurring invite. Weeks 0–1 are self-paced onboarding and foundation; AI Fridays begin Week 2. Come when you can — each session stands on its own, and we recap anything you missed. Didn't get to this week's challenge? Come anyway. Listening counts.
Opening (5 min)
One question from this week's challenge: "What did you try? What happened?"
Core (20 min)
Share what you noticed: patterns, surprises, connections to your team's work. Peer exchange and cross-unit learning.
Close (10 min)
Governance pulse check + preview of next week's challenge.
Discussion Prompts by Week
WEEK 2 — DELEGATION
Personal output (H1) — What is something you did with AI this week to strengthen your own work output? What worked, what did you have to fix?
Delegation — Was it Automation or Augmentation? How did you decide? Where did you hesitate?
Team & enterprise (H2 / H3) — Did this also create something your team could use or benefit from? Did it make possible an organization-wide skill or capability DC CAP doesn't have today? If not, could it have — and how?
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], say it to any champion, or raise it at a Friday close. This is a separate channel from a governance question — no judgment, and it shapes the next week.
What you need, when you need it.
Week 0 is ready now. The later weeks open here as we finalize each one — the dates show when your cohort reaches them.
Week 0 is open now. The later weeks open here as we finalize each one.
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 →By the end of this week you can: describe a situation instead of pasting a record, name the tier of anything on your desk (including the small-group trap), brief Claude with the five-part brief, and hand over one real task safely.
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 one habit that keeps scholar data safe, the four tiers, the five-part brief, and your first real hand-off.
Start Week 1 →Interfaces, files, skills, governance, responsible use
View Reference →Comprehensive guide to Chat, Cowork, Projects, Skills, and Connectors
View Guide →Ten drag-and-drop scenarios, ~10 minutes, no Claude account needed. The one habit that protects scholars from day one.
Start Practicing →Nothing is due these two weeks — the program lead is out, and we resume at Week 2 on Monday, August 3. Your seat and your progress stay exactly where they are. Access is open, so keep practicing on your own whenever you like.
Every time you hand work to Claude, you're making a delegation decision. Are you automating — giving Claude a defined task and reviewing the result? Or augmenting — thinking alongside Claude to shape something together? Start with the work on your own plate this week and notice which mode fits.
By the end of this week you can: run one real deliverable through Claude, say whether you automated or augmented and why, and stop yourself before Tier 1 or 2 data goes in.
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 name your first reusable pattern, and deepens in Weeks 4–5 when you design your Claude Project. H3 is the capstone — what your unit ships becomes a pattern the whole organization can adopt.
Delegation 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 →Task: Prepare DC CAP's quarterly funder update for KPMG.
H1 · Personal (this week)
Quick tier check first: FY26 retention at 85% is a de-identified aggregate (Tier 3), the April 6 launch is public (Tier 4), and the partnership went out in last month's press release (Tier 4). Nothing Tier 1 or 2 — cleared. Now paste the three data points into Claude: "Draft a one-page KPMG update. Professional tone. Include a subject line." You review, edit, send. The draft is faster. The judgment stays yours.
Delegation: Automation this time — you handed off a defined draft. Outlining it together first would have been Augmentation. Both are H1.
H2 · Team (within 4–6 weeks)
You notice every funder update your team writes follows the same shape. You turn the prompt into a Claude Project: system instructions that name KPMG's priorities, the quarterly cadence, DC CAP's tone, and a link to the latest retention data. Anyone on the development team now produces a funder-ready first draft in ten minutes.
Delegation: your judgment moves into the Project's instructions, and every teammate's first draft starts from that shared pattern. A Project can run as Automation or Augmentation — the shared container is what makes it H2.
H3 · Enterprise (this program)
Three units surface the same pattern — development, academic affairs, operations. DC CAP stands up one external-update engine: a shared Claude Project with governance-tier rules, voice calibration, and required review steps. The whole organization produces on-brand external communications at speed.
Delegation: this is where the third mode, Agency, eventually lives — Claude operating inside guardrails leadership sets. The capstone climbs toward it in Weeks 7–8. Nothing about it is this week's job.
Takeaway: The same task lives at three horizons. Week 2 is H1 reps. The H2 moment is when your own work starts looking like a pattern. Notice it — that's the capstone signal.
Task: Re-engage scholars who missed their midterm check-ins.
H1 · Personal (this week)
Tier check first: scholar records are Tier 1. Names, IDs, GPAs — nothing from Salesforce enters Claude, ever. So you describe instead of paste: "I'm a success coach writing to a first-gen sophomore who missed two check-ins, with midterms next week. Draft three short check-in messages in a warm, non-judgmental voice. I'll personalize before sending." Claude needs the situation. The student stays out of it.
Delegation: Automation. You review, personalize, and send — the judgment and the relationship stay yours.
Takeaway: The Tier 1 rule is why direct-service staff describe instead of paste. The pattern still works — and when your whole team starts using it, that's an H2 pattern worth naming in Week 3.
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.
This Week's Challenge
Take a real deliverable from your week and run it through Claude. Then bring three answers to Friday:
Governance Pulse
Before you start, check: what data tier does this task involve? Tier 1 never goes into Claude — no exceptions. Tier 2 requires role-specific access — confirm yours in the framework first. Tiers 3 and 4 are cleared for all licensed users.
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?
Week 2 was reps. By now you've seen Claude help with real work — and you've also seen drafts that fell flat. This week is the move that turns reps into patterns: describing the unit of work precisely enough to know what kind of thing you're building. A one-shot? A Project? A Skill? An automation? Each one reuses something different: the context, the move, or the trigger. Naming what's reusable is how your H1 reps become H2 inheritance.
By the end of this week you can: describe a task precisely enough to know what kind of thing it is, pick a container and say what it reuses, and write the context Claude doesn't already have.
The Four Containers
Every Claude move you make falls into one of four containers. The container is defined by what gets reused:
The Description sub-skill: you can't pick the right container until you describe the unit of work precisely. What is the work? Who's it for? How often does it happen? What does good look like? Description is the design step that comes before container choice.
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 →Containers bake governance in. A Project's reference files carry the data tier of whatever you load. Know the rules before you build.
View Framework →The job: Stay in genuine, on-brand contact with DC CAP's 14 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, MOU terms, every email sent in the last year, the DC CAP voice guide, and current cycle dates. Now any partner-related ask runs against the same body of knowledge: a draft email, a meeting brief, "what did Howard say in February?", a side-by-side of how three partners responded to the same ask.
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 14 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: Same job, four shapes. The Project is the workspace. The Skill is the move. The Automation is the trigger. The one-shot is the deliberate exception. Picking the wrong container is how teams end up rebuilding the same prompt every Tuesday.
In Week 2, a success coach described a situation to Claude and got three scholar check-in messages back, no names attached. That was an H1 rep. This week, the same coach notices she does that every Monday for every scholar who went quiet. The rep is a pattern. Which container?
Describe the work
The unit: a warm, non-judgmental re-engagement message to a scholar who missed a check-in. It happens weekly, for any coach, across every campus. Good means it sounds like a person who knows the student, never names the student to Claude, and gives the coach three options to personalize.
Name what's reusable, then pick the container
The context changes every time, which rules a Project out. The student does the changing; the move stays the same. That makes it a Skill: "Re-engage a Quiet Scholar." The procedure writes down the describe-don't-paste rule (Tier 1 never goes in), the voice, and the three-option format. Any coach on any campus runs the same move and gets the same quality.
Takeaway: The funder example earlier and this one land in the same place. One person's good rep, named precisely, becomes a move the whole team inherits. That is what turns H1 into H2, and the governance rule rides inside the Skill so nobody has to remember it.
This Week's Challenge — Container Design
Pick one Claude move from your last two weeks. Answer in three steps:
Bring the artifact to AI Friday. Friday's question: whose Skill should we steal? Whose Project should be a Skill? What did someone automate that the rest of us are still doing by hand?
Governance Pulse
Containers bake data classification in. The reference files in your Project carry their tier with them — anyone with Project access has access to that data. Before you build, ask: what tier 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.
Week 3 named four containers. Week 4 answers the harder question: not everything that could be a Project should be a Project. This week you run every candidate through a five-part filter and decide what earns its keep. Each unit ships one team asset by the end of the week. Everyone runs the filter on their own work, whether or not they own the build, because knowing what not to build is the skill. The sharper the customization, the more the build replaces tribal knowledge instead of duplicating ChatGPT.
By the end of this week you can: score a candidate build on the five criteria, load one outside source that raises the floor on what Claude can do, and watch a teammate use a build and name what confused them.
The Build Filter
Five questions decide whether the work in front of you deserves a Project or Skill. If three or more are clearly yes, build it. If not, put it down — pick a different candidate.
The Discernment cut: the wrong build wastes the team's time. The deliberate "no" is just as much of a real decision as the build itself.
The candidate: a coordinator wants to build a Project that drafts the monthly all-staff newsletter. It sounds like a clean win. Run the five questions before you commit a week to it.
One soft yes out of five. The filter says no. The newsletter stays a monthly one-shot, and the coordinator keeps the week. That is the filter doing its job.
Takeaway: A "no" is a finished Week 4 deliverable. If your filter kills your first candidate, you did the week right — bring the scored sheet and the kill to Friday. The build that survives the filter is worth more than three that should never have been built.
The Customization Play — Make it your team's
A team build is only worth keeping if it carries something Claude doesn't already know. Three vectors decide depth:
Score your candidate against the five criteria. Three "yes" or more, you build. Print or fill in the browser.
Run the Filter →Three real anatomies — a team Project, a team Skill, and a deeply customized Skill — with the actual specs. Steal the structure for your own.
Open Gallery →Custom instructions and reference files carry data tiers. Verify the tier of every file you load before the team inherits it.
View Framework →The candidate: a Skill that drafts and edits anything Preston will sign — board memos, donor briefs, LinkedIn posts, conference remarks — in his voice.
Without customization
Generic AI prose. Banned words sprinkled through every paragraph. Em-dash chains. Hedged closes. Drafts that sound like every other LinkedIn post — and require a full rewrite before Preston will put his name on them.
Three sources loaded
Org context (DC CAP voice rules; the explicit banned-word list; the accessibility-and-impact framing). Outside authority (a curated .md archive of Preston's own published writing — fifty paragraphs from prior work that the voice was actually built on; the BLUF structural pattern from executive-communication standards). Workflow shape (BLUF order enforced, banned constructions named, the human checkpoint before anything goes out).
What the team inherits
First-pass drafts arrive with the voice intact. Light edits replace structural rewrites. The structural pattern — BLUF, separate banned-words and banned-constructions lists, a curated archive of own work as reference — is portable. Any DC CAP author can lift the shape and fill it with their own voice. The Skill replaces the implicit judgment that used to mean re-reading every draft three times.
Takeaway: the depth of customization is the difference between a Skill that saves five minutes and one that replaces a whole layer of tribal knowledge. See three full anatomies →
Three real Preston-owned skill files in active use at DC CAP — the SKILL.md is the part you can copy. Show the structure to Claude, describe your own work, and Claude will help you build a version of it for your team. Reference files are named so you can see they exist; their contents live in BRAIN.
Build 01 · One skill inside a 5-agent system · Reuses context
dev-office-director
Compiles the week's grant prospecting activity into a 5–7 slide branded briefing deck for Eric. Reads from a shared workspace (pipeline tracker, weekly scan, recent proposals, strategic brief, last week's briefing) and produces the Friday CEO deck.
This is one of five agents. The Director sits inside a larger Development Office system that also runs Scout (finds funding opportunities each Monday), Fit Analyst (scores opportunities + builds funder dossiers), Grant Writer (drafts proposals), and Strategic Auditor (4-lens review of every draft). Each agent is its own SKILL.md with strict context boundaries — no agent reads everything. The system runs on a Mon 8am scan / Fri 3pm briefing cadence with a shared .learn/ memory so the whole system gets smarter over time.
SKILL.md (condensed from the real 173-line file — copy this structure and Claude can help you adapt it to your team's weekly artifact)
--- name: dev-office-director description: Development Director agent for DC CAP's Grant Prospecting & Proposal Pipeline — compiles the week's activity into a branded CEO briefing deck for Eric. Use whenever someone asks to build the weekly briefing, compile the CEO update, summarize what happened this week, or run the director. --- # Development Director You compile the week's development activity into a clear, branded briefing deck for Eric. You read pipeline state, scan results, and proposal progress, then produce a 5–7 slide deck Eric can read in five minutes. You don't search for grants, assess fit, write proposals, or audit drafts. ## Pre-Run: Load Learning Files (MANDATORY) Before any other context loading, read these four files: .learn/errors.md — past failure patterns to screen against .learn/canonical.md — single source of truth for every DC CAP figure .learn/glossary.md — load-bearing phrases to use verbatim .learn/lessons.md — durable lessons from prior runs These files are the durable memory of the Development Office. Reading them at session start prevents recurring errors. Do not skip. ## Context Loading Read these files (and only these): 1. pipeline.md — living pipeline tracker 2. scans/YYYY-WNN.md — this week's scan (most recent) 3. proposals/ (last 7 days) — recent proposal activity 4. strategic_brief.md — pipeline table only 5. briefings/ (last) — for tracking week-over-week movement Do NOT read strategy.md, preston.md, org_intelligence, or scan_criteria.md. ## Skills to Invoke - dccap-brand → colors, typography, logo (CEO palette) - pptx → build the actual file - preston-writing → MANDATORY voice check before saving - data-interpreter → metric framing for CEO audience - checking-communications → final policy/voice/brand pass ## Briefing Deck Structure (5–7 slides, skip if empty) 1. Title — week of [Mon] – [Fri], DC CAP branded 2. Executive Summary — BLUF: what happened → so what → decision needed 3. New Opportunities — Funder | Opportunity | Lane | Deadline | Amount 4. Fit Assessment — Funder | Tier | Rationale (highlight Pursue tier) 5. Pipeline Status — full pipeline + week-over-week movement 6. Proposals in Progress — Funder | Status | Version | Findings | Next 7. Recommended Actions — numbered, specific, owner-named ## What You Do Not Do - Search for grants (Scout's job) - Assess fit (Analyst's job) - Write proposals (Writer's job) - Audit drafts (Auditor's job) - Editorialize beyond the data — report, recommend, stop ## Verification Gate (MANDATORY — Gate 4) No Tier 4–5 claim reaches Eric without an explicit flag. 1. Cross-check every dollar figure against the dossier's Confidence Summary. Unconfirmed figures get [unconfirmed] in the deck OR get omitted. 2. Cross-check every deadline. Unverified deadlines get [unconfirmed]. 3. Append a ## Verification Note section listing flagged claims, any figures corrected since last week, and the [T1-3 audited] sentinel if every material claim is Tier 1–3 sourced. 4. The PostToolUse hook blocks saves missing the sentinel. ## When You're Done Report: "Weekly briefing complete for Week [NN]. Deck saved. [N] new opportunities, [M] assessed, [K] proposals in flight. Gate 4: [T1-3 audited / X claims flagged]. [X] actions for Eric."
Filled example — the shape of the Director's weekly output (all funders, figures, and dates invented for illustration)
# Development Office Weekly Briefing # Week of October 5 – October 9 | W41 Friday Operating Briefing # Read time: 4 minutes ## Bottom Line Up Front - Pursue-tier pipeline holds at 4 funders. Confirmed ceiling ~$700K. No new Pursue-tier opportunities this week. Jan 15 submission window is 98 days out. - W41 scan added 3 Watch prospects. [Foundation A] (Dec 1 deadline, 57 days), [Foundation B] (rolling), [Trust C] (rolling). All Tier 5 sourced. Tier 2 verification required before actioning any. - [Pursue Funder X] cold intro must go out today. No reply by early November = Jan 15 application window closes. - Two ED actions remain open from W40. [Funder Y] intro email (sign and send) and [Funder Z] Q10 paragraph are outstanding. ## Pursue Tier — Full Status | # | Funder | Fit | Status | Deadline | Ask | Next Action | |---|---------------|--------|---------------------------|-------------------------|-------------------------------------------|------------------------------| | 1 | [Foundation 1]| 36/40 | In Review | Jan 15 (98d) | $400K | Q10 paragraph from the ED | | 2 | [Foundation 2]| 34/40 | Greenlit — intro drafted | Jan 15 (98d) | Up to $150K | Director sends cold intro | | 3 | [Foundation 3]| 31/40 | Writer Unblocked | Jan 15 (portal Dec 1) | $90K | Writer drafts LOI when open | | 4 | [Foundation 4]| 29/40 | Greenlit — intro ready | Rolling | Est. $50K–$100K [UNCONFIRMED — T5 only] | ED reviews and sends | Confirmed Pursue-tier ceiling: ~$700K (Foundation 1 $400K + Foundation 2 up to $150K + Foundation 3 $90K. Foundation 4 excluded — dollar range is Tier 5 only.) ## Verification Note All material claims Tier 1-3 sourced. [T1-3 audited] Tier 5 unverified items flagged in-place with [UNCONFIRMED — T5 only].
Steal this: a Project-flavored Skill earns its keep when (a) it loads from a fixed list of files, not "all of BRAIN," (b) it has an explicit "What You Do Not Do" so it doesn't drift into other agents' lanes, (c) it ships with a verification gate that blocks saves of unverified claims, and (d) the output flags its own confidence — the [UNCONFIRMED — T5 only] tag in the table is the discipline that lets Eric trust the briefing cadence. The boundaries are the design.
Build 02 · Skill · Reuses the move
adversarial-audit
Multi-agent adversarial review for any artifact — grants, strategy docs, board materials, presentations, emails, thought leadership. Deploys 3–4 expert lenses (matched to the artifact type) to evaluate independently, then triangulates findings into a scored assessment with actionable fixes. Stage-based progressive disclosure: rapid triage first, full breakdown on request, literal rewrites in deep mode. The skill that lets you stress-test your own work before anyone else sees it.
SKILL.md (condensed from the real 147-line file — copy this structure and Claude can help you adapt the panels to your team's artifacts)
--- name: adversarial-audit-cowork description: Multi-agent adversarial review for nonprofit and education teams — deploys 3-4 expert lenses to evaluate any artifact (grants, strategy docs, presentations, emails, thought leadership), then triangulates findings into scored assessment with actionable fixes. Includes "The Adversary" panel for general argument, logic, and language QA. Trigger on "audit this," "stress test," "QA this," "poke holes," "run the adversary," "check this before I send it," "does this hold up," "is this AI-sounding," "full audit," "quick audit." --- # THE ADVERSARY — Adversarial Audit You are an expert multi-lens auditor. When triggered, run this protocol exactly. ## STEP 1: INTAKE Read the artifact silently. Then ask, before anything else: 1. Purpose & audience: What is this for, and who reads it? 2. Stakes & deadline: How high are the stakes? Any deadline? 3. Anything I should know? (criteria, sensitivities, prior feedback) Or say "just go" and proceed on the artifact alone. If "just go" → proceed, note missing context briefly at top of output. If answered → use answers to select panel and mode. Then go. No follow-ups. ## STEP 2: SELECT MODE | Mode | When | Agents | Output | |-----------|-----------------------------------------------|--------|------------------------------------| | Light | "quick audit," low stakes, short content | 3 | Stage 1 triage only — 600–900 wds | | Standard | Default. Reports, applications, strategy. | 3–4 | Stage 1 → ask → Stage 2 | | Full | "full audit," high stakes (>$100K, board) | 4 | Stage 1 → Stage 2 → offer Stage 3 | ## STEP 3: SELECT PANEL (match artifact to panel) Grant / LOI / Funding Proposal: - Program Officer → "Would I advance this or decline it?" - Evidence Reviewer → "Can I verify every claim?" - Budget Analyst → "Does the budget prove they can do this?" - Persuasion Editor → "Does this read like a winner or a compliance exercise?" Strategy Document: - Logic Auditor → "If I challenge every 'why this not that,' do answers hold?" - Evidence Checker → "What's the evidence this strategy will work?" - Operator → "Can they actually pull this off with what they have?" - Stakeholder Reader → "When partners and funders read this, do they see themselves in it?" Board / Executive / Funder Presentation: - Board Veteran → "Can I make a decision from this?" - Data Integrity Auditor → "Is every number traceable to a source I could check?" - Strategy Translator → "Does this tell a coherent story?" - Ask Evaluator → "Am I ready to say yes, or do I need more?" Written Content / Thought Leadership: - Editor → "Is there an argument here, or just observations?" - Fact-Checker → "Which claims survive a challenge?" - Audience Proxy → "Did I learn something, or did I read someone thinking out loud?" - Originality Critic → "Have I read this before under a different byline?" THE ADVERSARY — works on any artifact: - Logician → "If I challenge every 'therefore,' which survive?" - Claim Auditor → "Which claims is the author hoping I won't check?" - Language Critic → "If I removed every AI or committee-written sentence, what's left?" - Devil's Advocate → "If I were trying to discredit this publicly, where would I start?" (Full skill includes panels for Application, Data Analysis, and a custom-agent path.) ## STEP 4: RUN AGENTS (sequentially, in strict character discipline) For each agent: write the header, commit fully to the lens, complete the evaluation, close before opening the next. Agents do NOT see each other's outputs. Each produces: - Verdict (one sentence answering the driving question) - Score (X/10 with one-sentence justification) - Top 3 strengths + top 3 weaknesses (each with direct quote + specific fix) - Critical flags — anything that would cause rejection or embarrassment ## STEP 5: PRESENT — PROGRESSIVE DISCLOSURE Stage 1 — Rapid Triage (always first): Verdict: [safe to send / needs work / do not send yet] Score: [X/10 composite] Critical flags: [bulleted; "None" if clean] Light mode + no critical flags → end here. Two specific fixes. Done. Standard mode → ask: "Want the full breakdown, or is this enough?" Full mode → proceed to Stage 2. Stage 2 — Full Synthesis: 1. Scorecard table (Agent | Score | Rationale | Critical flag Y/N) 2. Where agents agreed (label "Convergent (N agents)") 3. Where agents disagreed (each position + your read) 4. Action items ranked: Critical → Recommended → Polish 5. Residual risk — what this audit can't catch Stage 3 — Deep Dive (Full mode, on request only): Per-agent full evaluations + literal rewrites for requested weaknesses. Show the improved version. Don't describe it. ## OPERATING RULES 1. Quote the artifact — every finding needs a direct quote, not a paraphrase 2. No cheerleading — if it scores 9/10, justify it rigorously 3. No scaffolding in output — output reads as expert human panel, not AI process 4. Verify before citing — never fabricate org facts; flag uncertainty 5. External research — when the artifact names a funder/program, search their current priorities before running agents. Surface contradictions as critical flags 6. Full mode = literal rewrites, not "this could be stronger" 7. One intake, then go — make reasonable assumptions, note them, proceed
Filled example — what Stage 1 Rapid Triage actually looks like (sample run on a hypothetical Q3 strategy memo, Standard mode)
Audit run: "Q3 Strategy Update" memo
Mode: Standard | Panel: Strategy Document (4 agents)
Intake: Audience = senior leadership; stakes = mid; deadline = Friday.
────────────────────────────────────────────────────────
Stage 1 — Rapid Triage
────────────────────────────────────────────────────────
Verdict: Needs work — convergent flag on the central growth claim.
Score: 6.5/10 composite
(Logic Auditor 7 · Evidence Checker 5 · Operator 6 · Stakeholder Reader 8)
Critical flags:
• CONVERGENT (2 agents): Logic Auditor + Evidence Checker independently
challenged "we expect 30% growth in Q4." Logic Auditor: "the 'therefore'
doesn't follow from Q1–Q2 trend." Evidence Checker: "no source, no
precedent, no model." When two lenses flag the same sentence cold, the
sentence is the problem.
• Operator: the August timeline assumes hiring two roles. No hiring plan
attached. The strategy is downstream of a capacity assumption that
hasn't been made. Not fatal — but the dependency needs to be named.
• Stakeholder Reader: borderline. Liked the framing for the leadership
audience; questioned whether the partner section reads as collaborative
or transactional. Flag for tone review, not a blocker.
Two specific fixes before going further:
1. Source the 30% Q4 growth claim, OR downgrade to "we are aiming for"
and name the assumptions.
2. Add a one-line capacity dependency under the August milestone.
Want the full breakdown, or is this enough to work from?
Steal this: a review Skill earns its keep when it (a) matches the panel to the artifact (a grant gets a Program Officer + Budget Analyst, a strategy doc gets a Logic Auditor + Operator), (b) runs each lens in character discipline — agents don't see each other's outputs, so disagreement becomes a signal, not a wash, and (c) presents in stages — triage first, full breakdown on request, rewrites only in deep mode. The convergence math is the magic: when 2+ independent agents flag the same line cold, the line is the problem.
Build 03 · Deeply customized Skill · Reuses the move with depth
preston-writing
The voice engine for everything Preston signs — board memos, LinkedIn posts, donor briefs, policy comments, conference remarks. Voice DNA extracted from his actual published writing, an explicit anti-AI rules file, three voice registers, and a curated archive of fifty published paragraphs as outside reference. Encodes the layer of judgment that used to live only in re-reading every draft three times.
SKILL.md — frontmatter + Voice DNA spine (condensed from the real 273-line file)
--- name: preston-writing description: > Preston Magouirk's writing voice, style, and anti-AI rules for all content creation. Use whenever drafting, editing, or reviewing any written content — LinkedIn posts, grant narratives, board materials, thought leadership, policy briefs, blog posts, conference remarks, donor communications, emails, or any deliverable that will carry Preston's name or voice. Trigger on any content creation task. --- # Preston Writing Two jobs: (1) Match Preston's voice. (2) Eliminate AI-generated patterns. ## Voice DNA (extracted from Preston's actual published writing) ### How Preston Opens Lead with a concrete fact, outcome, or situation. Never a question, never a sweeping claim, never throat-clearing. ✓ "DC CAP had a breakthrough year in 2025." ✗ "In today's rapidly changing education landscape..." ### How Preston Closes Conditional invitation that positions the writer as a learner. Pattern: "If you [share this context], I'd [welcome/love to hear]..." ### Pronouns "We" is the default for actions and outcomes. "I" is reserved for personal reflection or learning. Roughly 4:1 we-to-I ratio in org content. ### How Preston Handles Data Numbers bare, no adjectives. Signature phrase: "For context." ✓ "75-95% earned degrees. For context, ~37% of D.C. students do." ✗ "An impressive 75-95% — a staggering improvement..." ### The Deflation Principle Where AI inflates, Preston deflates. Where AI declares, Preston invites. Diagnostic: if a sentence would sound good in a TED talk, rewrite it. ### Transitions Zero explicit transition words. No However, Moreover, Furthermore, Additionally, That said. Transition by starting a new paragraph with a new concrete fact. ## Anti-AI Rules (the short version) Read reference/anti_ai_rules.md for the complete list. Quick scan: Forbidden phrases: "doing the heavy lifting," "the real question is," "here's the thing nobody is talking about," "it's not about X, it's about Y," "load-bearing" (metaphorical). Vocabulary red flags: leverage, utilize, delve, navigate (metaphorical), landscape (metaphorical), ecosystem, synergy, innovative, groundbreaking, transformative, game-changing, revolutionary, robust, holistic, unpack, deep dive. Structure red flags: question openers, "In today's..." openers, "As someone who..." credibility claims, triple parallel constructions, em-dashes >2 per piece. ## Three Voice Registers 1. External Research — policy briefs, research reports, partner evals 2. Internal Strategy — strategic plans, board materials, vision docs 3. Leadership Reflection — LinkedIn, thought leadership, conference remarks ## Forbidden Content - No partner or system disparagement (use "preparation gaps" not "fails") - No emergency/crisis language (DC CAP is academic support, not crisis services) - Frame around accessibility and impact
Reference files (the SKILL.md points to these; team copies the structure, builds their own)
Lives at BRAIN/skills/skills/preston-writing/reference/ — four guide files (voice_style_guide.md, anti_ai_rules.md, email_style_guide.md, source_paths.yml) plus eight sample files (LinkedIn drafts and finals, blog posts, policy briefs, research papers, reports). The SKILL.md routes to whichever sample matches the deliverable type. Mostly Tier 4Drafts in progress: Tier 3
Steal this: depth means every failure mode you have ever fixed by hand has a named home in the file. Voice rules go in their own list. Anti-AI rules go in their own file. Forbidden content patterns (partner disparagement, crisis language) get their own section because they fail differently. Walk through your last ten edits to AI drafts and ask: which corrections are in the file, and which are still in your head? The corrections still in your head are the next layer to encode.
Want the full side-by-side comparison and the cost/value table? Open the gallery →
This Week's Challenge — Build Worth Keeping
Everyone does step 1. Your unit ships at least one build by Friday.
Bring your scored sheet or your build to AI Friday. Friday's question: whose build do you want to inherit, and what would you change before adopting it?
Governance Pulse
Outside sources have data tiers too. Before you load a research PDF, a partner playbook, or a dataset, check: is it Tier 4 (public), Tier 3 (org strategy), or Tier 2 (sensitive)? Anyone with access to your build inherits access to its references. If you lead a team: the build you ship this week is a governance decision as much as a productivity one.
Four weeks of reps. You've been operating on principles — the 4Ds and 3As — without naming the layer underneath. Week 5 is that layer. Eight questions every early user trips over, answered plainly, with the move that fixes what's broken. Same principles, sturdier reasons. Better chats. Better tasks. Better Projects. Better Skills. Better outcomes.
Grounding our efforts in the principles for AI use and the background for how AI works.
The Principles You've Been Operating
The 4Ds are how we operate. The 3As are the shape your delegation takes. The eight questions below are why those moves work — or fail.
The plain answer. The context window is Claude's working memory for one conversation. It holds everything you've pasted, everything Claude has said back, and any reference files loaded. It has a ceiling, and the fuller it gets, the more Claude misses.
Where it breaks. People treat the window like email — long, sprawling, accumulating for weeks. Past a certain point, things on page three get missed.
The move. Treat each chat like a focused work session. One task, clean window. When the task ends, the chat ends. A clean window also costs less to run: every extra page Claude carries is compute the grant pays for. For anything that needs to persist across sessions, use a Project — that's what Projects exist for.
Description quality is bounded by what sits in this window.
The plain answer. Context is everything you load into the window before you ask. The single biggest predictor of a good Claude answer is whether you gave it the right context up front.
Where it breaks. "Write me an email to a parent" gets the average of the internet. "Draft a warm-professional email to a parent of a 12th grader who missed the May 1 renewal deadline, framed around the next step, signed by me" gets DC CAP work.
The move. Load names, numbers, dates, voice rules, audience, and format every time. Or load it once into a Project and stop retyping. Anytime you find yourself thinking "Claude should already know this," that's the signal — Claude doesn't, and the gap belongs in a file.
Empty context, generic answer. Rich context, sharp answer.
The plain answer. Claude doesn't remember you across chats. Each new conversation starts fresh unless you've built something that carries memory forward. Three layers: in this chat (yes), in a Project (yes, via reference files), across chats in general (no).
Two kinds of memory — and why the difference matters
External memory
What Claude absorbed from training data — vast but fuzzy. Lower precision and recall on the specifics of your world: names, numbers, dates, recent events.
This is where most hallucination comes from.
Internal memory
What's in the context window right now — your prompt, the chat history, the Project's reference files, anything you paste in.
High precision, high recall. Claude can quote it back verbatim.
The leader move: when accuracy matters, load the fact. Don't ask Claude to recall it. Internal memory beats external memory every time.
Where it breaks. The months-long chat. People keep one conversation open because they're trying to compensate for missing memory. The chat degrades long before the month is up. Performance thins, errors compound, and the team inherits a brittle artifact.
The move. Stop making one chat remember everything. Memory belongs in files. A Project carries context across tasks. A Skill carries a procedure across runs. If you retype the same instructions every week, that's a Skill waiting to be written.
Every Skill you write is Description carried forward.
The plain answer. Two meanings. The one to know first: within a long conversation, Claude's output drifts from your original intent. Early instructions get diluted. Tone shifts. Errors compound. (The second meaning — model behavior changes across versions — matters at the org level. DC CAP pins the current Opus and Sonnet as defaults and updates them as new versions ship.)
Where it breaks. You correct Claude on something at message 5. By message 30, the same error is back. Newer signals in the window crowd out older ones.
The move. When the trail feels off, start fresh. Re-anchor inside long chats with an explicit reminder: "remember — audience is counselors, voice is warm-professional, deadline is May 1." A Project loads the foundational context fresh every time you open a new chat inside it.
When the answer thins, that's your Diligence signal to verify and reframe.
The plain answer. Claude comes in three sizes. Each handles a different kind of job: fast, balanced, careful.
Where it breaks. Defaulting to Opus by reflex (slow, expensive, often unnecessary) or to Haiku by habit (ships sloppy work).
The move. Start with Sonnet. Upgrade to Opus when stakes warrant the depth. Drop to Haiku when speed matters more than judgment. Counselor email → Sonnet. Gates LOI → Opus. Summarize a 10-page PDF → Haiku or Sonnet. Voice scan on a board memo → Sonnet with thinking on. Open the Model Picker →
Model selection is a Delegation decision. Match the model to the task.
The plain answer. Hallucination is when Claude confidently states something that isn't true. A fabricated quote. A made-up statistic. A paper that doesn't exist. A person who never said the thing.
Why it happens. Large language models are pattern completers. When they don't know, they generate text that sounds like the right kind of answer. Without grounding, they invent.
The move — four-part discipline:
This is the discipline behind the dev-office-director's [T1-3 audited] sentinel from Week 4.
The plain answer. Two different checks. Both required before anything ships.
Where it breaks. People verify and skip validate — facts are right, tone is wrong for the audience. Or validate and skip verify — it reads great, the numbers are made up.
The move. Design verification into the workflow from the start. Pull at least one external check for any high-stakes claim. Read the output as the audience before you send. For the highest-stakes work, run it through the adversarial-audit Skill from Week 4's gallery — or hand it to a teammate.
Diligence is two moves, and you make both.
The plain answer. A great prompt has five parts.
Where it breaks. "Write me an email" gets nothing useful. "Make a deck about our program" gets nothing useful. Vague in, vague out.
Before / After — same task, different prompt
VAGUE
"Write a follow-up email to a counselor."
SHARP
"Draft a warm-professional follow-up to Ms. Reyes at McKinley Tech HS. We met last Friday about a Class of 2026 applicant who missed the May 1 renewal deadline. Audience: counselor with a heavy caseload, mid-stress. Format: 3 short paragraphs, signed Preston. Facts: renewal window reopens 7/15, our office hours M–F 9–5, my direct line is on file. Goal: confirm the next step without blame, invite her to forward to the family."
The move. Every great prompt is a SKILL.md waiting to be written. The more reps you put in on the five-part structure, the less you have to rewrite it the next time.
Description is the most valuable move in this whole program.
The AI Friday session deck. Each mechanic paired with a real work scenario outside DC CAP — from Mata v. Avianca and Air Canada to attorney case files, hospital triage, and spam filters.
Open Deck →Opus, Sonnet, Haiku — with named DC CAP example tasks for each. Printable one-pager.
Open Picker →The 4Ds matrix anchor. How Delegation, Description, Discernment, and Diligence interact across Automation, Augmentation, and Agency.
View Framework →Plain-language definitions for context window, tokens, model, memory, and the rest of the terminology in this week.
View Glossary →The capstone door opens this week. Use the mechanics above to scope Section 1 of your team's build.
Open Template →The task: draft the quarterly counselor partnership update for DC CAP's 28 high school counselor partners.
Q1–Q2 · Context window + Context
A fresh chat, opened for this task. Loaded into the window: the partner list (28 names + schools), DC CAP voice rules, this cycle's calendar, the prior quarter's update for tone reference.
Q3 · Memory
This sits inside a Project — "Counselor Partnerships" — so the next twelve quarterly updates inherit the partner list, voice rules, and cycle context. No retyping.
Q4 · Drift watch
Fresh chat inside the Project. Re-anchor mid-conversation: "remember — counselors with heavy caseloads, warm-professional tone, signed by Preston."
Q5 · Model
Sonnet. Recurring partnership comms don't need Opus, and Haiku won't hold the voice.
Q6 · Hallucination check
Every partner name verified against the live partner list. Any quoted counselor reply pasted in directly so Claude doesn't fabricate. Cycle dates checked against the cycle calendar.
Q7 · Verify + validate
Verify: names, dates, claims. Validate: tone reads warm-professional, format matches prior updates, the ask at the end is actionable.
Q8 · Prompt
"Draft the quarterly partnership update to our 28 high school counselors. Audience: counselors with heavy caseloads, mid-cycle. Format: 4 short paragraphs + a bulleted action list of three asks. Facts: the data table I pasted above, the cycle calendar in this Project, the prior quarter's update at the bottom for tone reference. Voice: warm-professional, signed Preston. Iterate with me on the opening before drafting the full thing."
Takeaway: the same partnership update you might have written in Week 2 with a one-shot prompt now has a back-end stack underneath. Same output, sturdier reasons. And the next time this update needs to go out, the Project does most of the work — because the answers to Q1, Q2, and Q3 are already in files.
Governance Pulse — Model Selection IS a Governance Decision
Defaulting everything to Opus burns nonprofit-tier compute and slows the team. Defaulting to Haiku ships AI-flavored slop. Sonnet is the responsible default; Opus is reserved for the highest-stakes drafting; Haiku is for lookups and classifications.
If you lead a team: as your team builds Projects and Skills, you're picking the model for everyone who runs them. Pick on purpose.
Week 5 named the mechanics. Week 6 deepens one of them — Claude getting things confidently wrong — and builds the verification discipline that catches it before it ships. Eight questions every newer user asks once they've watched a hallucination land. Plain-answer structure. Heavier focus on what to do, in what order, with what tools.
Hallucination is what the model does by design. Verification is what you do by design.
Where Confident-Wrong Hides — The Five Danger Zones
External memory is fuzzy on specifics. These five are where you spot-check first — every time, before anything ships.
The plain answer. Claude predicts the next word that fits the pattern of an answer. There's no database query happening underneath. When the pattern is strong — "the capital of France is" — the prediction is reliable. When the pattern is weak — "the most-cited paper on nonprofit AI adoption is" — the model generates something that looks like an answer. A plausible title. A plausible author. A plausible journal. None of which need to exist.
Where it breaks. People treat Claude like a search engine. Search engines retrieve. Claude generates. A retrieved fact is either there or it isn't. A generated fact is there whether or not it's true.
The move. Build the felt sense: every Claude answer is a generation. Hold one question in your head — "is the pattern strong enough here for the answer to be right?" Pattern is strong on broad, well-repeated things (definitions, well-known events, common code). Pattern is weak on specifics, recent events, and anything inside your own organization.
Real-world parallel — Mata v. Avianca, June 2023
Two attorneys filed a federal brief citing six prior cases. None of the six existed. The model had generated the kind of thing the prompt asked for — plausible case names, plausible courts, plausible citation numbers — and the lawyers never opened a single one. The court fined them and the case became the canonical hallucination story. The lesson is simpler than "AI is bad": the model completed the pattern, and no one checked.
Every confident answer is a completion.
The plain answer. Claude has no internal sense of how sure it is. There's no quiet "I'm 30% confident" threaded through every sentence. The training data is mostly written by humans who sound confident, so Claude does too. A fabricated case citation reads the same as a real one because, to the model, both are answers shaped like answers.
Where it breaks. Newer users use tone as a quality signal. A confident answer feels true. An uncertain one feels weak. With Claude, that intuition inverts: the most confident-sounding answer is sometimes the one with the least grounding underneath it.
The move. Two reps to rebuild the reflex:
Confidence is the model's default register. Calibration is something you ask for.
The plain answer. Week 5 named external memory — the fuzzy, recall-heavy memory of everything in the training data. External memory is strong on patterns and weak on specifics. The five danger zones at the top of this week — names, numbers, dates, citations, your world — are exactly where specifics live. So those are the five places to check first, every time.
Why your world is the highest-risk of all. Claude wasn't trained on your partner list, your scholar count, your renewal calendar, or your team's voice. When you ask, it pattern-matches to the nearest thing it knows — "education nonprofit in DC" — and invents plausible specifics. Plausible is the dangerous register: not obviously wrong, easy to miss, sometimes embarrassingly close to right.
The move. Two halves — one before the question, one after.
The closer the question gets to your specific world, the further it lands from Claude's strong patterns.
The plain answer. Loading a 50-page PDF doesn't mean Claude reads all 50 pages equally. Attention degrades through long contexts. The first and last pages stay sharp. The middle thins. The "Lost in the Middle" finding (Liu et al., 2023) showed this with strong evidence — models scored highest when the relevant info sat at the start or end of a long document, and noticeably worse when it sat in the middle.
Where it breaks. "I gave Claude the whole report and asked about page 14. The answer was wrong." Right — page 14 is the middle. The model pattern-completed something that fit the question because the middle was hazy. The fix lives in the context.
The move. Three plays, in order of value:
Sharper context produces sharper answers.
The plain answer. Week 5 named the symptom: by message 30, the rule you set at message 2 is gone. Here's the mechanic. Attention weighting tends to favor recent tokens — that's how the architecture works. And the model's own outputs become its future inputs, so any small wobble in message 10 feeds the wobble in message 15. By message 30, the wobbles have compounded into a different voice and a different set of working assumptions.
Where it breaks. A chat that started precise ends generic. A draft that started with three specific constraints ends with two general ones. People notice the result ("Claude got worse") and rarely the cause (the early rules got crowded out by the conversation that followed).
The move. Three plays you can run today:
Drift is built into the architecture. Build the workflow that fights it.
The plain answer. Three checks. Ninety seconds total. Every time.
Where it breaks. Two failure modes. Most common: skipping all three. The draft looks good and people send it. Less common but counterproductive: running heavy verification on everything. Manual checks are the floor. They run fast on every artifact; heavier gates stack on top for higher stakes.
The move. Make the ninety seconds a habit — small enough to run every time. The three checks always run. Q7 and Q8 are how the discipline scales up from there.
Manual verification is the floor. Heavier gates stack from there.
The plain answer. Most hallucinations happen when Claude is recalling. Loading the source — making the answer retrieve from internal memory instead of generate from external memory — is the single highest-impact move in the verification stack.
Three grounding patterns — easiest to most disciplined
1. Paste the source inline
Before the question, paste the partner email, the policy page, the data row. Twenty seconds. Cuts hallucination on those specifics to near zero.
2. Constrain the answer to the source
Add a one-line guardrail: "Only use facts from the document above. If a fact isn't there, say 'not in source' instead of guessing." Gives Claude permission to say it doesn't know — without permission, the model fills the gap.
3. Two-pass self-audit
First prompt drafts. Second prompt: "For every factual claim in your draft, mark whether you can trace it to a source I gave you, or whether you generated it from training. List the generated ones." The model will surprise you — it knows the difference, but doesn't volunteer it.
Where it breaks. People paste the source and still ask the recall question. ("Here's the partnership agreement — what year did we sign with Georgetown?") If the source has the answer, ask Claude to quote it. If it doesn't, paste the source that does.
Grounded answers are retrievals dressed as generations.
The plain answer. Manual checks (Q6) and source grounding (Q7) are moves you make on one draft. Verification gates are the cadence those moves live inside — what your team inherits every time, every artifact. A gate is a checkpoint where work doesn't pass until specific checks have run.
The three gates — light, standard, full
Where it breaks. Two failure modes. Skipping the light gate because it "sounds basic" — light is what catches the obvious hallucinations on every draft. Running full on everything because it feels thorough — full takes ten minutes per artifact, and the team that runs full on everything stops running it on anything.
The team move. A verification gate is a leader decision. The cadence you pick is what your team's defaults become. Skip the gate on Tier 2 work and you've moved the exposure from one draft to a thousand. Open the Audit Picker →
Manual checks are what you do. Gates are what your team inherits.
The AI Friday session deck. Each mechanic paired with a real-world parallel — eyewitness reconstruction, death by GPS, UN interpreters, jury attention, Bartlett's serial reproduction, the WHO surgical checklist, evidence in the record. Ends with a live stack run that catches five hallucinations in one paragraph.
Open Deck →The full gate — light, standard, full — mapped to artifact type and data tier. The Model Picker's sibling. Printable.
Open Picker →Plain-language definitions for hallucination, attention, context window, external memory, and the rest of this week's terms.
View Glossary →Week 4's gallery. The adversarial-audit Skill is Build 02 — the full SKILL.md is the structure behind the Full gate in Q8.
Open Gallery →Worked example with hallucinations planted against the public record. Every v2 fact is verifiable in Moffatt v. Air Canada, 2024 BCCRT 149 — go check it yourself after.
The artifact: a short recap note for teammates who couldn't make Friday's session, summarizing the standout case from Week 5. Internal, mid-stakes — standard gate.
Draft v1 — what Claude generated from recall
For teammates who couldn't make Friday's session: the standout case we walked through was Moffatt v. Air Canada. In 2023, attorney David Moffatt argued before the Canadian Supreme Court that Air Canada's chatbot had hallucinated a bereavement-fare policy. The court ordered the airline to refund approximately $2,400 and held that Canadian companies are liable for AI-generated statements on their websites. The ruling has been cited in at least a dozen subsequent cases.
Step 1 — Danger-zone scan (Q3 + Q6)
Flagged on a 30-second read:
Step 2 — Claim table (Q6)
Prompt: "List every factual claim in the draft above as a table —
claim, your confidence (high/medium/low), source. Be honest."
Claim | Confidence | Source
-----------------------------------------------|------------|------------------
Case discussed Friday was Moffatt v. Air Canada| HIGH | Week 5 deck
"2023" ruling | LOW | Generated
"Attorney David Moffatt" | LOW | Generated
Argued before "Canadian Supreme Court" | LOW | Generated
Refund of "approximately $2,400" | LOW | Generated
Air Canada bound by chatbot's hallucinated | HIGH | Public ruling
bereavement policy | |
Cited in "at least a dozen subsequent cases" | LOW | Generated
Notes: Six of seven claims are LOW confidence or generated. Only the
topic (Moffatt was Friday's case) and the underlying principle (Air
Canada held liable for chatbot output) are HIGH and grounded.
Step 3 — Source-loaded rewrite (Q7)
Pasted into the chat: the actual Moffatt v. Air Canada, 2024 BCCRT 149 decision (Jake Moffatt, self-represented passenger; British Columbia Civil Resolution Tribunal; $812.02 award) and the Week 5 deck slide with the verified facts.
New prompt: "Rewrite the paragraph using only facts from the BCCRT decision and the Week 5 deck slide I pasted above. If a fact is not in either source, replace it with [verify] instead of guessing."
Draft v2 — what shipped
For teammates who couldn't make Friday's session: the standout case we walked through was Moffatt v. Air Canada, 2024 BCCRT 149. In early 2024, passenger Jake Moffatt represented himself before the British Columbia Civil Resolution Tribunal after Air Canada's chatbot fabricated a bereavement-fare policy and the airline refused to honor it. The Tribunal ordered Air Canada to pay Moffatt $812.02 and held that the airline is responsible for the information its chatbot generates. The ruling is being cited as Canadian precedent on AI liability [verify scope].
What the stack caught: the year (2023 → 2024), the name and role (attorney David → passenger Jake, self-represented), the court (Canadian Supreme Court → BC Civil Resolution Tribunal), the amount (~$2,400 → $812.02), and the citation-scope claim (generated → bracketed for follow-up). Five fixes from three minutes of verification against the public record.
For higher-stakes drafts going to a board or funder, Q8's full gate (the adversarial-audit Skill) layers four expert lenses on top of this. The Audit Picker linked above maps the gates to artifact types.
This Week's Challenge — Run the Stack on One Real Draft
Pick one draft you wrote with Claude this week — a counselor email, a partner update, an internal memo, a LinkedIn post. Run the Q6 ninety-second pass: danger-zone scan, claim table, open one source.
Bring to Friday: the artifact (sanitized if needed), the claim table Claude produced, and the one fact the stack caught that you didn't see yourself. Friday's question: which of the five danger zones is your blindspot?
Capstone Bridge — Name Your Verification Cadence
One sentence in your capstone scope. Fill the blanks:
"The verification cadence for this build is ______ gate (light / standard / full), run by ______, before ______ ships."
That sentence is the Diligence stub for Section 1. Week 7's peer review pulls from it directly.
Governance Pulse — Verification Cadence by Data Tier
Tier 4 (public) work runs Q6 manual checks every time. Tier 3 (internal strategy) layers in Q7 source-grounding by default. Tier 2 (sensitive partner or operational) requires Q8's standard or full gate, with the verdict in the record. Tier 1 (FERPA/PII) doesn't touch Claude at all. The data tier sets the verification floor; heavier gates can stack on top.
If you lead a team: the cadence you pick for your team's build is the cadence every artifact inherits. Picking "light gate, run by the author" is a real decision with a real shape. Skipping the decision means the team picks for itself, one artifact at a time.
Week 6 closed the input-to-output loop. Week 7 opens a different one: designer to agent. The job stops being "prompt the model" and starts being "spec the work." Eight questions every team leader asks the first time they realize the build, the skill, the project, and the orchestration are the same conversation at four different scales. Default to the smallest container that survives the job.
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
Every higher stage strictly contains the lower ones. Promotion is cheap. Start small and move up only when reality demands it.
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 grounded in ~/Desktop/BRAIN/projects/financial_modeling/. One domain, four stages, every claim 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 ladder is strict: every higher stage contains the lower ones, so the upgrade path is cheap.
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 6 Q4 — 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 (Week 6 Q8 — light, standard, or full gate), 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 Opus agents, thirteen expertise references, four verification layers. Study the architecture; nobody is expected to ship Stage 4 themselves.
Open Walkthrough →The Friday session deck. The eight questions live, with the H3 financial_modeling walkthrough as the worked example. Bring your build sketch.
Open Deck →Your Deliverable — 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
Week 8 runs two weeks. Each unit builds and shares a Skill and a Project its team can use — no showcase, no turn-in. Preston keeps the H3 financial_modeling tour and the post-program assessment 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.
These next two weeks are one Week 8. By the end, every one of our six units has built and shared at least one Skill and at least one Project — something a teammate can open and use. No one presents, and no one turns anything in. The work is done and shared in Claude Enterprise, available to your team and ideally the whole org. The H3 financial_modeling walkthrough and the post-program assessment stay open the whole way through.
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 in Claude Enterprise — to your team, and ideally the whole org. The test is simple: a teammate opens your build and gets a good result without you in the room.
Before the all-staff · Done
Both builds live in the shared Claude Enterprise workspace, where your team can open them. Nothing to present. The H3 walkthrough and the post-program assessment stay open if you want them.
You already work this way. Over seven weeks we named the five layers 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 layers 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 →Layer 1. 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 layers. 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
Build at least one Skill and one Project for your unit. Run each through the eight quality questions, confirm the data tier, then share both in Claude Enterprise — the Project to your team or the whole org, the Skill published so anyone licensed can load it. Office hours stay open the whole two weeks 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 use the KPI cadence to track how the cohort's builds hold up across the next twelve months, and the Scale / Pause / Pivot gates to decide 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.