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 jentic/jentic-one --skill import-new-apigit clone --depth 1 https://github.com/jentic/jentic-oneWrote 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/jentic/jentic-one/import-new-api)<a href="https://agentmods.dev/skills/jentic/jentic-one/import-new-api"><img src="https://agentmods.dev/badge/skills/jentic/jentic-one/import-new-api.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.1 | $0.00142 | $0.03497 |
| Opus 5 | $0.00071 | $0.01749 |
| Sonnet 5 | $0.00028 | $0.00699 |
| Haiku 4.5 | $0.00014 | $0.00350 |
Grade C, and why
import-new-api scanned grade C 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 7d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf /tmp/import-openapi-specs Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
code=$(curl -s -o /dev/null -w "%{http_code}" -L "$RAW"); [ "$code" = 200 ] && break; sleep $((i*5)) How it starts
The opening of the file, as written. The whole thing — 270 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Import a New API (spec → local registry → import-openapi-specs repo → import issue)
Import an API that is not yet in jentic-public-apis:
generate an OpenAPI spec from the vendor's docs, optionally import it into the local Jentic
registry first (so the user's agent can execute it immediately), then publish it to the user's
single reusable public repo import-openapi-specs and open the import issue that drives it into
the community catalog.
This is the greenfield counterpart to contribute-spec-fix (which fixes a spec already in the
catalog). Use contribute-spec-fix when the vendor already exists; use this skill when it does not.
Target: $ARGUMENTS (a vendor name like firecrawl, or a URL to the vendor's API docs). If only
a company name is given, find its public API docs by searching for <company> API documentation.
Prerequisites
ghCLI authenticated (gh auth status) withreposcope. Note which account is active — the spec repo is created there and its raw links must resolve publicly.- No local jentic-public-apis checkout needed — the vendor-existence check runs against GitHub
via
gh. - For the optional local-first step only: a running Jentic control plane and a registered agent
identity (
jentic doctorconfirms a resolvable identity with a usable token;jentic access whoamishows what you can do).
Steps
1. Confirm the vendor is NOT already in the catalog (hard gate)
Check the live repo, not a local checkout:
gh api "repos/jentic/jentic-public-apis/contents/apis/openapi" --paginate \
--jq '.[].name' | grep -i '<vendor-guess>'
Try the real domain (firecrawl.dev), bare name (firecrawl), and obvious variants (with and
without subdomains: api.foo.com vs foo.com). If a matching vendor directory exists, STOP
and tell the user — re-importing produces a duplicate, and the import workflow hard-fails on an
existing version directory anyway. Point them at contribute-spec-fix if they meant to fix the
existing spec, or offer a genuinely-absent alternative.
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.
- 7d ago First seen · 270 lines · 142 tokens per session scan C 2850ea1c0446
import-new-api is a skill published in the GitHub repository jentic/jentic-one (175 stars, last pushed yesterday), licensed Apache-2.0. It adds 142 tokens to every session and 3,497 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it C with 2 findings (recursive force delete, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
api-design
Use when designing or reviewing an API surface — REST, GraphQL, or gRPC. Contract-first methodology: the contract artifact (OpenAPI 3.1, SDL, proto3) is written and reviewed BEFORE implementation, lives in the repo, and Phase 6 verifies implementation matches it.
dotnet-patterns
Use when writing C#/.NET backend code — ASP.NET Core APIs (minimal APIs or MVC), workers, EF Core data access. Builder playbook: layout, DI lifetimes, async/cancellation, EF Core discipline, options pattern, error contract, testing shape. Complements csharp-reviewer.
node-patterns
Use when writing Node.js/TypeScript backend code — Express, Fastify, or NestJS services, APIs, workers. Builder playbook: project layout, async discipline, typed config, error taxonomy, DI boundaries, testing shape. Complements typescript-reviewer (this prevents, the reviewer catches).
api-design
Design production-grade REST, GraphQL, gRPC, and Python library APIs with correct schemas, error contracts, auth, and versioning. Use when the user asks to design an API, define endpoints, create an OpenAPI/Swagger spec, design a GraphQL schema, build a gRPC service, model request/response with Pydantic, add…
content-modelling
Design CMS content models — content types, fields, editorial workflows, governance rules, and COPE (Create Once, Publish Everywhere) patterns — for structured, multi-channel publishing. Use when the user asks to design a content model, define content types in a CMS, structure fields for editorial content, plan a…
springboot-patterns
Spring Boot architecture patterns, REST API design, layered services, data access, caching, async processing, and logging. Use for Java Spring Boot backend work.