fork-discipline
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 fo
npx skills add jezweb/claude-skills --skill fork-discipline --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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 architectu
- The Principle
- When to Use
- Modes
- Audit Mode
- Step 1: Detect Project Type
- Step 2: Map the Boundary
- Step 3: Find Violations
- Step 4: Produce the Report
- Document Mode
- Refactor Mode
- 1. Move Client Code Out of Core
- 2. Replace Client Checks with Feature Flags
- 3. Implement Config Merge
- 4. Add Extension Point for Custom Routes
Search for hardcoded client identifiers in shared code grep -rn "acme\|smith\|client_name_here" src/ --include="*.ts" --include="*.tsx" Search for client-specific conditionals grep -rn "if.*client.*===\|switch.*client\|case.*['\"]acme" src/ --include="*.ts" --include="*.tsx" Search for environment-based client checks in shared code grep -rn "CLIENT_NAME\|TENANT_ID\|process.env.*CLIENT" src/ --include="*.ts" --include="*.tsx" Files with client names in their path but inside src/ find src/ -name "*acme*" -o -name "*smith*" -o -name "*client-name*" Routes or pages that serve a single client grep -rn "// only for\|// acme only\|// client-specific" src/ --include="*.ts" --include="*.tsx"
What does the fork-discipline skill do?
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 fo
How do I install it?
Run `npx skills add jezweb/claude-skills --skill fork-discipline --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From jezweb/claude-skills, a repository with 954 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.