Anatomy of the .claude/ folder

Original Article ↗ Hacker News Discussion ↗

Configuring Claude Code’s `.claude` folder—especially files like `CLAUDE.md`, `AGENTS.md`, and skills—has become a new locus of debate over how to work with “agentic” coding tools. Some engineers see shared prompts, skills, and sandboxing as essential guardrails and productivity boosters in large codebases, while others report better results with minimal configuration and criticize the growing ecosystem as cargo‑cult “AI slop” and configuration hell. Underneath are broader concerns about security, non‑determinism, model drift, and whether time spent tuning agents really pays off compared with simply using a plain coding assistant and writing good documentation.

Overall reaction to the article and “AI slop”

  • Many readers see the piece as marketing‑ish or “AI slop”: generic advice, LinkedIn tone, internal inconsistencies, and claims that feel overstated (e.g., “whatever you write in CLAUDE.md, Claude will follow”).
  • Others find it a useful, beginner‑friendly orientation to .claude/, especially for coworkers new to agentic coding.
  • Several say the official Claude Code docs or community guides are clearer and more grounded.

Behavior and importance of CLAUDE.md and .claude/

  • Strong disagreement on how “authoritative” CLAUDE.md is:
    • Some insist it is always loaded at session start and persists through compaction, making it central.
    • Others say it’s just more prompt text: often ignored, diluted in complex tasks, and treated as suggestion not contract.
  • Reported pain points:
    • Claude often forgets or ignores instructions (e.g., tests-first, logging rules).
    • Overly long or noisy CLAUDE.md can degrade performance; short, focused rules plus links are preferred by many.

Skills, agents, and configuration vs. keeping it simple

  • One camp: fewer skills and minimal config work best. Too many skills/agents:
    • Pollute context, confuse the model, and lead to tool‑call thrashing.
    • Become a “productivity setup” rabbit hole akin to dotfiles/Jira/Emacs bikeshedding.
  • Another camp: thoughtfully designed skills/MCPs are powerful, especially for:
    • Project‑specific workflows (debugging, querying logs, custom APIs, accounting systems).
    • Enforcing architecture patterns, separation of concerns, and repeatable debugging steps.
  • Several note that custom hacks often become obsolete quickly as models and harnesses improve.

Team workflows, guardrails, and standardization

  • .claude/ is seen as a way to:
    • Share conventions, tooling, and guardrails across teams (e.g., preconditions before running, “don’t push to main”).
    • Align agent behavior when multiple devs use AI on the same repo.
  • Concerns:
    • Editing shared files like AGENTS.md can affect everyone; some suggest treating them like config with PR review.
    • No cross‑vendor standard for these files; some people experiment with symlinks or per‑model files.

Security and sandboxing

  • Strong warnings about running Claude Code/agents without isolation:
    • Default “ask before running commands” is not a real sandbox.
    • Recommended approaches include Docker/devcontainers, official sandboxing, firejail, or cloud/VM isolation.
  • Deny‑lists in settings.json are viewed by some as partial “security theater”; containerization is preferred.

Broader views on AI coding and profession

  • Split between:
    • Enthusiasts who report big productivity and quality gains with well‑tuned setups and evals.
    • Skeptics who see “prompt and pray” as cargo‑cult engineering, fear config hell, and argue you still must review AI‑generated code line by line.
  • Some expect many current configuration practices to fade as models and harnesses improve.