Enforces strict modular code architecture: SRP, no monolithic index files, no catch-all utils, 200 LOC hard limit. This rule is NON-NEGOTIABLE. Violations BLOCK all further work until resolved.
70%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./skills/modular-code-enforcement/SKILL.mdThis rule is NON-NEGOTIABLE. Violations BLOCK all further work until resolved.
index files (index.ts, __init__.py, index.js, etc.) MUST ONLY contain:
export { ... } from "./module")index files MUST NEVER contain:
If you find mixed logic in an index file: Extract each responsibility into its own dedicated file BEFORE making any other changes. This is not optional.
A single utils, helpers, service, or common file is a gravity well — every unrelated function gets tossed in, and it grows into an untestable, unreviewable blob.
These file names are BANNED as top-level catch-alls. Instead:
| Anti-Pattern | Refactor To |
|---|---|
utils with formatDate(), slugify(), retry() | date-formatter, slugify, retry |
service handling auth + billing + notifications | auth-service, billing-service, notification-service |
helpers with 15 unrelated exports | One file per logical domain |
Design for reusability from the start. Each module should be:
If you catch yourself typing utils or service, STOP and name the file after what it actually does.
Every source file MUST have exactly ONE clear, nameable responsibility.
Self-test: If you cannot describe the file's purpose in ONE short phrase (e.g., "parses YAML frontmatter", "matches rules against file paths"), the file does too much. Split it.
| Signal | Action |
|---|---|
| File has 2+ unrelated exported functions | SPLIT NOW — each into its own module |
| File mixes I/O with pure logic | SPLIT NOW — separate side effects from computation |
| File has both types and implementation | SPLIT NOW — types file + implementation file |
| You need to scroll to understand the file | SPLIT NOW — it's too large |
Any source file exceeding 200 lines of code (excluding prompt strings, template literals containing prompts, and markdown content) is an immediate code smell.
When you detect a file > 200 LOC:
Prompt-heavy files (agent definitions, skill definitions) where the bulk of content is template literal prompt text are EXEMPT from the LOC count — but their non-prompt logic must still be < 200 LOC.
Count these (= actual logic):
if, for, while, switch, try/catch)} that belong to logic blocksExclude these (= not logic):
//, /* */, /** */)Quick method: Read the file → subtract blank lines, comment-only lines, and prompt string content → remaining count = LOC.
Example:
// 1 import { foo } from "./foo"; ← COUNT
// 2 ← SKIP (blank)
// 3 // Helper for bar ← SKIP (comment)
// 4 export function bar(x: number) { ← COUNT
// 5 const prompt = ` ← COUNT (declaration)
// 6 You are an assistant. ← SKIP (prompt text)
// 7 Follow these rules: ← SKIP (prompt text)
// 8 `; ← COUNT (closing)
// 9 return process(prompt, x); ← COUNT
// 10 } ← COUNT→ LOC = 5 (lines 1, 4, 5, 9, 10). Not 10.
When in doubt, round up — err on the side of splitting.
When reading, writing, or editing ANY source file:
Inspired by: oh-my-opencode modular-code-enforcement rule
ArabelaTso/Skills-4-SE
4f38503
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.