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 hmj1026/dhpk --skill module-designgit clone --depth 1 https://github.com/hmj1026/dhpkWrote 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/hmj1026/dhpk/module-design)<a href="https://agentmods.dev/skills/hmj1026/dhpk/module-design"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/module-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/hmj1026/dhpk/module-design"><img src="https://agentmods.dev/badge/skills/hmj1026/dhpk/module-design.svg" alt="Reviewed on agentmods" width="80" 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.00066 | $0.01144 |
| Opus 5.5 | $0.00026 | $0.00458 |
| Sonnet 5.5 | $0.00013 | $0.00229 |
| Haiku 4.5 | $0.00007 | $0.00114 |
Grade A, and why
module-design 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 yesterday.
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 — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Module design
Design the smallest deep module that makes the caller's next decision easy. Keep this guidance stack-neutral until the repository evidence selects a framework or language.
Scope before scan
Start with the user's named module, subsystem, or pain point. When no direction is named, use recent commit history to find the hot spots that keep changing and weight the exploration there. Do not propose deepening across the whole codebase before a real seam, caller, and near-term change are identified; this is the YAGNI filter for architecture work.
Modes
Select exactly one mode from design, review, compare, or
adversarial; design is the default. In every mode, frame the question,
constraints, scope, risks, and decision criteria before recommending a seam.
- Design proposes a boundary for a new capability or change.
- Review evaluates an existing boundary against callers, data flow, and failure modes.
- Compare scores concrete alternatives against the named criteria rather than treating personal preference as evidence.
- Adversarial forms an independent Proposal A and, only when explicitly
requested, a blind Proposal B; run three bounded critique rounds by default
and never more than five. Preserve material disagreement and stop with
unresolved disagreementwhen the evidence does not support convergence.
Optional second opinion
The primary path uses only the current in-process model and does not invoke a
second opinion. An explicit --second-opinion=codex-exec opt-in may run
codex exec as a blind, clearly labelled additional proposal or critique; it
must never replace the primary recommendation or become a silent fallback.
Record the question, constraints, research summary, assumptions, decision
criteria, failure modes, and any changed recommendation for that opinion.
Boundary tests — SSOT: architecture/tests own runtime behavior; this skill owns boundary decisions
- Caller leverage: define the decision the caller should make and make the module absorb the policy and variation behind that decision.
- Deletion test: temporarily imagine deleting the proposed abstraction. If callers become simpler or no behavior is lost, delete it; a name alone is not a module boundary.
- Interface-as-test-surface: make the public interface the behavior seam; tests should assert caller-visible outcomes through it, not private helpers.
- Keep one hypothetical adapter inline. Introduce an abstraction only when there are two real adapters, or when a documented near-term boundary has a concrete test or deployment need. Do not design for speculative providers.
- Make the change easy before making the easy change: prefer a small prefactor that improves locality only when the next requested behavior needs it, and record speculative candidates as deferred rather than building them.
What ships with it
3 files 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.
- yesterday Changed · +2 lines 21b5a1e06cb3
- 10d ago First seen · 107 lines · 66 tokens per session scan A 6d4633b1fac5
module-design is a skill published in the GitHub repository hmj1026/dhpk (2 stars, last pushed today), licensed MIT. It adds 66 tokens to every session and 1,144 once invoked, about $0.0003 per session on Opus 5.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-10-07.
Other skills, from other repositories
harness
A meta-skill for designing and maintaining a project harness: a coordinated set of specialist agents, skills, and project instructions. It defines their roles, connects them to the project, and updates the setup as the work changes.
evolve
A workflow for improving an existing setup that guides coding agents. It collects results and feedback, compares the current setup with its starting version, and records useful changes.
dev-plan
A planning tool that breaks a software project into features arranged in dependency-based waves, or groups of work that can be done in sequence or parallel.
research
A research workflow that assigns separate agents to study open-source projects, competing products, and current development practices. Git worktrees are separate working copies used to keep those investigations isolated.
glean
This skill should be used BEFORE any feature design. It runs structured gleaning with the user — asking 5 high-leverage questions per round, up to 3 rounds, to extract Goal / Scope / Constraints / Edges / Done. Output is saved to .mumei/scratch/ .md and used as input for /mumei:compose. Triggers include "I want to add…
validation-sample
A skill for building a reference test set of 50–100 realistic scenarios for checking an agent or product. It separates user inputs from expected answers to prevent answer leakage and requires at least 90% before shipping.