القائمة
When and along which lines to separate code into modules and files. Invoke before growing a module, judging a new one, or splitting a file or surface.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
What to expose in settings surfaces and how to organize it. Invoke before exposing a setting, organizing a page, or reworking a settings surface.
Testing posture — test behavior not implementation, stay sober, grow coverage per workstream. Invoke before writing a test or extending coverage.
One normalized way to name files, folders, symbols, resources and providers. Invoke before naming or renaming.
How to write the JOURNAL.md. Invoke when recording a finding, or a small decision worth keeping.
What to observe in code, and how to write it readable and actionable. Invoke before adding or changing an observation point.
How versions are numbered and the changelog written. Invoke before cutting a version, writing a CHANGELOG entry, or drafting release notes.
| name | deckle-modularite |
| description | When and along which lines to separate code into modules and files. Invoke before growing a module, judging a new one, or splitting a file or surface. |
| type | skill |
Modularize an application so it stays legible and easy to grow: each capability a separable unit, with clean one-way dependencies.
A module carries one responsibility nameable in a single sentence, and exposes a narrow public surface. More than one sentence, or a sprawling surface, means it is really several — separate them.
Know which kind of module you're writing before you grow it — the kind sets the rules. The dividing question: does it hold an active runtime state that acts on the system? If so, it's a domain module — it owns that state and everything attached to it, settings and persistence included. If not, it's support: pure code others call, the reusable bottom layer, referenced widely and depending on almost nothing. A module that owns no domain but assembles others is a shell when it only presents them, a host when its whole job is to aggregate by role — and for a host, referencing widely is the point, not a flaw.
Dependencies point one way only, toward the more fundamental — never sideways or up. A cycle means a shared notion must rise into a common module, or two modules are really one.
Make "could this live in its own file?" a reflex on every change — the answer is usually yes. Group related functions into small, cohesive, well-named files (a coherent cluster, never a single function stranded alone), many to a folder, subfolders for depth. A tree of named files shows what changed at a glance, and replaces both in-file section comments and thousand-line files. The only brake is performance: don't separate files when it would cost real load or runtime.
Settings are modular too: each module carries its own settings page and its persistence, instead of piling them into a central settings shell.
