Thank you for helping make AI-assisted software easier to understand and maintain.
VCRS welcomes contributions from experienced engineers, new vibe coders, technical writers, security reviewers, researchers, and coding-agent tool builders.
- clarify a confusing paragraph;
- report a broken link or inaccurate command;
- improve an example for a beginner;
- add a test for the validator;
- share a sanitized adoption case and what did or did not work;
- propose a repository profile backed by real projects;
- test one VCRS workflow with a non-Codex coding agent;
- improve accessibility, diagrams, or navigation.
Open an issue or Discussion before making a substantial normative change, new adapter, new profile, or broad restructuring. Explain:
- the user problem;
- current evidence;
- the proposed outcome;
- compatibility and migration impact;
- alternatives considered;
- how the result can be tested.
This prevents contributors from investing in a direction that does not fit the standard.
VCRS has no runtime dependency for its validators. Python 3.11 or newer is recommended.
Run the public repository checks:
python -m unittest discover -s tests/quality -p 'test_*.py' -v
python scripts/quality/validate_public_repository.py --root . --strict
python scripts/quality/audit_publication.py --root . --strictRun the starter-template checks:
python standard/template/scripts/maintenance/validate_repository_standard.py \
--root standard/template
python -m unittest discover \
-s standard/template/tests/standards \
-p 'test_*.py' \
-v- Trace the current behavior before changing it.
- Keep one pull request focused on one coherent outcome.
- Separate structural changes from normative behavior changes where practical.
- Prefer plain language over unexplained jargon.
- Do not create abstractions or files “for future use” without a present requirement.
- Preserve useful safety controls, tests, migration evidence, and attribution.
- Do not introduce a new dependency when the standard library is sufficient.
- Do not claim compatibility with an agent or platform without testing it.
- Never include private repository content, client data, credentials, or identifying logs in an issue or pull request.
Use the pull-request template. For material behavior, validator, prompt, or workflow changes, include test scenarios in this form:
| Scenario | Setup or input | Expected result | Actual result | Evidence |
|---|---|---|---|---|
| Example | Example | Example | Example | Command, test, screenshot, or report |
List any tests not run and why. A green CI result does not replace explaining what the tests prove.
The detailed standard uses:
- MUST / MUST NOT for mandatory compatibility or safety requirements;
- SHOULD / SHOULD NOT for strong recommendations with valid exceptions;
- MAY for optional behavior.
A proposal that changes normative language should explain adoption and migration impact.
A non-trivial change should receive independent review. Reviewers prioritize:
- correctness and misleading claims;
- security, privacy, and sensitive-data exposure;
- compatibility and migration impact;
- regressions in validators, prompts, links, or templates;
- evidence quality;
- clarity for the intended audience;
- maintainability and unnecessary complexity.
Preference-only comments are non-blocking unless they reflect an accepted project convention.
By submitting a contribution, you agree that it may be distributed under the project's Apache-2.0 license. Keep commits understandable and do not rewrite shared history without maintainer agreement.
Read and follow CODE_OF_CONDUCT.md. Use SECURITY.md for vulnerabilities and SUPPORT.md for help requests.