noggin

Items form a tree. There is at most one active item; the path from a root to the active item is your current spine. Other open items are paused. Done items stay in the tree so you can see what got finished.

[1📍] ship v1 of noggin
  [1✅] build a demo script
  [2✅] create a documentation file
  [3] perform final testing
  [4] create a PR
  [5] complete the PR

Quick taste

$ noggin push "ship v1"
$ noggin add  "write the README"
$ noggin push "wire up tests"        # side-quest under ship v1
$ noggin note "tried jest, going with node:test"
$ noggin pop                         # finish the side-quest, back to ship v1
$ noggin show
[1📍] ship v1
  [1✅] wire up tests ✏️
  [2]   write the README

The CLI is the source of truth. Everything else — VS Code extension, agent plugin, MCP server — wraps the same verbs.

Where noggin runs

The four experiences:

• Sidebar UI — the noggin tree with drag-and-drop and a details pane with inline-editable notes. VS Code adds a status bar item for the active item; the desktop app adds a sidebar that can list more than one noggin at once. Both share the same @noggin/ui components, so the interactions are identical.
• Agent skill — the behavioral guide (SKILL.md) the LLM reads to decide when to push, add, note, etc. Loaded automatically wherever skills are supported.
• Agent tools — the verbs exposed to the LLM as tools so it can invoke them directly. The VS Code extension uses in-process language-model tools; every other host uses the stdio MCP server.
• Bare CLI — noggin push, noggin show, etc., in any terminal. Always available; the YAML file is the source of truth.

Explore