---
title: "Structure Review"
description: "Cumulative review of Chapters 04-05: projects, skills, data, and trust."
type: review
order: 2
---

# 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.

<details>
<summary>Answer key — attempt every question first</summary>

## 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

</details>