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/netdata/ai-viewer/project-adaptersnpx skills add netdata/ai-viewer --skill project-adaptersgit clone --depth 1 https://github.com/netdata/ai-viewerWhat 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.00039 | $0.01040 |
| Opus 5 | $0.00019 | $0.00520 |
| Sonnet 5 | $0.00008 | $0.00208 |
| Haiku 4.5 | $0.00004 | $0.00104 |
Grade A, and why
project-adapters 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 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.
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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Adapters
Mental Model
An adapter is a sealed unit that converts one source format into the canonical event stream. It knows everything about its format and nothing about anything else. See .agents/sow/specs/adapter-contract.md.
Adding a New Adapter
-
Read the format authoritatively first. Open the upstream source mirror under
/opt/baddisk/monitoring/repos/ai/<tool>/and read its persistence code. Sample real files (sanitized) from the operator's environment. -
Write the spec first. Create
.agents/sow/specs/adapter-<name>.md. Required sections: source format, record shape, watch strategy, cursor design, mapping to canonical events, sub-agent linkage, known edge cases, references. The spec is the source of truth; the code follows. -
Create the package.
internal/adapters/<name>/adapter.go. Implement thecanonical.Adapterinterface. Keep the file under 400 lines; split helpers into sibling files. -
Commit sanitized fixtures.
testdata/<name>/<scenario>/. Scenarios are listed intesting-strategy.md. Runscripts/sanitize-fixture.shbefore committing. -
Write tests. Scan, Tail, cursor resume, error handling, idempotency. Use golden files.
-
Register the factory.
internal/adapters/registry.go:registry["myadapter"] = myadapter.Factory -
Add auto-discovery probe.
internal/ingest/discover.go: add a probe entry that detects the format's presence on disk. -
Update docs.
README.mdSource Formats table;docs/adding-an-adapter.mdif any new patterns emerged. -
Open or update a SOW. Use the external reviewer gates from
project-second-opinionson the adapter SOW's gap analysis, implementation plan, and implementation before closing the work.
Modifying an Existing Adapter
- Read the adapter's spec under
.agents/sow/specs/adapter-<name>.md. - Read recent commits to that adapter (
git log -p internal/adapters/<name>/). - Check existing fixtures for coverage of the case you're touching.
- Make the change.
- Update the spec in the same commit as the code.
- Run
go test ./internal/adapters/<name>/...with-race. - If the canonical mapping changed, refresh golden files with
-update-goldenand inspect the diff manually before committing.
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 · 76 lines · 39 tokens per session scan A 960c1879ef35
project-adapters is a skill published in the GitHub repository netdata/ai-viewer (2 stars, last pushed 2d ago), licensed MIT. It adds 39 tokens to every session and 1,040 once invoked, about $0.0002 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
dd-code-generation
Use pup CLI for immediate Datadog operations or generate code for integration into applications.
opentelemetry-net-instrumentation
Provides guidance for implementing OpenTelemetry instrumentation in .NET codebases, covering tracing (Activities/Spans), metrics, logs, naming conventions, error handling, performance, SDK setup, resources, context propagation, and API design best practices.
migrate-state-management
Migrate Redux or React Context to the correct state option (React Query for server state, nuqs for URL/shareable state, Zustand for global client state). Use when refactoring away from Redux/Context, moving state to the right store, or when the user asks to migrate state management.
frontmcp-observability
Use when adding tracing, structured logging, metrics, or monitoring to a FrontMCP server. Covers zero-config OpenTelemetry distributed tracing across all flows; the this.telemetry API for custom spans, events, and attributes in tools, plugins, agents, and skills; structured JSON logging with trace correlation and…
golang-observability-opentelemetry
Instrumenting Go applications with OpenTelemetry for distributed tracing, Prometheus for metrics, and structured logging with slog.
Observability Checklist
Reviews a service or codebase against a full observability checklist — logs, metrics, traces, and alerting gaps.