diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
new file mode 100644
index 0000000..d32fffa
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -0,0 +1,83 @@
+name: Bug report
+description: Something in Batik is broken or behaves unexpectedly
+labels: ['bug', 'triage']
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for the report. A minimal reproduction is the single most useful
+        thing you can give us — it usually turns a week of back and forth into
+        an afternoon.
+
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Before you start
+      description: By submitting this issue, you agree to follow our [Contributing Guidelines](https://github.com/devsantara/batik/blob/main/CONTRIBUTING.md).
+      options:
+        - label: I searched the existing issues or PRs and this has not been reported yet.
+          required: true
+        - label: I can reproduce this on the latest published version of the affected package.
+          required: true
+
+  - type: input
+    id: package
+    attributes:
+      label: Affected package and version
+      placeholder: '@batik/<package>@<version>'
+    validations:
+      required: true
+
+  - type: textarea
+    id: description
+    attributes:
+      label: What happened
+      description: What you saw, and what you expected instead.
+    validations:
+      required: true
+
+  - type: input
+    id: reproduction
+    attributes:
+      label: Reproduction
+      description: >-
+        A link to a minimal repository or a StackBlitz that shows the bug,
+        with the StyleX compiler plugin set up for your bundler. We may close
+        issues we cannot reproduce.
+      placeholder: https://github.com/your-name/batik-bug
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to reproduce
+      placeholder: |
+        1. Install the package
+        2. Render `<Button />`
+        3. See the token fall back to the wrong value
+    validations:
+      required: true
+
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: >-
+        Versions of Batik packages, React, and @stylexjs/stylex, your bundler
+        and StyleX plugin, and the browser if relevant.
+      placeholder: |
+        @batik/<package> <version>
+        react 19.1.0, @stylexjs/stylex 0.x
+        Vite 7 + @stylexjs/unplugin, Chrome 140
+      render: text
+    validations:
+      required: true
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Anything else
+      description: Logs, screenshots, or a guess at the cause.
+    validations:
+      required: false
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 0000000..025ed15
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Question or half-formed idea
+    url: https://github.com/devsantara/batik/discussions
+    about: Ask how to use Batik, or float an idea before it becomes a proposal.
+  - name: Security vulnerability
+    url: https://github.com/devsantara/batik/security/advisories/new
+    about: Report privately. Please do not open a public issue for this.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
new file mode 100644
index 0000000..3dc07f3
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -0,0 +1,58 @@
+name: Feature request
+description: Suggest a new feature or an improvement to Batik
+labels: ['enhancement', 'triage']
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Batik is a design system, so additions carry a long support tail. Tell
+        us about the problem first — it often has a cheaper solution than the
+        one that brought you here.
+
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Before you start
+      description: By submitting this issue, you agree to follow our [Contributing Guidelines](https://github.com/devsantara/batik/blob/main/CONTRIBUTING.md).
+      options:
+        - label: I read the documentation and this is not already possible.
+          required: true
+        - label: I searched the existing issues or PRs and this has not been proposed yet.
+          required: true
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem
+      description: >-
+        What are you trying to build, and where does Batik get in the way today?
+      placeholder: >-
+        I need a dense table row, and the spacing tokens only go down to `md`.
+    validations:
+      required: true
+
+  - type: textarea
+    id: solution
+    attributes:
+      label: What you would like
+      description: The API, token, or component you have in mind. Sketch it out.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: What you tried instead
+      description: >-
+        Workarounds you have already used, and why they are not good enough.
+    validations:
+      required: false
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Anything else
+      description: >-
+        Prior art from other design systems, links, screenshots.
+    validations:
+      required: false
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
new file mode 100644
index 0000000..98b24cc
--- /dev/null
+++ b/.github/workflows/ci.yml
@@ -0,0 +1,70 @@
+name: CI
+
+on:
+  pull_request:
+
+permissions: {} # each job declares only the permissions it needs
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  check:
+    name: Check
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    permissions:
+      contents: read # to check out repo (actions/checkout)
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@v7.0.1
+        with:
+          persist-credentials: false
+      - name: Set up Vite+ and install dependencies
+        uses: voidzero-dev/setup-vp@v1.19.0
+        with:
+          cache: true
+      - name: Format, lint and type check
+        run: vp check
+
+  test:
+    name: Test
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    permissions:
+      contents: read # to check out repo (actions/checkout)
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@v7.0.1
+        with:
+          persist-credentials: false
+      - name: Set up Vite+ and install dependencies
+        uses: voidzero-dev/setup-vp@v1.19.0
+        with:
+          cache: true
+      - name: Run tests
+        run: vp test run --coverage
+
+  commit:
+    name: Commit message
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    permissions:
+      contents: read # to check out repo (actions/checkout)
+    steps:
+      - name: Check out repo
+        uses: actions/checkout@v7.0.1
+        with:
+          persist-credentials: false
+      - name: Set up Vite+ and install dependencies
+        uses: voidzero-dev/setup-vp@v1.19.0
+        with:
+          cache: true
+      - name: Lint pull request title
+        env:
+          # Pull requests are squash merged, so the title becomes the commit
+          # subject on main and has to satisfy the same commitlint rules.
+          # Read through the environment, never interpolated into the script.
+          PR_TITLE: ${{ github.event.pull_request.title }}
+        run: printf '%s' "$PR_TITLE" | vp run commitlint
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index 241a24b..95f65ca 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -77,7 +77,7 @@ jobs:
         with:
           cache: false # avoid cache poisoning in release jobs
       - name: Build packages
-        run: vp run build
+        run: vp run -r pack
       - name: Pack packages
         id: pack
         uses: changesets/action/pack@v2.1.2
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000..a53ab1b
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,170 @@
+# Contributor Covenant 3.0 Code of Conduct
+
+## Our Pledge
+
+We pledge to make our community welcoming, safe, and equitable for all.
+
+We are committed to fostering an environment that respects and promotes the
+dignity, rights, and contributions of all individuals, regardless of
+characteristics including race, ethnicity, caste, color, age, physical
+characteristics, neurodiversity, disability, sex or gender, gender identity or
+expression, sexual orientation, language, philosophy or religion, national or
+social origin, socio-economic position, level of education, or other status.
+The same privileges of participation are extended to everyone who participates
+in good faith and in accordance with this Covenant.
+
+## Encouraged Behaviors
+
+While acknowledging differences in social norms, we all strive to meet our
+community's expectations for positive behavior. We also understand that our
+words and actions may be interpreted differently than we intend based on
+culture, background, or native language.
+
+With these considerations in mind, we agree to behave mindfully toward each
+other and act in ways that center our shared values, including:
+
+1. Respecting the **purpose of our community**, our activities, and our ways of
+   gathering.
+2. Engaging **kindly and honestly** with others.
+3. Respecting **different viewpoints** and experiences.
+4. **Taking responsibility** for our actions and contributions.
+5. Gracefully giving and accepting **constructive feedback**.
+6. Committing to **repairing harm** when it occurs.
+7. Behaving in other ways that promote and sustain the **well-being of our
+   community**.
+
+## Restricted Behaviors
+
+We agree to restrict the following behaviors in our community. Instances,
+threats, and promotion of these behaviors are violations of this Code of
+Conduct.
+
+1. **Harassment.** Violating explicitly expressed boundaries or engaging in
+   unnecessary personal attention after any clear request to stop.
+2. **Character attacks.** Making insulting, demeaning, or pejorative comments
+   directed at a community member or group of people.
+3. **Stereotyping or discrimination.** Characterizing anyone’s personality or
+   behavior on the basis of immutable identities or traits.
+4. **Sexualization.** Behaving in a way that would generally be considered
+   inappropriately intimate in the context or purpose of the community.
+5. **Violating confidentiality**. Sharing or acting on someone's personal or
+   private information without their permission.
+6. **Endangerment.** Causing, encouraging, or threatening violence or other harm
+   toward any person or group.
+7. Behaving in other ways that **threaten the well-being** of our community.
+
+### Other Restrictions
+
+1. **Misleading identity.** Impersonating someone else for any reason, or
+   pretending to be someone else to evade enforcement actions.
+2. **Failing to credit sources.** Not properly crediting the sources of content
+   you contribute.
+3. **Promotional materials**. Sharing marketing or other commercial content in a
+   way that is outside the norms of the community.
+4. **Irresponsible communication.** Failing to responsibly present content which
+   includes, links or describes any other restricted behaviors.
+
+## Reporting an Issue
+
+Tensions can occur between community members even when they are trying their
+best to collaborate. Not every conflict represents a code of conduct violation,
+and this Code of Conduct reinforces encouraged behaviors and norms that can help
+avoid conflicts and minimize harm.
+
+When an incident does occur, it is important to report it promptly. To report a
+possible violation, open a
+[private report](https://github.com/devsantara/batik/security/advisories/new) on
+this repository. It is the private channel GitHub gives us, and it is visible
+only to the maintainers — you do not need to be reporting a security issue to
+use it. If the behavior also violates
+[GitHub's Acceptable Use Policies](https://docs.github.com/site-policy/acceptable-use-policies/github-acceptable-use-policies),
+you can additionally report it to GitHub at
+https://github.com/contact/report-abuse.
+
+Community Moderators take reports of violations seriously and will make every
+effort to respond in a timely manner. They will investigate all reports of code
+of conduct violations, reviewing messages, logs, and recordings, or interviewing
+witnesses and other participants. Community Moderators will keep investigation
+and enforcement actions as transparent as possible while prioritizing safety
+and confidentiality. In order to honor these values, enforcement actions are
+carried out in private with the involved parties, but communicating to the whole
+community may be part of a mutually agreed upon resolution.
+
+## Addressing and Repairing Harm
+
+The maintainers of this repository act as its Community Moderators. If an
+investigation by the Community Moderators finds that this Code of Conduct has
+been violated, the following enforcement ladder may be used to determine how
+best to repair harm, based on the incident's impact on the individuals involved
+and the community as a whole. Depending on the severity of a violation, lower
+rungs on the ladder may be skipped.
+
+1. Warning
+   1. Event: A violation involving a single incident or series of incidents.
+   2. Consequence: A private, written warning from the Community Moderators.
+   3. Repair: Examples of repair include a private written apology,
+      acknowledgement of responsibility, and seeking clarification on
+      expectations.
+2. Temporarily Limited Activities
+   1. Event: A repeated incidence of a violation that previously resulted in a
+      warning, or the first incidence of a more serious violation.
+   2. Consequence: A private, written warning with a time-limited cooldown
+      period designed to underscore the seriousness of the situation and give
+      the community members involved time to process the incident. The cooldown
+      period may be limited to particular communication channels or
+      interactions with particular community members.
+   3. Repair: Examples of repair may include making an apology, using the
+      cooldown period to reflect on actions and impact, and being thoughtful
+      about re-entering community spaces after the period is over.
+3. Temporary Suspension
+   1. Event: A pattern of repeated violation which the Community Moderators have
+      tried to address with warnings, or a single serious violation.
+   2. Consequence: A private written warning with conditions for return from
+      suspension. In general, temporary suspensions give the person being
+      suspended time to reflect upon their behavior and possible corrective
+      actions.
+   3. Repair: Examples of repair include respecting the spirit of the
+      suspension, meeting the specified conditions for return, and being
+      thoughtful about how to reintegrate with the community when the
+      suspension is lifted.
+4. Permanent Ban
+   1. Event: A pattern of repeated code of conduct violations that other steps
+      on the ladder have failed to resolve, or a violation so serious that the
+      Community Moderators determine there is no way to keep the community safe
+      with this person as a member.
+   2. Consequence: Access to all community spaces, tools, and communication
+      channels is removed. In general, permanent bans should be rarely used,
+      should have strong reasoning behind them, and should only be resorted to
+      if working through other remedies has failed to change the behavior.
+   3. Repair: There is no possible repair in cases of this severity.
+
+This enforcement ladder is intended as a guideline. It does not limit the
+ability of Community Moderators to use their discretion and judgment, in keeping
+with the best interests of our community.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public or other
+spaces. Examples of representing our community include using an official email
+address, posting via an official social media account, or acting as an
+appointed representative at an online or offline event.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 3.0,
+permanently available at
+[https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
+
+Contributor Covenant is stewarded by the Organization for Ethical Source and
+licensed under CC BY-SA 4.0. To view a copy of this license, visit
+[https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
+
+For answers to common questions about Contributor Covenant, see the FAQ at
+[https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq).
+Translations are provided at
+[https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations).
+Additional enforcement and community guideline resources can be found at
+[https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources).
+The enforcement ladder was inspired by the work of
+[Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..e390701
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,335 @@
+# Contributing to Batik
+
+First off, thank you. Batik is a token-first design system for
+[StyleX](https://stylexjs.com), and it gets better every time someone reports a
+rough edge, asks a sharp question, or sends a fix.
+
+This guide explains how the project works so your time goes into the
+contribution itself instead of guessing at process. None of it is meant to
+gatekeep. If something here is unclear or gets in your way, that is a bug in
+this document, and we would like to hear about it.
+
+> [!NOTE]
+> Batik is in early development. The API is not stable, nothing is on npm yet,
+> and large parts of the design are still moving. Open an issue before you
+> start on anything bigger than a small fix, so your work does not collide with
+> changes already underway.
+
+## Contents
+
+- [Ways to contribute](#ways-to-contribute)
+- [Asking questions](#asking-questions)
+- [Reporting bugs](#reporting-bugs)
+- [Suggesting features](#suggesting-features)
+- [Reporting security issues](#reporting-security-issues)
+- [Your first contribution](#your-first-contribution)
+- [Development setup](#development-setup)
+- [Making a change](#making-a-change)
+- [Commit messages](#commit-messages)
+- [Changesets](#changesets)
+- [Opening a pull request](#opening-a-pull-request)
+- [Code review](#code-review)
+- [Releases](#releases)
+- [Code of Conduct](#code-of-conduct)
+- [License](#license)
+
+## Ways to contribute
+
+Code is only one way to help. All of these count:
+
+- **Report bugs** with a reproduction someone else can run.
+- **Propose ideas** for tokens, primitives, or APIs, and argue for them.
+- **Improve documentation**: fix a typo, clarify a paragraph, add an example
+  that would have saved you an hour.
+- **Review pull requests.** A second pair of eyes, even with no merge rights,
+  catches real problems.
+- **Answer questions** in [Discussions][discussions].
+- **Try Batik** in a real project and tell us where it hurt.
+
+## Asking questions
+
+Use [GitHub Discussions][discussions] for questions, "how do I…", and
+half-formed ideas. The issue tracker is for bugs and concrete proposals, and
+keeping it that way lets maintainers act on it quickly.
+
+Before you ask, search existing discussions and issues. Someone may have
+already asked.
+
+## Reporting bugs
+
+Search [open and closed issues][issues] first. If you find a match, add a 👍
+reaction or new information to it instead of opening a duplicate. "+1" comments
+notify everyone watching and do not help anyone fix the problem.
+
+If nothing matches, [open a bug report][new-issue]. A good report has:
+
+- **A minimal reproduction.** A small repository or a StackBlitz link is best.
+  A bug we can reproduce is a bug we can fix. A bug we cannot reproduce
+  usually stalls.
+- **Expected versus actual behavior**, stated plainly.
+- **Versions** of Batik, StyleX, Node.js, your bundler, and your OS.
+- **Error output** pasted as text, not screenshots.
+
+## Suggesting features
+
+[Open a feature request][new-issue] and lead with the problem, not the
+solution. "I can't express X without Y" gives us far more to work with than
+"add option Z". Describe what you tried, why it fell short, and who else is
+likely to run into the same thing.
+
+Not every good idea fits Batik. A design system stays useful by staying
+coherent, so a "no" or "not yet" is a statement about scope, not about the
+quality of your idea.
+
+## Reporting security issues
+
+**Do not report security vulnerabilities in public issues, discussions, or pull
+requests.** Follow [SECURITY.md](./SECURITY.md) to report them privately
+through a GitHub security advisory.
+
+## Your first contribution
+
+New to open source, or new to this project? Welcome. Some ways in:
+
+- Look for issues labelled
+  [`good first issue`][good-first-issue]. They are scoped to be approachable
+  without deep knowledge of the codebase.
+- Look for [`help wanted`][help-wanted] issues, which the maintainers want
+  done but have not gotten to.
+- Documentation fixes are always a good first pull request.
+
+Comment on an issue before you start working on it, so two people do not solve
+the same problem in parallel. If an issue has been claimed but has seen no
+activity for a couple of weeks, ask whether it is still in progress.
+
+Never contributed to a project on GitHub before?
+[How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
+and
+[First Contributions](https://github.com/firstcontributions/first-contributions)
+walk through forking, branching, and opening a pull request.
+
+## Development setup
+
+### Prerequisites
+
+Batik uses [Vite+](https://viteplus.dev), a unified toolchain that wraps
+Node.js, pnpm, Vite, Vitest, Oxlint, and Oxfmt behind one CLI called `vp`.
+[Install Vite+](https://viteplus.dev/guide/#install-vp) first. It downloads the
+exact Node.js and pnpm versions this repository pins, so you do not need to
+install or manage them yourself.
+
+### Get the code
+
+[Fork the repository](https://github.com/devsantara/batik/fork), then:
+
+```bash
+git clone https://github.com/<your-username>/batik.git
+cd batik
+git remote add upstream https://github.com/devsantara/batik.git
+vp install
+```
+
+`vp install` installs dependencies and sets up the Git hooks that format staged
+files and lint commit messages. Run it again whenever you pull new changes.
+
+### Project layout
+
+This is a pnpm workspace:
+
+| Path          | What lives there                                   |
+| ------------- | -------------------------------------------------- |
+| `packages/*`  | Published libraries                                |
+| `apps/*`      | Documentation, playgrounds, and other private apps |
+| `.changeset/` | Pending release notes                              |
+| `.github/`    | CI workflows and issue templates                   |
+
+### Commands
+
+| Command                  | What it does                                |
+| ------------------------ | ------------------------------------------- |
+| `vp check`               | Format, lint, and type check the whole repo |
+| `vp check --fix`         | Same, and apply every automatic fix it can  |
+| `vp test`                | Run the test suite                          |
+| `vp test watch`          | Run the test suite in watch mode            |
+| `vp test run --coverage` | Run the test suite once and report coverage |
+| `vp run changeset`       | Write a changeset for your change           |
+
+`vp <name>` runs a built-in Vite+ command. `vp run <name>` runs a script from
+`package.json`. When in doubt, `vp help` lists everything.
+
+If your environment misbehaves, run `vp env doctor` and include its output
+when you ask for help.
+
+## Making a change
+
+1. **Sync with upstream** and branch off `main`:
+
+   ```bash
+   git switch main
+   git pull upstream main
+   vp install
+   git switch -c fix/token-contrast
+   ```
+
+2. **Keep it focused.** One pull request should do one thing. A bug fix, a
+   refactor, and a formatting sweep are three pull requests. Small pull
+   requests get reviewed faster and are easier to revert.
+
+3. **Add tests.** A bug fix comes with a test that fails without it. A feature
+   comes with tests that pin down its behavior. If something is hard to test,
+   say so in the pull request, and we will work it out together.
+
+4. **Update the docs** that your change affects, including types and JSDoc on
+   public APIs.
+
+5. **Run the checks** before you push:
+
+   ```bash
+   vp check
+   vp test
+   ```
+
+   CI runs the same commands, so a clean local run means a green pull request.
+
+### Code style
+
+Formatting and linting are automated. Oxfmt and Oxlint run on staged files
+when you commit and again in CI, so do not spend review time arguing about
+style by hand. Beyond what the tools enforce:
+
+- Match the style of the code around you.
+- Prefer clear names over comments. Use comments to explain _why_, not _what_.
+- Do not add a dependency without discussing it in an issue first. Every
+  dependency becomes something our users install too.
+
+## Commit messages
+
+Commit messages follow
+[Conventional Commits](https://www.conventionalcommits.org), with a required
+scope:
+
+```text
+<type>(<scope>): <subject>
+
+[optional body]
+
+[optional footer]
+```
+
+For example:
+
+```text
+feat(tokens): add a neutral color scale
+fix(theme): keep dark mode overrides when nesting themes
+docs(readme): clarify the install steps
+```
+
+- **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`,
+  `build`, `ci`, `chore`, `revert`.
+- **Scope:** the area you touched, such as a package or a subsystem.
+- **Subject:** imperative mood ("add", not "added"), lowercase, no trailing
+  period, and a header of 72 characters at most.
+
+The full rule set lives in [`commitlint.config.ts`](./commitlint.config.ts),
+and a `commit-msg` hook enforces it. To check a message up front (exit code `0`
+means it passes):
+
+```bash
+printf '%s' "feat(tokens): add a neutral color scale" | vp run commitlint
+```
+
+If the hook rejects a commit, the rule names in brackets, such as
+`[subject-case]`, tell you what to fix. Please do not bypass the hook with
+`--no-verify`.
+
+Inside your branch, commit however you like. Pull requests are squash merged,
+so the **pull request title** becomes the final commit on `main` and has to
+pass the same rules. CI checks it.
+
+## Changesets
+
+Batik uses [Changesets](https://github.com/changesets/changesets) to version
+packages and write the changelog. If your change affects a published package,
+add a changeset:
+
+```bash
+vp run changeset
+```
+
+Pick the affected packages and the kind of version bump, then write one or two
+sentences **for the people who use Batik**, not for the people who build it.
+"Fix focus rings disappearing in high contrast mode" is useful in a changelog.
+"Refactor ring util" is not. Commit the generated file in `.changeset/` with
+the rest of your change.
+
+Choosing the bump:
+
+| Bump    | When                                                    |
+| ------- | ------------------------------------------------------- |
+| `major` | Consumers must change their code to upgrade             |
+| `minor` | New functionality that is backwards compatible          |
+| `patch` | Bug fixes and changes that do not affect the public API |
+
+Changes that ship nothing to npm, such as docs, CI, or tests, do not need a
+changeset.
+
+## Opening a pull request
+
+1. Push your branch to your fork and
+   [open a pull request](https://github.com/devsantara/batik/compare) against
+   `main`.
+2. Give it a title that passes commitlint (see
+   [Commit messages](#commit-messages)).
+3. In the description, explain what changes and why, and link the issue it
+   resolves with `Closes #123`.
+4. Call out breaking changes explicitly, along with what consumers need to do.
+5. Tick **Allow edits from maintainers**, so we can push small fixes without a
+   round trip.
+
+Open a **draft** pull request if you want early feedback on a direction before
+you polish it.
+
+## Code review
+
+Every pull request needs approval from a maintainer before it merges.
+
+- **What we look at:** whether the change fits Batik's direction, whether it is
+  correct and tested, and whether the public API it adds is one we want to
+  support for years.
+- **Response time:** Batik is maintained by a small team, so a first response
+  can take a few days. If a week goes by with no reply, a polite ping on the
+  pull request is welcome.
+- **Feedback is about the code, not about you.** Reviewers explain the reason
+  behind a request. If you disagree, say so. Discussion is part of review, and
+  reviewers get things wrong too.
+- **Addressing feedback:** push new commits instead of force pushing, so
+  reviewers can see what changed since their last pass. Everything is squashed
+  on merge anyway.
+
+Sometimes a pull request does not get merged, because the scope changed or the
+approach does not fit. When that happens we will explain why. Opening an issue
+before large work is the best way to avoid it.
+
+## Releases
+
+Maintainers handle releases. When changes with changesets land on `main`, a
+bot opens a release pull request that bumps versions and updates the
+changelog. Merging that pull request publishes to npm. You do not need to do
+anything beyond including a changeset.
+
+## Code of Conduct
+
+Everyone taking part in this project is expected to follow the
+[Code of Conduct](./CODE_OF_CONDUCT.md). Please report unacceptable behavior as
+it describes.
+
+## License
+
+By contributing to Batik, you agree that your contributions are licensed under
+the [MIT License](./LICENSE) that covers the project.
+
+[discussions]: https://github.com/devsantara/batik/discussions
+[issues]: https://github.com/devsantara/batik/issues?q=is%3Aissue
+[new-issue]: https://github.com/devsantara/batik/issues/new/choose
+[good-first-issue]: https://github.com/devsantara/batik/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22
+[help-wanted]: https://github.com/devsantara/batik/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22
diff --git a/README.md b/README.md
index 87e41ed..f66987a 100644
--- a/README.md
+++ b/README.md
@@ -9,3 +9,22 @@
   <a href="./LICENSE"><img alt="MIT License" src="https://img.shields.io/github/license/devsantara/batik?style=for-the-badge&labelColor=000000"></a>
   <a href="https://github.com/devsantara/batik/graphs/contributors"><img alt="contributors" src="https://img.shields.io/github/contributors/devsantara/batik?style=for-the-badge&labelColor=000000"></a>
 </div>
+
+> [!WARNING]
+> Batik is in early development and not ready for production use. Nothing is
+> published to npm yet, and the API is not stable. Breaking changes can land
+> in any release before 1.0.
+
+## Contributing
+
+Bug reports, ideas and pull requests are welcome.
+[CONTRIBUTING.md](./CONTRIBUTING.md) covers the setup, the commands, the commit
+convention and how changesets work here. Everyone taking part is expected to
+follow the [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+Found a security problem? Do not open an issue —
+[SECURITY.md](./SECURITY.md) explains how to report it privately.
+
+## License
+
+[MIT](./LICENSE) © [Devsantara](https://github.com/devsantara)
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..b8698d7
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,53 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+**Please do not report security vulnerabilities through public issues, pull
+requests, or discussions.**
+
+Report them privately through GitHub instead:
+
+> [**Open a private security advisory**](https://github.com/devsantara/batik/security/advisories/new)
+
+Only the maintainers can see a report filed this way, and it gives us a private
+place to work with you on a fix before anything becomes public.
+
+If you cannot use that form for any reason, open a regular issue saying only
+that you have a security report to make — no details — and a maintainer will
+reach out.
+
+## What to include
+
+The more of this you can give us, the faster we can confirm and fix it:
+
+- The affected package and version
+- The type of issue and where it is in the source
+- Step-by-step instructions to reproduce it, ideally a minimal repository
+- A proof of concept, if you have one
+- What an attacker could do with it
+
+## What to expect
+
+- **Within 72 hours** — we acknowledge the report.
+- **Within 7 days** — we confirm whether it is a vulnerability and tell you what
+  we plan to do.
+- **Then** — we keep you updated as we work on the fix, and credit you in the
+  advisory when it publishes, unless you would rather stay anonymous.
+
+We ask that you give us a reasonable window to ship a fix before disclosing
+publicly. We will not take legal action against anyone who reports in good faith
+and follows this policy.
+
+## How releases are secured
+
+- Packages publish from GitHub Actions with
+  [npm trusted publishing](https://docs.npmjs.com/trusted-publishers) (OIDC). No
+  long-lived npm tokens exist in this repository.
+- The publish job runs in a protected `npm` environment that requires a
+  maintainer to approve each release.
+- Release workflows check out with `persist-credentials: false` and every job
+  declares the narrowest permissions it needs.
+- Third-party actions are pinned to exact versions.
+- Dependency updates wait out a minimum release age before they can be installed
+  (`minimumReleaseAge` in `pnpm-workspace.yaml`), which blunts the window for a
+  compromised upstream release.
diff --git a/package.json b/package.json
index c9fc513..cbbc9c3 100644
--- a/package.json
+++ b/package.json
@@ -20,13 +20,6 @@
   "type": "module",
   "scripts": {
     "prepare": "vp config",
-    "build": "vp run -r build",
-    "dev": "vp run -r dev",
-    "start": "vp run -r start",
-    "format": "vp fmt",
-    "format:check": "vp fmt --check",
-    "lint": "vp lint",
-    "lint:fix": "vp lint --fix",
     "check": "vp check",
     "check:fix": "vp check --fix",
     "test": "vp test",