WEEK 7 · AI FRIDAY · MAY 29, 2026

Build
Your Own.

Designer → Agent. Eight questions that turn "I'd like Claude to do X" into a build the team actually inherits.

Preston Magouirk · DC CAP Enterprise AI Leadership Pilot · Spec the work.

The pivot

Week 6 closed the input-to-output loop.
Week 7 opens the designer-to-agent loop.

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.

Q1 · Which container?
Q2 · Do I have the expertise?
Q3 · One role or many?
Q4 · Instructions or files?
Q5 · What skills chain in?
Q6 · What tools does it need?
Q7 · How do I know "good"?
Q8 · How does it stay alive?

Same plain-answer rhythm as Week 5 and Week 6. Heavier focus on choosing the smallest container the work actually needs.

The cohort takeaway

The agent has no expertise.
The designer has the expertise.

Claude predicts the next word that fits the pattern. The pattern is whatever you encoded. A generic spec produces generic output. A spec that carries your ninety-second explanation of what "good" looks like produces output that carries it too. The failure mode lives in the spec the designer wrote.

The four-stage ladder

Smallest container that survives the job.

Every higher stage strictly contains the lower ones. Promotion is cheap. Start small. Move up only when reality demands it. Most pilot builds will stop at Stage 2 or Stage 3 — that is the right call.

Stage 1

Prompt

One reusable instruction the user pastes into a chat. One person, one recurring task, no team inheritance needed.
Artifact A · Big Idea Sentence Prompt
Stage 2

Skill

A named, versioned SKILL.md any agent can load on trigger. The team needs consistency; the expertise gets encoded once.
Artifact B · preston-writing Built Right
Stage 3

Project

Instructions + reference files + governance + workflow doc, loaded at every conversation start. A team workflow the unit inherits.
Artifact C · financial_modeling as a Project
Stage 4

Orchestration

Multi-agent + skills + tools + handoffs + verification gates. Audit-trail-grade output across roles. Worth the cost only when the work crosses lanes that each need their own expertise.
H3 walkthrough · financial_modeling
Stage 2 in concrete terms

A Skill is one SKILL.md file.
Plus the resources it owns.

Anatomy on disk

One folder. Three loading levels.

my-skill/
├── SKILL.md     ← name + description
│                  + instructions (<500 lines)
├── scripts/     ← deterministic code
├── references/  ← loaded on demand
└── assets/      ← templates & outputs
Progressive disclosure. Metadata (name + description, ~100 words) is always in Claude's context. The SKILL.md body loads on trigger. Bundled resources load only when the body says to read them.
Description = trigger

Pushy beats abstract.

Skills under-trigger. Write the description with both what the skill does AND the concrete contexts where it should fire. 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 in the library: preston-writing · funder-framing · dc-cap-org-intelligence · sf-demo-data
Stage 3 in concrete terms

A Project is four artifacts.
All four always ship.

Anatomy on disk

Instructions + files + governance + workflow.

My Project
├── System instructions   ← role, voice, scope
├── Reference files       ← curated, anchored
├── Governance config     ← tier + escalation
└── Workflow doc          ← how the team uses it
A Project loads its full instructions and reference files at the start of every conversation that lives inside it. Inside the Project, you can chain Skills — the Project sets the surface, the Skills add expertise where needed.
Instructions vs. files

Rules vs. world.

Instructions hold the durable rules. Role, voice, scope, the explicit "What You Do Not Do," the escalation path. These do not change between runs.
Files hold the world the rules apply to. The latest fpa-data-engineer JSON intake, the FY27 raise targets, the named-donor schedule, the IC memo precedent. Anything that refreshes on a known cadence.
A Project whose workflow doc runs a page-and-a-half is overdue for a promotion decision. A Project whose instructions balloon past 80 lines is doing too much.
Q1 · Delegation

Prompt, skill, project, or orchestration?

A real work scenario

Fence, vault, building, city.

An architect designing a community garden does not start with city planning. A fence is enough when one neighbor owns the work. A vault is the right move when something has to be secured for years. A building is the right move when many people use the space the same way. A city is the right move when the work crosses neighborhoods.

The job picks the container. The architect who starts every project with city planning ships nothing.

Christopher Alexander, A Pattern Language (1977). The pattern-language tradition treats container choice as the design decision; scale maximization is a separate failure mode.
In your Claude work

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 and governance — Project. Crosses roles, needs an audit trail — Orchestration. The ladder is strict; every higher stage contains the lower ones, so promotion is cheap.

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?" That is the moment to promote. Most pilot builds will stop at Stage 2 or Stage 3.

The takeaway: Start small. Promote when the work demands it. Knowing when to stop is the discipline this week trains.

Q2 · Discernment

Do I have the expertise to spec the work?

A real work scenario

Mise en place.

A working restaurant kitchen runs on mise en place — every ingredient prepared, portioned, named, and placed within the cook's reach before service starts. The chef who knows the menu can list the mise en place in ninety seconds. The chef who does not produces a mise that fights the dish all night.

