Getting started

The real CLI loop for making decisions without leaving your editor, and how it flows outward to your whole team.

What is decide?

Decide is an IDE for the decisions behind your software. It lives in your repo as a set of plain-text decision files — markdown that describes what you chose, why, and what code it governs. Every team member can read every decision. The CLI integrates into the loop you already run: plan, check, build, capture, and review.

No hosted dependency. Decisions stay in your repo alongside your code. The web surfaces at decide.golbi.ai are documentation and tooling — your store is yours.

Install

The CLI is a single binary with no runtime dependencies. Run the install script or grab a binary from /install.

Linux & macOS
$ curl -fsSL https://decide.golbi.ai/install.sh | sh

On Windows, use the PowerShell installer. Both scripts verify the binary checksum and place decide on your PATH.

Windows (PowerShell)
PS> irm https://decide.golbi.ai/install.ps1 | iex
Want a guided setup? Head to /install for platform-specific instructions, verification steps, and troubleshooting.

The inner loop

This is the tight loop you run as you build. It takes seconds, not meetings — you check the store, log your reasoning, and capture the call without leaving your editor.

1. Seed the store

Every repo that uses decide starts with a decision store — a .decide/ directory that holds your config and decision files. Run decide init to create it. On an existing repo, decide onboard seeds the store and walks you through capturing the decisions already embedded in your codebase.

decide init
$ decide init
created .decide/config.yaml
store ready at .decide/
decide onboard (existing repo)
$ decide onboard
scanning repo for existing decisions…
found 14 potential decisions across design docs, ADRs, and commit messages
seeded 14 provisional decisions — review with decide capture

2. Check before you work

Before you start a non-trivial task, run decide check. It searches the store for decisions relevant to what you are about to build, flags conflicts with what is already settled, and surfaces gaps — areas with no coverage where you are about to make an implicit choice.

decide check
$ decide check "add access-token refresh to the auth module"
3 relevant · 1 conflict · 2 gaps
relevant:
· sessions-in-a-signed-cookie (current, governs internal/auth)
· token-lifetime-is-15-minutes (current, governs internal/auth)
· no-silent-refresh-in-v1 (current, governs internal/auth)
conflict:
· no-silent-refresh-in-v1 — adding a refresh loop contradicts this
gaps:
· No decision covers refresh-token storage strategy
· No decision covers refresh-token rotation policy

Each result links back to the decision file in your repo. Relevant decisions are context you build on. Conflicts are calls that need reconciling before you proceed. Gaps are new ground — worth recording.

3. Log your reasoning

As you work, use decide log to record the choices you make. Each entry is plain text — a note about what you decided and why. These entries feed into decide capture later, so nothing gets lost between the moment of decision and the moment of writing it down.

decide log
$ decide log "We will store refresh tokens in an httpOnly cookie, not localStorage. This keeps them out of JS reach and matches the existing signed-cookie session pattern."
logged — 1 entry recorded

You can call decide log as many times as you need during a work session. Entries are collected until you run capture.

4. Capture the call

When your work is done, run decide capture to reconcile your session with the store. It analyzes your code diffs and log entries, creates new decision files, and updates existing ones where your work edits, supersedes, or deletes prior decisions.

decide capture
$ decide capture
analyzing diffs and log entries…
created decisions/refresh-token-storage-in-httponly-cookie.md
created decisions/refresh-token-rotation-on-each-use.md
superseded decisions/no-silent-refresh-in-v1.md
3 decisions captured — run decide dr to validate
Pro tip: Run decide status at any point to see whether you have pending checks or logs that have not been captured yet. It is a quick pulse check before you commit.

The DDD loop: decisions flow outward

The inner loop is personal — it is how you decide as you build. The outer loop is how those decisions flow to your team and to CI. Design Driven Development means decisions are part of the codebase, governed and validated like everything else.

PR review with decide

Open a pull request and decide review checks your changes against the store. It reports which decisions are honored, where conflicts exist, and what new ground your diff is quietly deciding. The analysis links each finding back to the decision file and the affected code, so reviewers see the blast radius before they merge.

decide review
$ decide review
base: main · diff: 3 files, +47 −12
honored (4)
· signed-cookie-sessions — token handling unchanged
· token-lifetime-is-15-minutes — lifetime preserved
· refresh-token-storage-in-httponly-cookie
· refresh-token-rotation-on-each-use
conflict (0)
gap (1)
· No decision covers token revocation on logout

Use decide review in CI to flag unreviewed decisions before they merge. It is an automated gate that keeps the store honest.

Validate the store

decide dr checks every decision file for structural integrity — required fields, valid status values, consistent filenames, and dangling references. Run it as a pre-commit hook and in CI.

decide dr
$ decide dr
14 decisions valid — no structural errors

Agent tooling: MCP

decide mcp runs a Model Context Protocol server that exposes decide tools to AI coding agents — Claude, Cursor, Copilot, and any MCP-compatible client. Agents can check decisions before generating code, log reasoning as they work, and capture decisions at the end of a session. It turns your decision store into shared context the agent reasons from.

decide mcp
$ decide mcp
MCP server listening on stdio
tools exposed: check, log, capture, dr, review, status

Add it to your agent’s MCP config and every code generation session starts with a check against the store. Decisions become a constraint boundary the agent respects.

Beta. MCP support is in active development. Expect tool coverage and agent-specific guidance to expand as the protocol matures. Join the discussion on GitHub.

Next steps

  • Install the CLI/install walks through platform-specific setup, shell completion, and verification.
  • Read the decisions — The decide repo is governed by its own store. Browse the decisions/ directory to see real decision files in action.
  • Try the web apphub.golbi.ai is the hosted surface for browsing, reviewing, and collaborating on decisions. Free during early access.
  • Follow the changelog/changelog tracks CLI releases and breaking changes.