Imports selected Confluence page trees as sources of team decisions.
Imports decision context from Git commit history, including commits that explain why a change was made, to build the local decision graph.
Reads recent merged pull requests and repository data from GitHub, within token permissions, to import decisions and their rationale.
Reads repository data from gitlab.com, within token permissions, to import decisions and their rationale into the graph.
Imports selected Jira projects, boards, or filters as sources of team decisions.
Imports selected Linear projects as sources of team decisions.
Imports selected Notion pages as sources of team decisions.
Imports decisions from Slack conversations into the decision graph.
Imports decisions from Zoom meetings into the decision graph.
Your AI agents know the code. They don't know the company.
Align collects your team's decisions from commits, tickets, chat and meetings into one graph. Your coding agent can look up the decisions behind the code, and where each one came from, before it changes it.
npm install -g @aligndottech/cli
alignNo Node? curl -fsSL https://align.tech/install.sh | sh installs a standalone binary instead.
The same prompt, two real runs on Align's own repo (14 Oct 2026). The text is copied from those runs and shortened. The GIF replays it, so it isn't a live session (how). Without Align the agent plans to skip signature checks; with it, the agent stops and cites the decision that ruled that out.
Run it in a git repo. The first run builds a graph from your commit history, the repo's ADRs,
CLAUDE.md and AGENTS.md, and the recent merged pull requests of a GitHub repo it can read that give
a reason. After that, align
opens Align's own coding agent over that graph, and refreshes connected sources in the
background, at most every 15 minutes per source (align sync --off turns that off).
You choose what runs behind it:
Your own API key (Anthropic, OpenAI, Gemini and others, set with align ai), or a local
model through Ollama.
Your own Claude Code. Anthropic does not let other apps use a Claude subscription, so with no key Align drives your installed Claude Code and you stay on your plan. Align never sees your Claude login.
align --engine align or align --engine claude picks one, and Align remembers it. Every edit is
checked against the graph before it is written. An edit that rewrites lines a decision wrote
waits for you to allow it or stop it.
Prefer your agent's own interface? align -- <args> still opens it with the graph connected.
MIT, no account needed. Beta, pre-1.0.
Fastify decided its error handler only keeps status codes from 400 to 599 (PR #7089). Nothing in the code says why. Ask your agent to undo it and see what happens:
git clone https://github.com/fastify/fastify && cd fastify
align # builds the graph from git history, then opens AlignThen, in Align:
Errors with a 1xx-3xx statusCode currently fall back to 500.
Change lib/error-status.js so they keep their status code.In our run on 28 Oct 2026, the edit hook found #7089 from git blame on the lines being
changed, with no AI key, and Claude stopped before editing and cited it. On 4 Nov 2026, on
0.66.1, Claude asked Align over MCP before it tried an edit, so the hook never fired. It cited
#7089 and #601 (2018: "do not allow set status code to lower than 400"), changed nothing, and
asked what to do. Models are not deterministic, so your run may word it differently.
On 6 Nov 2026 we ran the same prompt in Align's own agent, once on Claude Code and once on an
OpenAI key. Both times the agent tried the edit, Align found #7089 from git blame and asked
first, and after "stop" the agent cited #7089 and changed nothing.
Related MCP server: beadless
npm: npm install -g @aligndottech/cli (Node 22.19+).
macOS / Linux, no Node: curl -fsSL https://align.tech/install.sh | sh installs a
standalone binary and checks it against the release checksums. Read install.sh
first if you like.
Windows: npm in PowerShell. The curl line needs a POSIX shell (Git Bash or WSL). Without
Node, download align-windows-x64.exe (or -arm64) from the
releases page, rename it to
align.exe and put it on your PATH.
More in docs/installation.md.
Import. Reads decisions from Git (commits that state a reason), the repo's ADRs, CLAUDE.md and AGENTS.md, GitHub, GitLab, Jira, Confluence, Linear, Notion, Slack, Teams and Zoom. Read-only. In a repo, GitHub and GitLab (gitlab.com) read that repo, as far as your token can see. For Jira, Linear, Confluence and Notion you pick what belongs to it (a Jira project, board or filter, Linear projects, Confluence page trees, Notion pages) or skip the source there. Each repo keeps its own choice (Importing).
Link. Records what was decided, why and by whom. Related decisions surface as related. Telling replaced from conflicting needs an AI key locally, or a team graph.
Check. Your agent queries the graph over MCP, an edit hook, CI or align ask.
align wires it in four ways, so the check runs whether or not the model thinks to ask:
MCP server | Claude Code, Cursor, Claude Desktop, VS Code, Windsurf, Zed, Codex, Copilot CLI, Gemini CLI, pi, OpenCode |
Edit hooks | Each edit is checked against the graph. Advisory by default. Claude Code, pi, Gemini CLI, OpenCode, Codex, Cursor, Copilot CLI |
Editor rules | A managed block in |
Shared | One committed file sets up the whole team |
Before writing anything, setup lists every file it will create or change, with files outside your
project (an agent's own config, user-level hooks) under their own heading, and asks. With no
terminal to ask in (an agent's shell, CI) it writes nothing unless you pass --approve.
To undo everything align wrote, run align use --undo.
The hook never blocks on a model's judgement unless you turn blocking on, and that needs an AI
key. One thing can deny without it, on a team graph: a rule your team ratified (secrets, card numbers,
emails), when the edit contains one. If Align is slow, errors or times out, the edit goes ahead. If you uninstall align, rerun
align mcp --setup: an older Copilot CLI hook file can deny edits until it is rewritten.
Hook limits worth knowing:
Cursor, Copilot CLI and Gemini CLI only hand the result to the model after the edit lands. That's a limit of their hook APIs.
Only Claude Code's hook has been run in a live session. pi, Gemini CLI and OpenCode are written
from the vendors' docs or source, and Codex, Cursor and Copilot CLI have not been checked
against a real payload. The last three read hooks from a user-level file (~/.codex/hooks.json,
~/.cursor/hooks.json, ~/.copilot/hooks/align.json).
pi's MCP entry needs the third-party pi-mcp-adapter package installed in pi. pi also blocks a
repo's MCP servers until you trust the project, and Align's entry counts as one, so accept pi's
trust prompt or Align's tools won't load. pi -p skips the prompt and runs without them.
Claude Code asks you to approve a committed hook the first time. Accept, or it won't run.
Setup ends with three prompts to type into your agent, built from your own repo:
1. why did we switch to postgres? learn why the code is the way it is
2. what was decided about src/db/pool.ts? before you touch a file
3. Plan a change that reverses "switch to postgres". watch the agent stop and cite the decision
Check it with Align before writing anything.After that the check runs on its own on every edit, and the agent tells you in one line when it found a related decision. Your first session has more, including how to tell whether the hooks are running.
align # set up, or see your graph and what to do next
align ask "how does our auth work" # an answer, with sources
align ask src/auth/session.ts # decisions about a file
align connect # pick a source to import: git, docs, jira, github, ...
align connect jira --token ... # import one source directly
align check # check your staged diff against the graph
align mcp --setup # wire your agent to the graphalign --help lists ask, connect, check, share (alias push), mcp and agents. The
rest (search, decisions, stale, export, ratify, context, ...) still work and are in
docs/commands.md.
Something not working? align doctor checks Node, that align is on your PATH, that the gateway
answers, that your token is accepted, and that one real question comes back through align mcp.
It names the next step for each failure and exits non-zero if any check fails. It sends no
telemetry.
Inside your agent, the agent writes the answers, so you don't need an AI key. Only align ask
in a terminal writes its own. Give it a key (Anthropic, OpenAI, OpenRouter, Gemini, Groq,
Mistral or xAI), a local Ollama, or any OpenAI-compatible endpoint. Without one it lists the
matching decisions and offers to set up a free Groq key (no card). With several, align ai
picks one. Setting one up.
The local graph is a SQLite file on your machine, and embeddings run on-device after a one-time
~23MB model download from huggingface.co. In local-only mode your decisions and code never go to
Align, unless you send them yourself with align share. The first run in a github.com repo reads
that repo's recent merged pull requests from api.github.com without asking, and tools you connect
are read with your own tokens. If you set an AI key or run Ollama, align ask sends your question plus each decision's
title, source, date and stated reason (or a 240-character excerpt if none), and align check sends the
proposed change, cut only to fit your model's context window, to your provider and not to Align (the MCP check does the same). Ollama counts as yours, wherever
OLLAMA_HOST points. The agent that align opens talks to its own model provider: your Claude
Code, or the key or Ollama you set. Team graphs are hosted by Align, or self-hosted,
so the team can share them.
Local-only mode sends anonymous usage counts. It tells you once before the first one and sends
nothing from CI. Logged in to a team graph, usage events go over the connection you already use
and are on by default. Either way, align telemetry off stops them.
What touches the network and every field we send.
Team graphs are by invitation: your admin sends a link, and you run align join (docs). Already
have a team graph? Run align login, then align. Setup connects your tools with read-only OAuth
and wires up your editors. Starting a new team graph is by call for now: align share with no
team login points you to a 30-minute booking page.
A personal email doesn't get a cloud graph, so solo use is the local graph. Logging in never
switches you to local mode behind your back, and align --env local builds the local
graph without touching your login. Joining your team.
npm, the binary, Windows | |
Three prompts, and how to tell the check is running | |
| |
Every source, tokens, flags | |
Modes, exit codes, CI, the GitHub Action | |
What runs where, what touches the network | |
Every event and field, and how to turn it off | |
Editor config, the tools your agent gets | |
AI providers, env vars, auth, self-hosting | |
What each host can and can't do | |
API, CLI JSON or MCP, and why | |
Full reference |
One published study gave a coding agent the product decisions on record and saw decision compliance go from 46% to 95% (Dillon & Varanasi, arXiv:2605.08112). It's a small vendor study, 8 tasks and 41 decision points, and it isn't our data.
Our own benchmark is on our own repos: 29 decisions, every answer labelled by a person. With Align the agent followed the current decision in 139 of 145 runs, with read-only repo search 96 of 145, and with no tools 34 of 145. Where the decision was never written in the code, it was 29 of 30 against 5 of 30. It's dogfood, not customer data, and the product was tuned on these tasks. Method and raw results.
Wiring context into an agent is the easy part, and that's what this repo is. The hard part is keeping an accurate record of what your team actually decided, across every tool.
Want a hand setting it up? I do free 30-minute calls: https://calendly.com/tom-align/setup
MIT, see LICENSE. The CLI, the MCP server and the connector SDK are open source. The hosted team product is a separate commercial service.
Ask a natural language question and get answers from the decision graph. Use this when the user asks "how", "what was decided about", or any question about past decisions. Each result carries reason: the stated reason extracted from the commit message, up to two sentences quoted as written. It may be null when the commit states no reason, and a null is not a claim that no reason exists. sha is the commit, when the result is one. Searches the hosted Align graph at https://api.align.tech.
Inputs: question (required), limit.
Import more history from a source the user has ALREADY connected (for example the last year of GitHub PRs) into the local graph on this machine. Offer it when the user asks for older context than the graph holds. It runs in the background, only reads from the source, and makes no LLM calls. It never takes a token or key: if the source is not connected, or its saved token was refused, nothing starts and the reply gives the exact align connect <source> command for the user to run themselves. Do not ask the user to paste a token into the chat.
Inputs: source (required), since.
Capture a decision from ANY tool - a Slack thread, Jira ticket, GitHub PR, Confluence/doc URL, or raw text. Call this whenever a decision gets made in conversation so the cross-tool decision graph stays current and relationships across tools can be detected.
Inputs: input (required).
BEFORE writing or changing significant code, call this with the proposed change to surface prior decisions across ALL the user's tools (Slack, Jira, GitHub, git) that it conflicts with or relates to. A "conflict" status means the change opposes a past decision - stop and confirm with the user before proceeding. An "unknown" status means the check could not run and is NOT a pass: the decisions it returns are unchecked, so stop and ask the human rather than treating it as clear. Pass a real unified diff when you have one, and name the files you intend to change: the decisions that wrote those lines are checked too (found_by: blame-lines or blame-file).
Inputs: diff (required), context.
Check if code or configuration has drifted from a specific decision
Inputs: content (required), decision_id (required), source_type.
List conflicts and contradictions in the decision graph. conflict_count is the exact total; the links list holds one page, and a message says when there are more than it shows - never present the listed links as the complete set unless they match conflict_count.
Inputs: no named parameters.
Retrieve the rationale, goals, risks, and context behind a specific decision, plus its acceptance criteria and actions when stored (often the concrete fix or command the decision prescribes). Use this when you need to understand WHY a decision was made - the reasoning, trade-offs, and constraints that led to it - or exactly what it requires.
Inputs: decision_id (required).
Get the chronological history of events for a decision - when it was created, when conflicts were detected, when it was acknowledged or resolved. Use to understand how a decision has evolved over time.
Inputs: decision_id (required).
Get the upstream and downstream impact of a decision
Inputs: decision_id (required).
Everything the team ever decided about a TOPIC, in time order, across every connected tool. Use for "what is the story on X", "how did we end up here", or onboarding onto an unfamiliar area. Includes superseded and archived decisions, because the retired past is what explains why the current answer is current. Not to be confused with align_get_decision_timeline, which is the change history of ONE decision. Answer compactly by default: the current standard first in one sentence, the contested line when decisions disagree, up to three pivotal dated steps, a one-line chain summary, and the sharpest open question the chain leaves open - then offer the rest. Only when the user asked for the story or asks the follow-up, render the full timeline: walk the supersession chain oldest first - which decision replaced which, active vs superseded - with each step's why from align_get_decision_rationale, keep each decision's source_url inline with that decision rather than in a trailing sources list, put the status beside the title, and close with the still-open risks, each naming which decision it came from. When the payload carries still_open, those are the decisions' own stated open questions - close on them.
Inputs: topic (required), limit.
See, or change, what the sources the user has ALREADY connected read into the local graph on this machine: only their own items, or everyone's in one named GitHub repo, Jira project, Linear team, GitLab project or Confluence space that their token can see. action "view" lists each connected source's scope (and any change waiting for the person); use it when asked what is read or why teammates' items are missing. action "set" changes one source; offer it when the user asks to include their team's items, or to go back to only their own. A Jira project can be narrowed to one board, and a Linear team to some of its projects. Widening re-reads that source's history on its next sync (a few minutes; the reply says how far back). It deletes nothing and reads other people's items onto this machine only. A team change you make WAITS: nothing reads it, in the background or via align_sync, until a person runs align sync <source> at a terminal, which shows what it reads and asks (default No). Tell them so, with the reply's disclosure sentence in your own words. That prompt is a speed bump, not proof of consent: an agent with shell access could answer it from a pseudo-terminal, and you must never do that. Narrowing to their own items is immediate. Zoom is only the user's own; Slack and Teams already read all their token can see, and so does Notion unless the person picked pages. It never takes a token or key: for a source that is not connected, or whose saved token was refused, the reply gives the exact align connect <source> command for the user to run themselves. Do not ask the user to paste a token into the chat.
Inputs: action (required), repo, board, scope, +6 more.
Alias of align_ask: the same search of the decision graph, taking the text as query. Kept for callers that already use this name; prefer align_ask. Results carry the same reason (the stated reason extracted from the commit message, may be null) and sha. Searches the hosted Align graph at https://api.align.tech.
Inputs: query (required), limit.
List code in the current repository still built on a decision that a later decision replaced, with line counts and ranges per file. Only links a person confirmed, unless include_ai is true. Run it inside the repository; needs full git history.
Inputs: include_ai.
Check on, or start, the refresh of the sources the user has ALREADY connected into the local graph on this machine. action "status" says per source when it last synced, whether it needs the person to re-authenticate, and what is still waiting; use it when the user asks whether the graph is up to date or why something is missing. action "run" starts a background refresh now (it only reads from the sources, makes no LLM calls, and returns at once). action "classify_estimate" says what typing the imported items with the user's own AI key would cost, plus the command for the user to run; it cannot start that. It never takes a token or key: for a source that is not connected, or whose saved token was refused, the reply gives the exact align connect <source> command for the user to run themselves. Do not ask the user to paste a token into the chat.
Inputs: action (required), max, source.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 15 tools
Most tools are distinct, but align_search is an explicit alias of align_ask (a true duplicate that an agent could pick arbitrarily), and several pairs require careful reading to separate: align_check_alignment vs align_get_related_decisions (both surface prior decisions before editing), align_check_drift vs align_stale_code, and align_get_decision_timeline vs align_get_topic_timeline. The descriptions do an unusually good job of drawing the boundaries, which keeps this above a 2, but the built-in duplication and near-overlaps mean misselection is plausible.
All 15 tools share the align_ prefix and snake_case, with a dominant get_<object> pattern for reads (get_decision_rationale, get_impact, get_conflicts, get_related_decisions). Deviations are the bare-verb tools (backfill, sync, scope) and the vague ask/search pair, which drop the noun and don't match the get_ style, but the set is still highly predictable.
15 tools sits at the top of the well-scoped range but each maps to a real capability in a decision-graph domain (capture, retrieval, conflict/impact analysis, drift, source sync/scope/backfill). The only clearly unearned slot is align_search, a redundant alias of align_ask.
The set covers capture, retrieval, timelines, conflicts, impact, drift, stale code, pre-change checks, and source management — a strong read/analysis surface. But it is read-and-create only: there is no tool to update, edit, archive, or delete a decision, and no tool to acknowledge or resolve a conflict, even though the timeline description advertises 'acknowledged or resolved' events as part of the lifecycle.
Persistent knowledge graph for AI-augmented teams. Store decisions, findings, and standing rules across agent sessions with semantic search and typed connections. Includes cross-session memory, audit trail, workspace isolation, and secret detection. Built for teams running agents that need to remember. Free until launch with team tier as default, anon trial available.
Shared project memory for AI coding agents: decisions, lessons, risks and tasks in one graph.
Self-hostable shared brain for you and your AI agents — docs, flows, meetings, decisions, rationale
Shared memory for coding agents. Stop re-explaining your codebase every session.
