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 agents/ramilito/kubectl.nvim/statuslinegit clone --depth 1 https://github.com/Ramilito/kubectl.nvimWrote 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/agents/ramilito/kubectl.nvim/statusline)<a href="https://agentmods.dev/agents/ramilito/kubectl.nvim/statusline"><img src="https://agentmods.dev/badge/agents/ramilito/kubectl.nvim/statusline.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.00027 | $0.01102 |
| Opus 5 | $0.00014 | $0.00551 |
| Sonnet 5 | $0.00005 | $0.00220 |
| Haiku 4.5 | $0.00003 | $0.00110 |
Grade A, and why
statusline 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 — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Statusline Feature Guidance
ALWAYS use this subagent for ANY task involving:
- Statusline content, layout, or formatting
- Cluster health indicators
- Statusline refresh timing or performance
- Adding new metrics to the statusline
File Map
| Layer | File | Purpose |
|---|---|---|
| Rust | kubectl-client/src/statusline.rs |
Statusline struct, metrics aggregation |
| Rust | kubectl-client/src/lib.rs |
Exposes get_statusline_async to Lua |
| Lua | lua/kubectl/views/statusline/init.lua |
Timer, rendering, highlight formatting |
| Lua | lua/kubectl/config.lua:129-131 |
Config defaults (statusline.enabled) |
| Lua | lua/kubectl/init.lua:13,21-23 |
View initialization on plugin start |
Data Flow
Lua Rust (dylib)
-----------------------------------------------------------
View() --> timer:start() -------> (waits 5s)
Draw() --> get_statusline_async -> Aggregate node stats + events
+-> Query Warning events (1h window)
process() <-- JSON response <----+
vim.o.statusline = formatted
Current Metrics
| Metric | Source | Display |
|---|---|---|
ready / not_ready |
node_stats() snapshot |
Node count with health dot |
cpu_pct |
Average across nodes | Percentage |
mem_pct |
Average across nodes | Percentage |
crit_events |
Warning events in last hour | Count |
Rust: Statusline Struct
pub struct Statusline {
pub ready: u16,
pub not_ready: u16,
pub cpu_pct: u16,
pub mem_pct: u16,
pub crit_events: u32,
}
The get_statusline() async function:
- Reads from the global
node_stats()informer snapshot - Aggregates node readiness and resource usage
- Queries all Warning events, filters to last hour
- Returns serialized JSON to Lua
Lua: View Lifecycle
View() - statusline/init.lua:8-23
- Saves original statusline/laststatus settings
- Sets
laststatus = 3(global statusline) - Starts timer: 5s initial delay, 30s interval
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 · 139 lines · 27 tokens per session scan A 80df6be1c8c2
statusline is an agent published in the GitHub repository Ramilito/kubectl.nvim (537 stars, last pushed 22d ago), licensed Apache-2.0. It adds 27 tokens to every session and 1,102 once invoked, about $0.0001 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-09-04.
Other agents, from other repositories
proto-rpc-reviewer
Use when reviewing changes to any .proto file under rpc/ or to the Go bindings generated from them. Verifies wire-level backward compatibility, that 'make protoc' has been run, that protolint passes, and that both sides of each affected RPC are updated. Surfaces incompatibilities that would break older clients, older…
ark-security-patcher
Fix security vulnerabilities in Ark by researching CVEs, analyzing impact, proposing mitigations, implementing patches, and creating PRs. Use when the user reports CVE numbers or security issues that need fixing in Ark. Examples:\n\n- User: "Fix CVE-2025-55183 in Ark"\n Assistant: "I'll use the ark-security-patcher…
issue-tracker
Issues and PRDs for this repo live as GitHub issues. Use the gh CLI for all operations.
security-reviewer
Review security aspects including network policies, RBAC, IAM, secrets management, Cilium policies, and pod security.
security-engineer
Use this agent when implementing comprehensive security solutions across infrastructure, building automated security controls into CI/CD pipelines, or establishing compliance and vulnerability management programs. Invoke for threat modeling, zero-trust architecture design, security automation implementation, and…
code-reviewer
Use this agent when you need to conduct comprehensive code reviews focusing on code quality, security vulnerabilities, and best practices.