Fork Discipline
Audit whether shared platform code stays in core versus per-deployment client folders before you fork or white-label another customer build.
Overview
Fork Discipline is an agent skill most often used in Build (also Ship, Operate) that audits and enforces clean core versus client separation in multi-client codebases.
Install
npx skills add https://github.com/jezweb/claude-skills --skill fork-disciplineWhat is this skill?
- Maps core vs client layout: shared `src/`, default `config/`, per-deployment `clients/client-name/`
- Detects hardcoded client checks, replace-not-merge config, scattered client code, and migration conflicts
- Produces a boundary map, violation report, and refactoring plan
- Optionally generates FORK.md and restructuring scripts
- Triggers on fork discipline, platform audit, fork test, and refactor for multi-client
- Client schema migrations described as numbered 0100+
- Six allowed tools: Read, Write, Edit, Glob, Grep, Bash
Adoption & trust: 551 installs on skills.sh; 841 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your multi-client repo mixes platform code with deployment-specific hacks, so every new customer fork risks breaking the shared core.
Who is it for?
Solo builders maintaining one platform repo with `clients/*` deployments who need a systematic fork audit before scaling customers.
Skip if: Single-tenant apps with no shared/core split, or teams that only need a one-off code style review without deployment boundaries.
When should I use this skill?
Triggers include 'fork discipline', 'check the boundary', 'platform audit', 'fork test', and 'refactor for multi-client'.
What do I get? / Deliverables
You receive a boundary map, violation list, and refactoring plan—and optionally FORK.md plus scripts—to keep core stable while clients override safely.
- Boundary map and violation report
- Refactoring plan and optional FORK.md
- Optional restructuring scripts
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Boundary clarity is established while shaping the codebase during Build, but violations surface again during Ship review and Operate iteration. Core/client separation is primarily backend and configuration architecture, even when it affects frontend assets under client packages.
Where it fits
Before adding a second customer deployment, map whether new tables belong in core migrations or client schema numbered 0100+.
Find hardcoded client slugs in shared services and plan extension points instead of inline conditionals.
Pre-release audit for config files that replace defaults instead of merging client overrides.
After a hotfix landed in `src/`, decide how to move it into the correct `clients/name/custom` package.
How it compares
Use for platform boundary architecture instead of a generic linter or single-PR code review skill.
Common Questions / FAQ
Who is fork-discipline for?
Indie and small-team maintainers of multi-client or white-label codebases who need to know if changes belong in core or under `clients/`.
When should I use fork-discipline?
In Build when structuring a multi-client monorepo; in Ship before a major release audit; in Operate when migration conflicts or client checks keep reappearing.
Is fork-discipline safe to install?
The skill can Read, Write, Edit, Glob, Grep, and Bash—review the Security Audits panel on this Prism page and restrict Bash in sensitive repos.
SKILL.md
READMESKILL.md - Fork Discipline
# 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: | Signal | Pattern | |--------|---------| | `clients/` or `tenants/` directory | Explicit multi-client | | Multiple config files with client names | Config-driven multi-client | | `packages/` with shared + per-client packages | Monorepo multi-client | | Environment variables like `CLIENT_NAME` or `TENANT_ID` | Runtime multi-client | | Only one deployment, no client dirs | Single-client (may be heading multi-client) | If single-client: check if the project CLAUDE.md or codebase suggests it will become multi-client. If so, audit for readiness. If genuinely single-client forever, this skill isn't needed. ### Step 2: Map the Boundary Build a boundary map by scanning the codebase: ``` CORE (shared by all clients): src/server/ → API routes, middleware, auth src/client/ → React components, hooks, pages src/db/schema.ts → Shared database schema migrations/0001-0050 → Core migrations CLIENT (per-deployment): clients/acme/config.ts → Client overrides clients/acme/kb/ → Knowledge base articles clients/acme/seed.sql → Seed data migrations/0100+ → Client schema extensions BLURRED (needs attention): src/server/routes/acme-custom.ts → Client code in core! src/config/defaults.ts line 47 → Hardcoded client domain ``` ### Step 3: Find Violations Scan for these specific anti-patterns: #### Client Names in Core Code ```b