Delivery pack

Surface: Chat, Project or Artifact

• The prototype itself always lives in an Artifact: that's what makes it clickable and editable in place.
• Chat for a one-off build you won't reuse.
• Project when your prototypes share brand constraints or assets: drop your palette, tone and components into project knowledge, so every prototype starts on-brand instead of generic.

Describe it well: the D most people skip

"Make me a dashboard" gets you generic. Brief it in three parts:

• Product: what the tool does and the sample data it shows.
• Process: build it as an interactive artifact; you'll iterate by chat.
• Performance: premium, editorial, clickable, ready to demo.

The efficient workflow

1. Describe the tool plus sample data → get the first artifact.
2. Iterate by voice in small diffs ("add a region filter", "make it a heatmap"), not full rewrites. That's far faster and cheaper than regenerating the whole app.
3. Use Sonnet to iterate; reach for Opus only on a genuinely complex first build.
4. Stop at demo-ready. It's a throwaway to align people; hand engineering a spec, not the artifact.

Traps, and the Skill that makes it repeatable

• It builds a front-end only: no real backend or live data unless connected. Don't try to ship it.
• Synthetic/sample data only; the moment you'd paste real customer data, stop.
• Repeatable: the "Prototype scaffolder" Skill preloads your brand constraints, so every prototype opens on-brand in one invocation.

Surface, and holding context

• Chat for a one-off model; a Project for a model or dataset you return to. It persists and you never re-upload, which halves the token spend.
• Make it compute: get a computed artifact (real code behind it) or a .xlsx with live formulas, never a typed table, which drifts over a long chat.
• Keep every assumption in one editable block. Change inputs there and ask for the delta; don't re-paste the whole workbook each turn.
• Claude for Excel works inside the workbook (cell-level citations, native pivots) and is more token-efficient than the web app, which re-renders the full document and a PDF preview every time.

Describe it well: the D most people skip

Underspecify and it types a table that drifts. Brief it in three parts:

• Product: three scenarios, contribution by year, ranked sensitivity.
• Process: actually compute it; keep the assumptions in one editable block.
• Performance: show the delta on every change; flag what it's most sensitive to.

The efficient modelling workflow

1. Sonnet to build and iterate the structure (cheap); Opus only for genuinely hard logic.
2. Assumptions block up top; scenarios as columns.
3. Run sensitivity by conversation ("margin −200bps", "KSA delayed two quarters") and read the delta. Don't rebuild.
4. Ask which assumption contribution is most sensitive to. That ranking is the output a decision-maker actually wants.
5. Export .xlsx for the team; edit sections, don't regenerate the whole thing.

Traps, and the Skill that makes it repeatable

• Always verify the numbers: you own the model, not Claude.
• If totals stop tying out on a long chat, rebuild clean from the assumptions block.
• Don't let the Excel add-in become a setup rabbit hole; the artifact path works for everyone.
• Repeatable: the "Scenario model builder" Skill encodes your standard model structure.

Project vs Chat, and holding context

• One tight argument over a handful of documents → a single Chat, everything attached, held in full context for line-by-line reasoning.
• A large, evolving corpus you interrogate over days (a data room, a research library) → a Project. Upload once, it persists, the team shares it, and you never re-upload.
• Know the trade-off: past a size threshold a Project switches to retrieval: it pulls the most relevant chunks rather than holding every page. Strong for breadth ("what across these 200 docs touches change-of-control?"), weaker for a single exhaustive read. For a completeness question, be systematic; don't assume retrieval saw everything.
• Map before you drill: ask for an index of the corpus first, then target questions. Never open with "summarize everything".
• Force grounding: "quote the exact passage and name the document before each conclusion." It catches gloss and hallucination and makes every claim checkable. This is a standard long-context technique.

Describe it well: the D most people skip

A vague ask gets a bland summary. The brief is what turns it into a red-team:

• Product: the synthesis, the contradictions, and the questions the documents don't answer.
• Process: reason across all the documents; cite each claim to its source.
• Performance: a skeptical board member, not a cheerleader.

Due diligence over a data room: the efficient workflow

1. Load the data room into a Project once: persists, shared, no re-upload (re-uploading doubles the token spend).
2. Encode your DD framework as a Skill: "for each document extract parties, obligations, change-of-control, financial terms, red flags." Every doc now gets identical treatment and you never re-type the framework.
3. Pass 1, triage: index the room and flag the documents carrying material risk.
4. Pass 2, extract: run the schema over the flagged docs (Sonnet is fine and cheap here).
5. Pass 3, synthesize: contradictions, gaps ("what should be in this room and isn't?"), and the judgment call. Opus earns its cost on this step.
6. Output the DD memo as a .docx with citations via file creation; edit sections, don't regenerate the whole memo each change.

One schema, and the traps

• Use one extraction schema across every document (same fields each time) so the synthesis is apples-to-apples.
• It will synthesize confidently without pressure-testing. Always end with "where do these contradict, what's the weakest link, what's missing".
• Citations required, then spot-check a sample against source. Trust, then verify.
• Retrieval can miss on completeness. For "does any document mention X", be systematic, not trusting.
• Repeatable: the "Research synthesizer" Skill packages the map → extract → red-team method into one invocation.