Claude Code for Non-Developers: Your First Week, Step by Step

The first time I opened a terminal by choice, I had already been running a company for four years. I had no idea what a path was. I typed things and hoped. Then I found Claude Code, and something clicked.

This is the week-one sequence that gave me a working setup. Four steps. Each one has a clear done state. You can follow it without a coding background.

The short answer

Claude Code for non-developers works like this: install the tool, write one plain-English operating file that tells Claude how to behave in your business, add short trigger files called skills, and set up a state file so Claude remembers what it did between sessions. That four-step sequence takes about a week of casual setup time. After it, you have an AI system that follows the rules you wrote.

Day 1: Install Claude Code and open a project

Claude Code runs in the terminal. The terminal is the text window on your computer that takes typed commands. On a Mac it is called Terminal. On Windows it is called Command Prompt or PowerShell.

You need Node.js installed first. Node is a free program that lets your computer run JavaScript files. You can download it from nodejs.org. Install it, then restart your terminal.

Then run this one command:

1. Open the terminal.
2. Type: npm install -g @anthropic-ai/claude-code and press Enter.
3. When it finishes, type: claude and press Enter.
4. Done state: you see a prompt that says Claude Code and waits for input.

That is it. You are in. Nothing about this step requires you to understand code. You pasted a command and a tool installed itself. That is the whole job.

Now point Claude at a folder. Your folder can be a new empty folder on your desktop. Type: claude /path/to/your/folder. You can drag the folder into the terminal window to fill in the path automatically on most systems.

Day 2: Write your CLAUDE.md operating file

This is the most important file in the whole system. CLAUDE.md is a plain-text file that lives at the root of your project folder. Every time Claude Code opens that folder, it reads this file first.

Think of it as the onboarding doc you wish you had given every contractor you ever hired. Except this one actually gets read.

Here is what the real CLAUDE.md I use for my platform looks like at the top. I have stripped employer details, but the structure is real:

# CLAUDE.md > The single front-door map. Pointers, not content. > Only what must fire EVERY turn lives here. ## The two systems - The product app: src/, public/. The live site. - The agentic org: ops/ + .claude/ + memory/. How the company is run. ## Core conventions (fire every turn) - Plain-English copy: ALL copy is written at a 3rd-to-5th-grade reading level. Short sentences. One idea per sentence. Active voice. - Scope control: Never redesign beyond the requested change. Propose a better structure in ONE sentence and wait. - Build loop: brainstorm > spec > plan > build > verify > report.

That structure is real. A top-level description, a directory map, and a list of rules that fire on every turn. The rules are plain English. Claude reads them and follows them.

For your first CLAUDE.md, keep it short. Three sections is fine:

1. What this project is. One paragraph, plain English.
2. What folders contain what. A simple table.
3. Two or three rules Claude should follow every time. For example: always write in plain English, never make changes outside the scope of the request, ask before deleting anything.

Done state: you have a CLAUDE.md file in your folder and Claude reads it back correctly when you ask it to summarize your operating rules.

Days 3-4: Write your first three skills

A skill is a markdown file. That is it. It lives in a folder called .claude/skills/ inside your project. When you type /skillname in Claude Code, it reads that file and follows the instructions inside it.

Skills are how you turn repeated jobs into one-line commands. Instead of typing the same long instructions every session, you write them once in a skill file.

In my own setup, the skills catalog has over 80 entries. Here is a sample from the real index, showing how simple the structure is:

| Skill | Purpose | Trigger | |---|---|---| | ygs-blog-engine | Research/write/ship SEO posts | "write a blog post" | | ai-seo | AEO/GEO owner: get cited by AI engines | "AI SEO", "get cited by ChatGPT" | | slop-check | Anti-AI-slop critic gate | "check this for AI slop" | | knox-review | Clean-code + maintainability gate | "run Knox", "is this clean" |

Each skill has a name, a purpose, and a trigger phrase. That is the whole interface.

For your first three skills, pick the three jobs you repeat most often. Good starting candidates:

• A writing style skill: your tone rules, reading level target, things to avoid.
• A research skill: how you want Claude to gather and summarize information before recommending anything.
• A review skill: what Claude should check before calling any piece of work done.

Each skill file starts with a YAML header block, then plain English instructions:

--- name: my-writing-style description: "Apply my brand voice to any copy. Trigger: write, edit, review copy." --- # /my-writing-style All copy follows these rules: - Grade 3-5 reading level. Short sentences. - Active voice. One idea per sentence. - No jargon without a same-sentence definition. - No em dashes anywhere. When done, read the copy back and flag any sentence over 20 words.

Done state: you can type /my-writing-style and Claude applies your rules to any text you paste.

Days 5-7: Set up your first gate with STATE.json

Here is the part most first-week guides skip. And it is the part that makes everything else worth it.

Claude Code has no memory between sessions by default. You close the terminal, you reopen it, and Claude has forgotten everything it did yesterday. Skills help with rules. But they do not tell Claude what it already finished, what is blocked, or what comes next.

That is what STATE.json solves. It is a file that holds your work queue, your verified facts, and your locked decisions. Claude reads it at the start of each session to pick up where it left off.

The state machine in my own platform enforces this hard. A queue item with no acceptance criteria cannot be marked done. A fact with no proof command is flagged as a belief, not a fact. Here is the actual comment from the code:

// a fact with no `provedBy` command is a belief, not a verified fact // // This replaces the part a machine was re-parsing every session: // what is open, what is proven, what is decided.

That comment is from the real state.mjs file I use. I love that it uses the word "belief." The whole system is designed around one question: what do you KNOW, versus what are you guessing?

For your first STATE.json, keep it simple. Three sections:

1. queue: the list of open tasks with a title and a done condition for each one.
2. facts: things you have verified. Each one needs the command you used to prove it.
3. decisions: choices you have locked and do not want relitigated.

Then create a /resume skill that tells Claude to read STATE.json at the start of every session. My resume command prints the top three actionable items and flags anything blocked on a human. That is the first thing I read each morning.

Done state: you open Claude Code, type /resume, and see a clean list of what is open and what comes next.

What you have at the end of week one

Here is the honest picture. You have four files: CLAUDE.md, three skill files, and STATE.json. That is it. No code. No database. No deployment.

But those four files change how the tool works for you. Claude follows the rules you wrote. Jobs you repeat become one-line commands. Sessions start with your open queue instead of a blank cursor.

From here, you grow by adding skills for new jobs and keeping STATE.json honest. Every skill you write is a job you stop re-explaining. Every fact you add to the state file is something Claude stops guessing about.

I now have over 80 skills in my system. I did not write them all in week one. I wrote three. Then I wrote more when I caught myself repeating instructions.