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 receptron/mulmoterminal --skill domain-restrictiongit clone --depth 1 https://github.com/receptron/mulmoterminalWrote 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/receptron/mulmoterminal/domain-restriction)<a href="https://agentmods.dev/skills/receptron/mulmoterminal/domain-restriction"><img src="https://agentmods.dev/badge/skills/receptron/mulmoterminal/domain-restriction/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/receptron/mulmoterminal/domain-restriction"><img src="https://agentmods.dev/badge/skills/receptron/mulmoterminal/domain-restriction.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.00028 | $0.00805 |
| Opus 5.5 | $0.00011 | $0.00322 |
| Sonnet 5.5 | $0.00006 | $0.00161 |
| Haiku 4.5 | $0.00003 | $0.00081 |
Grade A, and why
blueprint-internal-domain-restriction 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 27d 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 — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Company domain only
- Blocking functions need the projects upgraded to Firebase Authentication with Identity Platform. Run
sh <usecase pack>/checks/identity-platform.sh dev prod(withBLUEPRINT_BASE/BLUEPRINT_USECASEset to the two pack paths): it reads each project and names only the ones not upgraded yet. Ask the user only if it fails, giving them exactly the URLs it printed — the upgrade is free at this size, but it is a click only they can make. - In
functions/, addbeforeUserCreatedandbeforeUserSignedIn(fromfirebase-functions/v2/identity). Both throwHttpsError("permission-denied")unlessevent.data.emailends with@<domain>ANDevent.data.emailVerifiedis true. Compare lower-cased. - If the spec says Google Workspace, also pass
hd: <domain>to the Google provider. That is a hint to the account picker, not a check — the functions are the check. - Copy
infra/firestore.rulesfrom the internal pack into the project, filling{{DOMAIN_REGEX}}with the domain in lower case with its dots escaped. First check the domain is only DNS labels (^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$after lower-casing); anything else — a*, a|, a space — could widen the rule, so ask instead of escaping it. Keep every collection already opened by the data-rules step. - A refused sign-in gets its own screen, not an error code. The blocking functions' refusal reaches the
client as
auth/internal-errorwhose message carries theHttpsError(look forpermission-denied/BLOCKING_FUNCTION_ERROR_RESPONSE), so classify the error in a pure function of its own file (refused-by-domain / cancelled / popup-blocked / other) with a unit test for each kind. The refusal screen says in plain words that only@<domain>accounts can use this app, names the account that was refused when the error carries it, and offers a button that opens the account chooser again (prompt: "select_account"). Other failures say what happened in words; the raw code may follow in small text, never on its own. - Write
test/blueprint/domain.spec.ts: a verified member of the domain is let in, also with an upper-case address; another domain, an unverified address, and look-alikes (example.co.jp.evil.com,evilexample.co.jp,@example.co.jpwith nothing before the@) are all refused.
The emulator proves the code, not the real projects: the functions only run once they are deployed AND
registered as blocking functions. The verify-dev and production-auth steps check that on each project.
Done when the check passes: emulator-test.sh domain.
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.
- 27d ago First seen · 45 lines · 28 tokens per session scan A 60e86b11f09f
blueprint-internal-domain-restriction is a skill published in the GitHub repository receptron/mulmoterminal (245 stars, last pushed yesterday), licensed MIT. It adds 28 tokens to every session and 805 once invoked, about $0.0001 per session on Opus 5.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-28.
Other skills, from other repositories
build-teaql-app
Build or change a TeaQL application in Java, Rust, Go, Swift, Python, C#/.NET, or TypeScript, including Kotlin/JVM applications that consume Java-generated libraries. Mandatory order: first draft and save a complete KSML model, then verify the client and evaluate that saved model, repair it through repeated evaluation…
moai-platform-deployment
Deployment and hosting platform specialist covering Vercel, Railway, and Convex. Use when deploying applications, configuring edge functions, setting up continuous deployment, or managing serverless infrastructure.
moai-ref-api-patterns
REST/GraphQL API design patterns, error handling conventions, and input validation reference for backend development. Agent-extending skill that amplifies backend domain work (spawned via Agent(general-purpose) with backend instructions) with production-grade API patterns. Use when designing APIs, implementing…
moai-platform-auth
Authentication and authorization specialist covering Auth0, Clerk, and Firebase Auth. Use when implementing authentication, MFA, SSO, passkeys, WebAuthn, social login, or security features.
moai-domain-backend
Backend development specialist covering API design, database integration, microservices architecture, and modern backend patterns. Use when designing APIs, implementing server logic, authentication, or authorization.
moai-ref-owasp-checklist
OWASP Top 10 security checklist, authentication patterns, input validation, and HTTP security headers reference. Agent-extending skill that amplifies backend-implementation and security-audit workflows with production-grade security patterns. NOT for: frontend UI, DevOps deployment, performance optimization, testing…