When wayfinder creates ready-for-agent tickets (Implement or Triage?)

[gregg-stcu]

When you run wayfinder and it creates a number of "ready-for-agent" issues, is the next step to run triage against these issues before implement? It seems that this has provided me better results, but there is a needs-triage label that wayfinder didn't use when creating the issues. Am I lighting tokens on fire? or should these really have been needs-triage first?

[yhay81]

You should not run generic triage on those tickets, and you should not send them straight to implement either. ready-for-agent means they are on Wayfinder’s current decision frontier: open, unblocked, and unclaimed, so a Wayfinder session may pick one up and resolve the decision.

That distinction is explicit in the current design:

• Wayfinder plans; it does not implement: its tickets are questions/decisions, not build slices.
• Each ticket already has its Wayfinder classification—wayfinder:research, prototype, grilling, or task—and the unblocked/unassigned children are the frontier.
• The prescribed next step is to invoke Wayfinder with the map (optionally naming a ticket). It selects the first frontier ticket, claims it, resolves it, records the decision, and closes it: Work through the map.

So the practical loop is:

/wayfinder <map URL>        # resolves one frontier decision
/wayfinder <map URL> ...    # repeat until no decisions/fog remain
/to-spec                    # turn the cleared route into a spec
/to-tickets                 # slice the understood plan into build work
/implement                  # execute those build tickets

The absence of needs-triage on Wayfinder-created issues is therefore expected. That label is for ordinary intake whose disposition is unknown; Wayfinder has already created a typed child ticket, linked it to a map, and wired its blockers. Running triage again mostly re-reads and reclassifies an artifact that already has a lifecycle—so yes, in the normal case it is extra token spend.

Use triage only as a repair step if a ticket was created outside Wayfinder or is malformed (for example, not a child of the map, missing its wayfinder:<type> label, or not actually phrased as a decision). Better triage results may have been masking one of those setup defects; the correct fix would be to repair the map/ticket metadata, not to add a mandatory triage pass.

One nuance: a wayfinder:task may perform manual work, but only to unblock a decision. It is still not a destination implementation ticket.

[gregg-stcu]

Amazing, thank you for the thoughtful response.