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/apache/tika/file-forensicsnpx skills add apache/tika --skill file-forensicsgit clone --depth 1 https://github.com/apache/tikaWhat 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.00142 | $0.05896 |
| Opus 5 | $0.00071 | $0.02948 |
| Sonnet 5 | $0.00028 | $0.01179 |
| Haiku 4.5 | $0.00014 | $0.00590 |
Grade B, and why
file-forensics scanned grade B 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 yesterday.
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.
Unrestricted tool accessmediumExcessive agency
A wildcard tool grant or "run any command" leaves no least-privilege boundary at all.
under `access-permission:*` — the restriction flags are themselves Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -T suspect.file http://localhost:9998/rmeta > suspect.rmeta.json How it starts
The opening of the file, as written. The whole thing — 458 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Local override: $TIKA_SKILLS_LOCAL/file-forensics/LOCAL.md (default ~/.tika-skills),
read after this file, wins on conflict.
File forensics with Apache Tika
What this can and cannot tell you. Tika cannot tell you who wrote a
file. It can tell you — exhaustively — what the file claims about itself
and what it actually contains, and those claims are the evidence: a
dc:creator value is an assertion some software recorded, not an identity;
a template-default author, an inconsistency between claimed dates, or a
conspicuously missing field is as much a finding as a present one. Report
what the file says; let the human draw conclusions.
The one rule for reading Tika's output: the key prefix tells you who is asserting each fact.
tk:*— Tika's own parse-time observations, which the file cannot forge into place: magic-byte-detected type, embedded-item structure, encryption status, digests of the actual bytes.- Everything else (
dc:,pdf:docinfo:,extended-properties:,xmp:, ...) — the file's claims about itself, recorded by whatever software touched it, editable by anyone with a hex editor.
Disagreement between the two classes is where findings live.
And one rule with no exceptions: no date in a file is an observation. Creation, modification, and print timestamps — including the per-revision timestamps inside PDF incremental updates — are written by software under the control of whoever produced the file, and can be set to anything. Tika can observe that a revision layer exists, how large it is, and what it contains; when it was written is only ever claimed. Report timestamps as "the file records...", never "this happened at...".
Setup (getting tika-app or a tika-server) is covered by the
file-to-markdown companion skill; this skill assumes one is available and
uses the same invocation shapes. Parse suspect files in isolation — this
is not optional for forensics work. tika-server and tika-app -f both
parse in crash-isolated forked processes; for hostile-file triage prefer the
Docker route with the input mounted read-only (see file-to-markdown-docker)
so the parse can neither modify the evidence nor touch anything else.
The one-command forensics rig — the stock Tika image started with this skill's config (which IS the unlock on the server surface: none of these switches are on by default there):
docker run -d --rm --name tika-forensics -p 127.0.0.1:9998:9998 \
-v "$(pwd)/file-forensics-config.json:/file-forensics-config.json:ro" \
apache/tika:latest-full -c /file-forensics-config.json
curl -T suspect.file http://localhost:9998/rmeta > suspect.rmeta.json
docker stop tika-forensics # when done
Guaranteed OCR, read-only config, process isolation, explicit named configuration — in one command.
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 458 lines · 142 tokens per session scan B be16e68b3d36
file-forensics is a skill published in the GitHub repository apache/tika (4,018 stars, last pushed 2d ago), licensed Apache-2.0. It adds 142 tokens to every session and 5,896 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it B with 2 findings (unrestricted tool access, 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
pr-checklist
Use when opening or finalizing a GitHub PR for OpenMetadata. Walks through the repo PR template — linked issue, high-level design (for big PRs), unit/integration/Playwright tests + coverage, UI screen recording, and manual test steps — then drafts a fully-filled PR body and (optionally) creates the PR.
systematic-debugging
Use when debugging a failing test, build error, or runtime issue that isn't immediately obvious. Guides a 4-phase root cause analysis instead of random fix attempts.
connector-standards
Load all OpenMetadata connector development standards into context. Use before building or reviewing connectors to ensure consistent patterns.
union-type-wrappers
Add typed getters and setters over BinaryData properties that represent TypeSpec union types in generated Java models. Use when generated classes expose BinaryData for union-typed fields and you need ergonomic, type-safe accessors instead.
run-tests
Run project tests using Maven (mvn). Use when the user asks to run tests.
search-m2
Search for Java classes inside Maven dependencies in /.m2. Use when the user asks to locate classes or inspect JARs. Cross-reference pom.xml files in the current directory to resolve dependency names/versions.