Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →fedoroff-vlad/add-observability
Use when adding logging/observability to a new or existing service, module, or pipeline — or when a long-running job turned out to be unexplainable after the fact. Fires on: "add logging", "нужно логирование", "what do we log here", "structured logs", "ship logs to Kibana/Elasticsearch/Loki", "why did this run fail and we can't tell", "add metrics/tracing to this pass". Produces a logging design (event vocabulary, sink, levels, payload rule) written into the architecture doc first, then the wiri
Passed 16 of 21 test cases with the skill, and 11 of 21 without it.
and 6 more in the full report
6 fixed11 passed either way5 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Нам нужно добавить системное логирование в новый микросервис обработки документов, чтобы потом анализировать его в Kibana. Напиши раздел про observability в арх-документ с детальной таблицей событий и внедри логирование на границах сервисов и ключевых этапах обработки.
| Checked | Without skill | With skill |
|---|---|---|
| The log configuration defaults output to stderr rather than stdout. | Missed | Passed |
| The log format uses single-line JSON Lines for indexed log streams. | Passed | Passed |
| Event field naming follows standard ECS conventions such as event.action and log.level. | Passed | Passed |
| Errors format stack traces onto a single line containing error.type and error.message. | Missed | Passed |
The instructions your model reads when the skill loads.
Logging is a contract, not a scattering of log.info calls. Ad-hoc logging
produces a stream nobody can query and everybody is afraid to delete. Decide the
shape first, write it into the project's architecture doc, then implement
against it.
Content does not go into logs. At any level. By design. Prompts, request and response bodies, document text, source code, personal data — none of it. Log names and metrics: the input's identifier, the output's identifier, sizes, counts, durations, outcome.
Why this is a rule and not a level:
If you cannot debug from names + sizes + durations, add a field, not the
payload — e.g. prompt_chars instead of the prompt, result_count instead of
the results.
Read the project's architecture doc and find where a cross-cutting
concern is documented (a ## Storage-style section). You are adding a
sibling ## Observability section.
Choose the sink, and justify it. Default: stderr. Check whether stdout is already spoken for — an MCP server, a CLI that pipes structured output, anything whose stdout is a protocol. If so, stderr is a correctness constraint, not a preference: one stray line corrupts the channel. Say that in the doc so nobody "tidies" it later.
Choose the format from the destination, not from taste. If the logs will
test cases passed, vs 11 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.