Getting Ready
to Work With
Claude.

What you'll get out of this

• A working picture of what Claude actually is — and what makes it different from a plain chatbot.
• The four habits that separate people who get real leverage from AI from people who don't.
• The three surfaces Claude lives in at INFLXD, and how to choose between them for a given task.
• The discipline of describing well and verifying carefully — the two skills that compound fastest.
• A 10-minute setup at the end, so you can close this doc and start using it.

How to read it

Linear is fine. Plan on about thirty minutes the first time through. The right rail lets you jump back to any section once you start working — most people come back to the four habits and the folder-layout pieces the most. The links at the end are for depth; bookmark them, don't try to read them today.

Three things that follow from this

• Conversations are the unit of memory. Inside one chat Claude can hold everything you have shared, including very large attachments. Across chats it carries nothing. The brief you dropped in yesterday is gone tomorrow unless you bring it back or pin it to a Project.
• Confidence is not accuracy. Claude will sometimes invent a citation, a function name, or a fact that does not exist. It tends to hedge more than other models, which helps, but the hedge is not a guarantee. You verify anything that has to be right — names, numbers, sources, code paths.
• Context is the lever. Claude's million-token window is only useful if you actually use it. Pasting a whole transcript, a real PRD, last quarter's notes — that is what changes the quality of the output. Sparse context, sparse answer.

Meta-lessons that transfer

These hold for Claude and for whatever comes next. Worth carrying with you, regardless of which model is in fashion.

• The first answer is a draft. Steer it; don't restart.
• Confidence is not accuracy. Verify anything load-bearing — names, numbers, sources, code paths.
• Context is what you bring. Sparse context, sparse answer. The model can only reason over what's in the window.
• Every session is a fresh start. Yesterday's careful brief evaporates. Pin context to a Project or bring it back yourself.
• Bigger models reduce errors. They don't eliminate them. The verification step doesn't go away with the next release.

The job is not to get out of the way. The job is to direct — decide what is worth doing, frame it precisely, read the result carefully, and decide what is good enough to ship. The four habits next — Delegation, Description, Discernment, Diligence — are how INFLXD does that consistently.

Two loops, one practice

The four habits sit in two nested loops. The strategic loop pairs Delegation with Diligence — zoom out, and ask what are we handing to Claude, and how will we know it actually worked when the result comes back? The tactical loop pairs Description with Discernment — zoom in, and ask how clearly did I brief this turn, and how carefully am I reading the answer? When work goes sideways, it is almost always because one of the four was skipped.

Two briefs, same job

Three surfaces want three briefs

The same job briefed three different ways. A Cowork brief read aloud in a chat window will fall flat, and vice versa.

CLAUDE.md — project memory

A CLAUDE.md file sits at the root of a project. Claude Code reads it on every session before doing anything else. Think of it as the onboarding doc you'd hand a smart new contractor on day one — the things they need to know so they don't make day-one mistakes.

• The vocabulary we use — what "treatment," "brief," and "memo" mean here, and how they differ.
• Files to read first — the house-style doc, the template folder, last quarter's reference deliverables.
• Patterns to imitate, anti-patterns to avoid — the way we open executive summaries, the words we never use.
• Format conventions — how a brief is structured, how a PRD is structured, how a deal memo is structured.

Skills & plugins — playbooks that compound

A skill is a small, reusable playbook. You write down once how a specific job gets done at INFLXD — "summarize this transcript into our call-notes format," "turn this research scan into a one-pager" — and from then on, anyone on the team can invoke it with a slash command. The skill carries the instructions; the person calling it carries the inputs. Same output shape, every time. Authoring is short: a markdown file with a name, a description, and the steps, dropped in ~/.claude/skills/ or the project's skills folder. First one takes ten minutes; the second takes two.

Plugins are the bundle layer. A plugin packages skills, hooks, and tools together, so installing one gives a teammate the full workflow — say, the ops plugin with the call-notes skill, the deal-memo skill, the research-scan skill, and the hooks that file outputs in the right places. One install; a working setup.

Four rules to internalise

Why a second opinion isn't proof

When Claude tells you the X library has a Y function, and a fresh Claude session says the same, that isn't verification — they may be quoting the same outdated documentation. Open the actual library code, the live data, the primary document. Primary sources are proof. Everything else is signal.

Pick how you want to use Claude

A first day that actually teaches you something

The fastest way to learn the tool is to run a real piece of INFLXD work through it on day one — not a sandbox prompt. Pick a transcript you would have summarised anyway, or a research scan you owe someone. Hand it to Cowork with a full brief — the goal, the inputs, the format, where to save. Watch the permission prompts. Read the artifact. Notice where Claude hedged, where it asked back, where it confidently invented something. That first delegation is worth more than any tutorial.