{
  "markdown": "# Shinobi\n\n[![Website](https://img.shields.io/badge/Website-shinobi--apps.com-c96442)](https://shinobi-apps.com/shinobi)\n[![test](https://github.com/numbererikson/shinobi/actions/workflows/test.yml/badge.svg)](https://github.com/numbererikson/shinobi/actions/workflows/test.yml)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![Node](https://img.shields.io/badge/node-%3E%3D18-brightgreen)](https://nodejs.org)\n\nThe task spine for AI coding agents. Shinobi holds the decisions that survive across sessions, **actively searches your past dead ends — semantically — before the agent writes code**, and routes approvals to your phone. One brain, every device: laptop, cloud session, and mobile all wired to the same store.\n\nWorks with Claude Code, Cursor, Cline, Continue.dev, Zed — any MCP-compatible client.\n\n> **Status:** v0.3 — autonomous agents. Run it as a hosted HTTP `/mcp` brain (the default deploy) or self-host a local instance. Mobile push, a headless dispatch loop, parallel swarm over git worktrees, and audit→subtask ingestion on top of the remote MCP foundation. 39 MCP tools, web dashboard, mobile approvals, plugin system, optional semantic recall.\n\n## What it does\n\nMost tools try to be a memory bolt-on. Shinobi is the **task spine** your agent\nworks *along* — the durable backbone of work, decisions, and known-bad paths\nthat outlives any single session and follows you across every device.\n\n- **Task spine** — projects + subtasks the agent claims, completes, or pivots; the persistent skeleton of multi-session work\n- **Decisions that survive** — record architectural choices with rationale so the next session (on any device) doesn't re-litigate them\n- **Dead ends, searched before you build** — every failed approach is logged and **semantically matched the moment an agent plans a similar one**, so it never burns a second session on the same wall. No other tool does this.\n- **Approvals on your phone** — `request_approval` pushes the decision to your pocket; the agent blocks until you tap yes/no, wherever you are\n- **One brain, every device** — laptop editor, Claude Code cloud session, and mobile chat all hit the same store over remote MCP; no sync step, no per-device drift\n- **Plans** — versioned plan snapshots, retrievable mid-task\n- **Context** — per-project conventions, \"don't touch\" rules, test patterns, deploy notes, file annotations\n- **Recall** — fulltext (FTS5) by default, semantic (embedding-backed) when an embedding provider is configured\n- **Notes** — free-form annotations and voice notes (audio_path field)\n- **Activity timeline** — every write path lands in the timeline so you can replay what happened\n- **Git linking** — `link_commit` ties commits to subtasks via `[SHI-N]` tags or via `target_path` attribution\n- **Web dashboard** — Hono-served Kanban + decisions + dead ends + notes + plans + context + timeline + analytics\n- **Plugin system** — drop a `.js` file in `~/.shinobi/plugins/` or install a `@shinobi/plugin-*` npm package and register custom `plugin_*` tools\n\n**Hosted or self-hosted, your call.** The default deploy is one remote brain\nbehind an HTTP `/mcp` endpoint (we run ours at `shinobi.shinobi-apps.com`); the\nsame binary still runs as a fully local single-machine instance when you'd\nrather keep everything on your own box. BYO embedding provider only if you want\nsemantic recall.\n\n> 🚀 New here? Follow [Getting started](docs/getting-started.md) — zero to a\n> working brain in ten minutes. Going multi-device? [Remote mode](docs/remote-mcp.md)\n> + [$0/month cloud deploy](docs/deploy-gcp-free.md).\n\n## Install\n\nRequirements:\n\n- Node.js 18+ on `PATH`\n- C++ build toolchain for `better-sqlite3` native build (most systems have prebuilt binaries; Windows may need [Visual Studio Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/) as fallback)\n\n### From npm (recommended)\n\n```bash\nnpm install -g @shinobiapps/shinobi\n```\n\nThe binary is `shinobi` (e.g. `shinobi serve`, `shinobi dashboard`).\n\n### From GitHub (latest, unreleased)\n\n```bash\nnpm install -g github:numbererikson/shinobi\n```\n\nPulls from `main`. Useful for trying unreleased fixes. On Windows you may need\nto add your Node directory to system `PATH` before this works, because the\n`prepare` build script runs in a subshell that does not always inherit\nper-session `PATH` (Laragon, portable installs). If install fails with `'node'\nis not recognized`, prefer the npm install above.\n\n### From a cloned source folder (for development / contributing)\n\n```bash\ngit clone https://github.com/numbererikson/shinobi.git\ncd shinobi\nnpm install            # triggers `prepare` → builds dist/\nnpm install -g .\n```\n\n### Then bootstrap\n\nIn any project root where you want Shinobi available to your MCP client:\n\n```bash\nshinobi init\nshinobi dashboard\n```\n\n`init` will:\n1. Create `~/.shinobi/` with `config.json`, `.env` template, and `shinobi.db` (migrations applied)\n2. Drop a `.mcp.json` snippet for the current project\n3. Print next steps\n\n`shinobi init` writes config for the two clients with a workspace-local\nMCP convention out of the box:\n\n- **Claude Code** — `<workspace>/.mcp.json`\n- **Cursor** — `<workspace>/.cursor/mcp.json`\n\nRestart the client and the `mcp__shinobi__*` tools become available.\n\nFor other MCP clients (Cline, Continue.dev, Zed), see the\n[MCP client setup](#mcp-client-setup) section below.\n\nThen open:\n\n```text\nhttp://127.0.0.1:8765\n```\n\nOn Windows PowerShell, if script execution blocks `shinobi`, use the `.cmd` shim:\n\n```powershell\nshinobi.cmd dashboard\n```\n\nIf you upgraded Node or copied an old `node_modules`, rebuild native dependencies:\n\n```bash\nnpm rebuild better-sqlite3\n```\n\nImportant: the code lives in the Shinobi folder, but the local memory database lives in:\n\n```text\n~/.shinobi/shinobi.db\n```\n\nTo move the tool only, copy/clone the Shinobi folder and run the install commands above. To move the existing projects, tasks, decisions, notes, and context too, either copy `~/.shinobi/` or use `shinobi sync`.\n\n## MCP client setup\n\nEvery snippet below uses the **same JSON shape** — `command` is the path\nto the Node binary that's running Shinobi, `args` is `[<absolute path to\ndist/cli.js>, \"mcp\"]`. Print the exact values for your machine:\n\n```bash\nshinobi init --print-config\n```\n\n(Or read `.mcp.json` from any project where you already ran\n`shinobi init` — the values are identical.)\n\n### Claude Code\n\nDrops in automatically — `shinobi init` writes `<workspace>/.mcp.json`.\nRestart Claude Code to pick up the server.\n\n### Cursor\n\nDrops in automatically — `shinobi init` writes `<workspace>/.cursor/mcp.json`.\nWorks on Cursor 0.43+. Restart Cursor or reload the workspace.\n\nFor a **global** Cursor config (every project sees Shinobi), paste the\nsame snippet into `~/.cursor/mcp.json` (or use Cursor Settings → MCP).\n\n### Cline (VS Code extension)\n\nOpen Cline's settings file:\n\n- Windows: `%APPDATA%\\Code\\User\\globalStorage\\saoudrizwan.claude-dev\\settings\\cline_mcp_settings.json`\n- macOS: `~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json`\n- Linux: `~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json`\n\nMerge the contents of your project's `.mcp.json` into the file's\n`mcpServers` object. Restart VS Code.\n\n### Continue.dev\n\nEdit `~/.continue/config.json`. Add Shinobi to the `mcpServers` array\n(note: Continue uses an **array**, not an object like the others):\n\n```json\n{\n  \"mcpServers\": [\n    {\n      \"name\": \"shinobi\",\n      \"command\": \"/absolute/path/to/node\",\n      \"args\": [\"/absolute/path/to/dist/cli.js\", \"mcp\"]\n    }\n  ]\n}\n```\n\nUse the values from your project's `.mcp.json` for `command` and `args`.\n\n### Zed\n\nEdit `~/.config/zed/settings.json`. Zed nests MCP servers under\n`context_servers`:\n\n```json\n{\n  \"context_servers\": {\n    \"shinobi\": {\n      \"command\": {\n        \"path\": \"/absolute/path/to/node\",\n        \"args\": [\"/absolute/path/to/dist/cli.js\", \"mcp\"]\n      }\n    }\n  }\n}\n```\n\nRestart Zed.\n\n### Generic / other clients\n\nAny MCP client that supports the standard `{ command, args }` server spec\nshould work. Use the same values your `.mcp.json` has:\n\n- `command`: absolute path to the Node binary running Shinobi\n- `args`: `[<absolute path to dist/cli.js>, \"mcp\"]`\n\nAvoid the bare `shinobi` command in MCP config — many clients spawn\nservers with `shell: false`, which skips the OS PATH resolution that\nmakes `shinobi` work in a terminal.\n\n### Remote mode (the default deploy)\n\nHost one Shinobi brain on a server and connect every device to it — your\ndesktop editor, Claude Code web/mobile sessions, any remote-MCP-capable\nclient. `shinobi serve` exposes the MCP endpoint at `/mcp` (streamable HTTP,\n**stateless**, bearer-token auth) alongside the dashboard:\n\n```bash\nclaude mcp add --transport http shinobi https://your-host/mcp \\\n  --header \"Authorization: Bearer YOUR_TOKEN\"\n```\n\nThis is the recommended way to run Shinobi — one brain, reachable from every\ndevice. The same binary still runs as a local single-machine instance if you'd\nrather self-host everything on your own box. Full deployment guide (Docker,\nCloudflare Tunnel, GCP Always Free, client config):\n[docs/remote-mcp.md](docs/remote-mcp.md).\n\n## CLI\n\n```\nshinobi <command> [options]\n\nCommands:\n  init                            Bootstrap ~/.shinobi/ and drop .mcp.json in the current directory\n  mcp                             Run the MCP server over stdio (invoked by the MCP client)\n  migrate                         Apply pending SQL migrations\n  dashboard                       Start the web dashboard on localhost (default port 8765)\n  serve [--host H] [--port P]     Dashboard + MCP HTTP endpoint (/mcp) in one process — see docs/remote-mcp.md\n  sync init <path> [branch]       Configure a local git repo as the cross-machine sync target\n  sync push                       Snapshot the DB and commit it to the sync repo\n  sync pull                       Restore the DB from the sync repo's snapshot\n  sync status                     Show last push/pull timestamps and git status\n  dispatch [--once|--drain]       Autonomous loop: pull next_task → run worker → complete/unblock → repeat\n           [--project N] [--interval S] [--max-failures N]   Worker via SHINOBI_WORKER_CMD (e.g. 'claude -p \"$SHINOBI_TASK_PROMPT\"'); unset → dry-run\n  swarm --agents N                N dispatch loops in parallel, each in its own git worktree/branch, one shared\n        [--project N] [--drain]   brain. Atomic claim → no two agents take the same task. --no-worktree / --keep-worktrees\n```\n\n## MCP tools (39)\n\n| Group | Tools |\n|---|---|\n| Projects | list_projects, get_project, create_project, update_project, archive_project, unarchive_project, delete_project |\n| Subtasks | list_tasks, get_task, create_task, bulk_create_tasks, update_subtask, delete_subtask, claim_task, complete_task, next_task |\n| Decisions | log_decision, decisions_for_file, update_decision_status |\n| Dead ends | log_dead_end, check_dead_ends |\n| Notes | add_note, list_notes |\n| Plans | save_plan, get_plan |\n| Context | get_context, update_context |\n| Recall | recall (FTS5 or semantic) |\n| Timeline | history, link_commit |\n| Workflow | agent_bootstrap, session_closeout, file_context |\n| Extraction | extract_decisions, compress_session_summary |\n| Approvals | request_approval |\n| Notifications | notify |\n| Findings | ingest_findings |\n| Plugins | plugin_hello |\n\n## Architecture\n\n| Layer | Tech |\n|---|---|\n| Language | TypeScript (strict mode, ES2022, NodeNext) |\n| Runtime | Node 18+ |\n| MCP | `@modelcontextprotocol/sdk` 1.x |\n| Storage | SQLite via `better-sqlite3` (WAL mode) |\n| Dashboard | Hono + `@hono/node-server` (same process, localhost:8765) |\n| Embeddings (optional) | OpenAI text-embedding-3-small / Voyage voyage-3-lite / Ollama nomic-embed-text |\n| Migrations | Forward-only, sha256 checksum, `schema_migrations` table |\n\nSee [docs/architecture.md](docs/architecture.md) for the request lifecycle and module layout.\n\n## Dashboard auth\n\nThe dashboard is open on loopback binds (`127.0.0.1`, `localhost`, `::1`) and token-protected on any non-loopback bind. The token is read from `SHINOBI_DASHBOARD_TOKEN`, otherwise loaded from `~/.shinobi/dashboard-token`, otherwise auto-generated and persisted there. `/health` is always open for probes.\n\nBrowser flow — open the dashboard with the token once and the cookie sticks:\n\n```text\nhttp://192.168.1.10:8765/?token=YOUR_TOKEN\n```\n\nCurl / scripts — any of these works:\n\n```bash\ncurl -H \"Authorization: Bearer $SHINOBI_DASHBOARD_TOKEN\" http://192.168.1.10:8765/api/projects/1/snapshot\ncurl -H \"X-Shinobi-Token: $SHINOBI_DASHBOARD_TOKEN\"      http://192.168.1.10:8765/api/projects/1/snapshot\ncurl --cookie \"shinobi_token=$SHINOBI_DASHBOARD_TOKEN\"   http://192.168.1.10:8765/api/projects/1/snapshot\n```\n\nSee [docs/configuration.md](docs/configuration.md#dashboard) for the full env-var reference.\n\n## Cross-machine sync\n\nShinobi syncs your local SQLite database via a private git repo. Setup once per machine:\n\n```bash\n# Once: clone a private GitHub repo to act as the sync repo\ngit clone git@github.com:USER/shinobi-sync.git ~/shinobi-sync\n\n# Once per machine: tell shinobi about it\nshinobi sync init ~/shinobi-sync main\n\n# Push from the writer machine:\nshinobi sync push\n\n# Pull on the reader machine:\nshinobi sync pull\n```\n\nThe DB file lands on the `main` branch as a binary; pre-existing local DB is backed up to `<path>.bak-<timestamp>` before restore.\n\n## Configuration\n\nEdit `~/.shinobi/.env` or set env vars before running `shinobi mcp`:\n\n| Variable | Default | Purpose |\n|---|---|---|\n| `SHINOBI_DB_PATH` | `~/.shinobi/shinobi.db` | SQLite location |\n| `SHINOBI_CONFIG_DIR` | `~/.shinobi` | Config + plugins directory |\n| `SHINOBI_PLUGINS_DIR` | `${configdir}/plugins` | Plugin discovery directory |\n| `SHINOBI_DASHBOARD_PORT` | `8765` | Dashboard port |\n| `SHINOBI_DASHBOARD_HOST` | `127.0.0.1` | Dashboard bind host. Loopback skips auth; non-loopback auto-enables token auth. |\n| `SHINOBI_DASHBOARD_TOKEN` | _(auto)_ | Override the dashboard token; auto-generated to `~/.shinobi/dashboard-token` when needed. |\n| `SHINOBI_EMBED_PROVIDER` | `none` | `openai` / `voyage` / `ollama` / `none` |\n| `SHINOBI_EMBED_API_KEY` | — | Auth for OpenAI / Voyage (else falls back to `OPENAI_API_KEY` / `VOYAGE_API_KEY`) |\n| `SHINOBI_EMBED_MODEL` | provider default | Override model id |\n| `SHINOBI_EMBED_DIMS` | provider default | Override dimensions |\n| `SHINOBI_OLLAMA_URL` | `http://localhost:11434` | Ollama endpoint |\n| `SHINOBI_MIGRATIONS_DIR` | `<package>/migrations` | Override migrations source |\n\nFull reference: [docs/configuration.md](docs/configuration.md).\n\n## Plugins\n\nWrite a single `.js` file in `~/.shinobi/plugins/`:\n\n```js\n// ~/.shinobi/plugins/my-plugin.js\nexport default function register(registry, api) {\n  registry.registerTool({\n    name: 'plugin_count_open',\n    description: 'Count open decisions across all projects',\n    inputSchema: { type: 'object', properties: {}, additionalProperties: false },\n    handler: (_args, api) => {\n      const projects = api.listProjects();\n      let total = 0;\n      for (const p of projects) {\n        total += api.listDecisions({ projectId: p.id, status: 'open' }).length;\n      }\n      return { open_decisions: total };\n    },\n  });\n}\n```\n\nRestart the MCP client and `mcp__shinobi__plugin_count_open` is available. See [docs/plugin-development.md](docs/plugin-development.md).\n\n## Roadmap\n\n- **v0.2** — remote MCP foundation: stateless HTTP `/mcp` endpoint,\n  Docker + GCP Always Free deploy, Cloudflare Tunnel, env-driven `.mcp.json`\n  for cloud sessions. One brain across laptop, cloud, and mobile.\n- **v0.3 (current)** — autonomous agents: push notifications (task-completed /\n  agent-blocked) → dispatch loop (headless agent pulls `next_task` and works\n  while you sleep) → Shinobi Swarm (N parallel agents, worktree isolation,\n  shared dead ends), plus `ingest_findings` (audit → subtask graph → swarm)\n  pulled forward from v0.4.\n- **v0.4** — unit-test coverage pass on `tools/*`; richer remediation templates\n  and finding-source adapters on top of `ingest_findings`.\n- **v1.0** — stability, security audit, performance pass; optional team mode /\n  hosted SaaS only on demand signal.\n\n## Changelog\n\nSee [CHANGELOG.md](CHANGELOG.md) for release notes.\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md). Issues and PRs welcome.\n\nBy participating you agree to our [Code of Conduct](CODE_OF_CONDUCT.md).\n\n## Security\n\nFor vulnerability reports, see [SECURITY.md](SECURITY.md) — please do\n**not** open public issues for security matters.\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n",
  "bytes": 16712,
  "sha": "160b64a08e0674766444cf382814a3af4940cdc64cb5b15ab2c4cdf265d1f052",
  "repo_slug": "numbererikson/shinobi",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_numbererikson_shinobi_1aa44147/readme"
}