Migrate Core Code to Submodules
tinyhumansai/openhuman
Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.
Audit and enforce the core/client boundary in multi-client projects.
$ npx skills add jezweb/claude-skills --skill fork-discipline -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install jezweb/claude-skills fork-discipline --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .claude/skills/fork-discipline && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .claude/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-disciplineType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add jezweb/claude-skills --skill fork-discipline -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install jezweb/claude-skills fork-discipline --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .agents/skills/fork-discipline && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .agents/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add jezweb/claude-skills --skill fork-discipline -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install jezweb/claude-skills fork-discipline --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .cursor/skills/fork-discipline && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .cursor/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/jezweb/claude-skills.git --path plugins/dev-tools/skills/fork-discipline--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add jezweb/claude-skills --skill fork-discipline -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install jezweb/claude-skills fork-discipline --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .gemini/skills/fork-discipline && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .gemini/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install jezweb/claude-skills fork-disciplineInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add jezweb/claude-skills --skill fork-discipline -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .github/skills/fork-discipline && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .github/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add jezweb/claude-skills --skill fork-discipline -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install jezweb/claude-skills fork-discipline --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/jezweb/claude-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/plugins/dev-tools/skills/fork-discipline .opencode/skills/fork-discipline && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "fork-discipline" agent skill from https://github.com/jezweb/claude-skills/tree/main/plugins/dev-tools/skills/fork-discipline into .opencode/skills/fork-discipline/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "fork-discipline", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
fork-disciplineAudit and enforce the core/client boundary in multi-client projects.
Fork Discipline is an agent skill from jezweb/claude-skills. 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…
Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: claude-code-only
It sits in Development, covering Refactoring and Code migrations. The repository describes itself as: Skills for Claude Code CLI such as full stack dev Cloudflare, React, Tailwind v4, and AI integrations. The licence is MIT.
9 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 64965d9. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
ReadWriteEditGlobGrepBashFrom allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
gitFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
claude-code-only
From compatibility in the SKILL.md frontmatter.
Fork Discipline loads about 3.1k tokens when it runs. Until then it costs about 155 tokens; SKILL.md has 754 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
allowed-tools: Read, Write, Edit, Glob, Grep, BashAutomated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from jezweb/claude-skills at commit 64965d9, republished under its MIT licence (© jezweb). 754 words, ~3,087 tokens.
.claude/skills/fork-discipline/SKILL.md (or your agent's skills folder).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.
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.
if (client === 'acme') checks creeping into shared code| 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
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.
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 domainScan for these specific anti-patterns:
# 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"Severity: High. Every hardcoded client check in core code means the next client requires modifying shared code.
Check if client configs replace entire files or merge over defaults:
// BAD — client config is a complete replacement
// clients/acme/config.ts
export default {
theme: { primary: '#1E40AF' },
features: { emailOutbox: true },
// Missing all other defaults — they're lost
}
// GOOD — client config is a delta merged over defaults
// clients/acme/config.ts
export default {
theme: { primary: '#1E40AF' }, // Only overrides what's different
}
// config/defaults.ts has everything elseLook for: client config files that are suspiciously large (close to the size of the defaults file), or client configs that define fields the defaults already handle.
Severity: Medium. Stale client configs miss new defaults and features.
Check if client-specific code lives outside the client directory:
# 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"Severity: High. Client code in src/ means core is not truly shared.
Check if core has mechanisms for client customisation without modification:
| Extension point | How to check | What it enables |
|---|---|---|
| Config merge | Does config/ have a merge function? | Client overrides without replacing |
| Dynamic imports | Does core look for clients/{name}/custom/? | Client-specific routes/pages |
| Feature flags | Are features toggled by config, not code? | Enable/disable per client |
| Theme tokens | Are colours/styles in variables, not hardcoded? | Visual customisation |
| Content injection | Can clients provide seed data, templates? | Per-client content |
| Hook/event system | Can clients extend behaviour without patching? | Custom business logic |
Severity: Medium. Missing extension points force client code into core.
# List all migration files with their numbers
ls migrations/ | sort | head -20
# Check if client migrations are in the reserved ranges
# Core: 0001-0099, Client domain: 0100-0199, Client custom: 0200+Severity: Low until it causes a conflict, then Critical.
// BAD — client name check
if (clientName === 'acme') {
showEmailOutbox = true;
}
// GOOD — feature flag in config
if (config.features.emailOutbox) {
showEmailOutbox = true;
}Search for patterns where behaviour branches on client identity instead of configuration.
Write to .jez/artifacts/fork-discipline-audit.md:
# Fork Discipline Audit: [Project Name]
**Date**: YYYY-MM-DD
**Pattern**: [explicit multi-client / config-driven / monorepo / single-heading-multi]
**Clients**: [list of client deployments]
## Boundary Map
### Core (shared)
| Path | Purpose | Clean? |
|------|---------|--------|
| src/server/ | API routes | Yes / No — [issue] |
### Client (per-deployment)
| Client | Config | Content | Schema | Custom |
|--------|--------|---------|--------|--------|
| acme | config.ts | kb/ | 0100-0120 | custom/routes/ |
### Blurred (needs attention)
| Path | Problem | Suggested fix |
|------|---------|--------------|
| src/routes/acme-custom.ts | Client code in core | Move to clients/acme/custom/ |
## Violations
### High Severity
[List with file:line, description, fix]
### Medium Severity
[List with file:line, description, fix]
### Low Severity
[List]
## Extension Points
| Point | Present? | Notes |
|-------|----------|-------|
| Config merge | Yes/No | |
| Dynamic imports | Yes/No | |
| Feature flags | Yes/No | |
## Health Score
[1-10] — [explanation]
## Top 3 Recommendations
1. [Highest impact fix]
2. [Second priority]
3. [Third priority]Generate a FORK.md for the project root that documents the boundary:
# Fork Discipline
## Architecture
This project serves multiple clients from a shared codebase.
### What's Core (don't modify per client)
[List of directories and their purpose]
### What's Client (varies per deployment)
[Client directory structure with explanation]
### How to Add a New Client
1. Copy `clients/_template/` to `clients/new-client/`
2. Edit `config.ts` with client overrides
3. Add seed data to `content/`
4. Create migrations numbered 0100+
5. Deploy with `CLIENT=new-client wrangler deploy`
### The Fork Test
Before modifying any file: is this core or client?
- Core → change in `src/`, all clients benefit
- Client → change in `clients/name/`, no other client affected
- Can't tell → the boundary needs fixing first
### Migration Numbering
| Range | Owner |
|-------|-------|
| 0001-0099 | Core platform |
| 0100-0199 | Client domain schema |
| 0200+ | Client custom features |
### Config Merge Pattern
Client configs are shallow-merged over defaults:
[Show the actual merge code from the project]After an audit, generate the concrete steps to enforce the boundary:
For each violation where client code lives in src/:
# Create client directory if it doesn't exist
mkdir -p clients/acme/custom/routes
# Move the file
git mv src/routes/acme-custom.ts clients/acme/custom/routes/
# Update imports in core to use dynamic discoveryFor each if (client === ...) in core:
// Before (in src/)
if (clientName === 'acme') {
app.route('/email-outbox', emailRoutes);
}
// After (in src/) — feature flag
if (config.features.emailOutbox) {
app.route('/email-outbox', emailRoutes);
}
// After (in clients/acme/config.ts) — client enables it
export default {
features: { emailOutbox: true }
}If the project replaces configs instead of merging:
// config/resolve.ts
import defaults from './defaults';
export function resolveConfig(clientConfig: Partial<Config>): Config {
return {
...defaults,
...clientConfig,
features: { ...defaults.features, ...clientConfig.features },
theme: { ...defaults.theme, ...clientConfig.theme },
};
}If clients need custom routes but currently modify core:
// src/server/index.ts — auto-discover client routes
const clientRoutes = await import(`../../clients/${clientName}/custom/routes`)
.catch(() => null);
if (clientRoutes?.default) {
app.route('/custom', clientRoutes.default);
}Write a script to .jez/scripts/fork-refactor.sh that:
| Client count | What to do |
|---|---|
| 1 | Don't refactor. Just document the boundary (FORK.md) so you know where it is. |
| 2 | Run the audit. Fix high-severity violations. Start the config merge pattern. |
| 3+ | Full refactor mode. The boundary must be clean — you now have proof of what varies. |
Rule 5 from the discipline: Don't abstract until client #3. With 1 client you're guessing. With 2 you're pattern-matching. With 3+ you know what actually varies.
if (client) even with one client. "This is mostly the same except..." = feature flag, not fork.© jezweb, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in plugins/dev-tools/skills/fork-discipline of jezweb/claude-skills.
Open the folder on GitHubat commit 64965d9
Fork Discipline next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Fork Discipline this skilljezweb/claude-skills | 1.1k | — | ~3.1k | Automated safety check: Notes | MIT | |
| Migrate Core Code to Submodulestinyhumansai/openhuman | 42k | — | ~2.6k | Automated safety check: Pass | GPL-3.0 | |
| ast-grep Structural Searchcode-yeongyu/oh-my-openagent | 70k | — | ~3.3k | Automated safety check: Pass | MIT | |
| ast-grep Codemod Referencewarp-drive-data/warp-drive | 3.2k | — | ~2.6k | Automated safety check: Pass | MIT | |
| Hai Ast Grephylarucoder/hai-stack | 383 | — | ~1.5k | Automated safety check: Pass | Custom licence | |
| Java 21 Developer Guide for Grailsapache/grails-core | 2.9k | — | ~1.9k | Automated safety check: Pass | Apache-2.0 |
tinyhumansai/openhuman
Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.
code-yeongyu/oh-my-openagent
Searches and rewrites code by syntax-tree shape across 25 languages with ast-grep, for codemods, structural queries and YAML lint rules, using a Python wrapper script.
warp-drive-data/warp-drive
Reference for writing and debugging TypeScript and JavaScript codemods with @ast-grep/napi: parsing, node queries, meta-variables, rule objects and editing.
hylarucoder/hai-stack
Produces a ready-to-run ast-grep command or reusable YAML lint/codemod rule, validated against positive and negative fixtures.
apache/grails-core
Guide for writing modern Java 21 in a Grails and Groovy codebase: records, sealed classes, pattern matching, text blocks and how Java works alongside Groovy.
nikolai-vysotskyi/trace-mcp
Replaces repeated hand edits with the trace-mcp apply_codemod tool, previewing matches in a dry run before bulk mechanical changes across one file or many.
jezweb/claude-skills
Generate custom favicons from logos, text, or brand colours.
jezweb/claude-skills
Set up Tailwind v4 + shadcn/ui themed UI with dark mode. An agent skill from jezweb/claude-skills.
jezweb/claude-skills
Build conversational AI voice agents on the ElevenLabs platform.
jezweb/claude-skills
Test website responsiveness across viewport widths using browser automation.
jezweb/claude-skills
Build MCP servers in Python with FastMCP. An agent skill from jezweb/claude-skills.
jezweb/claude-skills
Prepare and publish GitHub releases. An agent skill from jezweb/claude-skills.
Categories
Audit and enforce the core/client boundary in multi-client projects. Fork Discipline is an agent skill from jezweb/claude-skills. Audit and enforce the core/client boundary in multi-client projects.
Fork Discipline fits situations like: tasks that involve Refactoring; tasks that involve Code migrations.
Run `npx skills add jezweb/claude-skills --skill fork-discipline -a claude-code`. Or copy the skill folder (plugins/dev-tools/skills/fork-discipline in jezweb/claude-skills) into .claude/skills/fork-discipline in your project. Claude Code loads it when a task matches its description.
Run `npx skills add jezweb/claude-skills --skill fork-discipline -a codex`. Or copy the skill folder (plugins/dev-tools/skills/fork-discipline in jezweb/claude-skills) into .agents/skills/fork-discipline in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jezweb/claude-skills --skill fork-discipline -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/fork-discipline, .gemini/skills/fork-discipline, .github/skills/fork-discipline and .opencode/skills/fork-discipline in your project.
Going by SKILL.md and its folder, Fork Discipline needs the command-line tools its instructions call (git). Its frontmatter pre-approves these tools: Read, Write, Edit, Glob, Grep, Bash. Compatibility (from SKILL.md): claude-code-only.
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.
Fork Discipline is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Fork Discipline: Migrate Core Code to Submodules (tinyhumansai/openhuman, 42k stars), ast-grep Structural Search (code-yeongyu/oh-my-openagent, 70k stars), ast-grep Codemod Reference (warp-drive-data/warp-drive, 3.2k stars) and Hai Ast Grep (hylarucoder/hai-stack, 383 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
jezweb (a GitHub user) maintains it in jezweb/claude-skills, which has 1,052 GitHub stars. The repository holds 52 skills in this directory. The repository was last updated on October 5, 2026.
Source: jezweb/claude-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.