Contributing

Keep Rune boring.

Thank you for contributing to Rune Context.

Rune aims to become a universal repository understanding layer for code LLMs.

Long-term maintainability is more important than adding features quickly.

---

Philosophy

Rune follows a simple principle:

Complexity should be pushed outward.

The core should remain:

• small
• deterministic
• dependency-free
• language-agnostic

Plugins provide language intelligence.

Agents provide code generation.

Rune provides context.

---

Before Contributing

Ask:

Is this feature necessary?

Not:

Can we add it?

But:

Should we add it?

Prefer:

• fewer features
• simpler designs
• explicit behavior

---

Design Principles

Local First

Rune should work completely offline.

Avoid:

• accounts
• cloud services
• telemetry
• remote dependencies

---

Human Readable

Prefer:

• Markdown
• JSON

Avoid:

• binary formats
• databases

---

Deterministic

Running:

rune index

twice on the same repository should produce identical outputs.

Avoid:

• timestamps
• randomness
• machine-specific paths

---

Incremental

Prefer:

rune update

over rebuilding everything.

---

Small Surface Area

Good:

rune init
rune index
rune update
rune context
rune doctor

Bad:

rune server
rune daemon
rune login
rune cloud

---

Core Responsibilities

Rune core should only provide:

• CLI
• repository format
• graph engine
• context engine
• caching

Anything language-specific belongs in plugins.

---

Non-Goals

Please avoid turning Rune into:

• an IDE
• an agent framework
• a vector database
• an MCP server
• a SaaS platform

These are intentional exclusions.

---

Repository Layout

cmd/
internal/
plugins/
scripts/
tests/

.rune/

---

Building

Requirements:

• Go 1.24+

Clone:

git clone https://github.com/rune-context/rune

Build:

go build -o rune ./cmd/rune

Run:

./rune --version

---

Testing

Run:

go test ./...

New features should include tests.

Prefer:

• unit tests
• deterministic tests
• isolated tests

Avoid flaky tests.

---

Dependencies

Rune values simplicity.

Before introducing a dependency, ask:

Can the standard library do this?

Adding dependencies should be rare.

---

Code Style

Prefer:

Small functions

Good:

func LoadGraph() error

Bad:

func LoadGraphAndUpdateSessionsAndGenerateSummaries() error

---

Explicit names

Good:

LoadGraph()
UpdateFileSummary()

Avoid:

Do()
Process()
Handle()

---

Composition over inheritance

Keep components independent.

---

Simple data structures

Prefer:

map[string][]string

over deeply nested abstractions.

---

Error Handling

Prefer explicit errors.

Good:

if err != nil {
    return err
}

Avoid:

• hidden failures
• silent recovery

---

Performance

Optimize only after measuring.

Prefer:

• simplicity
• readability

over premature optimization.

Rune is mostly:

• file I/O
• parsing
• graph traversal

Maintainability matters more than microseconds.

---

Plugin Contributions

Language support should be implemented separately.

Examples:

rune-python
rune-typescript
rune-go

Core should remain language-agnostic.

---

Pull Requests

Small PRs are preferred.

Good:

Add graph validator

Bad:

Rewrite the entire indexing system

Large changes are difficult to review.

---

Commit Messages

Examples:

add graph validator

improve file summaries

fix incremental indexing

Prefer lowercase.

Keep messages short.

---

AI Contributions

AI-generated code is welcome.

However:

• humans remain responsible for review
• correctness matters more than speed
• generated code should follow project philosophy

Code quality is judged by the same standards regardless of who wrote it.

---

What Makes a Good Contribution?

Good contributions:

• reduce complexity
• improve clarity
• increase determinism
• simplify APIs
• remove dependencies

Deleting code is often a contribution.

---

Roadmap

See:

Roadmap

---

Philosophy

Git succeeded because it remained small.

Rune should do the same.

Git stores history.

Rune stores understanding.