rustfs-logging-governance
Add or review RustFS `tracing` events with the repository field shape, level policy, privacy boundaries, and guardrails. Use when a change adds or edits a tracing macro/instrumentation site or the logging guardrail script.
Install
npx skills add https://github.com/modem-dev/ossrules/tree/main/public/files/rustfs/.agents/skills/rustfs-logging-governance
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install modem-dev-ossrules@llmmart
git clone https://github.com/modem-dev/ossrules.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole modem-dev/ossrules collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
RustFS Logging Governance
Apply this skill only to changed logging sites; do not turn a local log edit into a broad logging cleanup.
Workflow
- Read the changed function/module context and classify the site as lifecycle, request/hot path, fallback, external fetch, or summary.
- Match neighboring structured events and reuse existing
EVENT_*,LOG_COMPONENT_*, andLOG_SUBSYSTEM_*constants. - Put stable fields first (
event,component,subsystem,state/result, then context) and a short label last. - Select the level by operational meaning:
error: behavior/security-affecting failure;warn: degraded/fallback/operator-actionable state;info: low-frequency lifecycle/mode change;debug: targeted diagnostics;trace: repetitive request/object/shard success paths.
- Never log secrets, tokens, auth headers, credential payloads, raw
attacker-controlled bodies, or merged config dumps. Error strings and
Debugoutput are log surfaces too. - Prefer one aggregate summary over inventories or startup banners.
- Run
./scripts/check_logging_guardrails.shand the checks selected by rootAGENTS.md.
Read logging-governance.md only for a broad logging audit, event-model migration, or guardrail expansion. Ordinary single- site edits do not require the full workspace scope map.
Files (ossrules)
-
SKILL.md 1.6 KB
--- name: rustfs-logging-governance description: Add or review RustFS `tracing` events with the repository field shape, level policy, privacy boundaries, and guardrails. Use when a change adds or edits a tracing macro/instrumentation site or the logging guardrail script. --- # RustFS Logging Governance Apply this skill only to changed logging sites; do not turn a local log edit into a broad logging cleanup. ## Workflow 1. Read the changed function/module context and classify the site as lifecycle, request/hot path, fallback, external fetch, or summary. 2. Match neighboring structured events and reuse existing `EVENT_*`, `LOG_COMPONENT_*`, and `LOG_SUBSYSTEM_*` constants. 3. Put stable fields first (`event`, `component`, `subsystem`, `state`/`result`, then context) and a short label last. 4. Select the level by operational meaning: - `error`: behavior/security-affecting failure; - `warn`: degraded/fallback/operator-actionable state; - `info`: low-frequency lifecycle/mode change; - `debug`: targeted diagnostics; - `trace`: repetitive request/object/shard success paths. 5. Never log secrets, tokens, auth headers, credential payloads, raw attacker-controlled bodies, or merged config dumps. Error strings and `Debug` output are log surfaces too. 6. Prefer one aggregate summary over inventories or startup banners. 7. Run `./scripts/check_logging_guardrails.sh` and the checks selected by root `AGENTS.md`. Read [logging-governance.md](references/logging-governance.md) only for a broad logging audit, event-model migration, or guardrail expansion. Ordinary single- site edits do not require the full workspace scope map.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.