Update README add CONTRIBUTING

Author: 0xGeorgii

CONTRIBUTING.md

@@ -0,0 +1,63 @@
+# Contributing guide
+
+## Style
+
+We keep code clean and constantly refactoring it for better readability, maintainability, and performance.
+- It is totally fine and encouraged to refactor existing code and send PRs for that. Event if it is a small renaming or a typo fix.
+- Do not mix up refactoring with new features/bug fixes in a single PR.
+
+## AI Generated Code
+
+Of course you can use AI tools to _help_ you write code (who can ban you from that?) but in this case, please make sure to:
+- Manually review and test all AI-generated code before submitting it
+- State clearly in the PR description which parts of the code were generated by AI tools
+- Prefer small, focused AI-generated snippets over large chunks of code
+- Ensure that AI-generated code adheres to the project's coding style and guidelines
+
+> [!WARNING]
+> If we find AI-generated code that is not reviewed or tested, we may ask you to remove it or even close the PR.
+
+# General
+
+## Dependencies
+
+We prefer to keep dependencies to a minimum so we can control the code quality, build process, and security. Also, we know how slow a compilation can get with too many dependencies. Therefore, if you are thinking about adding a new dependency, please consider checking with the maintainers first.
+
+## Branching Strategy
+
+We use the `main` branch as the default branch and create tags for releases. For new features and bug fixes, please create feature branches from `main` and open pull requests against `main`.
+
+Prior starting work on a PR, please ensure that you have an issue created for it and assinged to yourself. If a scope of work is less than existing issue, create a new issue and link it to the parent one.
+
+## Branch Naming
+
+Make branch names inherit the issue that it addresses. The pattern is: `<issue-number>-<type>-<short-description>`.
+
+Examples:
+- If you work on a new _feature_ "9 - Develop Linker", name your branch `9-feature-develop-linker`.
+- If you work on a _bug fix_ "15 - Fix Parser Crash", name your branch `15-bug-fix-parser-crash`.
+
+## Commit Messages
+
+Please, do not use emoji in commit messages. Keep them simple and descriptive. Avoid tagging people `@` because in case of rebasing or playing with history it may lead to unwanted notifications.
+
+## Clippy
+
+We use `clippy` but sometimes it is too lound. In this case, it is ok to disable specific warnings.
+
+# Code
+
+## Tests
+
+We tend to have as good test coverage as possible. At the same time we keep a balance between writing redundant test that can be make the codebase less readable and maintainable. Please keep in mind this balance when writing tests.
+
+Every PR (except for documentation-only changes and renaming) must include tests that cover the changes made.
+
+### Unit Tests
+
+When writing unit tests, you probably need to have Inference source code as input. In this case, locate the code on top of the test with in a compact format. For example:
+
+```rust
+```
+
+### Code Generation Tests

README.md

@@ -1,16 +1,24 @@
 [![Build](https://github.com/Inferara/inference/actions/workflows/build.yml/badge.svg?branch=main)](https://github.com/Inferara/inference/actions/workflows/build.yml)
 
-# Inference
+# 🌀 Inference Programming Language
 
-🌀 Inference programming language [specification](https://github.com/Inferara/inference-language-spec)
+Inference is a programming language designed for building verifiable software. It is featured with static typing, explicit semantics, and formal verification capabilities available out of the box.
+
+> [!IMPORTANT]
+> The project is in early development. Internal design and implementation are subject to change. So please be patient with us as we build out the language and tools.
+
+## Learn
+
+- The [book](https://inference-lang.org/book)
+- Inference Programming Language [specification](https://github.com/Inferara/inference-language-spec)
 
 ## Inference Compiler CLI (`infc`)
 
 `infc` drives the compilation pipeline for a single `.inf` source file. Phases are:
 
 1. Parse (`--parse`) – build the typed AST.
 2. Analyze (`--analyze`) – perform semantic/type inference (WIP).
-3. Codegen (`--codegen`) – emit WebAssembly and optionally translate to V when `-o` is supplied.
+3. Codegen (`--codegen`) – emit WebAssembly and optionally translate to `.v` when `-o` is supplied.
 
 You must specify at least one phase flag; requested phases run in canonical order.
 
@@ -45,6 +53,8 @@ Artifacts are written to an `out/` directory relative to the working directory.
 
 ## Roadmap
 
-* [Base type checker](https://github.com/Inferara/inference/issues/26)
-* Additional output formats.
-* [Linker](https://github.com/Inferara/inference/issues/9)
+Check out open [issues](https://github.com/Inferara/inference/issues).
+
+## Contributing
+
+Contributions are welcome! Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details.