Fork Discipline

If you've ever seen an `if (client === 'acme')` check creep into what should be shared platform code, you need this. It audits multi-client codebases for boundary violations: hardcoded client names in core, config files that replace instead of merge, client-specific code scattered in src/, and missing extension points that force developers to patch shared code for every new deployment. You get a boundary map showing what's actually core versus client-specific, a violation report with severity levels, and a refactoring plan. Most useful right before adding a second or third client to a project, or when onboarding someone who needs to understand why the codebase is structured the way it is.

skills.sh installs: 905
GitHub stars: 1.1K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add jezweb/claude-skills --skill fork-discipline --agent claude-code

Installs into .claude/skills of the current project.

Files

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.