The expertise lives in the prep. The cook's pan-handling is execution; the prep is where the dish was already decided. When the prep is right, the work flows. When the prep is short, every plate fights the gap.

Anthony Bourdain, Kitchen Confidential (2000). The discipline of mise en place is the discipline of front-loading expertise into a form the line cook can execute.
In your Claude work

The spec is your mise en place.

Claude has no expertise of its own. The build encodes your knowledge in a form the model can apply at scale. If you cannot explain to a teammate, in ninety seconds, what "good" looks like for this job — the spec is too thin. Specifics in, specifics out.

Two reps before you build: write the ninety-second explanation first, then convert to instructions; borrow expertise where you do not have it — that is exactly what the skill library is.

The takeaway: The failure mode lives in the spec. The model executes what the spec asks for.

Q3 · Delegation

One role or many — and where are the handoffs?

A real work scenario

The surgical team.

A surgeon does not also run anesthesia, also scrub, also count instruments, also chart, also close. The team splits the work into named roles with explicit handoffs. The anesthesiologist signals "ready to incise." The circulating nurse counts before close. Each handoff is a state contract: this output reaches that input.

Pre-surgical-team operating rooms had a single surgeon doing everything. The mortality rates were what you'd expect.

Atul Gawande, The Checklist Manifesto (2009). Modern OR teams average four to seven specialized roles with named handoff points.
In your Claude work

Name the role; name the handoff.

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 one instruction. The signal to keep it together: the workflow is one person's standard move, end to end.

Inside the financial_modeling H3 build: fpa-lead dispatches, fpa-data-engineer ingests, fpa-quant models, fpa-storyteller writes. Each output a state file the next agent reads.

The takeaway: One job per role. Explicit handoffs between them. The Lead never overwrites; the Lead routes.

Q4 · Description

What goes in instructions vs. reference files?

A real work scenario

Constitution and the news.

A constitution carries the durable rules — the structure that holds across every cycle. The day's news carries the world those rules apply to. A republic that rewrites its constitution every news cycle has no rules. A republic that updates its news from a 250-year-old document has no facts.

The split is the point. The durable rules hold; the world updates. Both surfaces work because they live in different places and refresh on different cadences.

James Madison, Federalist No. 51 (1788). The architecture of durable rules vs. shifting context is the founding pattern.
In your Claude work

Instructions are rules. Files are world.

Instructions: the durable spec. Role, voice, format, the rules that hold across every conversation. Short and prescriptive — if a rule needs three paragraphs to explain, the rule is doing too much.

Files: the world the rules apply to. Anything that refreshes weekly. Curated, named, front-loaded and back-loaded with what matters most. The middle of a long file fades; the top and bottom stay sharp (Week 6 Q4 was a real cost).

The takeaway: Instructions are the rules. Files are the world the rules apply to.

Q5 · Description

What skills should chain in?

A real work scenario

The orchestra section.

A symphony does not have one player doing strings, woodwinds, brass, and percussion. Each section is its own named expertise. The score chains them — each section enters where the score calls it in, and the conductor routes the timing. No section knows about another section's fingering; the chain handles the integration.

The same musician can also play in a smaller chamber group, where the score is different and only three sections are called. The expertise travels with the player; the chain travels with the score.

Berlioz, Treatise on Instrumentation (1844). The first systematic treatment of orchestration as a chain-of-expertise problem.
In your Claude work

Name the chain. Reuse the skills.

Most real builds chain two or three pieces of named expertise. A grant draft chains funder-framing + preston-writing. A board brief chains executive-summary-formatter + data-interpreter.

The same skill loads inside many agents. dccap-brand loads in fpa-frontend AND fpa-viz inside the financial_modeling build. Same SKILL.md. Two different lanes. No duplication.

The takeaway: Name the chain. The chain is the inheritance.

Q6 · Discernment

What tools and permissions does the build need?

A real work scenario

The Swiss Army knife paradox.

A Swiss Army knife with 35 tools is heavier, more expensive, and worse at almost every task than a knife with three tools. Survival experts carry fewer tools by deliberate practice. The reason is that every additional tool is one more surface that has to be maintained, sharpened, and remembered. Most expedition packing lists explicitly cap tool count.

The discipline is not minimalism for its own sake. It is the recognition that capability has a cost — to the user, to the operator, to the system.

Andrew Skurka, The Ultimate Hiker's Gear Guide (2012). The thru-hiking community's gear-minimization studies are the cleanest applied version of this lesson.
In your Claude work

Smallest tool set is the safest tool set.

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. Add a tool when the workflow cannot run without it. Tools that ship off by default ship off for a reason.

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 takeaway: The smallest tool set is the safest tool set.

Q7 · Diligence

How do I know "good" — and what failure modes do I plan for?

A real work scenario

FMEA in aerospace.

