Thanks for your interest in BioVoice. This project is public as a scientist-first research prototype, so good contributions are the ones that make the local experience clearer, safer, and easier to verify.
- Read the main README for the public product story
- Use docs/getting-started.md if you need the newcomer setup path
- Treat real credentials and local machine state as private
- Prefer structured tool improvements and verified workflows over raw-command shortcuts
npm install
npm run prepare:data
npm run generate:examples
cp .env.example .envSet OPENAI_API_KEY in local .env only if you need live voice. For most development, you can still make progress with offline rehearsal and the verification scripts.
- Read the README and one tutorial page so you understand the public user story.
- Run
npm run checkto establish a clean local baseline. - If your change touches workflows, run
npm run verify:examples. - If your change affects live demos or scientific walkthroughs, run
npm run verify:showcases. - Update docs when public behavior, commands, screenshots, or support expectations change.
npm run typecheck
npm test
npm run release:check
npm run buildnpm run checknpm run verify:examples
npm run verify:showcasesnpm run smoke:pymol
npm run smoke:chimeraxParts of the public reference library are generated. Do not hand-edit them and assume the changes will stick.
Generated outputs include:
examples/README.mdexamples/start-here/README.mdexamples/scientific-workflows/README.mdexamples/prompt-library/README.mdexamples/tool-playbooks/README.mdexamples/troubleshooting/README.mdexamples/gallery/README.mdexamples/workflow-recipes/**
Source of truth:
scripts/generate-example-files.ts- recipe and workflow definitions under
packages/runtime-and-adapters/src/examples/
After changing generator logic or recipe content, run:
npm run generate:examplesUpdate hand-authored docs under docs/ and the main README when you change:
- supported platforms
- live voice provider support
- setup steps
- workflow commands or recommended tutorials
- privacy or local-storage behavior
- contributor expectations
Update generated examples when you change:
- recipe steps
- scientific workflow mappings
- prompt packs
- sample data references
- verification checklists
- New validated workflows for PyMOL or ChimeraX
- Better AlphaFold, Rosetta, or cryo-EM tutorial coverage
- Linux / Windows startup improvements
- UI clarity and accessibility improvements
- Verification hardening for demos and guided workflows
- Better privacy-safe issue reproduction and reporting flows
- Keep the scope focused
- Explain the user-facing change, not just the internal edit
- Include the commands you used to verify the change
- Update docs if the public-facing behavior changed
- Avoid committing local secrets,
.runtime/state,output/, or machine-specific files
Use the PR template and make sure you can honestly check the relevant boxes.
- TypeScript strict mode stays on
- Avoid
anyin production code - Prefer structured actions over raw commands
- Use repo-relative path helpers instead of hardcoded personal paths
- Keep
.envlocal and keep.env.exampleas the tracked safe template - Keep
local/,private/,.runtime/,tmp/, andoutput/out of commits
- For usage questions and reporting guidance, see SUPPORT.md
- For vulnerabilities or privacy-sensitive issues, see SECURITY.md
- For community expectations, see CODE_OF_CONDUCT.md
By contributing, you agree that your contributions will be licensed under the MIT License.