Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add arch3rPro/dsh-skills --skill module-layeringgit clone --depth 1 https://github.com/arch3rPro/dsh-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/arch3rpro/dsh-skills/module-layering)<a href="https://agentmods.dev/skills/arch3rpro/dsh-skills/module-layering"><img src="https://agentmods.dev/badge/skills/arch3rpro/dsh-skills/module-layering.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00050 | $0.00572 |
| Opus 5 | $0.00025 | $0.00286 |
| Sonnet 5 | $0.00010 | $0.00114 |
| Haiku 4.5 | $0.00005 | $0.00057 |
Grade A, and why
module-layering scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 43 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Module Layering
A discipline for knowing and enforcing the dependency graph of a multi-module or multi-package codebase. It keeps the intended layering explicit, surfaces circular dependencies, and makes a violation fail instead of silently drifting.
The defining constraint: derive the graph from the canonical dependency signal — the single authoritative statement of what each module depends on (a package manifest's peer dependencies, a module's declared imports) — rather than from ad hoc inspection. Enforce intended direction with tooling, not memory.
Know the graph
- Identify the canonical dependency signal for each module: the declared peer/regular dependency for packages, or the module imports for in-repo modules.
- Derive the inter-module edges from that signal, grouped by the package or module hierarchy, so the graph is reproducible rather than hand-maintained.
- Keep the graph as a documented artifact (a module-graph page or generated report) so it is the single home for dependency facts.
Enforce layering
- Decide the intended layering — which modules may depend on which. State it explicitly (a layering rule per layer), not implicitly.
- Detect circular dependencies — a cycle means no clear layer boundary and is a signal to re-examine ownership.
- Enforce with tooling (e.g. a dependency-cruiser or graph analyzer), running in the check gate so a new edge that violates the intended direction fails rather than silently drifting.
When it applies
Reach for this when a codebase has enough modules or packages that dependency relationships are non-trivial — multiple packages, a plugin ecosystem, or a layered architecture where the direction of dependencies matters. A single small module does not need a graph.
Workflow
- Confirm the concern — enough modules that layering matters; if not, skip.
- Identify the canonical dependency signal and derive the edges.
- State the intended layering explicitly, per layer.
- Enforce with tooling in the check gate; treat a circular dependency or an edge against the intended direction as a failure.
- Keep the graph as a documented artifact, updated with the code.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 43 lines · 50 tokens per session scan A 7bca1e7d41b3
module-layering is a skill published in the GitHub repository arch3rPro/dsh-skills (4 stars, last pushed 20d ago), licensed MIT. It adds 50 tokens to every session and 572 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
dredge
When something goes wrong during a build — including when the report can't be reproduced at all — diagnose what type of failure it is before deciding how to respond. Targeted fix, hard reset, full rethink, or a reproduction gap — the right response depends on the right diagnosis.
speckit.checker
Static Analysis Aggregator - Run static analysis on the codebase.
python-performance-optimization
Profile and optimize Python code using cProfile, memory profilers, and performance best practices.
logging-patterns
Logging conventions -- level usage, formatting style, structured output.
speckit.debug
Systematic Debugger - Diagnose problems, find individual root causes, and recommend fix plans.
cm-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.