Contributing

Contributing

Thanks for helping improve AnyLM. This page is the contributor workflow; deeper topics live in the rest of the wiki.

Before you start

1. Read Getting Started and Architecture.
2. Skim Gotchas.
3. For skills/tools work, read Skills, Tools, and MCP & Extensions.

Workflow

1. Fork / branch from main.
2. Implement with small, focused commits.
3. Run:

   cd app && bun run typecheck && bun test

4. Manually smoke the path you touched.
5. Open a PR with:
   • Why the change exists
   • How to test it
   • Notes on Firestore rules / IPC / migrations if relevant

Code style expectations

• Match existing TypeScript style in the file you edit.
• Prefer focused changes; avoid drive-by refactors.
• Keep renderer free of Node APIs.
• Update api.d.ts + preload + ipc together.
• Update firestore.rules when changing governance data access.
• Don’t commit secrets, .env with live projects you care about, or signing material.

Where design docs live

Non-trivial features often have:

• docs/superpowers/specs/YYYY-MM-DD-*-design.md
• docs/superpowers/plans/YYYY-MM-DD-*.md

Follow them when working in that area; if reality diverged, prefer code and update docs/wiki when you can.

Extending the product

Contribution type	Guide
Custom tool/skill for yourself	UI only — Tools / Skills
Shipped builtin tool	registry + exec
Shipped builtin skill	builtins (+ connector if OAuth)
MCP support	Not present — propose a spec first
Marketing copy / catalog	web/
Rules / authz	firebase/ + api/

Review focus areas

Reviewers will especially watch:

• Security: tool risk flags, confirm gates, token handling
• IPC contract completeness
• Soft-fail behavior for Chroma/Ollama
• Multi-agent fallback side effects
• Cooperative governance honesty (don’t pretend Spark enforces usage adversarially)

Communication

• Prefer precise PR descriptions over large unstructured dumps.
• Link wiki pages or specs when useful.
• Call out leftover stale comments (Cloud Functions, NestJS) if your PR touches them.