Two new guides map how Claude Code teams are using `.claude/`, `CLAUDE.md`, commands, agents, skills, and global rules. The overlap matters because commenters favor short instructions and a small number of repeatable guardrails over larger prompt stacks.

CLAUDE.md and the .claude/ folder as a lightweight control surface for project instructions, custom commands, agents, skills, and permissions rather than a giant prompt blob, according to the cheat sheet and the folder guide.CLAUDE.md as the primary instruction file, while Hacker News commenters cited in the discussion describe .claude/commands/ for repeatable tasks, .claude/agents/ for narrow roles, and .claude/skills/ for broader behavior patterns.Posted by phasE89
Comprehensive cheat sheet for Claude Code, covering keyboard shortcuts (e.g., Ctrl+C cancel, Shift+Tab permission modes), slash commands (e.g., /clear, /model, /effort), MCP servers, memory files (CLAUDE.md), workflows, tips, and recent changes like PowerShell tool and transcript search. Updated regularly with new features; multilingual versions available. Author: Martin Baláž.
The new overlap is less about introducing a single feature than about documenting the operating surface Claude Code users now have to manage. Martin Baláž’s cheat sheet compresses shortcuts, slash commands like /clear, /model, and /effort, MCP server setup, memory files, and newer additions such as transcript search and a PowerShell tool into one reference. In the companion folder guide, the .claude/ directory is presented as the project-level control plane: CLAUDE.md for shared instructions, CLAUDE.local.md for personal overrides, and a global ~/.claude/ area for preferences and reusable setup.
Posted by freedomben
A complete guide to the .claude/ folder in Claude Code projects, explaining CLAUDE.md as the primary instruction file, CLAUDE.local.md for personal overrides, global ~/.claude/ folder for preferences, custom commands, skills, agents, permissions, and setup best practices. Emphasizes configuring the folder as a control center for Claude's behavior, with a practical starter progression using /init command.
That structure is what engineers appear to be standardizing around. The guide says /init can scaffold the starting point, then the rest of the folder becomes a place to separate stable instructions from task-specific automation. In the discussion around the cheat sheet, the author says the page was built because they “kept forgetting commands,” and a daily cron job now checks the changelog and marks additions with a “NEW” badge, which underscores how quickly the CLI surface is changing.
Posted by freedomben
Today’s new discussion is mostly about practical usage patterns rather than the folder’s basic structure. Several commenters converge on a “keep it short and simple” approach: brief instructions, narrow-scope agents, and only adding commands or skills where there’s a clear pain point. One commenter gives concrete examples of global Claude rules like “always use uv/venvs,” “don’t push to main,” and “read CONTRIBUTING.md,” while another describes using `.claude/commands`, `.claude/agents`, and `.claude/skills` for repeatable triage, lookup, and reviewer/security behaviors. There is also fresh skepticism: one commenter dismisses the article and points to official Claude docs instead, while another argues that some of the folder guidance feels like cargo-culting or influencer-driven overengineering. The new signal is less about whether `.claude/` exists and more about whether teams should treat it as a lightweight personal control surface or avoid turning it into a bloated workflow framework.
The strongest practitioner signal is about scope discipline. In the fresh Hacker News discussion, several commenters converge on keeping instructions “short and simple,” with one saying “more instructions does not mean better results” in the latest thread. Another commenter, quoted in the discussion, draws a practical boundary: use .claude/commands/ for “well defined repeatable” tasks, .claude/agents/ for narrow-scoped helpers, and .claude/skills/ for “job description like behaviors.”
Posted by freedomben
Thread discussion highlights: - HostingSift on Keep instructions brief: “the biggest lesson for me has been: keep things short and simple... More instructions does not mean better results.” - manfre on Practical folder layout: “Create .claude/commands/ when you have well defined repeatable... Create .claude/agents/ when you have a narrow scoped thing... Create .claude/skills/ for job description like behaviors” - EdwardDiego on Global guardrails: “I've put some stuff in my global Claude.md to avoid things like... always use uv and venvs... don't push to main ever... always read CONTRIBUTING.md”
The rule examples are similarly concrete. One user’s global Claude.md, cited in the thread discussion, encodes defaults such as “always use uv and venvs,” “don’t push to main ever,” and “always read CONTRIBUTING.md.” Another says their setup always runs task build before Claude can claim work is done, a simple check surfaced in the core discussion to catch false completions. The pushback is also part of the story: today’s delta notes skepticism that the folder should become a bloated framework, so the emerging consensus is not “add more structure,” but add only the smallest repeatable constraints that prevent common mistakes.
Posted by phasE89
Thread discussion highlights: - phasE89 on Launch and page features: I use Claude Code daily but kept forgetting commands, so I had Claude research every feature from the docs and GitHub, then generate a printable A4 landscape HTML page... A daily cron job checks the changelog and updates the sheet automatically, tagging new features with a "NEW" badge. - bibimsz on Useful reference for frequent updates: It's really nice to have a quick reference of all the features at a glance — especially since new features are being added all the time. Saves a lot of digging through docs. - comboy on Insights and reliability feedback: Wow /insights is genuinely useful... In general CLI could be more reliable and responsive though... It seems clear from the insights that some model is marking failure cases when things went wrong and likely reporting home.
Posted by freedomben
Useful framing for AI engineers: the discussion is about how to structure Claude Code repo instructions and when to use commands, agents, skills, and global rules. The practical takeaway is that small, targeted constraints seem favored over heavy prompt/framework layering, and teams are thinking about reliability, guardrails, and repeatable workflows.