coding-standards

Enforce Edgion observability and safety rules for Rust code changes.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Pandaala/Edgion --skill coding-standards-pandaala
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: coding-standards
Source: https://github.com/Pandaala/Edgion/tree/main/skills/03-coding
Command: npx skills add https://github.com/Pandaala/Edgion --skill coding-standards-pandaala

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It standardizes how Edgion writes tracing logs, access logs, metrics, and resource sync identifiers so engineers avoid secret/config leakage and keep control-plane and data-plane observability properly separated.

Core Features & Use Cases

  • Log ID propagation guidance (rv/sv/key_name): Ensures control-plane and data-plane records can be correlated when requests fail.
  • Log safety and boundaries: Enforces “no sensitive data”, “no config leakage”, and no tracing on the data-plane hot path.
  • Rust coding rules for reliability: Covers import style, unwrap/expect discipline, clone usage, actionable error messages, and graceful-degrade patterns for long-running paths.
  • Plugin and access log conventions: Defines how PluginLog should record decisions and error classification (including push_err) without leaking dynamic secrets.
  • Metrics restraint: Guides when to add counters/gauges vs avoiding histogram/label explosions, with unified metrics management.

Quick Start

Use the coding-standards skill during code review or implementation work that touches logging, tracing IDs, access logs, metrics, or shared observability rules in Edgion.

Frequently Asked Questions about coding-standards

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is the best way to prevent sensitive data leakage in Rust tracing logs?

Prevent sensitive data leakage in Rust tracing logs by enforcing strict log safety boundaries that prohibit config and dynamic secret exposure across all HTTP, gRPC, and TLS execution paths. This standardizes PluginLog error classification and access-log field semantics to ensure secrets remain isolated.

How do I separate control-plane and data-plane observability in Rust?

Separate control-plane and data-plane observability by prohibiting tracing macros on the data-plane hot path and enforcing disciplined Rust coding patterns for long-running paths. This ensures tracing and logging remain strictly isolated to control-plane operations.

How do I correlate control-plane and data-plane logs when requests fail?

Correlate control-plane and data-plane logs when requests fail by propagating standardized rv, sv, and key_name identifiers across all tracing and access log records. This ensures synchronized correlation IDs across HTTP, gRPC, and stream paths for accurate failure tracking.

When should I add metrics counters versus histograms in Rust observability?

Add metrics counters and gauges selectively in Rust observability by practicing metrics restraint to avoid histogram and label explosions. Unified metrics management guides when to introduce new counters versus avoiding high-cardinality labels that degrade system performance.

What Rust coding rules apply to graceful degradation in long-running paths?

Rust coding rules for graceful degradation in long-running paths require disciplined unwrap and expect avoidance, strict clone usage limitations, and actionable error messages. These patterns ensure long-running execution paths degrade safely without panicking or leaking sensitive configuration data.

Why does PluginLog error classification prohibit dynamic secret exposure?

PluginLog error classification prohibits dynamic secret exposure to maintain strict log safety boundaries during plugin execution summaries. By enforcing push_err rules without leaking secrets, it standardizes how plugin decisions are recorded across all observability paths.