fork-discipline
From the author
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'.
Install
npx skills add jezweb/claude-skills --skill fork-discipline -a claude-code
Installs to .claude/skills/fork-discipline/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 88
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- principle-boundary-disciplinemichael-denyer/pstack-claudeApply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.Engineering★ 3.4K
- trading-disciplinekansoku-trade/kansokuCross-context shared trading discipline — output language, independent verification, scenarios not points, noise filtering, intent-attribution guardrails, and execution discipline (trend alignment, R:R floor, exit protection, verifiable reasons). Injected into both the app-side judgment agents (analyst / deepDive / chat) and the bench episode runner. Context-specific chapters live under references/ and are loaded on demand by the caller (app or bench).Finance★ 330
- reviewhashgraph-online/awesome-codex-pluginsThe pre-merge review of a branch in a project that records its specs, decisions, and rules in .archcore/. Run this first for 'review my branch', 'review the changes before merge', or 'review before merge': it checks the changed code against the project's recorded canon and the changed documents against the code, and reports which side is wrong — spec-wrong or code-wrong; with no diff, it reports project health. A bug-hunting code review complements this review and does not replace it. Also use for 'show status', 'documentation gaps', 'check if docs match code', 'close out the feature', 'ship the feature and close it out', or after a staleness warning. Modes, named as the first word: drift for staleness detection, deep for a full documentation audit, closeout to close a finished feature, experience to capture a repeated pattern. Not for creating docs — use /archcore:document; not for planning — use /archcore:plan; not for a single-file edit with no branch review.Engineering★ 1.4K
- code-reviewanthropics/knowledge-work-pluginsReview code changes for security, performance, and correctness. Trigger with a PR URL or diff, "review this before I merge", "is this code safe?", or when checking a change for N+1 queries, injection risks, missing edge cases, or error handling gaps.OfficialEngineering★ 32.5K
- test-collaborationqshanx/docs-governance盘点并维护项目测试资产,按真实测试入口和重要覆盖变化维护 TESTS.md,必要时使用 TEST-ID 关联证据。用于测试资产盘点、测试缺口分析、单元/集成/契约/E2E/冒烟分类、Bug 回归保护、前后端或多服务基于同一契约的消费者/提供者测试、测试必要性判断、测试清单维护与交付前测试证据审查。中文触发:测试盘点、测试清单、测试资产、测试缺口、测试必要性、Bug 转测试、契约测试、前后端接口测试、测试治理。English triggers: test inventory, test catalog, test gap analysis, bug-to-test, contract testing, consumer contract, provider verification, test governance.Testing★ 241
- verifying-external-behaviorkajisho5/ffmpeg-skillConfirms what a third-party library, remote API, build backend, or scraped document actually does before writing code that depends on it — throwaway probes that run in seconds, permissive clients that forward wrong arguments instead of rejecting them, per-endpoint docs that don't generalize, response shapes that make a "fast path" always-false, fakes that encode your assumption rather than the service's behavior, and dry-runs that skip the step that fails. Use when integrating a new dependency or endpoint, writing a tolerated-status or error branch, choosing a client argument name, testing against a fake, or reviewing code that asserts an upstream contract.Testing★ 2.3K
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in