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/foundryside-dev/plainweave/loomweave-workflownpx skills add foundryside-dev/plainweave --skill loomweave-workflowgit clone --depth 1 https://github.com/foundryside-dev/plainweaveWhat 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.00104 | $0.08695 |
| Opus 5 | $0.00052 | $0.04347 |
| Sonnet 5 | $0.00021 | $0.01739 |
| Haiku 4.5 | $0.00010 | $0.00869 |
Grade A, and why
loomweave-workflow 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 yesterday.
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 — 520 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Loomweave Workflow
Overview
Loomweave pre-extracts a codebase into a queryable map — entities (functions,
classes, modules, files), the call/reference/import edges between them, the
relation edges (inherits_from/decorates/implements/derives), and
subsystem clusters — and serves it over MCP. Ask Loomweave instead of
re-exploring the tree. One entity_find + one entity_callers_list answers
"what calls this?" — and one entity_relation_list answers "what subclasses
this?" — without reading a single file.
When to use
- You're dropped into a codebase and need to locate a symbol or trace its callers/callees.
- You'd otherwise
grep/read many files to answer a structural question. - You need a function's neighborhood, execution paths, or which subsystem it belongs to.
Not for: editing code, reading exact implementation bodies (use
entity_summary_get or read the file once you have its path), or codebases
with no .weft/loomweave/ index.
Entity IDs — the model
Every entity has an ID: {plugin}:{kind}:{qualified_name}
(e.g. python:function:pkg.mod.func, python:class:pkg.mod.Cls,
python:module:pkg.mod). Subsystems are core:subsystem:{hash}.
You almost never type IDs. Get one from entity_find / entity_at, then
copy it verbatim into the next tool. Don't hand-construct or guess IDs.
id vs sei — which one to bind on
Every entity in a tool response now carries an sei field alongside its id.
They are not interchangeable:
idis the entity's locator — a mutable address. It changes when the code is renamed or moved, and it's the right thing to feed into the next Loomweave tool call (above).seiis the entity's durable, stable identity. It survives renames and moves. When you record a cross-tool binding — e.g. attaching a Filigree issue to a Loomweave entity — bind on thesei, not theid. A binding keyed on the mutableidsilently breaks the first time the entity moves.
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.
- yesterday First seen · 520 lines · 104 tokens per session scan A 1075ef8c8551
loomweave-workflow is a skill published in the GitHub repository foundryside-dev/plainweave (0 stars, last pushed 1mo ago), licensed MIT. It adds 104 tokens to every session and 8,695 once invoked, about $0.0005 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
derive-nfr-from-driver
Derives measurable NFRs from a parent business driver.
derive-security-from-risk
Derives security requirements from a named threat.
plan
Structured technical planning before implementation — architecture and task breakdown.
requirements
Requirements-engineering expert that operates in three modes: (1) Elicitation — extract atomic, testable requirements from briefs, meeting notes, or system specs using EARS notation, with full attribute set (ID, type, priority, ASIL, verification method, source), flagging ambiguities as open questions; (2) Refinement…
aomi-transact
Build natural-language crypto/DeFi agents and EVM MCP plugins (Claude Code, Cursor, Codex, Gemini). Aomi turns prompts into wallet-signed txs on Ethereum, Base, Arbitrum, Optimism, Polygon, Linea — non-custodial, fork-simulated. 40+ apps: Uniswap, Aave, Lido, Morpho, GMX, Hyperliquid, Polymarket.
aomi-transact
Build natural-language crypto/DeFi agents and EVM MCP plugins (Claude Code, Cursor, Codex, Gemini). Aomi turns prompts into wallet-signed txs on Ethereum, Base, Arbitrum, Optimism, Polygon, Linea — non-custodial, fork-simulated. 40+ apps: Uniswap, Aave, Lido, Morpho, GMX, Hyperliquid, Polymarket.