DOC: Add open-source contribution docs and issue templates

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,41 @@
+---
+name: Bug report
+about: Report something broken or incorrect
+title: "[BUG] : Brief description of issue"
+labels: bug
+assignees: ''
+
+---
+
+## Overview
+Clear, concise description in 1-2 sentences
+
+## Details
+Details about the issue
+
+## Reproduce
+1. step 1
+2. step 2
+3. step 3
+
+## Expected
+Describe expected behaviour
+
+## Actual
+Describe actual behaviour
+
+## Versions
+Library version (e.g. kiit-codes 1.0.1)
+
+## Target
+Which target(s) this occurs on:
+1. JVM
+2. Android
+3. JS
+4. iOS
+
+## Kotlin version
+Kotlin version in use
+
+## Additional
+Add any other context, stack traces, or logs here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,29 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: "[FEATURE] : Brief description of feature request"
+labels: feature
+assignees: ''
+
+---
+
+> For design changes, new codes, or language ports, consider opening a
+> [Discussion](../../discussions) first. See [CONTRIBUTING.md](../../CONTRIBUTING.md).
+
+## Overview
+Clear, concise description in 1-2 sentences
+
+## Details
+Details about the feature request
+
+## Area
+What area / module is this most applicable to?
+
+## Problem
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+## Solution
+A clear and concise description of what you want to happen.
+
+## Alternatives
+A clear and concise description of any alternative solutions or features you've considered.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,23 +1,21 @@
-## Overview
-<!-- General overivew of the PR -->
+## Related discussion or issue
+<!-- Link to the Discussion or Issue this PR came out of. PRs without prior discussion may be
+     asked to open one first, see CONTRIBUTING.md. -->
 
-## Ticket(s) 
-<!-- Link to any tickets -->
+## Overview
+<!-- General overview of the PR -->
 
-## Links(s) 
-<!-- Relevant links -->
+## Links
+<!-- Any other relevant links: related PRs, external specs, changed assets, etc. -->
 
 ## Dependencies
-<!-- Items this depends on -->
+<!-- Anything this depends on: another PR, a specific release, an upstream change -->
 
 ## Design
 <!-- High-level design/changes -->
 
-## Notes
-<!-- Explain any notes-->
-
-## Pending
-<!-- Pending items ? -->
-
 ## Tests
 <!-- Any tests added/changed -->
+
+## Notes
+<!-- Anything else worth calling out -->

CHANGELOG.md

@@ -0,0 +1,21 @@
+# Changelog
+
+All notable changes to kiit-codes are documented here. Format follows
+[Keep a Changelog](https://keepachangelog.com/), versions follow
+[Semantic Versioning](https://semver.org/).
+
+## [1.0.1] - 2026-08-15
+
+### Fixed
+- `OMITTED`'s message corrected to stay neutral about cause, no longer implies the item was
+  actively left out.
+
+## [1.0.0] - 2026-08-14
+
+### Changed
+- Groups and codes finalized after a full design and audit pass.
+
+## [0.x.x] - 2026-07-01
+
+### Added
+- Extracted from the Kiit framework as its own standalone module.

CONTRIBUTING.md

@@ -0,0 +1,71 @@
+# Contributing
+
+Thanks for your interest in kiit-codes.
+
+## Where things stand right now
+
+This project is early. The core taxonomy and design just went through a significant round of
+review and stabilized as `1.0.x`. **I'm not accepting general pull requests at this stage.** The
+priority right now is letting the design settle and get real-world feedback before opening up
+broader contribution.
+
+This isn't a permanent stance, just a "not yet."
+
+## What's welcome right now
+
+- **Bug reports.** If something is broken, incorrect, or the docs don't match the actual
+  behavior, please open an [issue](../../issues).
+- **Design feedback.** Disagree with a naming choice, a category, or a default? Open a
+  [Discussion](../../discussions). This is genuinely useful, and it's the best way to influence
+  where the project goes next.
+- **Questions.** Also welcome in Discussions, not Issues.
+
+## Language ports
+
+If you're interested in porting this taxonomy to another language, please start with a
+Discussion, not a PR. I'd like to talk through the approach first, what stays faithful to the
+original design, what should adapt to the target language's own idioms, before any code gets
+written. This keeps everyone's effort from being wasted, and gives the port a real shot at
+becoming an official, linked module rather than staying disconnected.
+
+**Ports hosted here need to genuinely enforce the same guarantees the design depends on.** A real
+sum type and compiler-checked exhaustive matching, not just a naming convention that happens to
+resemble the taxonomy. A "port" in a language that can't enforce this is a fundamentally
+different, weaker thing wearing the same name, and I'd rather not host something that only looks
+like the real design.
+
+This is about my principles on this design, not gatekeeping. An independent, unofficial
+implementation in any language is always fine to build on your own. This only concerns what gets
+hosted as an official Kiit port.
+
+### Candidate languages
+
+| Language | Real sum type | Exhaustiveness |
+|---|---|---|
+| TypeScript | Discriminated unions (literal-tagged interfaces, not classes) | Enforced via the `switch`/`never` idiom |
+| Scala | Sealed traits / case classes | Compiler-enforced |
+| Rust | `enum` | Compiler-enforced, no escape hatch |
+| Other (e.g. Swift, Java 21+, F#, Haskell, OCaml) | Must have a real sum type construct | Must be compiler-enforced, not just a lint or convention |
+
+Something not listed isn't automatically excluded. Open a Discussion and make the case. The bar
+above is what matters, not the specific list.
+
+## Before opening a PR
+
+If you've discussed something in an Issue or Discussion and I've said a PR would be welcome,
+please make sure:
+
+- The PR references the Discussion or Issue it came out of.
+- Tests are included for any behavioral change.
+- The change is scoped narrowly, one concern per PR.
+
+PRs opened without prior discussion may be closed and asked to start with a Discussion instead.
+Not out of unfriendliness, just to keep effort aligned before code gets written.
+
+## Build, test, and publish
+
+See [BUILD.md](./BUILD.md) for local build, test, and publish instructions.
+
+## Code of conduct
+
+Be respectful. Disagreement about design is welcome and expected, personal attacks are not.

README.md

@@ -219,7 +219,7 @@ Current work is focused on the Kotlin release, documentation, examples, and ecos
 | 2 | **TypeScript** | Add native TypeScript support with an idiomatic implementation of the same Codes taxonomy and semantics. |
 | 3 | **Taxonomy** | Continue taxonomy review based on real-world usage and community feedback. |
 
-See [GitHub Issues](https://github.com/slatekit/kiit-codes/issues) for current work and discussions.
+See [GitHub Issues](https://github.com/kiitdev/kiit-codes/issues) for current work and discussions.
 
 ## Learn More