Most Claude Code guides are written for developers. Install this, run that, here’s the API. But in practice, the people I work with include operations staff, customer teams, and managers who have no interest in a terminal and shouldn’t need one.
I ran a half-day workshop to level everyone up at once. Technical people sat with non-technical people. The goal wasn’t for everyone to write code - it was for everyone to understand what Claude Code can do and build habits that compound over time.
This is what I covered and what landed.
The parent folder
Before anything else, everyone set up a parent folder for their Claude work.
~/claude-work/
├── CLAUDE.md ← standing instructions
├── plans/ ← research and outlines
├── docs/
│ └── tasks/ ← documentation of completed work
└── projects/The purpose of the parent folder is to give Claude a home. When Claude Code opens a session in that folder, it reads CLAUDE.md and picks up your preferences, credentials, shortcuts - everything that’s stable about how you work.
The parent folder lets Claude reload your standing instructions on every new session, so you don’t have to repeat them.
We also added a shell alias:
alias cdwork="cd ~/claude-work"
alias plans="cd ~/claude-work/plans && ls"It’s a small change, but the people in the workshop use it.
One tab per thought
This is the habit that took the least time to explain and had the biggest immediate effect.
Claude holds the context of an entire conversation. When you mix topics in one session - “help me write this email, also debug this, also what does this error mean” - the responses degrade. Claude carries all of that context forward and it starts to blur.
The rule is simple: one conversation, one task. When you’re done, document it, then close the tab.
Open tab → brief Claude → do the work → "document this" → close tabPeople in the room who had 15 Claude tabs open looked uncomfortable.
CLAUDE.md: “when I say this, do that”
CLAUDE.md is a markdown file that Claude reads at the start of every session in that folder. It’s where you write standing instructions - things that are always true and that you never want to repeat.
For technical staff:
## Shortcuts
- When I say "start on:", create a branch, worktree, and draft PR
- When I say "ship it", commit, push, and open a PR
- When I say "document this", run /document-task immediatelyFor non-technical staff - and this surprised people - it works just as well:
## Preferences
- When I ask for an email, write three versions: formal, neutral, friendly
- When I say "summarise this", give me three bullets first, then detail
- When I ask for a plan, include weekly milestones
- When I say "check this", proofread for tone and missing informationThe framing that clicked for the room: this is speed-dial. You’re training Claude on your preferences once, and then every session benefits from that training.
The API keys and credentials live here too. CLAUDE.md is local, not committed to Git. It’s the right place for things Claude needs to know but that shouldn’t live in a codebase.
Slash commands
Claude Code has built-in commands that trigger workflows. The ones worth knowing:
/document-task- structured record of what you built or fixed/commit- commit your code with a sensible message/commit-push-pr- commit, push, open a PR/incident-start LABEL- start tracking a live production issue/help- show what’s available
The non-technical staff particularly liked /document-task. It creates a file in docs/tasks/ with the problem, solution, what changed, and what to remember next time. No formatting work required - Claude just asks questions and writes the doc.
Agent levels
This took the most explanation but was the part people found most interesting.
Claude can operate at three different altitudes:
Level 1 - Executor: “Do exactly this specific thing.” Level 2 - Planner: “Figure out how to do this and then do it.” Level 3 - Orchestrator: “Break this into parts, spawn helpers, coordinate.”
At Level 3, Claude acts as a team lead. It splits a large task across multiple independent Claude instances, each focused on one piece, then synthesises the results. I wrote about this in more depth separately - the short version is that it’s useful for tasks with independent parts, and expensive for tasks that don’t need it.
We did a quick exercise: label these requests Level 1, 2, or 3.
- “Change ‘colour’ to ‘color’ everywhere” - Level 1
- “Research competitors’ return policies and recommend ours” - Level 2
- “Audit all API endpoints, document them, write tests, create a Postman collection” - Level 3
- “Reply to this customer complaint” - Level 1 or 2 depending on complexity
- “Plan and build a holiday tracking tool for staff” - Level 3
Most people got these right. The interesting debates were the edge cases - where Level 1 turned into Level 2 because the scope was bigger than it first looked.
--dangerously-skip-permissions
This flag tells Claude: don’t ask, just act.
By default, Claude checks with you before writing files, running commands, or making changes. Useful when you’re unsure. Friction when you’re confident and working fast.
claude --dangerously-skip-permissions "set up the project, install deps, run tests"The checklist before using it:
- Is this a dev or test environment?
- Is the task clearly scoped?
- Would it be easy to undo if something goes wrong?
- Am I comfortable with Claude making all decisions without checking?
Four yeses: proceed. Any no: leave permissions on.
The technical people had all used something like this already. The value for everyone else was understanding what it means when a developer says they’re running Claude with full permissions - and being able to ask the right questions about whether that’s appropriate.
Drag and drop
The hands-on activity that got the most engagement: everyone found a real screenshot, error message, or document from their week and dropped it into Claude.
Customer support staff dropped screenshots of Shopify orders with questions. Operations dropped spreadsheets. Developers dropped stack traces.
Claude handled all of it. The only thing people needed to add was context - what they were looking at and what they wanted to know.
This is the part that’s hardest to explain in theory and obvious in practice. Drop in your problem, describe what you want, get an answer. The file format doesn’t matter much.
Document this
Every module ended with "document this".
Not as a coda but as a habit, so each session ends with a structured record before the tab closes.
The /document-task command creates a structured markdown file at docs/tasks/YYYY-MM-DD-description.md. Over a month, you build a record of everything you’ve done, what worked, and why. Over a year, it becomes a searchable record of how your team works in practice, separate from the wiki.
The people who’ll use this are the ones who felt the pain of rediscovering something they’d figured out before. There were a few of those in the room.
What stuck
After the session, I asked people what they were going to change. The top three answers:
- One tab per thought
- Set up CLAUDE.md with their own shortcuts
- Use
/document-taskinstead of letting work disappear
The parent folder and the alias were low friction enough that everyone set them up during the session. CLAUDE.md instructions ranged from “write three email versions when I ask for an email” to “always use British English” to specific workflow shortcuts for technical pipelines.
The agent levels and the permissions flag were useful context but not things most people would use immediately. That’s fine.