claude-code-autoconfig 1.0.113 → 1.0.115

package/.claude/commands/autoconfig.md

@@ -1,366 +1,367 @@
-<!-- @description The command you just ran. Analyzes your project and populates CLAUDE.md with real context. Re-run anytime your stack changes. -->
-
-# Autoconfig
-
-Analyze this project and configure Claude Code with real context.
-
-**Setup Note**: During autoconfig, prefer Glob/Read/Write tools over Bash commands. This ensures smooth setup without permission prompts. Only use Bash for opening the guide at the end.
-
-## Step 1: Detect Environment
-
-**Operating System:**
-Check the platform and note it for command syntax:
-- Windows → use `del`, `rmdir`, backslashes, `.cmd`/`.ps1` scripts
-- macOS/Linux → use `rm`, `mkdir -p`, forward slashes, `.sh` scripts
-
-Include this in CLAUDE.md so all commands use the correct syntax.
-
-## Step 2: Scan the Project
-
-Look for these indicators to understand the project:
-
-**Package/Config Files:**
-- `package.json` → Node.js, npm scripts, dependencies
-- `requirements.txt` / `pyproject.toml` / `setup.py` → Python
-- `Cargo.toml` → Rust
-- `go.mod` → Go
-- `Gemfile` → Ruby
-- `pom.xml` / `build.gradle` → Java
-- `*.csproj` / `*.sln` → .NET
-- `composer.json` → PHP
-
-**Framework Indicators:**
-- `next.config.*` / `app/` directory → Next.js
-- `vite.config.*` → Vite
-- `angular.json` → Angular
-- `svelte.config.*` → Svelte
-- `remix.config.*` → Remix
-- `nuxt.config.*` → Nuxt
-- `django` in imports → Django
-- `flask` in imports → Flask
-- `fastapi` in imports → FastAPI
-- `express` in dependencies → Express
-- `rails` / `Gemfile` with rails → Rails
-- `laravel` → Laravel
-
-**Testing Frameworks:**
-- `jest.config.*` / `@jest` in deps → Jest
-- `vitest.config.*` → Vitest
-- `pytest.ini` / `conftest.py` → Pytest
-- `*_test.go` files → Go testing
-- `*_spec.rb` files → RSpec
-- `cypress/` or `playwright/` → E2E testing
-
-**Infrastructure:**
-- `Dockerfile` / `docker-compose.*` → Docker
-- `*.tf` files → Terraform
-- `k8s/` or `kubernetes/` → Kubernetes
-- `.github/workflows/` → GitHub Actions
-- `serverless.yml` → Serverless Framework
-
-## Step 2b: Detect Version Divergence
-
-Scan for version declarations across the project. Multiple version sources that disagree can cause release failures (e.g., package.json says 1.0.74 but a hardcoded constant says 1.0.72).
-
-**Version Sources to Check:**
-
-| Source | Detection Method |
-|--------|------------------|
-| `package.json` | Parse JSON, read `version` field |
-| `**/*.{ts,js,mjs}` | Regex: `/(?:export\s+)?(?:const\|let\|var)\s+((?:BASE_\|APP_\|LIB_)?VERSION)\s*=\s*['"](\d+\.\d+\.\d+)['"]/i` |
-| `**/manifest.json` | Parse JSON, read `version` field |
-| `**/manifest.config.{ts,js}` | Regex: `/version:\s*['"](\d+\.\d+\.\d+)['"]/` |
-| `**/Info.plist` | Regex: `/<key>CFBundleShortVersionString<\/key>\s*<string>(\d+\.\d+\.\d+)<\/string>/` |
-| `**/build.gradle` | Regex: `/versionName\s+['"](\d+\.\d+\.\d+)['"]/` |
-| `pyproject.toml` | Parse TOML, read `project.version` or `tool.poetry.version` |
-| `Cargo.toml` | Parse TOML, read `package.version` |
-
-**Algorithm:**
-
-1. Glob for each file pattern
-2. Extract version using the appropriate method (JSON parse, regex, TOML parse)
-3. Collect results as `{ file, identifier, version }`
-4. Compare all collected versions
-5. **If all versions match** → no action needed
-6. **If versions diverge** → flag for CLAUDE.md
-
-**Skip these locations** (generated/vendored):
-- `node_modules/**`
-- `dist/**`
-- `build/**`
-- `.git/**`
-
-**Edge Cases:**
-- If version field references a function or variable (not a literal), note it as "dynamic"
-- For monorepos, compare root package.json against workspace packages
-- If only one version source exists, no comparison needed — skip silently
-
-## Step 3: Populate CLAUDE.md
-
-Focus on what Claude Code actually needs to work effectively. Claude can explore the codebase itself — don't document what it can discover.
-
-**Wrap content in markers** so `/sync-claude-md` knows what's auto-generated:
-
-```markdown
-<!-- AUTO-GENERATED BY /autoconfig at {TIMESTAMP} UTC — Do not edit. Use .claude/feedback/ for corrections. -->
-
-# Project Name
-...content...
-
-<!-- END AUTO-GENERATED at {TIMESTAMP} UTC — Use .claude/feedback/ for corrections. -->
-```
-
-Replace `{TIMESTAMP}` with the current UTC time in format `YYYY-MM-DD HH:MM:SS` (e.g., `2026-01-14 16:30:45`). Use the same timestamp in both markers.
-
-**Always include:**
-- **Project name + one-liner**: What is this thing?
-- **Tech stack**: One to two lines max. Only mention choices Claude wouldn't guess from config files alone (e.g., "Firebase Auth via WEB_OAUTH" is worth including; "React 18 with TypeScript" is not — Claude sees that in `package.json`). Do NOT list individual dependencies, testing libraries, or build tools that appear in `package.json`/`requirements.txt` — Claude reads those files directly.
-- **Commands**: How to run, test, build, deploy — Claude needs these to execute tasks
-- **Non-obvious conventions**: Multi-schema databases, monorepo structure, unusual patterns Claude wouldn't infer
-
-**Include if divergence detected (from Step 2b):**
-- **Version Management**: Only add this section if version divergence was found
-
-```markdown
-## Version Management
-
-⚠️ Multiple version sources detected with different values:
-- `package.json:version` → "X.Y.Z"
-- `{file}:{identifier}` → "A.B.C"
-
-Verify which source is authoritative before releases.
-```
-
-Place this section near the top (after Tech Stack, before Commands) since version issues block releases.
-
-**Include if relevant:**
-- **Deployment flow**: If non-standard or involves multiple steps
-- **Key architectural decisions**: Only when the project has non-standard module boundaries (e.g., Chrome extension background/content split, microservice routing, multi-entrypoint builds). For standard single-entrypoint apps (Next.js, Express, Django), skip it — Claude can infer the architecture from the file structure.
-
-**Skip these — Claude can discover them:**
-- Detailed project structure trees (Claude can run `ls` or `tree`)
-- Exhaustive route/endpoint lists (Claude can grep)
-- File-by-file descriptions (Claude can read files)
-- Database model lists (Claude can read schema files)
-- Individual dependency names or versions (Claude reads `package.json`/`requirements.txt` directly)
-- Standard framework patterns (e.g., "uses app router" for Next.js — Claude sees `app/` directory)
-
-**Keep it tight.** A 30-line CLAUDE.md that hits the essentials beats a 200-line doc Claude has to parse every session.
-
-**Always end with:**
-```markdown
-## Team Feedback
-See `.claude/feedback/` for corrections and guidance from the team.
-```
-
-This pointer persists across autoconfig runs and directs Claude to team-maintained content.
-
-## Step 4: Create Rules Directory
-
-Create `.claude/rules/` directory if it doesn't exist by writing a `.gitkeep` file to it:
-
-```
-Write .claude/rules/.gitkeep with empty content
-```
-
-**Important**: Use Write tool to create the directory (by creating a placeholder file), not `mkdir` Bash commands. This avoids permission prompts during setup.
-
-Rules are path-scoped context files that load automatically when Claude works on matching files. Effective rules require deep understanding of your codebase patterns, team conventions, and quality goals — they should be crafted intentionally, not auto-generated.
-
-## Step 5: Configure Formatter (JS/Node Projects)
-
-**Only for projects with `package.json`:**
-
-1. Check if `scripts.format` already exists in `package.json`
-
-2. **If `scripts.format` exists:**
-   - Skip to adding the hook (Step 5b)
-
-3. **If `scripts.format` does NOT exist:**
-   - Ask the user:
-   ```
-   No formatter detected. Adding one ensures Claude's output
-   matches your project's style.
-
-   Should I add Prettier to this project? (y/n)
-   ```
-
-4. **If user says yes:**
-   - Run: `npm install -D prettier`
-   - Add to `package.json` scripts:
-     ```json
-     "format": "[ -f .prettierrc ] && prettier --write . || echo 'Create .prettierrc to enable formatting'"
-     ```
-   - Create `.prettierrc.example` in project root:
-     ```json
-     {
-       "semi": true,
-       "singleQuote": false,
-       "tabWidth": 2
-     }
-     ```
-   - Inform user: "Formatting is ready but inactive. Rename `.prettierrc.example` to `.prettierrc` when your team decides on style preferences."
-
-5. **If user says no:**
-   - Skip formatter setup, continue to Step 6
-
-**Step 5b: Add PostToolUse Format Hook**
-
-If the project has `scripts.format` (either existing or just added), add the format hook to `.claude/settings.json`:
-
-```json
-{
-  "hooks": {
-    "PostToolUse": [
-      {
-        "matcher": "Write|Edit",
-        "hooks": [
-          { "type": "command", "command": "node .claude/hooks/format.js" }
-        ]
-      }
-    ]
-  }
-}
-```
-
-The format hook script (`.claude/hooks/format.js`) runs `npm run format` after Write/Edit operations on source files. Users can customize this script to add file filtering or different formatting logic.
-
-**Important:** Merge this with any existing hooks. Don't overwrite existing hooks.
-
-## Step 6: Configure Settings
-
-Update `.claude/settings.json` using the official schema.
-
-### Deny Patterns (files Claude shouldn't read/write)
-
-Use `Read()` for blocking reads, `Edit()` for blocking writes:
-
-**Always deny (security):**
-```
-Read(./.env)
-Read(./.env.*)
-Read(./secrets/**)
-Edit(./.env)
-Edit(./.env.*)
-```
-
-**Always deny (Windows artifacts):**
-```
-Write(./nul)
-Edit(./nul)
-```
-These prevent accidental `nul` file creation from bash/Windows command translation issues.
-
-**Often deny (generated/vendor):**
-```
-Edit(./node_modules/**)
-Edit(./dist/**)
-Edit(./.git/**)
-```
-
-### Allow Patterns (auto-approve without prompting)
-
-Use `Bash()` patterns with prefix matching:
-
-```
-Bash(npm run test:*)
-Bash(npm run lint:*)
-Bash(npm run build)
-```
-
-### Environment Variables
-
-Set session-level env vars:
-
-```json
-{
-  "env": {
-    "NODE_ENV": "development"
-  }
-}
-```
-
-**Keep it minimal** — only include patterns that actually exist in this project.
-
-## Guidelines
-
-- Replace ALL placeholder content with real values from THIS project
-- Delete sections that don't apply — no empty stubs
-- Optimize for Claude's efficiency, not human documentation
-- When uncertain, leave it out — Claude can ask or explore
-
-## Step 7: Configure MEMORY.md
-
-Claude Code has a persistent auto memory file (`MEMORY.md`) that loads into the system prompt at the start of every session. Write the debugging methodology to this file so Claude always follows evidence-based troubleshooting.
-
-**Locate the MEMORY.md file:**
-
-The file lives at `~/.claude/projects/{encoded-project-path}/memory/MEMORY.md` where the project path is encoded by replacing path separators with dashes and removing colons (e.g., `C:\CODE\my-project` becomes `C--CODE-my-project`).
-
-**Before writing, read MEMORY.md first.** If a `## Debugging` section (or similar heading like `## Debugging — Evidence Before Solutions`) already exists, **skip this step entirely** — never duplicate or overwrite user-curated memory content.
-
-**Only if no debugging section exists**, write this content (append if file already exists, create if it doesn't):
-
-```markdown
-## Debugging — Evidence Before Solutions
-NEVER guess the root cause and jump to coding a fix. Ask yourself: is the cause deterministic and verifiable from the error alone (e.g., stack trace, compile error)? If yes, fix it directly. If not:
-1. Add logging / check actual data first
-2. Confirm root cause with evidence
-3. Only then propose and implement a fix
-```
-
-**Important**: Use the Write tool (or Edit to append). Do not skip this step on first-time setup — it ensures Claude investigates root causes before making changes in every future session. But never overwrite existing user content in MEMORY.md.
-
-## Step 8: Update the Docs
-
-After populating CLAUDE.md, update the docs file previews to show actual project content:
-
-1. Open `.claude/docs/autoconfig.docs.html`
-2. Find the `fileContents` JavaScript object
-3. Update these entries with the real content just generated:
-   - `'claude-md'` → the CLAUDE.md content from Step 3
-   - `'memory-md'` → the MEMORY.md content from Step 7
-   - `'settings'` → the settings.json content from Step 6
-4. Use template literal syntax and escape any backticks in the content
-
-This ensures double-clicking these files in the docs shows real project content, not stale placeholders.
-
-## After Completion
-
-### Open Docs & Finale
-
-**Only if `.claude/docs/autoconfig.docs.html` exists**, open it in the user's browser:
-
-- macOS: `open .claude/docs/autoconfig.docs.html`
-- Linux: `xdg-open .claude/docs/autoconfig.docs.html`
-- Windows: `powershell -NoProfile -Command "Start-Process '.claude/docs/autoconfig.docs.html'"`
-
-If the docs file exists, output:
-
----
-
-✅ Setup complete! The interactive docs are now open in your browser.
-
----
-
-If the docs file does NOT exist (e.g., user ran `/autoconfig` without the full npx install), output:
-
----
-
-✅ Setup complete!
-
-Run `/show-docs` to view the interactive documentation (requires full install via `npx claude-code-autoconfig`).
-
----
-
-**IMPORTANT**: Do not add any additional text, summaries, or details after this message. The finale should be clean and punchy - end here.
-
-### Windows Cleanup
-
-On Windows, if a `nul` file was accidentally created in the project root (a common artifact from bash/Unix command translation), delete it silently using the Bash tool:
-
-```bash
-del nul 2>NUL
-```
-
+<!-- @description The command you just ran. Analyzes your project and populates CLAUDE.md with real context. Re-run anytime your stack changes. -->
+<!-- @version 1 -->
+
+# Autoconfig
+
+Analyze this project and configure Claude Code with real context.
+
+**Setup Note**: During autoconfig, prefer Glob/Read/Write tools over Bash commands. This ensures smooth setup without permission prompts. Only use Bash for opening the guide at the end.
+
+## Step 1: Detect Environment
+
+**Operating System:**
+Check the platform and note it for command syntax:
+- Windows → use `del`, `rmdir`, backslashes, `.cmd`/`.ps1` scripts
+- macOS/Linux → use `rm`, `mkdir -p`, forward slashes, `.sh` scripts
+
+Include this in CLAUDE.md so all commands use the correct syntax.
+
+## Step 2: Scan the Project
+
+Look for these indicators to understand the project:
+
+**Package/Config Files:**
+- `package.json` → Node.js, npm scripts, dependencies
+- `requirements.txt` / `pyproject.toml` / `setup.py` → Python
+- `Cargo.toml` → Rust
+- `go.mod` → Go
+- `Gemfile` → Ruby
+- `pom.xml` / `build.gradle` → Java
+- `*.csproj` / `*.sln` → .NET
+- `composer.json` → PHP
+
+**Framework Indicators:**
+- `next.config.*` / `app/` directory → Next.js
+- `vite.config.*` → Vite
+- `angular.json` → Angular
+- `svelte.config.*` → Svelte
+- `remix.config.*` → Remix
+- `nuxt.config.*` → Nuxt
+- `django` in imports → Django
+- `flask` in imports → Flask
+- `fastapi` in imports → FastAPI
+- `express` in dependencies → Express
+- `rails` / `Gemfile` with rails → Rails
+- `laravel` → Laravel
+
+**Testing Frameworks:**
+- `jest.config.*` / `@jest` in deps → Jest
+- `vitest.config.*` → Vitest
+- `pytest.ini` / `conftest.py` → Pytest
+- `*_test.go` files → Go testing
+- `*_spec.rb` files → RSpec
+- `cypress/` or `playwright/` → E2E testing
+
+**Infrastructure:**
+- `Dockerfile` / `docker-compose.*` → Docker
+- `*.tf` files → Terraform
+- `k8s/` or `kubernetes/` → Kubernetes
+- `.github/workflows/` → GitHub Actions
+- `serverless.yml` → Serverless Framework
+
+## Step 2b: Detect Version Divergence
+
+Scan for version declarations across the project. Multiple version sources that disagree can cause release failures (e.g., package.json says 1.0.74 but a hardcoded constant says 1.0.72).
+
+**Version Sources to Check:**
+
+| Source | Detection Method |
+|--------|------------------|
+| `package.json` | Parse JSON, read `version` field |
+| `**/*.{ts,js,mjs}` | Regex: `/(?:export\s+)?(?:const\|let\|var)\s+((?:BASE_\|APP_\|LIB_)?VERSION)\s*=\s*['"](\d+\.\d+\.\d+)['"]/i` |
+| `**/manifest.json` | Parse JSON, read `version` field |
+| `**/manifest.config.{ts,js}` | Regex: `/version:\s*['"](\d+\.\d+\.\d+)['"]/` |
+| `**/Info.plist` | Regex: `/<key>CFBundleShortVersionString<\/key>\s*<string>(\d+\.\d+\.\d+)<\/string>/` |
+| `**/build.gradle` | Regex: `/versionName\s+['"](\d+\.\d+\.\d+)['"]/` |
+| `pyproject.toml` | Parse TOML, read `project.version` or `tool.poetry.version` |
+| `Cargo.toml` | Parse TOML, read `package.version` |
+
+**Algorithm:**
+
+1. Glob for each file pattern
+2. Extract version using the appropriate method (JSON parse, regex, TOML parse)
+3. Collect results as `{ file, identifier, version }`
+4. Compare all collected versions
+5. **If all versions match** → no action needed
+6. **If versions diverge** → flag for CLAUDE.md
+
+**Skip these locations** (generated/vendored):
+- `node_modules/**`
+- `dist/**`
+- `build/**`
+- `.git/**`
+
+**Edge Cases:**
+- If version field references a function or variable (not a literal), note it as "dynamic"
+- For monorepos, compare root package.json against workspace packages
+- If only one version source exists, no comparison needed — skip silently
+
+## Step 3: Populate CLAUDE.md
+
+Focus on what Claude Code actually needs to work effectively. Claude can explore the codebase itself — don't document what it can discover.
+
+**Wrap content in markers** so `/sync-claude-md` knows what's auto-generated:
+
+```markdown
+<!-- AUTO-GENERATED BY /autoconfig at {TIMESTAMP} UTC — Do not edit. Use .claude/feedback/ for corrections. -->
+
+# Project Name
+...content...
+
+<!-- END AUTO-GENERATED at {TIMESTAMP} UTC — Use .claude/feedback/ for corrections. -->
+```
+
+Replace `{TIMESTAMP}` with the current UTC time in format `YYYY-MM-DD HH:MM:SS` (e.g., `2026-01-14 16:30:45`). Use the same timestamp in both markers.
+
+**Always include:**
+- **Project name + one-liner**: What is this thing?
+- **Tech stack**: One to two lines max. Only mention choices Claude wouldn't guess from config files alone (e.g., "Firebase Auth via WEB_OAUTH" is worth including; "React 18 with TypeScript" is not — Claude sees that in `package.json`). Do NOT list individual dependencies, testing libraries, or build tools that appear in `package.json`/`requirements.txt` — Claude reads those files directly.
+- **Commands**: How to run, test, build, deploy — Claude needs these to execute tasks
+- **Non-obvious conventions**: Multi-schema databases, monorepo structure, unusual patterns Claude wouldn't infer
+
+**Include if divergence detected (from Step 2b):**
+- **Version Management**: Only add this section if version divergence was found
+
+```markdown
+## Version Management
+
+⚠️ Multiple version sources detected with different values:
+- `package.json:version` → "X.Y.Z"
+- `{file}:{identifier}` → "A.B.C"
+
+Verify which source is authoritative before releases.
+```
+
+Place this section near the top (after Tech Stack, before Commands) since version issues block releases.
+
+**Include if relevant:**
+- **Deployment flow**: If non-standard or involves multiple steps
+- **Key architectural decisions**: Only when the project has non-standard module boundaries (e.g., Chrome extension background/content split, microservice routing, multi-entrypoint builds). For standard single-entrypoint apps (Next.js, Express, Django), skip it — Claude can infer the architecture from the file structure.
+
+**Skip these — Claude can discover them:**
+- Detailed project structure trees (Claude can run `ls` or `tree`)
+- Exhaustive route/endpoint lists (Claude can grep)
+- File-by-file descriptions (Claude can read files)
+- Database model lists (Claude can read schema files)
+- Individual dependency names or versions (Claude reads `package.json`/`requirements.txt` directly)
+- Standard framework patterns (e.g., "uses app router" for Next.js — Claude sees `app/` directory)
+
+**Keep it tight.** A 30-line CLAUDE.md that hits the essentials beats a 200-line doc Claude has to parse every session.
+
+**Always end with:**
+```markdown
+## Team Feedback
+See `.claude/feedback/` for corrections and guidance from the team.
+```
+
+This pointer persists across autoconfig runs and directs Claude to team-maintained content.
+
+## Step 4: Create Rules Directory
+
+Create `.claude/rules/` directory if it doesn't exist by writing a `.gitkeep` file to it:
+
+```
+Write .claude/rules/.gitkeep with empty content
+```
+
+**Important**: Use Write tool to create the directory (by creating a placeholder file), not `mkdir` Bash commands. This avoids permission prompts during setup.
+
+Rules are path-scoped context files that load automatically when Claude works on matching files. Effective rules require deep understanding of your codebase patterns, team conventions, and quality goals — they should be crafted intentionally, not auto-generated.
+
+## Step 5: Configure Formatter (JS/Node Projects)
+
+**Only for projects with `package.json`:**
+
+1. Check if `scripts.format` already exists in `package.json`
+
+2. **If `scripts.format` exists:**
+   - Skip to adding the hook (Step 5b)
+
+3. **If `scripts.format` does NOT exist:**
+   - Ask the user:
+   ```
+   No formatter detected. Adding one ensures Claude's output
+   matches your project's style.
+
+   Should I add Prettier to this project? (y/n)
+   ```
+
+4. **If user says yes:**
+   - Run: `npm install -D prettier`
+   - Add to `package.json` scripts:
+     ```json
+     "format": "[ -f .prettierrc ] && prettier --write . || echo 'Create .prettierrc to enable formatting'"
+     ```
+   - Create `.prettierrc.example` in project root:
+     ```json
+     {
+       "semi": true,
+       "singleQuote": false,
+       "tabWidth": 2
+     }
+     ```
+   - Inform user: "Formatting is ready but inactive. Rename `.prettierrc.example` to `.prettierrc` when your team decides on style preferences."
+
+5. **If user says no:**
+   - Skip formatter setup, continue to Step 6
+
+**Step 5b: Add PostToolUse Format Hook**
+
+If the project has `scripts.format` (either existing or just added), add the format hook to `.claude/settings.json`:
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hooks": [
+          { "type": "command", "command": "node .claude/hooks/format.js" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+The format hook script (`.claude/hooks/format.js`) runs `npm run format` after Write/Edit operations on source files. Users can customize this script to add file filtering or different formatting logic.
+
+**Important:** Merge this with any existing hooks. Don't overwrite existing hooks.
+
+## Step 6: Configure Settings
+
+Update `.claude/settings.json` using the official schema.
+
+### Deny Patterns (files Claude shouldn't read/write)
+
+Use `Read()` for blocking reads, `Edit()` for blocking writes:
+
+**Always deny (security):**
+```
+Read(./.env)
+Read(./.env.*)
+Read(./secrets/**)
+Edit(./.env)
+Edit(./.env.*)
+```
+
+**Always deny (Windows artifacts):**
+```
+Write(./nul)
+Edit(./nul)
+```
+These prevent accidental `nul` file creation from bash/Windows command translation issues.
+
+**Often deny (generated/vendor):**
+```
+Edit(./node_modules/**)
+Edit(./dist/**)
+Edit(./.git/**)
+```
+
+### Allow Patterns (auto-approve without prompting)
+
+Use `Bash()` patterns with prefix matching:
+
+```
+Bash(npm run test:*)
+Bash(npm run lint:*)
+Bash(npm run build)
+```
+
+### Environment Variables
+
+Set session-level env vars:
+
+```json
+{
+  "env": {
+    "NODE_ENV": "development"
+  }
+}
+```
+
+**Keep it minimal** — only include patterns that actually exist in this project.
+
+## Guidelines
+
+- Replace ALL placeholder content with real values from THIS project
+- Delete sections that don't apply — no empty stubs
+- Optimize for Claude's efficiency, not human documentation
+- When uncertain, leave it out — Claude can ask or explore
+
+## Step 7: Configure MEMORY.md
+
+Claude Code has a persistent auto memory file (`MEMORY.md`) that loads into the system prompt at the start of every session. Write the debugging methodology to this file so Claude always follows evidence-based troubleshooting.
+
+**Locate the MEMORY.md file:**
+
+The file lives at `~/.claude/projects/{encoded-project-path}/memory/MEMORY.md` where the project path is encoded by replacing path separators with dashes and removing colons (e.g., `C:\CODE\my-project` becomes `C--CODE-my-project`).
+
+**Before writing, read MEMORY.md first.** If a `## Debugging` section (or similar heading like `## Debugging — Evidence Before Solutions`) already exists, **skip this step entirely** — never duplicate or overwrite user-curated memory content.
+
+**Only if no debugging section exists**, write this content (append if file already exists, create if it doesn't):
+
+```markdown
+## Debugging — Evidence Before Solutions
+NEVER guess the root cause and jump to coding a fix. Ask yourself: is the cause deterministic and verifiable from the error alone (e.g., stack trace, compile error)? If yes, fix it directly. If not:
+1. Add logging / check actual data first
+2. Confirm root cause with evidence
+3. Only then propose and implement a fix
+```
+
+**Important**: Use the Write tool (or Edit to append). Do not skip this step on first-time setup — it ensures Claude investigates root causes before making changes in every future session. But never overwrite existing user content in MEMORY.md.
+
+## Step 8: Update the Docs
+
+After populating CLAUDE.md, update the docs file previews to show actual project content:
+
+1. Open `.claude/docs/autoconfig.docs.html`
+2. Find the `fileContents` JavaScript object
+3. Update these entries with the real content just generated:
+   - `'claude-md'` → the CLAUDE.md content from Step 3
+   - `'memory-md'` → the MEMORY.md content from Step 7
+   - `'settings'` → the settings.json content from Step 6
+4. Use template literal syntax and escape any backticks in the content
+
+This ensures double-clicking these files in the docs shows real project content, not stale placeholders.
+
+## After Completion
+
+### Open Docs & Finale
+
+**Only if `.claude/docs/autoconfig.docs.html` exists**, open it in the user's browser:
+
+- macOS: `open .claude/docs/autoconfig.docs.html`
+- Linux: `xdg-open .claude/docs/autoconfig.docs.html`
+- Windows: `powershell -NoProfile -Command "Start-Process '.claude/docs/autoconfig.docs.html'"`
+
+If the docs file exists, output:
+
+---
+
+✅ Setup complete! The interactive docs are now open in your browser.
+
+---
+
+If the docs file does NOT exist (e.g., user ran `/autoconfig` without the full npx install), output:
+
+---
+
+✅ Setup complete!
+
+Run `/show-docs` to view the interactive documentation (requires full install via `npx claude-code-autoconfig`).
+
+---
+
+**IMPORTANT**: Do not add any additional text, summaries, or details after this message. The finale should be clean and punchy - end here.
+
+### Windows Cleanup
+
+On Windows, if a `nul` file was accidentally created in the project root (a common artifact from bash/Unix command translation), delete it silently using the Bash tool:
+
+```bash
+del nul 2>NUL
+```
+
 Do this cleanup silently without any output to the user.