بنقرة واحدة
write-structured-tracing
Standard for writing structured tracing logs behind debug flags.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Standard for writing structured tracing logs behind debug flags.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run comprehensive Rust code quality checks including compilation, linting, documentation, and tests. Use after completing code changes and before creating commits.
Enforce the "Clean Imports over Inline Absolute Paths" rule by removing inline crate:: prefixes and adding proper use statements.
Rules and guidelines for creating well-formatted commit messages, including 72-char limits, scope prefixes, and trailer blocks for tasks, PR closing, and attribution.
Zero-allocation string building strategies. Use when formatting strings, generating ANSI codes, or writing hot loops to avoid heap allocations and Formatter state machine overhead.
Run clippy linting, enforce comment punctuation rules, format code with cargo fmt, and verify module organization patterns. Use after code changes and before creating commits.
Create a structured integration and review plan for a Pull Request
| name | write-structured-tracing |
| description | Standard for writing structured tracing logs behind debug flags. |
This skill documents the project's standard for writing tracing logs (tracing::info!, tracing::debug!, etc.). It ensures logs are easily filterable, consistently formatted, and don't affect performance when disabled.
All tracing::*! calls must be gated behind a specific debug flag from tui/src/tui/mod.rs (or similar location) using the .then(|| { ... }) pattern. This ensures the tracing macro and any string allocations are completely bypassed when the flag is disabled.
Choosing the right flag (Scope Specificity): Make sure the flag you use is specifically scoped to the module or subsystem you are debugging. This scope can be narrow or broad depending on the requirements.
DEBUG_TUI_PTY_MUX) for a microscopic, high-volume subsystem (like a byte-stream parser). Doing so would spam the orchestrator logs.DEBUG_TUI_VT100_PARSER) to ensure developers can isolate and filter logs effectively without overwhelming the IO overhead.crate::DEBUG_TUI_MOD.then(|| {
// ... tracing call ...
});
// % is Display, ? is Debug. CommentYou MUST add the exact line comment // % is Display, ? is Debug. directly above every tracing::*! invocation. This serves as a quick syntax reminder.
messageDo not use unstructured string formatting (e.g., tracing::info!("Hello {}", name)). Instead, use structured fields with an explicit message key that identifies the context (e.g., the struct and method name).
crate::DEBUG_TUI_MOD.then(|| {
// % is Display, ? is Debug.
tracing::info! {
message = "ComponentName::method_name",
status = "Something happened",
};
});
inline_string! vs format! for Complex FormattingWhen you need to format complex strings within a tracing field, bind it to a field using the % (Display) modifier and follow this rule:
inline_string! macro to stack-allocate it.format! macro (since inline_string! would spill to the heap and allocate anyway).crate::DEBUG_TUI_MOD.then(|| {
// % is Display, ? is Debug.
tracing::info! {
message = "AppNoLayout::handle_event",
input_event = %inline_string!(
"{a} {b:?}",
a = glyphs::USER_INPUT_GLYPH,
b = input_event
)
};
});
Bad (Unstructured and Un-gated):
tracing::debug!("Received input event: {:?}", input_event);
Good (Structured and Gated):
crate::DEBUG_TUI_PTY_MUX.then(|| {
// % is Display, ? is Debug.
tracing::debug! {
message = "PTYMux::run_event_loop",
input_event = %format!("{:?}", input_event)
};
});