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/agenticpawan/fullstack-pilot/azure-api-managementnpx skills add AgenticPawan/FullStack-Pilot --skill azure-api-managementgit clone --depth 1 https://github.com/AgenticPawan/FullStack-PilotWhat 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.00098 | $0.01349 |
| Opus 5 | $0.00049 | $0.00674 |
| Sonnet 5 | $0.00020 | $0.00270 |
| Haiku 4.5 | $0.00010 | $0.00135 |
Grade A, and why
azure-api-management 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Standard IDs
| ID | Severity | What it checks |
|---|---|---|
| APIM-001 | P1 | No rate-limit/quota policy configured at the gateway |
| APIM-002 | P1 | JWT validation missing at the gateway, or duplicated inconsistently with the backend |
| APIM-003 | P2 | No backend health monitoring/circuit-breaker configured for the backend pool |
| APIM-004 | P2 | Gateway policy duplicates backend business validation instead of staying a thin pass-through |
APIM sits in front of the app-layer checks dotnet-rate-limiting already covers — this
skill governs the gateway policy layer, not a replacement for the app-layer defense-in-depth.
Check A — No rate-limit/quota policy at the gateway (APIM-001)
Detection
Check the API's policy XML for a <rate-limit-by-key>/<quota-by-key> element. Gateway-
level rate limiting protects the backend from traffic that never even reaches the app
layer's own AddRateLimiter baseline (dotnet-rate-limiting RL-003) — without it, a
traffic spike still fully lands on the backend before the app-layer limiter engages.
BAD — no gateway-level throttling, everything reaches the backend first
<policies>
<inbound>
<base />
<!-- No rate-limit-by-key — every request reaches the backend regardless of volume. -->
</inbound>
</policies>
GOOD — gateway-level rate limit per subscription key, backend's own limiter as defense-in-depth
<policies>
<inbound>
<base />
<rate-limit-by-key calls="100" renewal-period="60"
counter-key="@(context.Subscription.Id)" />
</inbound>
</policies>
Check B — JWT validation missing or inconsistent with the backend (APIM-002)
Detection
Check whether the API's policy XML includes <validate-jwt> matching the same issuer/
audience the backend's AddAuthentication().AddJwtBearer(...) validates
(dotnet-authorization). Two independent, potentially drifting validation
configurations (gateway trusts one issuer, backend trusts another) is worse than a
single source of truth — pick one layer as authoritative and keep the other consistent
with it, or omit gateway-level validation and rely on the backend exclusively.
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 · 160 lines · 98 tokens per session scan A 9b1ab382c7b7
azure-api-management is a skill published in the GitHub repository AgenticPawan/FullStack-Pilot (2 stars, last pushed 1mo ago), licensed MIT. It adds 98 tokens to every session and 1,349 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
reference-signal-forms
Explains the mental model and architecture of the code under packages/forms/signals. You MUST use this skill any time you plan to work with code in packages/forms/signals.
roll-dice
Roll dice using a random number generator. Use when asked to roll a die (d6, d20, etc.), roll dice, or generate a random dice roll.
azure-mgmt-botservice-dotnet
Azure Resource Manager SDK for Bot Service in .NET. Management plane operations for creating and managing Azure Bot resources, channels (Teams, DirectLine, Slack), and connection settings. Triggers: "Bot Service", "BotResource", "Azure Bot", "DirectLine channel", "Teams channel", "bot management .NET", "create bot".
refresh-arm-sdk-release
WORKFLOW SKILL — Prepares Azure.ResourceManager SDK refresh pull requests in azure-sdk-for-net. WHEN: "prepare sdk refresh", "refresh Azure.ResourceManager package", "update ARM SDK from autorest tag", "refresh changelog dependencies". INVOKES: git and GitHub pull request tools for branch, commit, push, and PR…
azsdk-common-pipeline-analysis
Analyze Azure SDK CI/CD pipeline failures into a structured diagnosis, and define the required output format. Load this skill before calling azsdkanalyzepipeline, which returns raw failure data that this skill interprets and formats. USE FOR: "pipeline failed", "build failure", "CI check failing", "tests failing in…
run-tests
Run project tests using Maven (mvn). Use when the user asks to run tests.