# Fork Discipline

Audit and enforce the core/client boundary in multi-client projects.

- Repository: https://github.com/jezweb/claude-skills (1094 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-09
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add jezweb/claude-skills --skill fork-discipline -g -a claude-code -y`
Codex: `npx skills add jezweb/claude-skills --skill fork-discipline -g -a codex -y`
Cursor: `npx skills add jezweb/claude-skills --skill fork-discipline -g -a cursor -y`
Gemini CLI: `npx skills add jezweb/claude-skills --skill fork-discipline -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add jezweb/claude-skills`

## Description

Audit and enforce the core/client boundary in multi-client projects. Detects where shared platform code is tangled with client-specific code, finds hardcoded client checks, config files that replace instead of merge, scattered client code, migration conflicts, and missing extension points. Produces a boundary map, violation report, and refactoring plan. Optionally generates FORK.md documentation and restructuring scripts. Triggers: 'fork discipline', 'check the boundary', 'is this core or client', 'platform audit', 'client separation', 'fork test', 'refactor for multi-client', 'clean up the fork'.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Fork Discipline

Audit the core/client boundary in multi-client codebases. Every multi-client project should have a clean separation between shared platform code (core) and per-deployment code (client). This skill finds where that boundary is blurred and shows you how to fix it.

## The Principle

```
project/
  src/            ← CORE: shared platform code. Never modified per client.
  config/         ← DEFAULTS: base config, feature flags, sensible defaults.
  clients/
    client-name/  ← CLIENT: everything that varies per deployment.
      config      ← overrides merged over defaults
      content     ← seed data, KB articles, templates
      schema      ← domain tables, migrations (numbered 0100+)
      custom/     ← bespoke features (routes, pages, tools)
```

**The fork test**: Before modifying any file, ask "is this core or client?" If you can't tell, the boundary isn't clean enough.

## When to Use

- Before adding a second or third client to an existing project
- After a project has grown organically and the boundaries are fuzzy
- When you notice `if (client === 'acme')` checks creeping into shared code
- Before a major refactor to understand what's actually shared vs specific
- When onboarding a new developer who needs to understand the architecture
- Periodic health check on multi-client projects

## Modes

| Mode | Trigger | What it produces |
|------|---------|-----------------|
| **audit** | "fork discipline", "check the boundary" | Boundary map + violation report |
| **document** | "write FORK.md", "document the boundary" | FORK.md file for the project |
| **refactor** | "clean up the fork", "enforce the boundary" | Refactoring plan + migration scripts |

Default: **audit**

---

## Audit Mode

### Step 1: Detect Project Type

Determine if this is a multi-client project and what pattern it uses:

The rest: https://github.com/jezweb/claude-skills/blob/HEAD/plugins/dev-tools/skills/fork-discipline/SKILL.md