Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/luccapinto/agentic-data-kitnpx agentmods add skills/luccapinto/agentic-data-kit/creating-agents-and-skillsWrote 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/luccapinto/agentic-data-kit/creating-agents-and-skills)<a href="https://agentmods.dev/skills/luccapinto/agentic-data-kit/creating-agents-and-skills"><img src="https://agentmods.dev/badge/skills/luccapinto/agentic-data-kit/creating-agents-and-skills.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.00110 | $0.01671 |
| Opus 5 | $0.00055 | $0.00835 |
| Sonnet 5 | $0.00022 | $0.00334 |
| Haiku 4.5 | $0.00011 | $0.00167 |
Grade A, and why
creating-agents-and-skills 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 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.
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 — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: creating-agents-and-skills
The governance gate for extending this kit. Goal: people add capabilities only when they help, build them with quality, and every installed tool folder stays in sync.
Follow three phases in order: Decide → Author → Propagate.
Phase 1 — Decide what (if anything) to build
Run these gates before creating anything. If a gate says stop, explain why and stop.
- LLM-native? → don't create. If a capable model already does this well ("write clean code", "use CTEs", "explain this function"), no artifact is needed. Just do the task.
- Narrow knowledge / a tool / a format / a checklist? → make a SKILL. Most additions are skills: a team naming standard, a framework's rules, a validation procedure. Skills auto-activate by description and cost almost nothing until used.
- A distinct role with its own domain and judgement? → make an AGENT. Only when there's a
persona that owns a body of work (like
data-engineer). Agents are expensive (routing, attention); the bar is high. - Overlaps an existing agent/skill? → extend it, don't add a near-duplicate. Ambiguous routing between two similar artifacts degrades results.
- A repeatable multi-step procedure the user invokes? → make a WORKFLOW (slash command).
Default to a skill. Recommend an agent only if you can name the distinct domain it owns and confirm nothing existing covers it.
Phase 2 — Author it lean
Write only domain/org-specific signal. No filler, no restating what the model knows. English.
Agent — .agent/agents/<name>.md:
---
name: <lowercase-hyphenated>
description: One sharp sentence on what it does + trigger keywords (drives routing).
tools: Read, Grep, Glob, Bash, Edit, Write
model: inherit
skills: skill-a, skill-b # optional hints; skills also self-activate
---
# <Name>
<1–2 line identity> → domain rules → handoffs to other agents → out-of-scope.
Skill — .agent/skills/<name>/SKILL.md (gerund-style name, e.g. validating-dbt-models):
---
name: <name>
description: What it does AND when to use it, in the third person, with trigger words so it
auto-activates (e.g. "Use when the user asks to ... "). This is the most important field.
---
# Skill: <name>
<when/why> → concrete rules or steps. Keep the body under ~500 lines; move long reference
material to sibling files (e.g. reference.md, scripts/) and link them.
Write descriptions in the third person ("Generates...", "Use when...") — never "I can help". The description is what makes the skill fire without the user naming it.
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 · 115 lines · 110 tokens per session scan A b580987ba7a2
creating-agents-and-skills is a skill published in the GitHub repository luccapinto/agentic-data-kit (7 stars, last pushed 1mo ago), licensed MIT. It adds 110 tokens to every session and 1,671 once invoked, about $0.0006 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
rework-rate
Measure and interpret PR rework rate — the emerging 5th DORA metric.
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
managing-astro-local-env
Manage local Airflow environment with Astro CLI (Docker and standalone modes). Use when the user wants to start, stop, or restart Airflow, view logs, query the Airflow API, troubleshoot, or fix environment issues. For project setup, see setting-up-astro-project.
checking-freshness
Quick data freshness check. Use when the user asks if data is up to date, when a table was last updated, if data is stale, or needs to verify data currency before using it.
110-java-maven-best-practices
Use when you need to review, improve, or troubleshoot a Maven pom.xml file — including dependency management with BOMs, plugin configuration, version centralization, multi-module project structure, build profiles, or any situation where you want to align your Maven setup with industry best practices. This should…
128-java-generics
Use when you need to review, improve, or refactor Java code for generics quality — including avoiding raw types, applying the PECS (Producer Extends Consumer Super) principle for wildcards, using bounded type parameters, designing effective generic methods, leveraging the diamond operator, understanding type erasure…