fork-discipline

Solid

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'.

Data & Documents 851 stars 86 forks Updated today MIT

Install

View on GitHub

Quality Score: 96/100

Stars 20%

Recency 20%

100

Frontmatter 20%

Documentation 15%

100

Issue Health 10%

License 10%

100

Description 5%

100

Skill Content

# 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 rep...

Details

Author: jezweb
Repository: jezweb/claude-skills
Created: 7 months ago
Last Updated: today
Language: Python
License: MIT

Integrates with

Anthropic · AI Cloudflare · Cloud

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

nfs-review-project

Review an existing project scaffolded with nextjs-fullstack-starter against the architectural invariants and patterns. Use this whenever the user wants to audit project conventions, asks 'does this follow our patterns', wants a pre-PR architecture check, suspects drift, is onboarding a new contributor, or invokes /nfs-review-project. Runs a mechanical check script for fast objective violations (missing server-only, DB queries in src/app/, missing requirePermission on mutations, missing audit, wrong cache primitives, tRPC imports from the wrong stack), then samples files for judgment calls, then produces a categorized report grouped by severity (must fix / should fix / notes / passing).

0 Updated 2 weeks ago

juncoding

Data & Documents Solid

skillshare-codebase-audit

Cross-validate CLI flags, docs, tests, and targets for consistency across the codebase. Use this skill whenever the user asks to: audit the codebase, check for consistency issues, find undocumented flags, verify test coverage, validate targets.yaml, check handler split conventions, or verify oplog instrumentation. This is a read-only audit — it reports issues but never modifies files. Use after large refactors, before releases, or whenever you suspect docs/code/tests have drifted out of sync.

2,204 Updated yesterday

runkids

Data & Documents Listed

bedrock

Foundation audit mode. Walk a codebase as an adversarial building inspector - stress-test load-bearing logic to bank-grade, limit-test feature flows by actually running them, and file a fragility report backed by runnable repros. Maintains an AUDIT.md ledger at repo root across runs. Use when the user asks to audit the foundations, check whether things are foundationally strong or flaky, run a bank-logic check, limit-test or stress-test features after a heavy build sprint, question the codebase from first principles, or harden what the audit found ("report and fix"). Two modes - report (default) and report-then-fix.

0 Updated 2 days ago

kennykankush