Skip to content
riggerrigger

note

rigger note <PROJECT> <TEXT> [--kind <KIND>]
rigger wish <PROJECT> <TEXT>

Records an event against a project. This is how the record grows during a session, instead of by editing markdown afterwards. An assistant does the same through the MCP server; this is the door for the owner and for scripts.

Terminal window
$ rigger note sample "The parser must take hubs as they are." --kind finding
Recorded a finding for sample


$ rigger note sample "Ship the importer next." --kind next
Recorded a next for sample

Kinds

Section titled “Kinds”
Kind What it is for
decision a decision and the reason behind it
finding something learnt about the code or the domain
pitfall a trap worth remembering
change something that changed in the product
next the one line the next session starts from

finding is the default. Decisions, findings, pitfalls and changes appear under Recent in the context packet; the newest next becomes its Next step and is not repeated among the events.

A question is not a kind here: questions are addressed to the owner, and they arrive from the hub or from an assistant calling ask_owner. Answering one is rigger resolve.

A change can also arrive on its own: rigger sync reads them from commit messages.

rigger wish

Section titled “rigger wish”

A wish is something to sort into the plan later, so it needs no kind:

Terminal window
$ rigger wish sample "Show how many days the project has gone without a commit."
Recorded a wish for sample

Wishes have their own section in the packet, and the same text recorded twice stays one wish - unlike a dated event, a wish is identified by what it says. Once a wish is in the plan, rigger resolve takes it off the list.

Section titled “Related”
  • context - where these events are read back.
  • mcp - the same recording, as an assistant’s tools.
  • resolve - closing a question or a wish.