If you build with Claude or any LLM as an active collaborator rather than autocomplete, this one is worth a look. TL;DR Hard-wrapping markdown at 80 characters is a 50-year-old terminal convention that LLMs now reproduce by default because their training data is full of it. In an LLM-collaborative workflow it actively hurts you: diffs balloon, grep misses matches, retrieval chunks badly, and model output drifts when half your files use the convention and half don't. The fix is to stop hard-wrapping anywhere in your project, pick semantic paragraphs (one paragraph per line) or semantic line breaks (one sentence per line) per folder based on how that folder's content gets read and edited, and let your editor handle soft-wrap for display. Treat project files as a runtime, not as documentation. The discovery I came across a Claude system prompt (https://pastebin.com/C0s47rjV) posted to Reddit, dense and content-rich but only 71 lines long, with each paragraph sitting on a single line. Then I looked at my own project files. Around 100 markdown files of decision logs, architecture specs, reference docs, and glossaries, and most paragraphs were broken across multiple lines with manual newlines at roughly 70-80 characters. Same amount of text, two to three times the line count. The system prompt was written for a machine to read. Mine were written by following an inherited convention without anyone noticing. How the convention got there The 80-column rule is roughly 50 years old. Punch cards were literally 80 columns, VT100 terminals inherited the width, and early Unix tooling assumed fixed-width displays everywhere. Email reinforced it with RFC 2822 recommending 78 characters. By the time Markdown was invented in 2004, every developer had internalized "wrap at 80" as a virtue, and Gruber wrapped his own examples that way. The spec never required it, GitHub renders unwrapped markdown identically, but the convention propagated through every README, every dotfiles repo, every "how to write good docs" tutorial.

What has everyone found to be their sweet spot when it comes to the line length of thier MD files? Wouldn't it be more efficient to have fewer lines in a markdown file but have them be higher quality? You would likely need to create more MD files, which will take more time. However from my understanding it's easier for LLMs to process higher quality MD files with more files than the other way around. I was wondering what everybody else thought of this.

Not sure if there is a right answer here or if it's a preference thing but my question is do ya'll compact a session or take that as a hint to wrap up current work and start a new session? I'm using VS Code and when I see the auto compact about to set off, I ask claude to update the respective .md files in the workspace to wrap up the session. Is that less efficient than just compacting? I suppose my thought process was if the .mds inside the workspace are lean enough then a new session would be more token efficient than compacting.

Hoping to get a few questions answered on skills/tools based on the resource materials and examples from the classroom. 1. Do you guys keep a "global skills" folder at the project level (ie. for skills used for multiple workspaces)? That way you don't have to maintain the same skill in multiple places? 2. In the workspace-blueprint example, it says "skills work best when they're wired into the CONTEXT.md files. I asked Claude how to "wire" (which I assume just means making it accessible via backslash) and Claude said it needs to exist in the .claude/ folder, but I don't see this in the example. 3. The example also states "you can wire up to 15 skills per workspace". I don't see this limitation in any documentation - is this just a suggestion? If so, why? If you invoke a skill by name or md, why would you want to limit the number of skills in a workspace - if the ICM works as intended, it should only load in the specified skills.

The amount of posts that are nothing more than copy paste of other peoples work for like farming makes for another facebook or x. the fact that there are real incentives to gain points in the community only makes this worse. as someone who produces genuine novel content i find it very frustrating to see all the copy paste thats nothing but point farming.