Contributing

Ikenga is built in the open and licensed Apache-2.0. Issues, pull requests, and design discussion all happen on GitHub under Royalti-io. This page is the friendly overview; the canonical rules live in the org-wide CONTRIBUTING.md, which every repo inherits.

The fastest way to contribute is a package

You don’t need to touch the platform internals to extend Ikenga — most of the surface area is packages (UI panels, MCP tool servers, engine adapters, skills). If you have an idea, the shortest path from zero to shipped is Build your first pkg.

Ways to contribute

• Build a pkg — a panel, an MCP tool server, an engine adapter, or a skill. Start at Build your first pkg; the archetype matrix is on the Pkgs page.
• Report a bug — open an issue using the bug template (see below).
• Request a feature — describe the problem first; use the feature template.
• Improve the docs — this site, repo READMEs, and per-archetype authoring guides all take PRs. Small doc fixes can skip the issue step.
• Fix code — grab a good first issue or open a PR for an obvious fix.

Pick the right repo

Ikenga is a multi-repo project. Change the thing where it lives:

Repo	Role	Package manager
ikenga	Tauri 2 + Vite + React 19 desktop app + pkg kernel (the shell)	bun
ikenga-contract	Shared TS package: manifest schema (Zod), RPC types, Engine interface, capability scopes	pnpm
ikenga-tokens	Canonical design tokens (CSS + TS)	pnpm
ikenga-cli	ikenga — disk-side pkg manager (add | update | list | dev)	bun
iyke-cli	iyke — Rust runtime controller for a running shell	cargo
ikenga-pkgs	Canonical monorepo for all pkgs (engines, MCP servers, apps, skills)	pnpm + Changesets
ikenga-registry	Static JSON registry of published pkgs	—
ikenga-site	Marketing site + docs for ikenga.dev	pnpm
ikenga-artifact-builder	Claude Code skill for self-contained HTML artifacts	pnpm

Don’t introduce a foreign lockfile

Package managers vary by repo on purpose. The shell and the ikenga CLI use bun; the shared libraries and ikenga-pkgs use pnpm; iyke-cli uses cargo. Use the one the repo already uses.

Filing a good issue

Use the templates — they exist so we can act on a report without a round-trip for missing detail.

• Bug reports — include your OS, the affected repo/version, and the smallest reproduction you can manage.
• Feature requests — describe the problem before the solution.
• Questions & ideas — open a GitHub Discussion rather than an issue.
• Security issues — do not open a public issue. See Reporting a vulnerability below.

One report per issue. If you’ve found three bugs, file three issues.

Opening a pull request

1. Fork the repo and branch off main — name it for the work: fix/iframe-handshake-race, feat/codex-adapter, docs/contributing-setup.
2. Commit in logical units following Conventional Commits: type(scope): summary (e.g. fix(kernel): unregister dev pkg on Ctrl-C). Types: feat, fix, docs, refactor, test, chore.
3. Add a changeset if the repo publishes through Changesets (ikenga-contract, ikenga-tokens, ikenga-cli, ikenga-pkgs, ikenga-artifact-builder): run pnpm changeset and commit it. Not needed for docs-only or CI changes.
4. Run the repo’s tests and match its formatter/linter before pushing. Don’t reformat unrelated code.
5. Open the PR against main, fill in the template, and link the issue it closes (Closes #123). Review is a conversation, not a gate.

Provenance — no CLA

We use inbound = outbound: by opening a pull request you agree your contribution is licensed under the same Apache-2.0 terms as the project. There’s no CLA and no DCO sign-off step — keeping contribution friction low, the way most non-foundation open-source projects do.

Good first issues

New here? Look for issues labelled good first issue across the org, or help wanted for slightly larger pieces. These are scoped to be approachable without deep platform knowledge, and maintainers give them extra review support.

Code of Conduct

Participation is governed by our Code of Conduct (Contributor Covenant). It applies everywhere in the project. Report concerns to hello@royalti.io.

Security

Found a vulnerability? Don’t open a public issue. Use GitHub Private Vulnerability Reporting (the Security tab → Report a vulnerability) or email hello@royalti.io. Full policy: SECURITY.md.