Add contributing doc, style guide doc and issue template

.github/ISSUE_TEMPLATE/feature.md

@@ -0,0 +1,39 @@
+---
+name: Feature
+about: For new features
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+### **Description**
+
+Describe the task. What does this aim to implement?
+
+### **Technical Details**
+
+-   Implementation details
+-   Insight to what needs to be done
+-   Etc.
+
+### **Acceptance Criteria**
+
+-   Are metrics required?
+-   Are translations required?
+-   Cases to satisfy
+-   XYZ should work
+-   Etc.
+
+Scenario: xxxx
+- GIVEN a user is in x state
+- WHEN a user does x
+- AND a user does x
+- THEN x should occur
+
+### **References**
+
+-   References go here.
+-   Issue numbers. Links.
+-   Slack threads.
+-   Etc.

CONTRIBUTING.md

@@ -0,0 +1,24 @@
+# Contributing
+
+Thank you for your interest in contributing to the `snap-7715-permissions`! Your contributions help make this project better for everyone. Below are guidelines to help you get started.
+
+
+## How Can I Contribute?
+
+You can [open an issue](https://github.com/MetaMask/snap-7715-permissions/issues/new/choose) to suggest a feature. Please follow the new feature template. To report a bug, please follow our [security policy](https://github.com/MetaMask/snap-7715-permissions/security/policy).
+
+Before creating a new issue, check the current open and closed issues to see if your concern has already been addressed. Adding a comment to an existing issue can often be more effective.
+
+When suggesting a new feature, provide comprehensive details, particularly about the motivating use cases. Clearly illustrating the feature’s potential impact on the ecosystem can help prioritize its development. High-impact features are given priority, so detailed explanations are highly valued.
+
+### Submitting Pull Requests
+
+All Pull Requests must be paired with an open issue. When creating a Pull Request, you will be presented with a PR template; please be as detailed and thorough as possible to increase the likelihood of your PR being merged.
+
+Create your PR against `main` as the base branch.
+
+Please ensure your pull request adheres to the [style guide](https://github.com/MetaMask/snap-7715-permissions/blob/main/docs/styleGuide.md) and includes unit tests for new functionality.
+
+## Releasing changes
+
+[Read more on "Release" ->](https://github.com/MetaMask/snap-7715-permissions/blob/main/docs/release.md)

docs/styleGuide.md

@@ -0,0 +1,100 @@
+# Style Guide
+
+This document outlines the coding style and conventions used in the snap-7715-permissions project.
+
+## General
+
+- Use UTF-8 encoding for all files
+- Use 2 spaces for indentation
+
+## TypeScript/JavaScript
+
+### Naming Conventions
+
+- Use camelCase for variables, functions, and method names
+- Use camelCase for file names
+
+### Documentation
+
+- Use JSDoc comments for public APIs
+- Include descriptions for parameters and return values
+- Document thrown exceptions
+
+Example:
+```typescript
+/**
+ * Description of the function.
+ *
+ * @param options - The options object.
+ * @param options.param1 - Description of param1.
+ * @returns Description of the return value.
+ * @throws When something goes wrong.
+ */
+```
+
+### Error Handling
+
+- Use descriptive error messages
+- Prefer custom error classes for specific error types
+- Handle errors appropriately
+
+## Testing
+
+- Use Jest for unit and integration tests
+- Name test files with `.test.ts` suffix
+- Group related tests with `describe` blocks
+- Use clear and descriptive test names with `it` statements
+- Use mocks for external dependencies
+
+Example:
+```typescript
+describe('MyFunction', () => {
+  it('should return the expected result when given valid input', () => {
+    // Arrange
+    const input = 'valid input';
+
+    // Act
+    const result = myFunction(input);
+
+    // Assert
+    expect(result).toBe('expected output');
+  });
+});
+```
+
+## Code Organization
+
+- Organize code by feature or domain
+- Keep files focused on a single responsibility
+- Use barrel exports (index.ts files) to simplify imports
+- Separate interfaces/types into their own files when they become large
+
+## Git Workflow
+
+- Create feature branches from `main`
+- Use descriptive commit messages
+- All pull requests must be linked to an open issue
+- Pull requests should target the `main` branch
+
+## Project Structure
+
+- `/packages`: Contains all the project packages
+- `/scripts`: Contains build and utility scripts
+- `/docs`: Project documentation
+- `/external`: External dependencies
+
+## Dependencies
+
+- Use Yarn as the package manager
+- Pin dependency versions where appropriate
+
+## Best Practices
+
+1. Follow the Single Responsibility Principle
+2. Write pure functions when possible
+3. Use async/await for asynchronous code
+4. Use descriptive variable names
+5. Keep functions small and focused
+6. Use TypeScript's type system to prevent bugs
+7. Document complex logic with comments
+8. Write tests for all new functionality