Structure Review

A cumulative review of Chapters 04-05 (Making Your Organization Legible, Trusting Your Own Data). Ten questions, drawn from across the chapters and deliberately mixed together — interleaved practice is harder than chapter-by-chapter review, and that difficulty is exactly what builds retention.

How to use this review:

Pass bar: 9 of 10. Higher than lesson quizzes, because this is where knowledge proves it stuck.
Answer in writing, in your own words, before checking anything. Constructing the answer is the exercise.
With a tutor: it will run the review one question at a time, grade against the key, and generate fresh variants for any retake.
If you miss the bar — or barely clear it — come back tomorrow, not in five minutes. Spaced retakes are dramatically better for retention than immediate ones. The gap is a feature.

Check your understanding

Q1. You have a beautifully structured rules document sitting in a chat thread. List the escalation path it should travel — thread → ? → ? — naming what each stage adds and what limitation pushes you to the next.

Q2. Write the frontmatter description for a skill that handles your team’s client-onboarding checklist — then explain what job that field performs and the mistake that makes skills invisible.

Q3. A consultant proposes six weeks of process documentation before any AI work. Management balks. Make the argument for why this is the AI project — and name the benefit that survives even if no AI is ever deployed.

Q4. Claude analyzed your exported sales data and flagged a pattern you’d missed. Before acting on it, what three things do you demand to see, and what is the general property they add up to?

Q5. Your team wants Claude to answer questions from the shared Drive and the support inbox by next week, and nobody owns a terminal. Lay out the path, and explain what those connections actually are under the hood.

Q6. Same skill file: works on your machine, authentication error on your teammate’s. Diagnose the design flaw and describe the pattern that makes one skill file portable across every machine.

Q7. Explain the difference between what a Project remembers and what a SKILL.md knows — scope, formality, and the moment a piece of knowledge should graduate from one to the other.

Q8. Why is ‘connect once, use everywhere’ the economic argument for MCP? Contrast it with the pre-MCP cost structure using a concrete integration example.

Q9. The trust inversion happened: Claude found four real errors in the books. Name two organizational changes that should follow — one to process, one to posture — and the trap to avoid.

Q10. Apply the new-hire test to a document from your own work. State the test, apply it honestly, name one thing that fails it — and explain why that same failure blocks the machine.

Answer key — attempt every question first

Answer key

Q1

Model answer: Thread → Project (instructions + knowledge: every chat in the workspace inherits it; limitation: locked to one workspace) → SKILL.md (structured, portable, shareable across surfaces and teammates; loaded automatically when relevant). Some answers add → MCP server later; accept it.

Pass criteria: both stages with what each adds; single-workspace limitation as the driver to skills

Q2

Model answer: Description must be ‘use when…’ phrased in the user’s own words: “Use when onboarding a new client, setting up a client account, or asking what the onboarding steps are.” The field is the trigger — Claude matches tasks against it to decide loading. The invisibility mistake: writing it like documentation (‘Contains onboarding procedures’) that matches nothing anyone says.

Pass criteria: use-when phrasing with natural trigger words; trigger mechanism explained; doc-style anti-pattern named

Q3

Model answer: You cannot delegate to a system that does not understand the work — legibility IS the substrate; the bookkeeping firm needed six weeks of documentation before one line of agent code. The AI-independent benefit: the org finally has real operational documentation — onboarding shrinks, bus-factor drops, inconsistencies surface.

Pass criteria: documentation framed as prerequisite substrate, not overhead; names a concrete no-AI benefit

Q4

Model answer: Source attribution (which records produced the claim), the audit trail (what steps/code ran), inspectable reasoning (the evidence for each flag). Together: verifiability — the property that separates actionable findings from ‘the AI said so.’

Pass criteria: all three; property named verifiability/auditability

Q5

Model answer: Settings → Connectors: authorize Google Drive and the email connector — one OAuth flow each, no terminal, works across every device and surface. Under the hood these are MCP servers hosted by providers; ‘connector’ is MCP wearing a friendly name — which is why the same knowledge applies when custom servers arrive later.

Pass criteria: connectors path described; connectors-are-hosted-MCP identity stated

Q6

Model answer: The flaw: credentials hardcoded or assumed from one machine’s environment. The pattern: cascading lookup at runtime — project-local secrets file, then global config, then a secrets manager — so the skill file carries knowledge only, and each user’s credentials resolve locally.

Pass criteria: hardcoding diagnosed; cascade described with per-user resolution

Q7

Model answer: A Project remembers informally: instructions and files scoped to one workspace, accumulating organically. A SKILL.md knows formally: structured rules with a trigger, portable to any surface, project, or teammate. Graduation moment: when the knowledge is tested, stable, and someone else (or another surface) needs it.

Pass criteria: scope and formality contrast; a sensible graduation criterion

Q8

Model answer: Pre-MCP: one capability = N implementations (Slack bot, CLI, dashboard, mobile) — cost scales with access methods. With MCP: build/authorize the server once and every surface — chat, terminal, phone, schedules, events — is a client, including surfaces that ship later. Example: QuickBooks connected once serves the desk query, the phone question, the Monday routine, and the failure alert.

Pass criteria: N-implementations vs build-once contrast; example spans several access methods

Q9

Model answer: Process: route the machine’s checks into the workflow (run the analysis on a schedule; flagged items get human review). Posture: humans shift from doing the first pass to reviewing the machine’s pass — checking their own assumptions against it. Trap: swinging to blind trust — inversion is earned per-domain and only with verifiability intact.

Pass criteria: one process change + one posture change; over-trust trap named

Q10

Model answer: Test: could a new hire follow it on day one and get it right without calling you? Honest answers surface a gap (an exception, a naming ambiguity, an unstated threshold). The same failure blocks Claude because both readers lack access to your unwritten context — what the document omits, the machine fills with a guess.

Pass criteria: test stated; real gap admitted; shared-ignorance reasoning connects hire to machine