CtrlK
BlogDocsLog inGet started
Tessl Logo

detecting-pv-signals

Computes disproportionality signals — PRR, ROR, EBGM, and IC (BCPNN) — over FAERS / OpenFDA drug-event data to flag potential safety signals. Use when the user wants to mine spontaneous-report data for drug-reaction associations, build a 2x2 contingency table, compute a Proportional Reporting Ratio or Reporting Odds Ratio, run Empirical Bayes (EBGM/EB05) or Information Component shrinkage, or screen a drug for over-reported reactions. Trigger keywords: disproportionality, signal detection, PRR, ROR, EBGM, EB05, IC, BCPNN, MGPS, 2x2 table, signal of disproportionate reporting, SDR, OpenFDA, FAERS. Pairs adjacent to OpenMed: aggregate de-identified, coded cases (from reporting-adverse-events) then query the public OpenFDA /drug/event count API to build the contingency table. Reaction terms are MedDRA PTs (licensed, user-supplied).

74

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

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

A strong, dense body: executable code, real API gotchas, and honest statistical caveats (disproportionality ≠ causality, small-count instability, OpenFDA non-deduplication). The main deductions are the duplicated metric formulas between prose and code, a duplicated step number in the workflow, and no error-recovery guidance for the cell-sum validation.

Suggestions

State the PRR/ROR/IC formulas once — either keep the formulas in 'The 2x2 table' as math and let the Python block implement them, or drop the prose restatement — to trim the duplicated explanation.

Fix the workflow numbering: 'Resolve the drug field' and 'Use .exact' are both numbered '2', so the six steps mis-number as 1, 2, 2, 3, 4, 5, 6.

Add one line of recovery guidance after 'Verify a + b + c + d == N' (e.g. what a mismatch implies about the background population choice) to turn the checkpoint into a feedback loop.

DimensionReasoningScore

Conciseness

Largely efficient — the OpenFDA gotchas (404-as-empty, .exact, rate limits, MedDRA licensing) are exactly what Claude does not already know. But the PRR/ROR/IC formulas appear twice (prose in 'The 2x2 table' plus the Python implementations), and the opening paragraph re-explains what an SDR is; both could be trimmed. Efficient with minor over-explanation, which is the level-4 anchor, not level 5 where every token earns its place.

4 / 5

Actionability

Copy-paste-ready executable code covering the common case end-to-end: OpenFDA count queries with 404 handling, 2x2 construction for a concrete example (warfarin x gastrointestinal haemorrhage), and PRR/ROR/CI/IC implementations. The one hand-off (EBGM to the openEBGM/PhViD packages) is explicitly justified — 'the shrinkage prior is the whole point and easy to get wrong' — which the rubric's justification carve-out covers.

5 / 5

Workflow Clarity

The six-step Workflow is clearly sequenced with an explicit validation checkpoint ('Verify a + b + c + d == N') and a triage-not-verdict framing. It falls short of 5 because there is no error-recovery loop around the validation (what to do when the cells don't sum to N), and the step list has a numbering glitch — two consecutive steps are both numbered '2' ('Resolve the drug field' and 'Use .exact'), which disrupts the sequence.

4 / 5

Progressive Disclosure

Well-organized with clear headers (When to use, Quick start, Workflow, Hand-off, Edge cases, Standards) and one-level-deep navigation — no buried or nested references. No bundle files exist, and at ~190 lines the body is self-contained but borderline: the quick-start code block and the standards list could live in reference files to keep the overview lighter, which keeps it at 'good structure, minor organization gaps' rather than a model split.

4 / 5

Total

17

/

20

Passed

Description

100%Weight 40%Scale 1-5

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

An exemplary description: third-person voice, explicit 'Use when…' triggers, a comprehensive natural-keyword list, and a well-delineated niche with adjacent-skill boundaries stated. It is longer than the archetype examples, but every clause carries information — no filler or over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'Computes disproportionality signals — PRR, ROR, EBGM, and IC (BCPNN)', 'build a 2x2 contingency table', 'screen a drug for over-reported reactions' — covering the metric family, the data source, and the screening workflow comprehensively. It is not a level-4 case because no meaningful capability is missing: computation, table construction, shrinkage methods, and screening are all named explicitly.

5 / 5

Completeness

It explicitly answers both questions: 'Computes disproportionality signals … over FAERS / OpenFDA drug-event data' (what) and 'Use when the user wants to mine spontaneous-report data … or screen a drug for over-reported reactions' (when), followed by concrete trigger phrases. It cannot be a 4 because neither half is vague or merely implied.

5 / 5

Trigger Term Quality

The keyword list 'disproportionality, signal detection, PRR, ROR, EBGM, EB05, IC, BCPNN, MGPS, 2x2 table, signal of disproportionate reporting, SDR, OpenFDA, FAERS' covers the natural synonyms, acronyms, and source-database names a user would actually say. Full method names ('Proportional Reporting Ratio', 'Reporting Odds Ratio', 'Empirical Bayes') are also present, so nothing common is missing.

5 / 5

Distinctiveness Conflict Risk

A clear pharmacovigilance niche with distinct triggers (PRR/EBGM/BCPNN/FAERS/SDR) that no adjacent data-analysis skill would claim; the OpenMed pairing sentence ('Pairs adjacent to OpenMed') further delineates its boundary against sibling skills. Minimal overlap risk with anything else.

5 / 5

Total

20

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
maziyarpanahi/openmed
Reviewed

Table of Contents

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.