awslabs/agent-plugins is a collection of plugins, skills, instructions, an MCP server, a hook, and a setting that guide AI coding agents in architecting, deploying, and operating software on Amazon Web Services. It is for developers using coding agents such as Claude Code, Codex, and Cursor with AWS projects. The catalogue entries are the repository's own agent workflows and supporting components.
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 awslabs/agent-plugins --skill use-case-specificationgit clone --depth 1 https://github.com/awslabs/agent-pluginsWrote 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/awslabs/agent-plugins/use-case-specification)<a href="https://agentmods.dev/skills/awslabs/agent-plugins/use-case-specification"><img src="https://agentmods.dev/badge/skills/awslabs/agent-plugins/use-case-specification/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/awslabs/agent-plugins/use-case-specification"><img src="https://agentmods.dev/badge/skills/awslabs/agent-plugins/use-case-specification.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00085 | $0.00869 |
| Opus 5.5 | $0.00034 | $0.00348 |
| Sonnet 5.5 | $0.00017 | $0.00174 |
| Haiku 4.5 | $0.00009 | $0.00087 |
Grade A, and why
use-case-specification 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 1mo 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Use Case Specification
Multi-turn conversation to gather use case details and produce a use case specification document.
Principles
- One thing at a time. Each response advances exactly one decision or collects one piece of information.
- Confirm before proceeding. Wait for the user to approve the spec before considering this skill complete.
- Infer, don't interrogate. Use what's already known from the conversation. Only ask when you truly can't infer.
- Do NOT ask about base model selection. Model selection is handled exclusively by the model-selection skill.
Workflow
Step 0: Check for Existing Spec
Before starting discovery, check if a *_use_case_spec.md file already exists in the project. If it does, present it to the user and ask whether they want to reuse it, modify it, or start fresh.
Phase 1: Discovery (1–3 turns)
Review what is already known from the conversation so far, then identify what is still missing. You need these three things:
- What is the problem the user is trying to solve with model customization
- Who will use the finetuned model and in what context
- Which success criteria can be used to evaluate how well the custom model performs compared to the base model on a test set. Success criteria must be measurable by an LLM-as-a-Judge (e.g., response accuracy, tone adherence) — not things like latency or throughput.
Guidelines:
- Infer as much as possible from what the user has already said
- If the user gave examples, use them to fill gaps rather than asking again
- Only ask clarifying questions when you cannot infer the information needed for Phase 2
- If everything is already clear, say "You've given me a clear picture. I'll put together a use case specification now." and move to Phase 2.
⏸ Wait for user after each clarifying question.
Phase 2: Producing a Use Case Specification Document
- Save all generated artifacts under the project directory structure defined by the directory-management skill, if available.
- Synthesize the information you collected from the user into a Markdown document called [relevant_title]_use_case_spec.md containing the following fields (and only these fields):
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.
- 1mo ago First seen · 80 lines · 85 tokens per session scan A 6eb2f6426e64
use-case-specification is a skill published in the GitHub repository awslabs/agent-plugins (924 stars, last pushed 6d ago), licensed Apache-2.0. It adds 85 tokens to every session and 869 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
aiml-gpu-training-cluster-investigation
Use this skill for GPU training or inference clusters on SageMaker HyperPod (Slurm or EKS), ParallelCluster, or self-managed EC2/EKS GPU instances. It adds three things. First, a GPU evidence coverage audit that proves per node whether kernel Xid logs and HyperPod health-agent detections were actually arriving, hour…
sagemaker-ai-ops-review
Amazon SageMaker AI Operational Review. Use this skill when a user asks to review, audit, or assess Amazon SageMaker AI workloads (endpoints, training jobs, pipelines, notebooks, Studio domains) for best-practices posture across Security, Performance, Cost Optimization, Service Quotas, Resiliency, Operational…
agentproto-llm-endpoint
Use the local LLM endpoint proxy (localhost:18090) — or your own gated public deployment — to route Claude Code / Claude SDK through custom providers (OpenRouter, Moonshot, Groq, ZAI) via an Anthropic-compatible gateway. Covers adapter-specific behaviors, auth patterns, proxy codenames, and common failure modes.
llm-evaluation
LLM evaluation and testing patterns including prompt testing, hallucination detection, benchmark creation, and quality metrics. Use when testing LLM applications, validating prompt quality, implementing systematic evaluation, or measuring LLM performance.
rag-implementation
Comprehensive guide to implementing RAG systems including vector database selection, chunking strategies, embedding models, and retrieval optimization. Use when building RAG systems, implementing semantic search, optimizing retrieval quality, or debugging RAG performance issues.
huggingface-transformers
Hugging Face Transformers best practices including model loading, tokenization, fine-tuning workflows, and inference optimization. Use when working with transformer models, fine-tuning LLMs, implementing NLP tasks, or optimizing transformer inference.