[FEATURE] Support `.claude/CLAUDE.md` as an alternative project-level memory location

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Project-level CLAUDE.md must live at the workspace root (./CLAUDE.md), but every other Claude Code configuration file lives inside .claude/:

project/
├── CLAUDE.md              ← only file outside .claude/
└── .claude/
    ├── settings.json
    ├── settings.local.json
    ├── rules/
    ├── skills/
    ├── agents/
    └── .mcp.json

This is inconsistent with Claude Code's own global-level convention, where CLAUDE.md does live inside .claude/:

~/.claude/
├── CLAUDE.md              ← inside .claude/ at the global level
├── MEMORY.md
├── skills/
└── settings.json

For workspaces that aren't traditional codebases — research projects, writing directories, monorepos with many config files at root — having CLAUDE.md at the top level adds clutter alongside README.md, LICENSE, and other root-level files. There is no way to keep all Claude Code configuration self-contained under .claude/ at the project level, even though this is exactly how the global level already works.

Proposed Solution

Support .claude/CLAUDE.md as a valid project-level memory location, in addition to ./CLAUDE.md.

The lookup order would become:

1. ./CLAUDE.md (current behavior, preserved for backward compatibility)
2. ./.claude/CLAUDE.md (new)

If both exist, ./CLAUDE.md wins (or they are merged, matching how parent-directory CLAUDE.md files are merged today). This ensures zero breakage for existing projects while giving users the option to tuck the file inside .claude/.

The same logic should apply to CLAUDE.local.md.

---

Why This Matters Beyond Aesthetics

• Consistency. The global level already uses ~/.claude/CLAUDE.md. The project level should support the same layout.
• Interoperability. The Agent Skills open standard is converging on .claude/ (or .agents/) as a self-contained namespace. Centralizing everything under one dotfolder makes it easier to sync, symlink, and share configurations across machines and tools.
• Clean roots. Research workspaces, writing projects, and non-code repositories benefit from keeping tool configuration out of the root directory. .gitignore-ing or editor-hiding a single dotfolder is simpler than managing individual top-level files.

Alternative Solutions

• .claude/rules/ workaround: Currently, putting context in .claude/rules/context.md (without path frontmatter) is functionally similar, but it's semantically wrong — it's project memory, not a rule — and it won't be populated by /init or the # shortcut.
• .gitignore / editor exclusion: Hides the file visually but doesn't solve the organizational inconsistency.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

• A prior issue (#15278) requested this and was closed as not planned in Dec 2025. Since then the ecosystem has evolved significantly: the Agent Skills open standard, cross-tool skill sharing (Codex, Gemini CLI, Cursor all using .claude/ or similar dotfolders), and growing adoption of Claude Code for non-codebase workspaces all strengthen the case for a self-contained .claude/ directory.
• The strace output in #2274 confirms the current lookup checks ~/.claude/CLAUDE.md (global) and ./CLAUDE.md (project) — adding ./.claude/CLAUDE.md to this sequence would be a minimal change.