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 commands/dagster-io/dagster/learngit clone --depth 1 https://github.com/dagster-io/dagsterWrote 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/commands/dagster-io/dagster/learn)<a href="https://agentmods.dev/commands/dagster-io/dagster/learn"><img src="https://agentmods.dev/badge/commands/dagster-io/dagster/learn.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.00006 | $0.03294 |
| Opus 5 | $0.00003 | $0.01647 |
| Sonnet 5 | $0.00001 | $0.00659 |
| Haiku 4.5 | $0.00001 | $0.00329 |
Grade B, and why
learn scanned grade B with 2 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 4d 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.
Enumerates other installed skillsmediumAgent snooping
Other skills' SKILL.md files reveal prompts, capabilities and secrets that should be invisible to peers.
ls -la .claude/skills/ 2>/dev/null || echo "No .claude/skills/ directory" Runs shell commandslowCapability
Expected in a hook, worth knowing in a rule or an instructions file.
- **Tripwire**: Cross-cutting concerns that apply broadly (e.g., "before using subprocess.run anywhere") How it starts
The opening of the file, as written. The whole thing — 410 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/erk:learn
Create a documentation plan from Claude Code sessions associated with a plan implementation. The verb "learn" means: analyze what happened, extract insights, and create an actionable plan to document those learnings.
Usage
/erk:learn # Infers issue from current branch (P{issue}-...)
/erk:learn 4655 # Explicit issue number
Purpose
Audience: All documentation produced by this command is for AI agents, not human users.
These docs are "token caches" - preserved reasoning and research so future agents don't have to recompute it. When you research something, discover a pattern, or figure out how something works, that knowledge should be captured so the next agent doesn't burn tokens rediscovering it.
Document reality: Capture the world as it is, not as we wish it to be. "This is non-ideal but here's the current state" is valuable documentation. Tech debt, workarounds, quirks - document them. Future agents need to know how things actually work.
Bias toward capturing: When uncertain whether something is worth documenting, include it. Over-documentation is better than losing insights.
Reject dismissiveness: If you find yourself thinking "this doesn't need documentation," pause. That instinct is often wrong. New features, patterns, and capabilities almost always benefit from documentation, even when the code is "clear."
Agent Instructions
Step 1: Get Session Information
Run the exec script to get session details:
erk exec get-learn-sessions <issue-number>
Parse the JSON output to get:
session_paths: Paths to readable session filesplanning_session_id: Session that created the planimplementation_session_ids: Sessions that executed the planlocal_session_ids: Fallback sessions found locally
If no sessions are found, inform the user and stop.
Step 2: Analyze Implementation
Before analyzing sessions, understand what code actually changed. A smooth implementation with no errors can still add major new capabilities that need documentation.
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.
- 4d ago First seen · 410 lines · 6 tokens per session scan B 208586895dd7
learn is a command published in the GitHub repository dagster-io/dagster (16,073 stars, last pushed 6d ago), licensed Apache-2.0. It adds 6 tokens to every session and 3,294 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it B with 2 findings (enumerates other installed skills, runs shell commands). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
OPSX: Continue
Continue working on a change - create the next artifact (Experimental).
OPSX: Fast Forward
Create a change and generate all artifacts needed for implementation in one go.
OPSX: Verify
Verify implementation matches change artifacts before archiving.
OPSX: Onboard
Guided onboarding - walk through a complete OpenSpec workflow cycle with narration.
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
OPSX: Propose
Propose a new change - create it and generate all artifacts in one step.