Production-tested rules for Claude Code that solve problems you'll only discover after losing work.
One rule. One real problem. Battle-tested before published.
Most Claude Code skill collections race to 200+ entries. We go the other way.
Every rule here was born from a real incident — hours of work destroyed by an agent that didn't know another session was running in the same directory. We wrote the rule, tested it across 20+ repos for weeks, and only then published it.
The philosophy is simple: a few rules that actually work beat a hundred that sound good on paper.
If you run multiple Claude Code sessions in the same repo (and you will, once your projects grow), you'll eventually hit this:
- Session A is building a feature, editing files, staging changes
- Session B sees unexpected errors in code it didn't touch
- Session B assumes they're "pre-existing bugs" and runs
git reset --hard - Session A's work is gone. No warning. No recovery.
This has happened to us multiple times. It will happen to you too — unless your agents know they're sharing a workspace.
The rule that prevents the scenario above. Four numbered safeguards:
| Rule | What It Does |
|---|---|
| PSA-001 Detect Before Acting | Teaches agents to recognize signs of parallel work — unexpected git changes, unfamiliar commits, spontaneous errors |
| PSA-002 Ask, Don't Assume | When parallel work is detected: stop, ask the user, don't "fix" things outside your scope |
| PSA-003 Never Destroy What You Didn't Create | Blocks git reset, git clean, git checkout --, file deletion without user approval |
| PSA-004 Isolate Your Changes | git add <file> not git add . — commit only what you touched |
A template for writing your own rules. Includes format guidance, tips for agent-readable structure, and the always-on vs. path-scoped distinction.
Copy the rule into your project's .claude/rules/ directory:
# Single rule
curl -o .claude/rules/parallel-sessions.md \
https://raw.githubusercontent.com/goetzendorfer/claude-code-skills/main/rules/parallel-sessions.md
# Or clone and copy
git clone https://github.com/goetzendorfer/claude-code-skills.git /tmp/claude-code-skills
cp /tmp/claude-code-skills/rules/parallel-sessions.md .claude/rules/That's it. Claude Code automatically loads all .md files in .claude/rules/ on session start. No configuration, no plugins, no restart needed.
Rules are markdown files in .claude/rules/ that Claude reads at the start of every session. Two types:
- Always-on (no YAML frontmatter) — loaded in every session, every file. Use for universal guidance like parallel-session awareness.
- Path-scoped (with
paths:YAML frontmatter) — loaded only when editing files matching the glob patterns. Use for domain-specific rules (frontend, backend, security).
your-project/
.claude/
rules/
parallel-sessions.md # Always-on: no frontmatter
frontend.md # Path-scoped: paths: ["src/components/**"]
Rules should be concise (under 80 lines), scannable (bold keywords), and prescriptive ("Do X" not "Consider X"). Agents scan rules, they don't study them — structure matters more than prose.
Other collections ship 100-200 skills covering everything from code review to marketing copy. Here's why we don't:
Context window cost. Every always-on rule is loaded into every session. 200 rules means thousands of tokens consumed before the agent writes a single line of code. That's context window space you're paying for — literally, in API costs — that could be used for actual work.
Signal-to-noise ratio. When an agent reads 50 rules, the critical ones (like "don't destroy parallel work") compete for attention with nice-to-haves (like "use semantic commit messages"). The more rules you add, the less each one matters.
Maintenance burden. Rules need updating as Claude Code evolves. A collection of 5 battle-tested rules is maintainable. A collection of 200 becomes stale documentation that actively misleads agents.
Our criteria for inclusion:
- Does this prevent a real, recurring problem? (not hypothetical)
- Has this been tested across multiple repos for weeks? (not just written)
- Is this universally useful? (not project-specific)
- Can Claude Code not already handle this on its own? (no duplication)
If a rule doesn't pass all four, it doesn't ship.
Use templates/RULE.md.template as a starting point. Key principles:
- One problem per rule. Don't combine "parallel sessions" with "commit conventions" — they're different concerns.
- Bold the action. Agents scan for bold text.
**Never run git reset**gets followed. "You should avoid running git reset" gets ignored. - Include anti-patterns. Agents learn as much from "don't do X" as from "do Y". Name the specific mistake, then explain why it's wrong.
- Test it. Run a Claude Code session with the rule active. Does the agent actually follow it? Adjust wording until it does.
These rules work best when combined with practices you probably already use:
- Conventional Commits — PSA-004 (isolate your changes) naturally pairs with scoped commit messages. Each session's commits stay clean and reviewable.
- Branch protection — PSA-003 (never destroy what you didn't create) reinforces branch protection rules. The agent won't force-push even if it could.
- CI/CD pipelines — When parallel sessions each commit cleanly (PSA-004), your CI pipeline sees atomic, testable changes instead of tangled merges.
- Code review — Clean, scoped commits from parallel sessions are reviewable. A single
git add .commit mixing two sessions' work is not.
- Solo developers running 2-3 Claude Code sessions on the same project (the most common parallel scenario)
- Teams where multiple people use Claude Code on a shared repo
- Anyone who has lost work to an agent that didn't know it wasn't alone
See CONTRIBUTING.md. We accept rules that solve real, universal problems — and nothing else.