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/lewing/helix.mcp/centralized-filter-normalizationnpx skills add lewing/helix.mcp --skill centralized-filter-normalizationgit clone --depth 1 https://github.com/lewing/helix.mcpWrote 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/lewing/helix.mcp/centralized-filter-normalization)<a href="https://agentmods.dev/skills/lewing/helix.mcp/centralized-filter-normalization"><img src="https://agentmods.dev/badge/skills/lewing/helix.mcp/centralized-filter-normalization.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 | $0.00030 | $0.01519 |
| Opus 5 | $0.00015 | $0.00759 |
| Sonnet 5 | $0.00006 | $0.00304 |
| Haiku 4.5 | $0.00003 | $0.00152 |
Grade A, and why
centralized-filter-normalization 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 4d 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 — 170 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Context
Use when a filter record (e.g., AzdoBuildFilter) has optional string fields with server-side defaults
and case-insensitive server interpretation. Multiple layers (HTTP client, cache key builder, service
layer) historically re-implement the same canonicalization rules, causing algorithmic drift.
The pattern was extracted from the Issue #82 refactor of AzdoBuildFilter, which fixed four rounds
of reviewer feedback on PR #78 (each round finding the same class of normalization bug at a different
layer).
The Principle
"Canonicalize at boundaries, share the algorithm."
- Validate at user/input boundaries (CLI/MCP) — for early, useful error messages
- Canonicalize at semantic boundaries (URL construction, cache key derivation) — where the value's meaning is consumed
- Centralize the canonicalization algorithm — multiple layers call the shared helper; none re-implement
"Normalize at every layer" (a common first instinct) leads to algorithm duplication and drift.
Pattern: Three Types, One File Per Filter
1. Defaults class (in domain model file, alongside the filter record)
public static class AzdoBuildFilterDefaults
{
public const string QueryOrder = "queueTimeDescending";
public const string Outcomes = "Failed";
}
- Lives in the domain layer (same project/namespace as the filter record)
- Both HTTP client and cache layer reference these constants — no layer depends on another for constants
2. Normalizer class (domain layer, {FilterType}Normalizer.cs)
public static class AzdoBuildFilterNormalizer
{
public static AzdoBuildFilter Normalize(AzdoBuildFilter filter) =>
filter with
{
PrNumber = NormalizeString(filter.PrNumber),
Branch = NormalizeString(filter.Branch),
StatusFilter = NormalizeString(filter.StatusFilter),
QueryOrder = NormalizeQueryOrder(filter.QueryOrder),
};
private static string? NormalizeString(string? value) =>
string.IsNullOrWhiteSpace(value) ? null : value.Trim();
private static string? NormalizeQueryOrder(string? value)
{
var trimmed = NormalizeString(value);
if (trimmed is null) return null;
if (string.Equals(trimmed, AzdoBuildFilterDefaults.QueryOrder, StringComparison.OrdinalIgnoreCase))
return null; // collapse explicit server default to null
return trimmed.ToLowerInvariant(); // lowercase for case-insensitive equivalence
}
}
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.
- 4d ago First seen · 170 lines · 30 tokens per session scan A 5c791e1cd1f2
centralized-filter-normalization is a skill published in the GitHub repository lewing/helix.mcp (4 stars, last pushed 4d ago), licensed MIT. It adds 30 tokens to every session and 1,519 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
maui-networking-offline-data
Build MAUI networking and offline data. USE FOR: typed HttpClient, JSON serialization, Android 10.0.2.2, iOS simulator localhost, LAN/dev-tunnel fallback, debug cleartext, offline-first screens, SQLite/EF Core sync metadata, queues, encryption decisions, retries, cancellation. DO NOT USE FOR: auth redirects, Aspire…
new-entity
Create a backend entity with EF Core configuration and migration.
add-entity
Scaffold a new domain entity or aggregate in this Vertical Slice Architecture template — the entity itself, its strongly typed ID, errors, specification, EF Core configuration, DbSet, the mandatory Vogen registration, and the migration. Use when the user says "add an entity", "add an aggregate", "create a domain…
npgsqlrest
Build and modify REST APIs with NpgsqlRest — exposing PostgreSQL as HTTP endpoints from two sources (database functions/procedures/tables/views, and plain .sql files), driven by SQL comment annotations (no C# needed). Use when working in an NpgsqlRest project: writing or changing endpoint SQL (functions or .sql…
sod
Use when needing a multi-paradigm .NET ORM with SQL-MAP (MyBatis-style XML mapping), OQL (Object Query Language), and traditional ORM. PDF.NET SOD: combines ORM + SQL-MAP + OQL for flexible .NET data access.
sqlsugar
Use when doing multi-database ORM operations in .NET — SQL Server, MySQL, PostgreSQL, SQLite, Oracle with fluent API, code-first, and LINQ. SqlSugar: high-performance .NET ORM supporting 10+ databases.