I keep it pretty simple and projectscoped.

My setup is;

One Claude chat per project (or per major feature) never reused

A short “working contract” at the top: goals, constraints, what not to touch

I paste small, relevant files only (no whole repos)

I ask claude to explain why before proposing changes if it’s non-trivial

For spec or exploratory projects, I use claude more like a thinking partner

Outline the idea Identify failure modes early, generate a minimal first version I can throw away.

The biggest improvement for me was treating chats as disposable scratchpads instead of long-running conversations.

I guess there are probably better worfklows, but I went from raw-dogging it to more structure frameworks like Get Shit Done (GSD) back to raw-dogging it but with lots of use of planning mode.

Initially I thought the structure of a framework would be nice. Tracking state, breaking things down into milestones, phases, etc. But ultimately I felt like it was all an illusion. Im not sure it's possible to track and provide Claude with the current state of the project at all times and it's just going to have to re-grok a lot of things all the time, whether you use one of these frameworks or not.

IDK, maybe there are better ways. But it feels like it increases the time and effort by a lot without any real improvement other than briefly making me feel more organized.

My Claude Code Setup

I work on multiple git worktrees of the same repo simultaneously, so I keep my Claude config in a parent directory and symlink it into each worktree. One place to update settings, policies, skills - they all stay in sync.

I use a policy MCP server that serves my coding standards as markdown files. I reference them with a § notation and they get pulled into context automatically. The server recursively resolves references, so if one policy points to another (like general code rules pointing to C++ specific rules), it follows the chain and pulls in everything needed. I have general rules, code quality rules, and C++ specific style all defined once and injected when needed.

I've set up a few skills to streamline things. The engineer skill loads the relevant policies before any code gets written. The continue/restart skills let me save session state to a continuation plan and pick up where I left off later.

Checkmate handles linting validation - different rules for different parts of the codebase (C++ engine code vs TypeScript cloud workers vs shell scripts).

Basically: policies keep the code consistent, skills keep the workflow consistent, and the shared config keeps everything in sync across worktrees.

(edited for formatting)