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 instructions/data-privacy-stack/presidio/yaml-configgit clone --depth 1 https://github.com/data-privacy-stack/presidioWhat 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.01345 | $0.01345 |
| Opus 5 | $0.00673 | $0.00673 |
| Sonnet 5 | $0.00269 | $0.00269 |
| Haiku 4.5 | $0.00135 | $0.00135 |
Grade A, and why
presidio yaml-config.instructions.md 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 — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
YAML configuration & pydantic validation layer
Rules for the layer that translates YAML configuration into Presidio instances:
the pydantic models in presidio_analyzer/input_validation/
(yaml_recognizer_models.py, schemas.py), the loaders in
recognizer_registry/, and the shipped configs in conf/.
This layer is a public contract. YAML files written by users years ago must keep parsing, and every field a user can write must actually reach the object it configures. When reviewing, lead with:
- A YAML-reachable field that silently goes nowhere (schema/constructor drift).
- A change that makes existing YAML files stop parsing or change meaning.
- A validation failure surfacing as a distant
TypeErrorinstead of a parse-time error with an actionable message.
Schema/constructor sync
Every constructor parameter that should be settable from YAML needs a matching
pydantic field. In every contribution, check that constructor parameters and
schema fields have not drifted apart — a mismatch means a value a user writes
in YAML never reaches the object, or reaches it unvalidated. As of today the
consequence is silent: PredefinedRecognizerConfig ignores unknown YAML keys,
so a constructor kwarg without a schema field is dropped without any error and
the recognizer falls back to its defaults (the failure
LangExtractRecognizerConfig exists to prevent; see its docstring). Even if
that extra behavior changes, the no-mismatch rule stands.
- A recognizer whose constructor takes model-specific kwargs needs a dedicated
config model registered in
CONFIG_MODEL_MAP(keyed byclass_nameorname), followingHuggingFaceRecognizerConfig/GLiNERRecognizerConfig/LangExtractRecognizerConfig. - When a PR adds a constructor parameter to a recognizer that already has a config model, require the matching field in that model — otherwise YAML users cannot set it and get no error telling them so.
extra must be a deliberate choice
extra="forbid"for closed configs (TextChunkerConfig,RecognizerRegistryConfig): typos fail fast at parse time with a clear message.extra="allow"for pass-through configs whose kwargs flow to a constructor (HuggingFace, GLiNER, LangExtract).- Flag a new model that leaves pydantic's default (
extra="ignore") without justification — silent ignoring is almost never the intended behavior.
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 · 109 lines · 1,345 tokens per session scan A f1b3c94eb1b0
presidio yaml-config.instructions.md is an instructions file published in the GitHub repository data-privacy-stack/presidio (10,706 stars, last pushed 2d ago), licensed MIT. It adds 1,345 tokens to every session, about $0.0067 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 instructions, from other repositories
piighost CLAUDE.md
Instructions for Athroniaeth/piighost, covering claude.md, project overview, development commands, architecture and anonymization pipeline.
privacy-kit-cl AGENTS.md
Instructions for Yugoxc/privacy-kit-cl, covering agents.md — guía de integración para una ia, objetivo, paso 0 — detectar el terreno, paso 1 — instalar y configurar and paso 2 — implementar el store.
rizzo-pii CLAUDE.md
Instructions for Rizzo-AI-Academy/rizzo-pii, covering claude.md, cos'è questo progetto, ambiente — vincoli critici e non ovvi, mappa della repo and tassonomia: 22 tag (dettaglio in tassonomiatag.md).
pii-guard AGENTS.md
Instructions for danyuchn/pii-guard, covering agents.md, project overview, tech stack, architecture and commands.
datamimic AGENTS.md
Instructions for rapiddweller/datamimic, covering agents.md, when should an agent reach for datamimic?, tool selection, benchmarking local ollama models and authoring a new model.
docs_masked AGENTS.md
Instructions for kpshinnik/docs_masked, covering agents.md — правила работы в этом репозитории, инварианты, которые нельзя ломать, разработка, как добавить детектор and как добавить формат.