# INSTALL.md — instructions for Claude Code

> **This file is addressed to you, Claude Code** (or any equivalent agent). A
> user pointed you here to install the "Claude Code for Non-Coders" method on
> their machine, adapted to their context. Follow these phases in order. The
> user may be a non-developer: keep every explanation plain and assume no
> technical knowledge. The method's files are written in English, but
> **converse in the user's language** — whatever language they write to you in.

## Rules of the install (before anything else)

- **Announce, then GO**: start by summarizing what the install will do (the 5
  phases below, in three lines) and wait for the user's agreement before
  writing anything.
- **Never overwrite silently**: if a file already exists, show the difference
  and ask before touching it.
- **Verify every write**: after each file created, confirm it exists and that
  its content starts as expected.
- **Install understanding, not just files**: every installed piece gets a
  one-sentence explanation (what it's for, when it activates). A user who
  doesn't understand what they just accepted is a failed install, even if the
  files are in place.

Source file base (raw URLs):
`https://raw.githubusercontent.com/Arlenjim/claude-code-for-non-coders/main/`

## Phase 1 — The 3 skills (always)

Download and install into the **user-level** skills folder (not the project
one) — `~/.claude/skills/` (Windows: `C:\Users\<name>\.claude\skills\`):

| Folder to create | Source |
|---|---|
| `work-discipline/SKILL.md` | `<base>/skills/work-discipline/SKILL.md` |
| `scientific-debugging/SKILL.md` | `<base>/skills/scientific-debugging/SKILL.md` |
| `framing-vague-requests/SKILL.md` | `<base>/skills/framing-vague-requests/SKILL.md` |

Verification: each installed file must start with `---` followed by a
`name:` line. Explain to the user: *"three working methods I will load
automatically — one for executing cleanly, one for debugging without hacks,
one for clarifying a vague request before coding."*

## Phase 2 — The global CLAUDE.md (with interview)

This is the rules file loaded into all their sessions: `~/.claude/CLAUDE.md`.

**If it doesn't exist**: download `<base>/CLAUDE-global.md`, then ask the
user these two questions (one at a time, in plain language):
1. Their first name (for the "Who the pilot is" section).
2. Are they a developer, somewhat technical, or not technical at all?
   (Adjust the "Who the pilot is" section accordingly: if they're a
   developer, soften the plain-language requirement instead of removing it.)

Fill in the `<...>` fields, delete the "How to use" block at the top, and
write the file.

**If it already exists**: do NOT overwrite. Read the existing file, identify
what the method would add (session cycle, relational rules, discipline), and
propose a merge as a diff the user validates section by section.

## Phase 3 — The current project (optional, with interview)

Ask: *"Are you in a long-lived project (several work sessions ahead), or
just exploring?"*

**If exploring**: skip this phase, and tell them they can run it later by
pointing me at this file again from inside their project.

**If a long-lived project**, run the adaptation interview (questions one at a
time, each with a concrete example):
1. The project's name and what it does, in one sentence.
2. **The non-negotiable zone**: *"where would a mistake really cost you —
   money, your users' data, security, shared content?"* If the user doesn't
   know, help them: look at the project structure and suggest candidates.
3. The project's commands (run, test) — if a project already exists, detect
   them yourself and have the user confirm.

Then generate, from the repo's templates (`<base>/templates/...`), filled in
with their answers:
- `SESSION-HANDOFF.md` at the project root (the handoff journal),
- the project `CLAUDE.md` (or a merge if one exists — same rule as phase 2),
- the resume template `<PROJECT>-RESUME.txt` (ask where they want to keep
  it; suggest the Desktop).

## Phase 4 — Guardrails (inform, do NOT install)

Install NO hooks. Simply say: *"the repo also contains optional automatic
guardrails (the `guardrails/` folder) — we'll add them later IF your project
develops a critical zone that justifies them. The method's rule: lighten,
don't harden."* If the user insists on installing them now, have them read
`<base>/guardrails/07-what-we-removed.md` first.

## Phase 5 — The final report

Finish with a recap table: each installed element, its role in one sentence,
and when it activates. Then explain **the first concrete gesture**: *"at your
next work session, I will read your handoff and the git state before
anything else; at the end, just tell me 'let's stop here' and I'll prepare
the handoff."*

And point out the one thing the install cannot provide: the method lives in
the pilot's habits (precise briefs at session start, explicit GOs on
consequential actions, demanding proof rather than narrative) — the files are
only the support. Suggest reading the repo's README to understand the story
behind each piece.