monitoring-database-transactions

Monitor use when you need to work with monitoring and observability. This skill provides health monitoring and alerting with comprehensive guidance and automation. Trigger with phrases like "monitor system health", "set up alerts", or "track metrics".

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Advisory

Suggest reviewing before use

Quality

Content

65%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is highly actionable with executable, engine-specific SQL and concrete alerting thresholds, but it keeps everything in one monolithic inline wall and skips the validate/retry feedback loop around its destructive termination step. The existing bundle scripts are not wired into the body, leaving progressive disclosure underused.

Suggestions

Add a validation/feedback loop to step 9: confirm the target session is truly idle-in-transaction and older than the threshold before terminating, log the result, and verify the lock queue clears afterward.

Move the per-engine query catalog into reference files (e.g. references/postgres_queries.md, mysql_queries.md) and link them from the Instructions section so the body stays a lean overview.

Reference the bundled scripts/rollback_analyzer.py (and the lock_detector/transaction_monitor scripts listed in scripts/README.md) from the body where step 5 and 10 discuss rollback and reporting, so the bundle is discoverable.

Dimension	Reasoning	Score
Conciseness	The body is dense and mostly free of filler, but it front-loads ten fully-expanded SQL queries inline, much of which could live in reference files, so while efficient per-line it could be tightened by offloading query catalogs.	2 / 3
Actionability	Every step ships concrete, executable SQL or CLI commands with specific thresholds (30s OLTP vs 5min batch, 60s alert, 5-min idle, 10-lock-waiter, 5% rollback), engine-specific variants, and named remediation commands — copy-paste ready.	3 / 3
Workflow Clarity	Steps 1-10 are clearly sequenced, but step 9 is a destructive operation (pg_terminate_backend / KILL) with no validate-before-act checkpoint or feedback loop, which per the rubric caps workflow clarity at 2 for destructive database operations.	2 / 3
Progressive Disclosure	The body has clear sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources), but the bundled scripts/rollback_analyzer.py and references are never linked from the body, so the inline SQL wall is content that should be split out into well-signaled one-level references.	2 / 3
	Total	9 / 12 Passed

Description

60%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is grammatically complete with an explicit trigger clause, but it is generic and omits the skill's actual domain (database transaction monitoring), creating high conflict risk with other monitoring skills. It satisfies completeness structurally while failing to convey the skill's distinct purpose.

Suggestions

Rewrite the description to name the actual capability, e.g. 'Monitor active database transactions across PostgreSQL, MySQL, and MongoDB to detect long-running queries, idle-in-transaction sessions, lock contention, and rollback anomalies.'

Replace the generic trigger phrases with domain-specific ones a user would naturally say, such as 'find long-running transactions', 'check for idle-in-transaction sessions', or 'diagnose lock contention'.

Drop the filler phrase 'with comprehensive guidance and automation', which adds no signal and reads as marketing fluff.

Dimension	Reasoning	Score
Specificity	It names a domain ('monitoring and observability') and broad actions ('health monitoring and alerting') but these are generic, and it never mentions the actual topic — database transactions — so it stops short of listing concrete, skill-specific actions.	2 / 3
Completeness	It answers both 'what' ('health monitoring and alerting with comprehensive guidance and automation') and 'when' via an explicit 'Trigger with phrases like' clause, satisfying the what-and-when requirement even though the substance is vague.	3 / 3
Trigger Term Quality	It offers explicit trigger phrases ('monitor system health', 'set up alerts', 'track metrics'), but these are generic monitoring keywords that any observability skill could claim, missing the natural terms a user would say for transaction monitoring like 'long-running queries' or 'lock contention'.	2 / 3
Distinctiveness Conflict Risk	The description describes generic 'health monitoring and alerting' with no mention of database transactions, so it would conflict with numerous other monitoring/observability skills and trigger for the wrong one.	1 / 3
	Total	8 / 12 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
allowed_tools_field	'allowed-tools' contains unusual tool name(s)	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: jeremylongshore/claude-code-plugins-plus-skills
Commit: 2cafb23

Reviewed: 2 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.