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/closetheloops/moradin/forgenpx skills add CloseTheLoops/moradin --skill forgegit clone --depth 1 https://github.com/CloseTheLoops/moradinWhat 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.00054 | $0.01437 |
| Opus 5 | $0.00027 | $0.00718 |
| Sonnet 5 | $0.00011 | $0.00287 |
| Haiku 4.5 | $0.00005 | $0.00144 |
Grade A, and why
moradin-forge 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 2d 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 — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
moradin:forge
The front door of the pipeline. You never guess what to do next in a forge project — this command reads the state and routes.
When invoked
/moradin:forge or /moradin:forge <what the operator wants to do>
Step 1 — Find the target project
The forge runs against a target project directory — always a SIBLING of the Moradin folder, never inside it (nesting tangles git and pollutes context). If the conversation already names it, use it. Otherwise ask: "Which project folder are we working in? (Give me a path, or a name and I'll create a new folder next to Moradin.)" For a brand-new project, create the sibling directory and git init it — explain in one sentence that git is the save-point system everything else relies on.
Step 2 — Read the journal first
Read .forge/journal.md in the target project. It is 3 lines: current stage, last action, next action.
- No
.forge/directory → first run. Go to Step 3 (Calibrate). - Journal exists → tell the operator where they are in one sentence ("You're mid-research; last time we compared databases. Next: run /moradin:decide.") Then route via Step 4.
Load other .forge/ files only when the route needs them — never all at once.
Step 3 — Calibrate (first run only)
Before asking anything: if this workshop has memory/preferences/ content, read its _INDEX.md and pre-fill what's already known about how this operator works. Confirm pre-filled answers in one line ("I know you try the app rather than read diffs — still true?") instead of re-asking.
Then a short plain-language interview for the gaps, a few questions at a time — never a wall. "I don't know what that is" is a real answer and means "not yet."
- What are you building here, in a sentence or two?
- When AI writes code for you — do you read it, skim it, or just try the app?
- Do you use git? Branches? Pull requests?
- Are there tests? Do you run them?
- How do you find out something broke?
- Ever wished you could rewind the project to yesterday? What happened?
- How much process do you want — light guardrails, or fuller structure that catches more?
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.
- 2d ago First seen · 99 lines · 54 tokens per session scan A ec699b2ecf80
moradin-forge is a skill published in the GitHub repository CloseTheLoops/moradin (2 stars, last pushed 24d ago), licensed MIT. It adds 54 tokens to every session and 1,437 once invoked, about $0.0003 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
okf-harness-bootstrap
This unified entrypoint routes setup and workspace maintenance without making the user choose a mode.
okf-harness
One Door routes OKF Harness workspace requests to exactly one internal workflow at a time.
llm-wiki-faq
Explain LLM-Wiki adoption and answer stakeholder objections. Use when the user wants a concise FAQ response, evidence summary, ROI framing, migration answer, or plain-language rebuttal; route adversarial risk registers and bad-fit audits to llm-wiki-critique-audit.
llm-wiki-mcp-integration
Design or review MCP/API integration for an LLM-Wiki. Use when the user wants agents such as Claude Code, Codex, Cursor, ChatGPT, VS Code, GitHub Copilot, LangGraph or other MCP clients to search, read, lint, rescan, propose, review or export wiki knowledge through MCP or a local/remote API.
llm-wiki-retrieval-architect
Design the retrieval/indexing layer for an LLM-Wiki. Use for lexical/FTS search, BM25, hybrid retrieval, vector databases, rerankers, metadata filters, or GraphRAG, or when rg/index.md no longer retrieves enough context; route whole-stack local-first tooling choices to llm-wiki-local-first-stack.
llm-wiki-eval-tooling
Select evaluation tools and CI gates for LLM-Wiki measurement. Use when the user asks which eval framework, dataset format, scorecard file, red-team config, prompt regression test, hosted/self-hosted service, or human calibration workflow to use; route actual pilot runs to llm-wiki-eval.