Thank you for improving the Base Foundry ecosystem. Start with the target
repository's README.md, CONTRIBUTING.md, and issue acceptance notes. Those
documents are the effective contract when they are more specific than this
organization default.
- Search existing issues and pull requests before proposing duplicate work.
- Use the repository's issue-backed workflow when one is documented.
- Keep a change focused on one problem and explain the observable outcome.
- Do not include credentials, personal data, or security-sensitive details in public issues, logs, or pull requests.
Describe the problem, the change, and the validation you ran. Link the issue that motivates the change. Documentation-only changes should still explain the reader or maintainer outcome. Follow the repository's language-specific test, formatting, packaging, and release instructions; this default does not impose one build command on every project.
The default pull-request template records summary, issue linkage, validation, documentation, demo impact, and security considerations. Repository-local templates may add required checks.
Be precise, patient, and constructive. Review the behavior and evidence, not the contributor. See CODE_OF_CONDUCT.md for the shared community expectations.
Never disclose a vulnerability in a public issue or discussion. Use the private reporting path in SECURITY.md.