Decisions & search
Record the durable "why" behind your code, and find anything across your team's shared memory.
Decisions & learnings
A decision is durable, team-visible, and searchable forever — the rationale that's usually lost. Record one whenever you choose between alternatives or reject an approach.
stn decide "Use Postgres advisory locks for the job queue"
stn decide "..." --why "Redis adds a dependency we don't need yet; revisit at scale"
stn decide "..." --kind learning # decision (default) | learning
stn decide "..." --tag infra --tag queue # tags (repeatable)
stn decide "..." --team TEAM # defaults to your current team
stn decide "..." --supersedes 42 # revise an earlier decision (forms a chain)
List and review them:
stn decisions # a team's decisions, most recent first
stn decisions --tag infra --kind decision --mine
stn decisions --agent # only agent-authored decisions
stn decisions --pending # only decisions awaiting confirmation
stn decision show ID # one decision, with its full rationale
stn decision confirm ID # promote a pending (agent/auto-extracted) decision into the record
stn decision edit ID "new rationale" --title "new title" [--replace]
The agent review loop. When a coding agent logs a
decision, it lands as pending and is tagged with the agent's label. Review what your
agents recorded with stn decisions --agent --pending, then
stn decision confirm ID to make it part of the team's permanent record. Decisions
captured from Slack (via /stndp or a 📌
reaction) land here as pending too. A --supersedes chain is walkable with
stn graph path.
Search
stn search "retry policy" # search everything you can reach
stn search "..." --type decision # restrict to one kind (see below)
stn search "..." --team TEAM --since YYYY-MM-DD --limit 20
stn search "..." --keyword # exact-match only (default blends semantic ranking)
Search spans your team's shared memory — decisions, entries, your checkpoints, episodes and bugs — and, by identity, every other entity the platform tracks: repos, branches, work items, files, people, teams, and more. It's great for absolute-identity lookups too ("hydra service", a Jira key, a file path). Each hit is shown with its connected context — linked tickets/PRs and graph edges such as a supersession chain — beneath it.
--type accepts any entity kind the server returns, including decision,
entry, checkpoint, episode, bug,
repo, branch, directory, file,
workitem, user, and team. By default results blend semantic
ranking when the server has it enabled; --keyword forces exact matching.