DevScope Air is still evolving quickly. Contributions are welcome, but the changes most likely to land are the ones that are small, focused, and easy to verify.
Before opening a PR, read:
AGENTS.mddocs/current/README.md
- small bug fixes
- reliability improvements
- performance improvements
- maintainability refactors that reduce duplication without changing product direction
- tightly scoped UI polish that preserves the existing visual language
- large mixed-scope PRs
- unrelated fixes bundled together
- speculative feature expansion without prior discussion
- rewrites that do not clearly improve correctness, reliability, or maintainability
- Keep the change focused.
- Explain exactly what changed.
- Explain why the change should exist.
- Call out anything you did not verify.
- Update relevant docs when behavior or workflow changes.
If the PR changes visible UI behavior, include:
- before/after screenshots for layout or styling changes
- short video or GIF if motion, transitions, or interaction timing matters
Run the lightest useful validation for the change and say what you ran.
For this repo, useful validation usually starts with:
npm run typecheck- targeted checks for the specific area you changed
Do not treat a change as verified if you did not actually run the checks.
If you touch release, packaging, or update flow:
- read
docs/current/RELEASE_VERSIONING.md - read
docs/current/RELEASE_OPERATIONS_PLAYBOOK.md - verify that release assets and local
distoutput still follow the documented layout
For larger changes, open an issue or start a discussion first. That is especially important for:
- architecture changes
- release workflow changes
- settings/data model changes
- broad UI direction changes