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/nanasess/eccube-dev-agents/plannpx skills add nanasess/eccube-dev-agents --skill plangit clone --depth 1 https://github.com/nanasess/eccube-dev-agentsWrote 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/nanasess/eccube-dev-agents/plan)<a href="https://agentmods.dev/skills/nanasess/eccube-dev-agents/plan"><img src="https://agentmods.dev/badge/skills/nanasess/eccube-dev-agents/plan.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.00007 | $0.00797 |
| Opus 5 | $0.00003 | $0.00398 |
| Sonnet 5 | $0.00001 | $0.00159 |
| Haiku 4.5 | $0.00001 | $0.00080 |
Grade A, and why
plan 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 5d 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.
What it actually says
実装計画の立案
現在のIssue/PRの内容やコードベースを分析し、実装計画をチェックリスト形式で生成します。
手順
1. コンテキスト収集
引数に Issue/PR URL がある場合:
gh issue view <number> --repo {owner}/{repo}またはgh pr view <number> --repo {owner}/{repo}で内容を取得- コメントも取得:
gh issue view <number> --comments/gh pr view <number> --comments - PRの場合は差分も確認:
gh pr diff <number> --repo {owner}/{repo}
引数がない場合:
git branch --show-currentで現在のブランチを確認- ブランチ名からIssue番号を推定（例:
feat/123-xxx→ #123） gh pr list --head <branch>で関連PRを検索- 会話のコンテキストから作業対象を推定
2. コードベース分析
- プロジェクト構造の把握:
- CLAUDE.md があれば Read で確認
- 主要ディレクトリ構成を確認
- 影響範囲の特定:
- Issue/PRの要件から変更が必要なファイル/モジュールを特定
- Grep/Glob で関連コードを検索
- 既存パターンの確認:
- 類似の実装がないか確認
- 使用しているフレームワークの慣例を確認
- 依存関係の分析:
- 変更が他のコンポーネントに与える影響を評価
3. 計画生成
以下の形式で日本語の実装計画を生成:
## 実装計画: <タイトル>
### 背景
<Issue/PRの要約、なぜこの変更が必要か>
### 実装手順
- [ ] Step 1: <具体的な作業内容> (`path/to/file`)
- [ ] Step 2: <具体的な作業内容> (`path/to/file`)
- [ ] Step 3: <具体的な作業内容> (`path/to/file`)
...
### テスト
- [ ] <テスト項目1>
- [ ] <テスト項目2>
...
### 考慮事項
- <注意点や潜在的なリスク>
- <依存関係や前提条件>
4. 計画の品質基準
- 各ステップは1つの明確なアクションに限定
- ファイルパスを必ず付記
- 依存関係の順序を考慮した並び
- テスト項目は具体的で実行可能な形式
- 既存の実装パターンを尊重した提案
エラーハンドリング
- Issue/PRが見つからない場合: 番号やURLの確認を促す
- リポジトリ情報が取得できない場合: カレントディレクトリの確認を促す
- 要件が不明確な場合: ユーザーに追加情報を求める
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.
- 5d ago First seen · 79 lines · 7 tokens per session scan A 7866d665875a
plan is a skill published in the GitHub repository nanasess/eccube-dev-agents (2 stars, last pushed 1mo ago), licensed MIT. It adds 7 tokens to every session and 797 once invoked, about $0.0000 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
Behat BDD Testing
PHP BDD testing with Behat framework using Gherkin feature files, Mink browser extension, context classes, and Symfony integration for behavior-driven acceptance testing.
execution-grounded-review
Execution-grounded review: run tests first, trace each acceptance criterion to execution evidence. Use when verifying an implementation meets spec.
multi-model-delegation
Multi-model design consults via PAL (kimi, glm, gemini, gpt). Use when asking other models to brainstorm a design or reconciling their split answers.
blueprint-work-order
Create a work-order for isolated subagent execution, optionally linked to a GitHub issue. Use when breaking a PRP into delegatable tasks or spawning from an issue.
document-detection
Detect PRD/ADR/PRP opportunities in conversations and prompt for document creation. Use when the user discusses feature requirements, tech trade-offs, or implementation plans.
ticket-drafting-guidelines
What/Why/How prose structure and neutral, positive register for issues, PR descriptions, and tickets. Use when wording a ticket body, tightening prose, or applying house tone.