Add contributing guidelines and security policy documentation.

CONTRIBUTING.md

@@ -0,0 +1,54 @@
+# Contributing to PHP Forge
+
+Thank you for your interest in contributing. Please read this guide before submitting issues or pull requests.
+
+By participating in this project, you agree to abide by the [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Development Environment
+
+**Requirements:**
+
+- PHP 8.3 or higher.
+- [Composer](https://getcomposer.org/) 2.x.
+
+**Setup:**
+
+```bash
+git clone https://github.com/ui-awesome/<package>.git
+cd <package>
+composer install
+composer test
+```
+
+## Coding Standards
+
+All PHP code must follow these standards:
+
+- **PER 3.0 + PSR-12** coding style.
+- `declare(strict_types=1)` in every PHP file.
+- Strong typing: use type declarations for parameters, return types, and properties.
+- Use [php-forge/coding-standard](https://github.com/php-forge/coding-standard) for automated style checks.
+
+## Testing
+
+- All tests use **PHPUnit 12+**.
+- Target **100% code coverage** for new code.
+- Run the test suite before submitting a pull request:
+
+```bash
+composer test
+```
+
+## Pull Request Process
+
+1. Fork the repository and create a feature branch from `main`.
+2. Make your changes in small, focused commits.
+3. Use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) for commit messages.
+4. One logical change per pull request.
+5. Ensure all tests pass and coding standards are met.
+6. Open a pull request against `main` with a clear description of the change.
+
+
+## Security Vulnerabilities
+
+Do not open public issues for security vulnerabilities. See [SECURITY.md](SECURITY.md) for reporting instructions.

PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,12 @@
 # Pull Request
 
-| Q            | A                                                                  |
-| ------------ | ------------------------------------------------------------------ |
-| Is bugfix?   | ✔️/❌                                                              |
-| New feature? | ✔️/❌                                                              |
-| Breaks BC?   | ✔️/❌                                                              |
-| Fixed issues | <!-- comma-separated list of tickets # fixed by the PR, if any --> |
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+- [ ] Bugfix (non-breaking change that fixes an issue)
+- [ ] CI/build configuration
+- [ ] Documentation update
+- [ ] New feature (non-breaking change that adds functionality)
+- [ ] Refactoring (no functional changes)
+
+## Related Issues
+
+<!-- Reference related issues: Fixes #123, Closes #456 -->

SECURITY.md

@@ -0,0 +1,28 @@
+# Security Policy
+
+## Reporting a Vulnerability
+
+**Do not open a public issue for security vulnerabilities.**
+
+Use the GitHub Security Advisories feature in the affected repository to report vulnerabilities privately:
+
+1. Navigate to the affected repository (for example, `https://github.com/ui-awesome/<package>`).
+2. Go to the **Security** tab.
+3. Click **Report a vulnerability**.
+4. Provide a detailed description including steps to reproduce, impact, and any suggested fix.
+
+For more information, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability).
+
+## Supported Versions
+
+Security fixes are applied to the latest release of each package. Older versions do not receive security updates.
+
+## Response Timeline
+
+- **Acknowledgment**: Within 48 hours of the report.
+- **Assessment**: Within 7 days, an initial assessment and plan of action.
+- **Fix and disclosure**: A fix is developed, tested, and released before public disclosure.
+
+## Scope
+
+This policy applies to all repositories under the [ui-awesome](https://github.com/ui-awesome) organization.