fork-discipline

Audits and enforces the core/client code boundary in multi-client projects.

989|102|Updated Oct 20, 2025
One-click install
npx skills add https://github.com/jezweb/claude-skills --skill fork-discipline
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fork-discipline
Source: https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline
Command: npx skills add https://github.com/jezweb/claude-skills --skill fork-discipline

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Multi-client codebases tend to blur the line between shared platform code and per-client code, leading to hardcoded client checks, config files that replace instead of merge, and scattered client logic that makes adding new clients painful.

Core Features & Use Cases

  • Boundary Audit: Maps core, client, and blurred zones, then reports violations such as hardcoded client names, client-specific conditionals, and migration number conflicts with severity ratings.
  • FORK.md Documentation: Generates a FORK.md file documenting the architecture, migration numbering ranges, config merge pattern, and steps to add a new client.
  • Refactoring Plans: Produces concrete steps and scripts to move client code out of core, replace client checks with feature flags, and implement config merging.
  • Use Case: Before onboarding a second or third client to an existing SaaS project, run the audit to find every place where client identity leaks into shared code and get a prioritized fix list.

Quick Start

Ask Claude to run a fork discipline audit on this project and report any core/client boundary violations.

Frequently Asked Questions about fork-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a multi-client codebase for boundary violations?

Run the audit mode, which scans for hardcoded client names, client-specific conditionals, and client code living in shared src/ directories. It produces a boundary map and a violation report with severity ratings and suggested fixes.

How to separate client-specific code from shared platform code?

Move client code into a clients/{name}/ directory with config, content, schema, and custom subdirectories. Replace client identity checks with feature flags and merge client configs over shared defaults instead of replacing them.

When should I refactor a single-client project for multi-client support?

With one client, only document the boundary in FORK.md. With two clients, fix high-severity violations and start config merging. With three or more, run a full refactor since you now know what actually varies per deployment.

What is the difference between feature flags and client checks?

Client checks branch on identity, like if (client === 'acme'), which forces core changes for every new client. Feature flags branch on configuration, like config.features.emailOutbox, so new clients only need config entries.

How do I avoid migration number conflicts in multi-client projects?

Reserve numbered ranges: 0001-0099 for core platform migrations, 0100-0199 for client domain schema, and 0200+ for client custom features. The audit checks whether client migrations stay within their reserved ranges.