agentleFS
dprakash2101dprakash2101/dotnet-production-agent-skills/skills/production-logging/SKILL.md

production-logging

Skill4 starsChanged 53 days agoMITView on GitHub

Use when adding, reviewing, or reducing .NET structured logs, exception telemetry, correlation IDs, sensitive-data exposure, or high-traffic API logging costs.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow the repository's logging, telemetry, redaction, sampling, and correlation conventions.

    line 8
  2. Distinctive:

    Do not use interpolation/concatenation that defeats structured fields.

    line 14
  3. Distinctive:

    Avoid per-item success noise in high-volume paths, local-variable narration, whole request/response or message bodies, large collections, …

    line 18
  4. Distinctive:

    Never log credentials, tokens, API keys, connection strings, authentication headers, secrets, or unredacted sensitive payloads.

    line 20
  5. Distinctive:

    Test/red-team log output when a change touches sensitive input or centralized failure handling.

    line 24
  6. Distinctive:

    Check trace propagation across HTTP and message boundaries, and assert sensitive values are absent from logs and telemetry in tests …

    line 26

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Production logging for .NET

Follow the repository's logging, telemetry, redaction, sampling, and correlation conventions. Emit structured templates with stable property names and values as arguments:

logger.LogInformation("Order {OrderNumber} processed for {CustomerNumber}", orderNumber, customerNumber);

Do not use interpolation/concatenation that defeats structured fields. Prefer source-generated logging for proven hot paths when the repository uses it; do not add ceremony to cold code without value.

Log events that support operations: unexpected failures, dependency failures, important business failures, operationally useful retries and final exhaustion, significant state transitions, security-relevant events, safe correlation identifiers, and meaningful latency anomalies. Choose Trace, Debug, Information, Warning, Error, or Critical from operational severity—not habit.

Avoid per-item success noise in high-volume paths, local-variable narration, whole request/response or message bodies, large collections, duplicate exception logs at multiple layers, and values with no diagnostic action. Consider ingestion, indexing, retention, and alert cost before adding high-cardinality fields or frequent logs.

Never log credentials, tokens, API keys, connection strings, authentication headers, secrets, or unredacted sensitive payloads. Minimize PII and customer identifiers; hash/redact only through approved repository mechanisms and remember that hashes may remain identifying.

Define one layer to own the exception event. Lower layers may add context by wrapping or enriching traces, but should not repeatedly log and rethrow the same failure. Include exceptions as exception arguments so stacks remain available internally. Preserve trace/correlation IDs across boundaries and prefer OpenTelemetry spans/metrics for high-volume timing or cardinality that does not belong in logs.

Test/red-team log output when a change touches sensitive input or centralized failure handling. Verify useful fields exist and prohibited data does not.

Check trace propagation across HTTP and message boundaries, and assert sensitive values are absent from logs and telemetry in tests touching those paths.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.