openevidence-local-dev-loop
Provides a local development workflow using mock servers to iterate on OpenEvidence integrations without API quotas.
Install
mkdir -p .claude/skills/openevidence-local-dev-loop && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6320" && unzip -o skill.zip -d .claude/skills/openevidence-local-dev-loop && rm skill.zipInstalls to .claude/skills/openevidence-local-dev-loop
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.
Local Dev Loop for OpenEvidence.Key capabilities
- →Simulate clinical evidence queries with mock data
- →Toggle between mock and live API modes
- →Validate query categorization using topics endpoint
- →Run integration tests against real API endpoints
How it works
The development server uses a proxy middleware to route requests to the live API or a mock handler based on the MOCK_MODE environment variable.
Inputs & outputs
When to use openevidence-local-dev-loop
- →Configuring development workflows
- →Setting up testing environments
- →Creating rapid iteration loops
- →Simulating API responses
About this skill
OpenEvidence Synthetic Workflow Evaluation Loop
Overview
Replace the nonexistent local developer loop with a repeatable browser/app evaluation process. 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 does not publish a local runtime, sandbox SDK, or public test API in the audited documentation.
- Synthetic scenarios are the default evaluation input; real PHI requires the full approved data boundary.
- Evaluation tests workflow fitness and evidence review, not medical-device validation.
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
- Define feature, user role, expected workflow outcome, unacceptable failure, and clinical reviewer.
- Create synthetic scenarios spanning routine, ambiguous, conflicting-evidence, and failure-path cases.
- Read the current guide and record the model, feature, and surface used for each run.
- Execute manually through the supported product, preserving only de-identified prompts, citations, and observations.
- Have a qualified reviewer score traceability, applicability, uncertainty, and workflow burden.
- Iterate one variable at a time and publish a go, revise, or stop recommendation.
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 sandbox | Use synthetic inputs in an authorized account; do not probe private infrastructure. |
| Output non-deterministic | Score invariant qualities rather than exact wording. |
| Reviewer disagreement | Preserve both rationales and escalate to the clinical owner. |
Examples
This compact example shows the minimum reviewable handoff; adapt fields to the approved workflow without adding sensitive data.
Input:
feature=Ask; cases=12 synthetic; reviewer=clinical lead; surface=web
Expected handoff:
runs=12; acceptable=9; revise=2; stop=1; next-change=prompt
Resources
When not to use it
- →Using real patient data in development environments
- →Relying on mock data for production validation
Prerequisites
Limitations
- →Mock data must be de-identified
- →Live API queries may have 2-5s latency
How it compares
This approach allows for rapid iteration without consuming live API quotas by providing realistic, de-identified clinical responses.
Compared to similar skills
openevidence-local-dev-loop side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| openevidence-local-dev-loop (this skill) | 1 | 2mo | Caution | Beginner |
| nestjs-expert | 37 | 8mo | Review | Advanced |
| test-nodebridge-handler | 1 | 8mo | Review | Intermediate |
| ideogram-local-dev-loop | 0 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
nestjs-expert
davila7
Nest.js framework expert specializing in module architecture, dependency injection, middleware, guards, interceptors, testing with Jest/Supertest, TypeORM/Mongoose integration, and Passport.js authentication. Use PROACTIVELY for any Nest.js application issues including architecture decisions, testing strategies, performance optimization, or debugging complex dependency injection problems. If a specialized expert is a better fit, I will recommend switching and stop.
test-nodebridge-handler
neovateai
Use this skill when testing NodeBridge handlers using `bun scripts/test-nodebridge.ts`, including listing available handlers and passing parameters
ideogram-local-dev-loop
jeremylongshore
Configure Ideogram local development with hot reload and testing. Use when setting up a development environment, configuring test workflows, or establishing a fast iteration cycle with Ideogram. Trigger with phrases like "ideogram dev setup", "ideogram local development", "ideogram dev environment", "develop with ideogram".
node
dannybrown37
Invoke when the user is writing or debugging TypeScript or JavaScript code, working with Node.js tooling, or asking about ESLint/Prettier configuration.
supabase-developer
daffy0208
Build full-stack applications with Supabase (PostgreSQL, Auth, Storage, Real-time, Edge Functions). Use when implementing authentication, database design with RLS, file storage, real-time features, or serverless functions.
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.