Wayfinding with nitro agent tasks

A loose idea has arrived: too big for one agent session, and wrapped in fog, so the way from here to the destination is not visible yet. Wayfinding finds that way instead of charging at the destination. You chart a map in nitro agent tasks, then work its decision tickets (questions whose resolution is a decision, not slices of a build) one at a time until nothing is left to decide. Then you cut the implementation tasks that carry the result to the build. If nitro itself is not found, the CLI is not installed — stop and tell the user to install it: https://chillicream.com/docs/nitro/cli/installation. Do not attempt to install it yourself.

The destination varies per effort, and naming it is the first act: it fixes the scope every ticket is measured against. It is usually a feature or change ready to be cut into implementation tasks; it can also be a design or migration plan that those tasks then execute.

Core principles

• nitro agent is the only memory. Sessions die and compact; the workspace survives. Every decision lives in exactly one closed ticket; the map only indexes it. Standing preferences for the effort go to nitro agent memory, the workspace-wide store every agent here reads (see the nitro-memory skill); coordination with other sessions goes over nitro agent mail. Never rely on chat context for anything a future session needs.
• The board is the working memory, not only the record. A grill in progress lives on its ticket: every agreed point is a progress comment written before the next question is asked, and the map exists before the first question of an effort. Chat holds only the question currently on the table. A session that dies mid-grill is resumed from the ticket, not re-run.
• Plan, don't do. Each ticket resolves a decision. The pull to just build something is the signal that you have reached the edge of the map and it is time to hand off (see references/handoff.md). Nothing in a map's Notes section can license execution; building always happens in a separate session, from implementation tasks.
• One decision per session. Resolve one ticket, do the graduation pass, stop. Chaining into the next decision is how context quality degrades. Research tickets are the exception: nitro-research runs them as background subagents, in parallel, alongside the one decision.
• The map is an index, not a store. It gists and links; the ticket holds the detail. A session loads the map at low resolution and zooms into tickets on demand with nitro agent tasks show <id> --output json.
• Refer by name. In everything the human reads, call tickets by their title, with the id in parentheses: "Which export format? (bill-3f2.1)". A wall of bare ids is illegible.
• HITL tickets need the human. HITL (human in the loop) tickets resolve only through a live exchange; AFK (away from keyboard) tickets are driven by the agent alone. An agent that answers its own questions has broken the loop.

Command mechanics for tasks, mail, and memory live in the nitro-task, nitro-mail, and nitro-memory skills. This skill covers how they compose; the exact commands for each wayfinding operation are in references/operations.md.

The map