Smetti di rispiegare il tuo progetto a Claude

1Write a CLAUDE.md for this project — the file Claude Code reads at the start of
2every session, so I never have to re-explain my stack, my rules or my folders
3again.
4 
5Don't write it from guesses. Explore the repo first, then ask me only what the
6code can't tell you, then write the file and prove the commands in it work.
7 
8## Step 1 — Explore (read, don't edit)
9 
10Look at, at minimum:
11- the package manifest(s) and lockfile (package.json, pyproject.toml, go.mod, …)
12- framework and tool configs (next.config, vite.config, tsconfig, eslint,
13  prettier, tailwind, docker, CI workflows)
14- the top two levels of the folder tree, and one or two typical files in each
15  main folder, to learn the real naming and code style
16- README, any existing CLAUDE.md / AGENTS.md / .cursorrules, and .env.example
17- the last ~20 commit messages, to learn the commit style
18 
19## Step 2 — Ask me (one short message, max 6 questions)
20 
21Only ask what you could not infer, for example:
22- what the product does, in one sentence, and who it's for
23- rules you must never break (e.g. "never touch the payments folder",
24  "no new dependencies without asking")
25- how I like to work (small PRs? tests first? explain before coding?)
26- anything that regularly goes wrong in this repo
27 
28## Step 3 — Write CLAUDE.md at the repo root
29 
30Use exactly these sections, in this order. Be specific and short: bullet
31points, real paths, real commands. Aim for 60–120 lines total — every line
32is read every session, so cut anything generic.
33 
34```
35# <Project name>
36One sentence: what it is and who it's for.
37 
38## Stack
39Languages, framework + version, database, auth, hosting, key libraries.
40 
41## Commands
42dev, build, test (all + single file), lint, typecheck, format, db migrate.
43Only commands you have actually run successfully in Step 4.
44 
45## Map
46The folders that matter, one line each: what lives there and what doesn't.
47 
48## Conventions
49Naming, file structure, state, styling, error handling, imports —
50as they ARE in this codebase, with one example path each.
51 
52## Rules
53- ALWAYS: …
54- NEVER: …
55(the hard rules from my answers, plus anything dangerous you found:
56secrets, generated files, migrations, protected folders)
57 
58## Workflow
59How to work with me: plan first or just do it, test expectations,
60commit message style, when to ask before acting.
61 
62## Gotchas
63Non-obvious traps you noticed: env vars needed, ports, flaky tests,
64order-of-operations, legacy code not to copy.
65```
66 
67## Step 4 — Verify
68 
69- Run every command you put under "Commands". If one fails, fix the line or
70  remove it — never leave an untested command in the file.
71- Re-read the file and delete anything that would be true of *any* project.
72- If a folder has its own very different rules (e.g. a separate backend or
73  mobile app), create a short CLAUDE.md inside that folder too, and say so.
74 
75## Step 5 — Hand over
76 
77Show me the final file, list what you inferred vs. what I told you, and
78suggest 2–3 rules I might want to add after a week of using it.
79 
80Do not change any code in this task — only create CLAUDE.md file(s).