Menu
Add logs, metrics, traces, profiling, or operational notes for meaningful workflows without unsupported performance claims.
Create, update, or review Agent Skill directories and SKILL.md files for valid frontmatter, structure, portability, progressive disclosure, and validation readiness.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Discover and run the project's local formatting, linting, static analysis, test, and build checks before handoff.
Update project-facing documentation after a user-visible behavior, configuration, operation, or workflow change.
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Design stable APIs, module contracts, schemas, component boundaries, command interfaces, or other public integration surfaces that are predictable, documented, and hard to misuse.
| name | add-observability |
| description | Add logs, metrics, traces, profiling, or operational notes for meaningful workflows without unsupported performance claims. |
| metadata | {"version":"1.1.0"} |
Use this skill when a workflow needs better runtime visibility, measurable performance evidence, or operator-facing troubleshooting support.
Use this skill when you need to:
Do not use this skill to justify toy benchmarks, noisy logs, speculative performance claims, or instrumentation that exposes sensitive data.
Use performance-optimization when the goal is to diagnose and fix a known or
suspected bottleneck. Use this skill when the goal is to add or improve the
signals that make runtime behavior observable. Use
debugging-and-error-recovery when an active failure needs reproduction,
localization, and root-cause repair. Use shipping-and-launch when observability
is part of a release checklist, rollout, or rollback plan.
Identify the specific path, such as:
State what you want to observe, for example latency, throughput, failure rate, retry behavior, queue depth, memory growth, saturation, or error categories.
Before claiming an optimization or reliability improvement, capture a baseline using representative inputs and environment notes.
Record:
If the outcome is better visibility rather than better performance, say that plainly.
Prefer instrumentation at boundaries where an operator or maintainer can act on the signal, such as:
Avoid scattering instrumentation across low-value internal helpers.
Inspect existing observability conventions before adding new instrumentation. Prefer established loggers, metric clients, tracing APIs, naming patterns, and documentation locations. Do not introduce a new observability dependency or vendor-specific tool unless the project already uses it or the user explicitly asks for it.
Choose signals that fit the project conventions.
Do not log or emit secrets, credentials, personal data, or highly variable labels that would create high cardinality.
Use stable names and fields. Document what a signal means, when it increments or records, and what action a maintainer should take when it changes.
When alerting or dashboards are affected, document thresholds, ownership, and known limitations if those details are available.
When the change matters operationally, update project-facing docs with:
Use update-project-docs for durable documentation updates.
