I'm building a multi-contributor project with three workspaces — writing, visual/creative, and business/marketing. Each contributor will have their own ICM workspace. I want shared global context files — character profiles, world-building, backstory, business overview — that sit above all three workspaces and feed into each one consistently. Two questions: 1. Can a workspace's CONTEXT.md reference markdown files that live outside its own folder — upstream in a parent directory? 2. Has anyone structured a shared GitHub repo where global files live at the root and individual workspaces pull from them? How did you handle keeping global files canonical when multiple contributors are updating their workspaces? I'm not sure how to go about this.. I'm definitely green around the edges 🌱 Thank you kindly!

Since i started using claude code, i started using the CLI more. It made me understand Bash and what is needed and be done under the hood of my MacOS. Does it make me feel super cool and nerdy too, uuuuuuh, yea 🤓. [insert steve urkel laugh] I dont understand everything claude does or ask permission for but i am learning to read and watch more as my ideas get built and my .md file directions get executed on. I started doing the same with Codex. Google CLI for gemini came out a while back and now Notion came out with their CLI. I want to go deeper into this to see the effiecency and use case for myself and my path for working and building. Are you using your OS CLI? these other CLIs for other tools and services? are you back to claude code desktop? I want to hear if you started using it, been using it and Why? What are your Pros and Cons? ill go first....

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.

So I've been vibe coding with claude for a few months and actually got a decent working mvp for a technician helper app (I work in appliance repair). Sometimes my mind races with so many new ideas that I don't know how to handle haha. It's kept me up at night before because in one way I can see a path forward to so many of my ideas if I can implement a good system and make ai work for me. I want to know how you guys plan for and implement large scale coding projects? I think my most ambitious was creating a full field service suite with invoicing and dispatching and "smart parts" and some other stuff. Building from the ground up with AI in mind. But I feel like this is too big, even chunked down into smaller portions. I've taught myself a little bit of coding, but nothing on the scale for my ambition, and I honestly don't have time to do that (in a reasonable amount of time in my mind anyway haha). How do you decide what's feasible?