openevidence-ci-integration
Provides CI/CD configuration and testing utilities for clinical AI applications using OpenEvidence.
Install
mkdir -p .claude/skills/openevidence-ci-integration && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8918" && unzip -o skill.zip -d .claude/skills/openevidence-ci-integration && rm skill.zipInstalls to .claude/skills/openevidence-ci-integration
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Ci Integration for OpenEvidence.Key capabilities
- →Run unit tests with mocked evidence queries
- →Validate clinical citation extraction
- →Test live API connectivity
- →Verify query formatting in CI pipelines
How it works
The integration uses GitHub Actions to run unit tests with mocked client responses and integration tests that validate live API connectivity for clinical queries.
Inputs & outputs
When to use openevidence-ci-integration
- →Configure GitHub Actions for medical AI
- →Test clinical evidence retrieval logic
- →Validate API integration in CI
- →Mock evidence queries for unit tests
About this skill
OpenEvidence Rollout Acceptance Gate
Overview
Turn practice requirements into a manual, evidence-backed acceptance suite for supported OpenEvidence web or mobile workflows. Keep inputs minimal, separate observed facts from assumptions, and leave consequential decisions with the named accountable owner.
Prerequisites
- A clearly bounded workflow, accountable clinical owner, and organizational policy
- Current first-party OpenEvidence documentation and applicable institution agreements
- Synthetic or properly authorized minimum-necessary data
Tool Discipline
Use Read, Glob, and Grep to inspect supplied policies, plans, and evidence. Use WebFetch only for current first-party OpenEvidence documentation. Use Write or Edit only when the user requests a named deliverable with an approved destination. Never expose credentials, PHI, recordings, or unrestricted environment output.
Current Contract
- OpenEvidence publishes end-user web and mobile workflows, not a public CI or test API contract.
- Acceptance evidence must come from an authorized test account, synthetic scenarios, and current first-party instructions.
- A passing product check never validates the clinical correctness of a real patient decision.
Authentication
Use only the official OpenEvidence web/mobile sign-in or an institution-approved access path. Do not invent API keys, OAuth clients, SDK credentials, service accounts, or private endpoints. Never ask a user to reveal a password, session token, cookie, or recovery code.
Instructions
- Inventory the rollout requirements, supported devices, accountable clinical owner, and approved synthetic test scenarios.
- Read the current OpenEvidence guide for each feature in scope; mark undocumented behavior as unverified.
- Build a matrix covering sign-in, Ask response citations, export/copy behavior, and only the explicitly selected Visits features.
- Execute with synthetic or properly authorized data; capture timestamps and redacted evidence, never patient identifiers.
- Record pass, fail, blocked, and not-tested separately; route clinical-content review to a qualified professional.
- Publish the gate result with owners, exceptions, rollback criteria, and a re-test date.
Approval Boundaries
Do not create or share accounts; change access, roles, agreements, consent, retention, or security settings; enter PHI; record a conversation; copy content into another system; contact a patient; make a diagnosis or treatment decision; submit billing; transmit a support packet; run a production pilot; or represent vendor capabilities without explicit approval from the accountable owner. A qualified professional remains responsible for clinical decisions.
Output
Return scope, current first-party evidence and date, data classification, workflow or findings, citations reviewed, assumptions rejected, clinical and governance owners, approval state, unresolved risk, and the exact next action. Redact patient and credential data.
Error Handling
| Condition | Response |
|---|---|
| No automation interface | Keep the gate manual; do not reverse-engineer private endpoints. |
| Clinical answer varies | Evaluate evidence traceability and review process, not exact generated wording. |
| PHI required | Stop until the institution confirms agreement, authorization, consent, and test-data handling. |
Examples
This compact example shows the minimum reviewable handoff; adapt fields to the approved workflow without adding sensitive data.
Input:
pilot=cardiology; surfaces=Ask+Visits; data=synthetic; gate=pre-launch
Expected handoff:
coverage=12 checks; pass=10; blocked=2; clinical-review=pending; launch=no-go
Resources
When not to use it
- →Environments without Node.js 20
- →Workflows requiring non-clinical AI testing
Prerequisites
Limitations
- →Rate limit of 1 request per second for clinical queries
- →Requires specific clinical terms for evidence matching
How it compares
It provides specific clinical validation logic for evidence parsing and citation extraction rather than generic API testing.
Compared to similar skills
openevidence-ci-integration side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| openevidence-ci-integration (this skill) | 0 | 2mo | Review | Intermediate |
| twinmind-local-dev-loop | 1 | 2mo | Caution | Beginner |
| write-test | 1 | 7mo | Review | Advanced |
| deepgram-hello-world | 1 | 2mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
twinmind-local-dev-loop
jeremylongshore
Set up local development workflow with TwinMind API integration. Use when building applications that integrate TwinMind transcription, testing API calls locally, or developing meeting automation tools. Trigger with phrases like "twinmind dev setup", "twinmind local development", "twinmind API testing", "build with twinmind".
write-test
useautumn
Write integration tests for the Autumn billing system. Use when creating tests, writing test scenarios for billing/subscription features, track/check endpoints, or when the user asks about testing, test cases, or QA.
deepgram-hello-world
jeremylongshore
Create a minimal working Deepgram transcription example. Use when starting a new Deepgram integration, testing your setup, or learning basic Deepgram API patterns. Trigger with phrases like "deepgram hello world", "deepgram example", "deepgram quick start", "simple transcription", "transcribe audio".
groq-hello-world
jeremylongshore
Create a minimal working Groq example. Use when starting a new Groq integration, testing your setup, or learning basic Groq API patterns. Trigger with phrases like "groq hello world", "groq example", "groq quick start", "simple groq code".
speak-hello-world
jeremylongshore
Create a minimal working Speak language learning example. Use when starting a new Speak integration, testing your setup, or learning basic Speak API patterns for language tutoring. Trigger with phrases like "speak hello world", "speak example", "speak quick start", "simple speak lesson".
exa-local-dev-loop
jeremylongshore
Configure Exa local development with hot reload and testing. Use when setting up a development environment, configuring test workflows, or establishing a fast iteration cycle with Exa. Trigger with phrases like "exa dev setup", "exa local development", "exa dev environment", "develop with exa".