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 j5ik2o/okite-ai --skill package-designgit 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/package-design)<a href="https://agentmods.dev/skills/j5ik2o/okite-ai/package-design"><img src="https://agentmods.dev/badge/skills/j5ik2o/okite-ai/package-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/j5ik2o/okite-ai/package-design"><img src="https://agentmods.dev/badge/skills/j5ik2o/okite-ai/package-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.00157 | $0.03307 |
| Opus 5 | $0.00078 | $0.01654 |
| Sonnet 5 | $0.00031 | $0.00661 |
| Haiku 4.5 | $0.00016 | $0.00331 |
Grade A, and why
package-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 6d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- package-design — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 233 lines — stays where its author put it; the contents beside it link to each section on GitHub.
パッケージ設計スキル
乱雑なコードを、体系立てた分析で整理されたパッケージへ再構成する。
核心: パッケージ設計は「ソースコードの配置」ではなく「変更の波をどこで止めるか」「依存の向きをどう制御するか」の設計問題である。
コアワークフロー
フェーズ1: 変更理由の分析 - 分割の起点を見つける
分割の出発点は「処理手順」ではなく「変化しそうな設計決定」である。
Parnas の情報隠蔽に基づき、まず以下を問う:
- 「何が変わるか？」（変更理由・変更源の列挙）
- 「変わったとき、どこまでを巻き込んでよいか？」（リリース単位・責務境界）
- 対象コードの変更履歴（git log）を分析し、一緒に変更されるファイル群を特定する
- 外部要因（UI変更、DB変更、API変更、ビジネスルール変更）ごとに影響範囲を整理する
- 各変更理由に対して「この変更は、ここで閉じるべき」という境界候補を仮置きする
出力: 変更理由と影響範囲の対応表
フェーズ2: Chunk Down（分解） - 責務を洗い出す
対象コードから原子的な責務を抽出する:
- 公開されている型・関数・トレイトをすべて列挙する
- 各要素に対して「一文の責務説明」を書く
- 暗黙的な責務（エラー処理、ログ、設定など）を洗い出す
- 複数責務を持つ要素（SRP違反）をフラグする
出力: 10〜50件の原子的な責務一覧
フェーズ3: グルーピング - 候補パッケージを作る
責務を分割する際の軸を選択し、グルーピングする。
分割軸の選択
| 分割軸 | 凝集の性質 | 適するケース | リスク |
|---|---|---|---|
| 機能（feature/vertical） | 変更が縦に閉じる | チーム独立、マイクロサービス候補 | 共通化地獄 |
| ドメイン（業務概念） | 情報的凝集 | ドメインモデルの一貫性重視 | コンテキスト間翻訳コスト |
| レイヤ（技術層） | 技術責務の分離 | 小規模、導入初期 | 1変更が全層に散る |
| 責務（変更理由） | CCP準拠 | 変更頻度が明確 | 初期分析コスト |
| API境界（公開IF） | 表面積最小化 | ライブラリ設計 | 内部柔軟性とのバランス |
グルーピングのヒューリスティクス
- 一緒に変更される要素 → 同一パッケージ（CCP）
- 一緒に再利用される要素 → 同一パッケージ（CRP）
- ドメイン概念の境界 → 自然なパッケージ境界
出力: 3〜7個の候補パッケージ（認知負荷の観点から7±2が目安）
MECEによる検証（設計目標ではなくチェック観点として）
MECEは「設計の目的」ではなく「網羅性チェックの補助」として使う。 厳密MECEにこだわりすぎると、横断的関心（ログ、認可、トランザクション等）の扱いで境界が薄くなる危険がある。8〜9割の網羅で十分。
- 各責務は1つのパッケージに割り当てられているか（重複なし）
- 未割り当ての責務が残っていないか（漏れなし）
- 「Xはどこに置く？」に対して答えが1つだけあるか
詳細は references/principles.md#mece-分割 を参照。
フェーズ4: Chunk Up - 抽象化と命名
各グループを一段抽象化して命名する:
- 各グループを貫く概念を見つける
- 技術的な役割ではなく、ドメイン概念で命名する
- そのパッケージの目的を一文で言えることを確認する
- 命名が難しい場合はグルーピングが誤っている可能性が高い → フェーズ3に戻る
良い例: authentication, billing, inventory
避ける例: utils, helpers, common, misc
フェーズ5: 依存関係設計と原則検証
依存の向きを設計する
依存は「より安定・より抽象」な側へ向ける。
- パッケージ間の依存グラフを描く
- 循環依存がないか確認（ADP）
- 安定側（多くから依存される）→ 不安定側（多くに依存する）の向きに依存が逆転していないか確認（SDP）
- 安定なパッケージが十分抽象的か確認（SAP）
循環依存の解消手順
循環が見つかった場合:
- 依存性逆転: 依存される側の抽象（Interface/Trait）を依存する側へ移し、実装は逆向きに差し込む
- 共有抽出: 相互参照している共通型/ロジックを第三のパッケージへ移動し、循環辺を切る
- 統合: 本当に同一責務ならパッケージを統合する
What ships with it
2 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.
- 6d ago First seen · 233 lines · 157 tokens per session scan A 593d4ec5f500
package-design is a skill published in the GitHub repository j5ik2o/okite-ai (81 stars, last pushed 4mo ago), licensed MIT. It adds 157 tokens to every session and 3,307 once invoked, about $0.0008 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-03.
Other skills, from other repositories
autoreview
Pre-commit/ship code review: Codex default; optional Claude or Pi.
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric.
omh-code-review
This is a Hermes-native code-review workflow skill.
revdiff-plan
Review the last Codex assistant message (plan, analysis, or proposal) with inline annotations in a TUI overlay. Extracts the most recent response from Codex rollout files and opens it in revdiff for review and annotation. Activates on "revdiff-plan", "review plan with revdiff", "annotate plan", "review last response"…
code-reviewer
Code review specialist focused on patterns, bugs, security, and performance.
agent-teams-simplify-and-harden
Implementation + audit loop using parallel agent teams with structured simplify, harden, and document passes. Spawns implementation agents to do the work, then audit agents to find complexity, security gaps, and spec deviations, then loops until code compiles cleanly, all tests pass, and auditors find zero issues or…