graphify
Graphify
A loose idea has arrived, too big for one agent session, and wrapped in fog. Chart a shared decision graph toward a named destination and work its decision tasks one at a time. These are questions whose resolution is a decision, not implementation slices. The graph consists of task records and blocking relationships; a rendered diagram is an optional view, not the graph itself.
The destination might be a specification to hand off, a decision to settle before planning, or an in-place migration. It shapes every task. This workflow fits engineering and other domains with the same decision structure.
Document and tracker contract
The project documents and their rules are in project-documents.md; its terms (authorized, obligation, lazy, pointer) apply throughout, and requirements constrain the destination and every decision.
Read the task tracker configuration that AGENTS.md points to for map storage, parent-child relationships, blocking, claims, and frontier queries. If it points to none, keep the graph local following local-graph.md, and tell the user so.
- A local map lives where the tracker configuration says, or as local-graph.md sets out without one; its decision tasks are capability task files.
- A remote map and its children use native tracker records and relationships.
- The capability's specifications hold the agreed living behavior, design, and acceptance; its draft holds open proposals. The map indexes decisions and each task keeps its rationale.
An explicit request to chart a map authorizes creating the map, its decision tasks, and their blocking relationships on the configured tracker. A request to work through the map authorizes claiming, resolving, and closing its tasks and updating the map. Ask before any remote change outside the named effort.