Failure Modes and Effects Analysis (FMEA) started at NASA in the 1960s and became the standard for high-reliability engineering. Before any system ships, the team enumerates the ways it can fail, sorts by severity (cosmetic / costly / catastrophic), names the early-warning sign for each, and assigns the check that catches it. Apollo, the Space Shuttle, modern commercial aviation all run on this discipline.

The teams that fail FMEA are not the teams that miss a failure mode. They are the teams that ship without writing the failure-mode map at all.

NASA, MIL-STD-1629A (1980); Stamatis, FMEA from Theory to Execution (2003). Same discipline runs in clinical medicine, automotive, software safety.
In your Claude work

Cosmetic, costly, catastrophic.

Good is what your team would call "ready to ship" with you out of the room. Failure modes fall into three buckets. Cosmetic: formatting drift, voice slip — caught at light gate, costs minutes. Costly: wrong number, wrong audience — caught at standard gate, costs trust. Catastrophic: FERPA leak, fabricated funder fact — caught at full gate, costs the relationship.

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 takeaway: A build without a failure-mode map is a build that ships its failures.

Q8 · Diligence carried forward

How does the build stay alive?

A real work scenario

Building codes.

A building code is written once, but it earns its keep over decades. It names the durable rules (structural-wall standards, fire-egress paths), the inspection cadence (occupancy permit, annual fire inspection), and the escalation path (variance request, code-board review). The code is what keeps the structure standing through three owners and two renovations.

Cities without code revisits — without inspections, without iteration — produce buildings that look fine for ten years and start failing in year fifteen. The code is the cadence.

International Building Code (2024 edition). The discipline of durable rules + inspection cadence + escalation path is what makes the built environment survive the people who built it.
In your Claude work

Three lines that decide survival.

Every build needs three explicit lines: a verification cadence (light / standard / full gate + who runs it + before what ships), an iteration cadence (what triggers a revisit — new data, new team member, quarterly refresh), and a governance line (data tier + escalation path + restricted topics).

A build ships with no review cadence — six weeks later the data has moved, the team has changed, and the outputs are confidently wrong. Write the three lines into the build itself.

The takeaway: A build's longevity is the discipline of its cadence.

The H3 worked example

The same eight questions, scaled to eleven agents.

DC CAP's financial modeling tool combines three live data streams into one audit-trail-grade view of the organization's financial position now and through FY35. The arc of the build is the arc of the eight questions answered at the upper rung of the ladder.

3 data streams

Development · Finance · Pathstone

Development raise targets across individual, corporate, and philanthropic sources. Finance historical-and-projected actuals. Investment-market projections from Pathstone. Three refresh cadences, one reconciled model.

11 Opus agents

One job each. Lead routes.

fpa-lead · fpa-architect · fpa-data-engineer · fpa-quant · fpa-insight-hunter · fpa-analyst · fpa-strategist · fpa-modeler · fpa-viz · fpa-storyteller · fpa-frontend.

4 verification layers

L1 → L2 → L3 → L4

Source-cell provenance · Parser hard-gate · Runtime cross-foots · Defaults alignment. Latest build: 53/53 checks green.

The orchestration is a process the designer authored. The agents have no expertise. The designer has the expertise. The failure mode lives in the spec the designer wrote.

Pick your stage

Four artifacts. Pick the one that matches your work.

Each artifact teach-page walks the same eight questions concretely. Pick the artifact whose stage matches the work you would actually ship for your team in the next two weeks.

Stage 1 · Prompt

A — Big Idea Sentence Prompt

fpa-quant headline numbers in, Investment Committee-ready Big Idea sentence out. One pasteable prompt. Light gate. Tier 3.

Stage 2 · Skill

B — preston-writing Built Right

v2.6 of the voice skill any host loads — grants, LinkedIn, board memos, fpa-storyteller. Pushy description, fast-path routing table, evidence trailers under every rule, eleven differentiated samples in reference/. Standard gate.

Stage 3 · Project

C — financial_modeling as a Project

Thought experiment: compress the Stage 4 system into one Claude Project. What fits, what chains as Skills, what cannot collapse. Standard gate.

Stage 4 · Orchestration

D — financial_modeling, the System

The real production build. 3 data streams · 11 Opus agents · 13 references · 4 verification layers. Full gate. Live behind Cloudflare Access.

This week

Office hours. Pick your stage. Spec the build.

No 1:1 pairings this week. Three drop-in office-hours blocks across Weeks 7–8. Calendar-only. Bring your build.

01
Pick the artifact.

A, B, C, or D. The stage that matches what you would actually ship in the next two weeks. Most of us land at Stage 2 or 3 — that is the right call.

02
Write the eight answers.

One paragraph each. The eight questions are the same at every stage. If Question 2 surfaces a gap in your own expertise to spec — that gap is the most useful finding of the week.

03
Bring it.

Office hours: drop in with your sketch. AI Friday: walk one through together. Week 8 closes with the showcase — three slides each, June 4. The H3 financial_modeling tour runs live.