Kiro Crew
A persistent workspace for development work that self-improves and continues beyond one session.
Kiro Crew is an open source development workspace that runs locally or remotely on
your hardware. It is persistent, self-learning, and self-evolving. Work with it
from the desktop app, web dashboard, and CLI, or continue the same work through
connection tools like Slack and Discord.
Your multi-step tasks can run unattended, recurring jobs run on your schedule,
and heartbeats monitor systems until something needs attention. Kiro Crew Apps
tailor that experience to a specific job, combining a purpose-built interface
with agents, skills, schedules, integrations, and backend services.
Quick start ·
Build from source ·
Why Kiro Crew ·
Capabilities ·
How it works ·
Security ·
Install ·
Telemetry ·
Docs
## Quick start
You choose how to run Kiro Crew: the desktop app with automatic updates, a
one-line install on your machine or a remote host, the Docker image for
always-on servers, or a build from source. Every path runs on `kiro-cli`
underneath, so the first launch installs it if needed and guides Kiro
device-code sign-in.
### App downloads
The desktop app starts a bundled Gateway when no local Gateway is already
running, updates itself on the channel you download, and can connect to a
remote Gateway over an SSH tunnel. See the
[desktop app guide](docs/build/desktop-app.md).
- **macOS**: [Stable](https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew.dmg) | [Insider](https://download.crew.kiro.dev/desktop/insider/latest/KiroCrew.dmg) | [Nightly](https://download.crew.kiro.dev/desktop/nightly/latest/KiroCrew.dmg)
- **Linux**: [Stable](https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-x86_64.AppImage) | [Insider](https://download.crew.kiro.dev/desktop/insider/latest/KiroCrew-x86_64.AppImage) | [Nightly](https://download.crew.kiro.dev/desktop/nightly/latest/KiroCrew-x86_64.AppImage)
- **Windows**: no desktop build yet, so run the Gateway from a [source install](#build-from-source) and open the dashboard in your browser
Take Stable unless you have a reason not to — the table below says who each
channel is for.
### Release channels
Every install path — desktop app, CLI, Docker image — offers the same three
channels. Pick by how much churn you can absorb, not by version number:
| Channel | Who it's for | Built from | Cadence |
|---------|--------------|------------|---------|
| **Stable** | Everyone. The default on every install path. | The Insider build that baked long enough to be promoted | On promotion, no calendar commitment |
| **Insider** | Power users who want features days to weeks early and accept the new bugs that come with them | Release-branch release-candidate tags | Every RC |
| **Nightly** | Us and contributors. Untested `main` HEAD — expect breakage. | `main`, 06:00 UTC daily | Daily |
Stable and Insider are two update lanes of the **same** app. The desktop app
switches between them in Settings → About, a CLI install switches by re-running
the installer with `--channel`, and a container switches by pulling a different
tag. Either way, the other lane's current version then arrives as an ordinary
update.
Nightly is a separate app with its own name and icon, so it installs *alongside*
a Stable or Insider one rather than replacing it. It is not a sandbox, though: it
reads the same `~/.kiro/crew` data home unless you point it elsewhere with
`KIROCREW_HOME`.
Running Insider or Nightly is a real contribution. When something looks wrong,
please [open an issue](https://github.com/kirodotdev/KiroCrew/issues) so it gets
fixed before it reaches Stable.
### One-line install
Install the prebuilt, SHA-256-verified wheel from the release CDN without
cloning the repository or running `npm` and a local build.
Stable, the default:
```bash
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
```
Track a faster channel, `insider` or `nightly` (see
[Release channels](#release-channels) for who each one is for):
```bash
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
```
Pin an exact version:
```bash
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.0
```
Open `http://localhost:5476` and start a conversation. The web dashboard works
without messaging credentials. Add [Slack](docs/guides/slack-setup.md),
[Telegram](src/kiro_crew/docs/telegram-integration.md), or
[WeCom](src/kiro_crew/docs/wecom-integration.md) when you want to continue
working with the same agent away from the dashboard. These channels connect
outbound, so you do not need to expose the dashboard port publicly.
### Docker
For always-on servers, the Gateway ships as a public multi-arch image on GHCR:
```bash
docker run -d --name kirocrew \
-p 127.0.0.1:5476:5476 \
-v kirocrew-home:/home/kirocrew \
ghcr.io/kirodotdev/kirocrew:stable
```
See the [Docker guide](docs/guides/docker.md) for first-run login, channel tags, and
the container security model.
### Build from source
macOS and Linux require Python 3.10+, Node.js 18+, npm, and
[`kiro-cli`](https://kiro.dev/docs/cli/). The first desktop or dashboard launch
can install Kiro CLI on the Gateway host and guide device-code sign-in before
chat opens. Windows is supported through a native source install; follow the
[Windows guide](docs/guides/windows-install.md) instead of the shell steps below.
```bash
# 1. Clone and build Kiro Crew
git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
make build
source .venv/bin/activate
# 2. Configure, verify, and start
kirocrew setup
kirocrew doctor
kirocrew gateway
```
## Why Kiro Crew
Most agent sessions end when the chat closes. Kiro Crew runs continuously on
hardware you control and keeps working between conversations.
**Persistent.** Sessions, memory, schedules, and task checkpoints survive
Gateway restarts, and scheduled or reactive work continues without someone at
the terminal.
**Self-learning.** Corrections and task failures become durable lessons.
Preferences and project context carry into new sessions.
**Self-evolving.** Repeated patterns become reusable skills. Memory, lessons,
and skills stay visible and editable, so each Kiro Crew grows more tailored to
the person and work around it.
**Runs where you choose.** Your Mac, a local container, or a remote machine
you control.
**One Gateway, many surfaces.** Work directly in the desktop app or web dashboard,
or continue the same work from the CLI and messaging surfaces like Slack and
Discord.
## What Kiro Crew does
| Capability | What it gives you |
|---|---|
| **Persistent sessions** | Run concurrent, isolated conversations, resume them after Gateway restarts, search prior sessions, and carry recent context into new work. |
| **Self-learning** | Turn corrections and task failures into durable lessons that change later behavior. Keep preferences, active-project context, and history scoped to the relevant workspace. Say *"no, always run the frontend checks before calling a change done"* and it becomes a workspace-scoped lesson applied in future sessions. |
| **Self-evolving skills** | Synthesize reusable skills from repeated patterns, then inspect, refine, or remove them as your work changes. |
| **Long-running tasks** | Give Kiro Crew a task spec and walk away. It plans steps, executes them, validates results, retries failures, and resumes from checkpoints. *"Implement this migration plan and stop if the tests fail"* runs as a checkpointed task with validation at each step. |
| **Unattended autonomy** | Run scheduled agent work or deterministic scripts and commands without a model call. Monitor work until it is done, or react to messaging events and authenticated webhooks without someone at the terminal. *"Every weekday at 9, summarize the open work I should review"* becomes a timezone-aware recurring job delivered to the surface you choose. |
| **Delegation** | Spawn isolated subagents for parallel work and bring their results back into the parent conversation. *"Research these three options in parallel and recommend one"* fans out to isolated subagents and synthesizes the tradeoffs. |
| **Work where you choose** | Work directly in the desktop app or web dashboard, or continue through the CLI and any connected messaging surface without moving the agent runtime or its state. |
| **Installable Apps** | Add focused interfaces and domain workflows through dashboard pages, scoped Gateway APIs, events, and lifecycle hooks. |
| **Extensible tools** | Add MCP servers, markdown skills, and hooks without changing the core runtime. |
| **Visible execution** | Watch tool calls, subagent progress, context usage, approvals, schedules, memory, and logs from the dashboard. |
| **Defense in depth** | Combine tool approvals, OS sandboxing, sensitive-path checks, credential redaction, deny rules, audit events, and governance profiles. |
You can also paste a screenshot and ask what is causing an error. Kiro Crew sends
the image to the active Kiro model and keeps the diagnosis in the conversation
history.
The complete inventory is in [Features](src/kiro_crew/docs/index.md) and
[What's New](CHANGELOG.md).
## How it works
```mermaid
flowchart TD
S["Desktop app · Web dashboard · Slack · Telegram · WeCom · CLI"]
G["Gateway
access · sessions · memory · schedules · approvals · apps"]
A["Agent sessions
ACP runtime · kiro-cli · MCP tools · models"]
S --> G --> A
```
The Gateway separates where the agent runs from where you work with it. In the
desktop app or web dashboard, you can work directly through parallel conversations,
files, task runs, approvals, memory, and apps. From Slack, Telegram, WeCom, or
the CLI, the Gateway routes your work to managed agent sessions under the same
memory, tool, approval, and policy services. Apps extend the dashboard and
Gateway APIs with focused workflows.
Each active conversation or background task uses an agent session. Its session
provider drives `kiro-cli` over ACP, streams model and tool events, and preserves
conversation state. Depending on the workload, a session is backed by its own
ACP process or by a session handle on a shared multiplexed ACP runtime. The
Gateway manages these sessions along with scheduling, approvals, memory,
security policy, messaging connections, and the dashboard.
The current runtime places the Gateway, agent sessions, ACP processes, and state
on the same host. Run Kiro Crew on your Mac, inside a container on your machine,
or on a remote Linux host you control. Conversation history, memory, and
knowledge indexes remain on that host. Model requests are handled by `kiro-cli`
and follow the account and model configuration you use there.
**Gateway.** The Gateway is the long-running Kiro Crew process. It routes
messages from the desktop app, web, CLI, and the messaging surfaces listed below. It persists
session state, injects memory and skills, starts scheduled work, coordinates
subagents, brokers approvals, enforces runtime policy, and exposes activity in
the dashboard.
**Agent sessions.** A dashboard conversation or Slack thread maps to an isolated
agent session. Scheduled jobs, task runs, Telegram and WeCom conversations, and
subagents also use managed sessions. These sessions preserve conversation
context and can run concurrently before returning results to a parent session or
configured surface.
**ACP runtime and turns.** Kiro Crew supports both a dedicated `kiro-cli` ACP
process for a session and a shared ACP runtime that multiplexes multiple session
handles. During each turn, the session sends a prompt, streams model and tool
events, resolves approvals, and returns the final result. An agent session is a
logical isolation boundary, not necessarily one OS process.
**Use the surface that fits the moment.**
| Surface | Best for |
|---|---|
| **Desktop app** | The simplest local experience, with a bundled Gateway plus multi-tab connections to local or remote Gateways. |
| **Web dashboard** | Parallel conversations, files, approvals, activity, memory, schedules, apps, settings, and system status at `localhost:5476`. |
| **Slack** | Work from DMs and threads with streaming replies, approvals, notifications, and session links back to the dashboard. |
| **Telegram** | Reach your agent from private DMs on your phone or laptop, with streaming replies, inline approvals, and commands. |
| **Discord** | Work from DMs with streaming replies and approvals delivered as message buttons. |
| **Teams** | Reach your agent from Microsoft Teams chats with streaming replies and approvals. |
| **Webex** | Work from Webex direct messages with streaming replies and inline approvals. |
| **WeCom** | Chat through an outbound-connected WeCom AI bot with configured user access and streaming replies. |
| **WeChat (Weixin)** | Reach your agent from WeChat with configured user access and streaming replies. |
| **CLI** | Fast interactive chat and direct automation with `kirocrew chat`, `run`, `cron`, `spawn`, and `security`. |
**Choose how work starts.**
| Mode | Use it for | Entry point |
|---|---|---|
| **Scheduled** | Briefings, audits, backups, and recurring maintenance | `kirocrew cron` or a natural-language request |
| **Proactive** | Goals that need another pass without waiting for a new user message | AutoNudge and goal-loop skills |
| **Reactive** | CI alerts, external automation, Slack activity, and other events | Authenticated agent webhooks and messaging events |
| **Task runner** | Bounded projects with explicit steps, tests, review, and checkpoint resume | `kirocrew run TASK.md` |
| **Subagents** | Independent workstreams that can run concurrently | `kirocrew spawn run "task"` |
**Memory, learning, and evolution.** Kiro Crew maintains preferences, active
project context, decaying history summaries, and durable lessons. Corrections
and task failures can change later behavior, while repeated patterns can become
reusable skills. In-process embeddings add semantic retrieval for memory and
the knowledge library. The stored state remains inspectable and editable
from the dashboard. Incognito and temporary session modes let you opt out when
a conversation should not persist.
**Skills, MCP, and apps.** Markdown skills supply reusable workflows and can be
loaded only when relevant. The built-in `kirocrew-core` and `kirocrew-cron` MCP
servers expose task, subagent, learning, messaging, and scheduling tools. You
can discover additional MCP servers from Kiro or Kiro Crew configuration. The
App Kit adds installable interfaces and domain workflows. Apps can add dashboard
pages, use scoped Gateway APIs, subscribe to events, and register lifecycle
hooks.
## Security and control
Kiro Crew gives an AI agent real tool access, so the controls are enforced at
the runtime boundary instead of relying only on prompt instructions.
- **Local by default.** The dashboard binds to loopback unless you explicitly
configure a network URL. Remote dashboards require token authentication.
- **Interactive approvals.** Review tool requests in the dashboard, Slack, or
Telegram. Session-scoped trust can reduce repeated prompts without changing
the underlying deny and sensitive-path controls.
- **OS sandbox.** On Linux and macOS, `kiro-cli` can run inside namespace or
Seatbelt isolation. Standard, strict, and off modes make the tradeoff
explicit. Windows offers no equivalent OS-level layer, so Kiro Crew fails
closed there: agent subprocesses are refused rather than run unconfined, until
you declare the
[`sandbox_allow_unsandboxed_exec` opt-in](docs/guides/windows-install.md#the-unsandboxed-exec-opt-in).
- **Sensitive data guards.** Kiro Crew blocks direct access to protected paths,
strips sensitive environment variables, and redacts credential patterns from
output before it reaches a chat surface.
- **Denied operations.** 137 bundled deny patterns block destructive commands and
common exfiltration paths even when a session has broad approval.
- **Auditability.** Security events and tool activity are recorded for review.
Use `kirocrew security events`, `audit`, and `verify` to inspect them.
- **Governance ceiling.** Optional policy and profile files compose with a
tightest-wins model. A running app or agent can narrow the allowed scope but
cannot loosen the enterprise ceiling. Inspect it with `kirocrew policy show`,
`validate`, and `explain`.
No agent security layer removes the need to protect credentials and review
high-impact actions. Avoid pasting secrets or sensitive personal data into a
chat. Read the [security architecture](docs/architecture/security-deep-dive.md) and use
[SECURITY.md](SECURITY.md) for private vulnerability reporting.
## Install, configure, and operate
**Installer details.** The installer resolves the channel feed, verifies the wheel's SHA-256 against
the published manifest, installs through `pipx` when available or a managed
virtual environment at `~/.kiro/crew-venv` (beside the data home; override with
`KIROCREW_VENV`), and records the channel in `~/.kiro/crew/channel`. The channels
are `stable`, `insider`, and `nightly`, and `KIROCREW_CHANNEL` sets the default.
On Linux it installs a Python 3.10+ interpreter from your distro when the system
lacks one — via `apt` on Debian/Ubuntu, `dnf` on Amazon Linux / RHEL / CentOS
Stream, `yum` on CentOS 7. Where no base-repo package supplies 3.10+ (CentOS 7,
older Ubuntu) it uses an already-installed [mise](https://mise.jdx.dev/) if you
have one, otherwise it prints how to install a newer Python and stops. The
signed installer never pipes an unsigned third-party script into a shell.
**Pin an exact wheel.** You can also install one exact wheel directly and pin it to its published
SHA-256. Every version directory publishes a `SHA256SUMS` file next to the
wheel, so take the hash for your wheel from there and put it in the URL
fragment. `pip` verifies the hash and does not consult a package index for
Kiro Crew itself:
```bash
pip install "https://download.crew.kiro.dev/cli/stable//kirocrew--py3-none-any.whl#sha256="
```
**Semantic memory.** Semantic memory needs no setup. Embeddings run in-process, and the Gateway
downloads its embedding model in the background on first start, verifies it,
and stores it under `~/.kiro/crew/models`. Until the model lands, memory search
falls back to keyword search and picks up embeddings automatically without a
restart. Set `KIROCREW_EMBED_MODEL_URL` to point at a mirror for airgapped
installs.
See [Installing and Building](docs/guides/install.md) for wheels, desktop builds,
Windows, optional voice dependencies, and manual setup.
**Choose where Kiro Crew runs.** The current deployment model keeps the Gateway,
agent session runtime, ACP processes, and state together on one host. Your Apps
and chat surfaces connect to that Gateway.
| Deployment | How to run it | Where Kiro Crew and its state live |
|---|---|---|
| **Mac app, local** | Install or build the desktop app with `make desktop` | The app starts its bundled Gateway. Agent sessions, ACP processes, and `~/.kiro/crew` stay on your Mac. |
| **Native local** | `make build`, or install a wheel from `make wheel` | The Gateway and agent runtime run directly on your macOS, Linux, or Windows machine. |
| **Local container** | Run `ghcr.io/kirodotdev/kirocrew` and persist `/home/kirocrew` | The Gateway and agent runtime run inside the official multi-arch container on your machine. |
| **Remote hardware** | Follow the [remote host guide](docs/guides/remote-and-mobile.md) and install the service | The Gateway, agent sessions, and state run continuously on your Linux server, home lab, or cloud instance. Connect the desktop app or browser through an SSH tunnel. |
| **Windows source install** | Follow [the Windows guide](docs/guides/windows-install.md) | The Gateway, agent sessions, chat, cron, and dashboard run natively with documented feature limits. |
For containers, mount the directory selected by `KIROCREW_HOME` so sessions,
configuration, memory, and credentials survive replacement. Keep the Gateway
port bound to loopback unless you intentionally configure authenticated remote
access. Container isolation and the Kiro Crew OS sandbox are separate layers
and depend on the host runtime configuration. See the
[Docker guide](docs/guides/docker.md) for the published image and deployment details.
**Keep it running.** Install a systemd service on Linux or a launchd agent on
macOS:
```bash
kirocrew service install
kirocrew service status
kirocrew logs
```
To bind a non-default port (for example a host where `5476` is already taken),
set `KIROCREW_PORT` when you install the service — the value is baked into the
unit:
```bash
KIROCREW_PORT=5477 kirocrew service install
```
To change it later without reinstalling, edit `/etc/kirocrew/kirocrew.env`
(created by `service install`) and run `sudo systemctl restart kirocrew`.
The desktop app can use this local Gateway or connect to a remote one. For an
always-on VPS, home server, or cloud VM in your account, follow the
[remote host guide](docs/guides/remote-and-mobile.md). Kiro Crew does not require a
Kiro Crew-hosted control plane.
**Configure it.** User data lives under `~/.kiro/crew` by default. Manage the
main configuration with `kirocrew config get`, `set`, and `edit`.
```json
{
"agent": {
"provider": "acp",
"approval_mode": "interactive",
"sandbox": "auto"
},
"session": {
"timeout_secs": 1800,
"pool_size": 2
},
"dashboard": {
"bot_name": "Kiro Crew"
}
}
```
`agent.provider` is fixed to `acp`. Kiro Crew drives `kiro-cli` over the Agent
Client Protocol. Set the dashboard port with `KIROCREW_PORT` or
`kirocrew gateway --port `. Slack credentials live in `~/.kiro/crew/.env`
rather than the JSON config.
**Troubleshoot quickly.** Start with `kirocrew doctor`. For an ACP timeout,
confirm `kiro-cli` is on `PATH` and logged in, then allow extra time for the
first MCP startup. For memory search, check that the embedding
model finished downloading under `~/.kiro/crew/models`. For a stale MCP configuration, run
`kirocrew setup --agent-only`, or add `--clean` to rebuild it.
**Find the logs.** When you need to debug, the fastest path is
`kirocrew logs` (tail the most recent gateway output) or `kirocrew logs -f` to
follow it live; `kirocrew logs -n 200` prints more history. `kirocrew logs`
reads the right source automatically — the systemd journal when the Linux
service is installed, the launchd stdout file on macOS, or the foreground
gateway log otherwise. Raise verbosity with `kirocrew gateway -v` (INFO:
session lifecycle and context usage) or `-vv` (DEBUG: full ACP events and
message traces); set the persistent default with
`kirocrew config set agent.log_level`, or change it at runtime from the
dashboard **Logs** page. Under `~/.kiro/crew` (or your `KIROCREW_HOME`) you can
also read the raw files directly:
| File | What it holds |
|---|---|
| `~/.kiro/crew/gateway.log` | Main gateway log when running in the foreground. |
| `~/.kiro/crew/security_events.jsonl` | Append-only security and tool-access events. Inspect with `kirocrew security events`, `audit`, and `verify`. |
| `~/.kiro/crew/audit.log` | Human-readable audit trail of privileged operations. |
| `~/.kiro/crew/subagents//result.txt` | Full transcript of a completed subagent, kept for a grace window after it finishes. |
See the [Troubleshooting guide](src/kiro_crew/docs/troubleshooting.md) for the
full log-level reference and emergency recovery steps.
## Anonymous usage telemetry
Kiro Crew sends **one anonymous heartbeat per day** so maintainers can see how
many copies are actively running, which versions are in use, and which
platforms and install channels to support. After a successful install or update
from the official app catalog, it also sends one anonymous per-app receipt.
Both signals are on by default and use the same controls below.
To turn it off, flip **Settings → Privacy → Send anonymous usage heartbeat** in
the dashboard (the same switch appears on the last step of first-run
onboarding). Or from a terminal:
```bash
kirocrew telemetry disable # persists to config.json
export KIROCREW_TELEMETRY_DISABLED=1 # or per-shell / per-container
kirocrew telemetry status # print exactly what would be sent
```
The toggle and `kirocrew telemetry disable` write the same setting, so either
one sticks across restarts and upgrades. `KIROCREW_TELEMETRY_DISABLED` overrides
both — when it is set, the dashboard toggle is disabled and says so.
**Exactly these five fields are sent, at most once per day, and nothing else:**
| Field | Example | Why |
|-------|---------|-----|
| Random instance id | `9c75560d…` (UUID4) | Lets us count how many copies ran on a given day. Generated once on first run and derived from nothing — not your hostname, username, MAC, IP, or any account. It identifies an installed copy, never a person. |
| App version | `0.1.2` | Which releases are still in use. **Release number only** — build stamps like `-nightly.20260731t065756` are stripped before sending, because a per-build timestamp is near-unique and would help identify a specific machine. |
| Python minor version | `3.12` | When the minimum can move up |
| Install channel | `dmg` | Which install path people actually use |
| First-run flag | `1` / `0` | New installs vs returning |
**Official-app install receipts are separate and event-based.** After a
successful official-catalog install or update, Kiro Crew sends one GET to
`/b/1/install/?t=&k=&v=` on the same
telemetry host. The slug is the public catalog identifier. `t` is the first 32
hex characters of HMAC-SHA256 keyed by the local beacon install id over
`app-install:`; the raw install id is never sent, and tokens for different
apps cannot be linked to assemble an installed-app profile. `k` separates fresh
installs from updates, and `v` is the same release-only Kiro Crew version clamp
used by the heartbeat.
Receipts are emitted only for bundled or edition-provided official catalog
entries. Apps from user-configured registries, local-directory installs, and
self-registered apps emit nothing, so private app names never leave the machine.
If no persistent beacon install id exists yet, the receipt is skipped.
This list used to be nine fields. Release channel, OS, CPU architecture and
governance posture were **removed** — each was coarse on its own, but the
instance id is stable, so those attributes all describe the *same* copy and
together they narrowed the group any one install blends into far more than any
single field suggests.
We report this as **Daily Active Crews** rather than "users": Kiro Crew has
no account system of its own, and the Kiro sign-in that `kiro-cli` uses for
model access is never read or sent. There is no way to resolve a copy to a
person, so one person running Kiro Crew on three machines counts as three
Crews.
**Never sent:** your prompts, model responses, file contents, file paths, repo
or branch names, credentials, environment variables, hostname, username, or IP
address. The receiving CDN is configured **not to log client IP addresses** — the
log delivery does not include that field, so no IP is stored at all.
**Automatically off** in CI, and whenever `KIROCREW_HOME` points somewhere other
than `~/.kiro/crew` (dev instances and pods are never counted).
**Enterprise administrators can pin it off entirely.** A `capabilities.telemetry`
entry in the security policy blocks both outbound signals regardless of the local
setting, and the dashboard toggle then says so instead of offering a change that
would not take effect:
```json
{"version": 1, "boot": {"fail_closed": true},
"capabilities": {"telemetry": {"enabled": false}}}
```
See [docs/system-specs/modules/governance.md](docs/system-specs/modules/governance.md).
This is separate from `telemetry.enabled`, which controls **local-only**
performance metrics that never leave your machine. See
[docs/system-specs/modules/metrics.md](docs/system-specs/modules/metrics.md).
## Docs and contributing
| Topic | Start here |
|---|---|
| Install and packaging | [Install and build](docs/guides/install.md), [Windows](docs/guides/windows-install.md), [Docker](docs/guides/docker.md), [Desktop](docs/build/desktop-app.md), [Remote host](docs/guides/remote-and-mobile.md), [Release process](docs/build/release.md) |
| Product capabilities | [Features](src/kiro_crew/docs/index.md), [Skills](skills/README.md), [All user docs](src/kiro_crew/docs/README.md) |
| All documentation | [docs/](docs/README.md) for contributor and architecture docs |
| Channels | [Slack](docs/guides/slack-setup.md), [Discord](src/kiro_crew/docs/discord-integration.md), [Telegram](src/kiro_crew/docs/telegram-integration.md), [Teams](src/kiro_crew/docs/teams-integration.md), [Webex](src/kiro_crew/docs/webex-integration.md), [WeCom](src/kiro_crew/docs/wecom-integration.md), [WeChat (Weixin)](src/kiro_crew/docs/weixin-integration.md) |
| Architecture | [System architecture](docs/architecture/overview.md), [Memory](docs/system-specs/modules/memory-skills-hooks.md), [MCP](docs/architecture/mcp.md), [App Kit](docs/app-kit/getting-started.md) |
| Trust and dependencies | [Security](docs/architecture/security-deep-dive.md), [Security policy](SECURITY.md) |
| Project work | [Contributing](CONTRIBUTING.md), [Tenets](TENETS.md), [Governance](GOVERNANCE.md), [Maintainers](MAINTAINERS.md), [AI assistant rules](AGENTS.md), [Changelog](CHANGELOG.md) |
Contributions are welcome. Create a branch from `main`, keep changes focused,
and run the relevant checks before opening a pull request:
```bash
# Backend
pip install -e ".[voice]" --group dev
pytest
# Frontend
cd website
npm ci
npm run check
npm run build
```
Use [GitHub Issues](https://github.com/kirodotdev/KiroCrew/issues) for bugs and
feature requests. Do not file security vulnerabilities publicly.
## Contributors
Kiro Crew was made possible by its internal community, the people who supported the
project and shipped its code, together with everyone who has since opened a pull
request in the open. This is that founding group; as Kiro Crew grows in the open, we
look forward to many more contributors joining them. Thank you to everyone who helped
make this tool possible:
Listed alphabetically by GitHub username. Internal contributors appear here if they
consented to public recognition in the contributor survey; open-source contributors are
included from this repository's pull request history. If you contributed and would like
to be added, corrected, or removed, please open an issue or a pull request.
## License
Kiro Crew is licensed under the [Apache License 2.0](LICENSE). See
[NOTICE](NOTICE) for attribution information.