> ## Documentation Index
> Fetch the complete documentation index at: https://docs.loongclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Contribution Areas

> Where different kinds of contributors can create real leverage in Loong.

# Contribution Areas

Loong needs more than one kind of contributor.

The public contribution story is intentionally broader than "write core runtime
code".

Use the repository's
[contribution-areas reference](https://github.com/eastreams/loong/blob/dev/docs/references/contribution-areas.md)
when you want the deeper repository-native area map and source-level starting
points behind this shorter overview.

## What The Project Values

* ownership over what you ship
* taste in product, API, docs, and engineering decisions
* care for other contributors and reviewers
* long-term thinking over clever shortcuts
* realistic, steady contribution instead of heroic bursts

## Where Your Strengths Can Help

| Area                                 | We especially welcome                                                       | Why it matters                                                                              |
| ------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| product and interface design         | designers with strong product judgment and trust-sensitive UX instincts     | Loong should feel legible and humane, not only technically capable                          |
| frontend and interaction engineering | engineers who can turn rough user surfaces into polished flows              | first-run experience, diagnostics, and future UI work all need strong interaction design    |
| Rust and systems engineering         | engineers with deep Rust skill and architecture discipline                  | the runtime depends on strong boundaries, reliability, and maintainability                  |
| hardware, robotics, and embodied AI  | people who understand real-world device or operational constraints          | the project should grow beyond a narrow software-only shell                                 |
| cross-platform delivery              | engineers who care about packaging and platform reliability                 | a private assistant runtime only matters if it works across the systems people actually use |
| testing, QA, CI, and operations      | contributors who enjoy release hygiene, observability, and failure analysis | trust is built through boringly reliable validation and delivery                            |
| documentation and docs-site clarity  | writers and engineers who can make public docs easier to scan and trust     | public docs shape adoption and contribution quality directly                                |
| community care                       | contributors who are good at triage, review, and unblocking others          | healthy collaboration is part of the product, not an afterthought                           |

## Good Starting Points

| If you want to start in...          | Useful places to look                                                |
| ----------------------------------- | -------------------------------------------------------------------- |
| product and docs clarity            | `README.md`, `README.zh-CN.md`, `site/`, onboarding and doctor flows |
| runtime and systems work            | `crates/kernel/`, `crates/app/`, `ARCHITECTURE.md`, design docs      |
| install, release, and platform work | install scripts, release workflows, reliability docs                 |
| public contribution improvement     | contributor docs, issue templates, discussions, review flow docs     |

## How To Join

* Join an existing issue if you already know what you want to improve.
* Open a discussion first if the scope is large or architecture-sensitive.
* Reach out directly if you want to introduce yourself and explain what you would like to own.

## A Helpful Introduction

If you introduce yourself directly, the most useful signals are:

* your time zone or typical working hours
* the kinds of problems you are strongest at
* the area you would most like to push forward
* what part of Loong feels most worth building
* examples of work, writing, design, or code you want maintainers to see

## Deep Reference

* [Contribution Areas We Especially Welcome](https://github.com/eastreams/loong/blob/dev/docs/references/contribution-areas.md)