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).

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.

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.

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.

Check if code or configuration has drifted from a specific decision

Get the upstream and downstream impact of a decision

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.

BEFORE editing a file or module, call this to learn what was already decided about it across all the user's connected tools (not just code) - surfacing the cross-tool context an agent would otherwise miss. To answer a question about why something is the way it is, use align_ask instead.

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.

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.

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.

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.

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.

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.

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.