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 agentmods add skills/j5ik2o/okite-ai/ddd-module-patternnpx skills add j5ik2o/okite-ai --skill ddd-module-patterngit clone --depth 1 https://github.com/j5ik2o/okite-aiWrote 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/j5ik2o/okite-ai/ddd-module-pattern)<a href="https://agentmods.dev/skills/j5ik2o/okite-ai/ddd-module-pattern"><img src="https://agentmods.dev/badge/skills/j5ik2o/okite-ai/ddd-module-pattern.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 | $0.00185 | $0.01447 |
| Opus 5 | $0.00093 | $0.00724 |
| Sonnet 5 | $0.00037 | $0.00289 |
| Haiku 4.5 | $0.00018 | $0.00145 |
Grade A, and why
ddd-module-pattern 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 3d 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 — 168 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DDDモジュールパターン
「モジュールはドメインの概念を反映すべきであり、技術的な関心事ではない」 — Eric Evans, Domain-Driven Design (2003)
核心原則
ドメイン層のパッケージ名は、ユビキタス言語の一部である。
問題: 技術駆動パッケージング
domain/
entities/ ← ❌ 技術的分類
Order.java
Customer.java
value-objects/ ← ❌ 技術的分類
Money.java
OrderId.java
services/ ← ❌ 技術的分類
OrderService.java
| 問題点 | 影響 |
|---|---|
| ドメイン構造が見えない | パッケージを見ても業務の形が分からない |
| 凝集性の低下 | 関連する概念が異なるフォルダに散在 |
| 変更の波及 | 1つの機能変更で複数フォルダを横断 |
解決策: ドメイン駆動パッケージング
domain/
order/ ← ✅ ドメイン概念
Order.java
OrderId.java
OrderItem.java
customer/ ← ✅ ドメイン概念
Customer.java
CustomerId.java
pricing/ ← ✅ ドメイン概念
PricingPolicy.java
Money.java
| 利点 | 効果 |
|---|---|
| ドメインの可視化 | パッケージ一覧 = ドメインの主要概念 |
| 高凝集 | 関連する型が同一パッケージに集約 |
| 局所的変更 | 機能変更が1パッケージで完結 |
検出パターン
避けるべきパッケージ名（ドメイン層）
❌ entities/
❌ value-objects/ (valueobjects/, vo/)
❌ aggregates/
❌ services/
❌ interfaces/
❌ impl/
❌ dto/
❌ domain/types/
❌ domain/core/
レビューチェックリスト
-
パッケージ名テスト: 業務担当者に通じるか？
- ✅
order,billing,inventory→ 業務用語 - ❌
entities,services,impl→ 技術用語
- ✅
-
凝集性テスト: 同じ業務文脈に属するか？
- ✅
order/にOrder,OrderItem,OrderId - ❌
entities/にOrder,Customer,Product
- ✅
-
変更影響テスト: 1業務要件で何パッケージ触るか？
- ✅ 1-2パッケージ
- ❌ 3パッケージ以上
リファクタリング手順
Step 1: ドメイン概念の抽出
現状分析:
- Order, OrderId, OrderItem → 「注文」概念
- Customer, CustomerId → 「顧客」概念
- Money, PricingPolicy → 「価格設定」概念
Step 2: パッケージ境界の決定
order/
customer/
pricing/
Step 3: 移動と参照更新
型を新パッケージに移動し、import文を更新。
Step 4: 依存方向の確認
✅ order → pricing (注文が価格計算を使う)
❌ pricing → order (循環の可能性)
言語別ガイダンス
詳細は references/language-guides.md を参照。
例外と注意点
共有カーネル (Shared Kernel)
複数ドメインで使われる基本型は共有パッケージに置いてよい：
domain/
shared/ ← 許容される例外
Money.java
DateRange.java
order/
customer/
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.
- 3d ago First seen · 168 lines · 185 tokens per session scan A 367e36fcb92c
ddd-module-pattern is a skill published in the GitHub repository j5ik2o/okite-ai (81 stars, last pushed 4mo ago), licensed MIT. It adds 185 tokens to every session and 1,447 once invoked, about $0.0009 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-09-01.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…