Comments about Wayfinder

[TimHoogervorst]

Hi All,
I was wondering what we find of the new skill Wayfinder, As for me this skill does not really do anything for me, but maybe i am missing something, or using this the wrong way.

In short, i really liked the design of Grilling -> Spec -> Issues/Tickes -> implemeting,

Grilling made me feel confident about the implementation steps, how and what we are implementing
Specs made me feel confident about what it understood about the grilling and made sure we alligned during the implementation
Tickets/Issues made me feel confident about not blowing my context window with implementating the steps above
And then after all, implementing along with the /review made sure we allign with the steps above

Wayfinder however, made this first step kinda awkward, it never really created any prototypes or research tasks, it mainly defaults to wayfinder/tasks for me, which i then need to awkwardly babysit these steps (not using any automated features, like sandcastle or others, so maybe that is just an me issue). With the grilling i had an pretty confident workflow, work on the next grilling section, review specs, or PRs, while it was implementing the features for me during. But i cannot seem to find this with wayfinder, as getting to the spec docs, now requires a lot more babysitting, and a lot more tokens.

Maybe it is also an getting used to it? since i got pretty comfortable with the grilling sessions, and usually got arround 20 Questions to an spec, pretty comfortably.

Using claude code with Deepsek V4 Pro.

Wondering if more people have the same issues, or other opinions about this new new skill

[John-Ridgway]

I myself am trying to find a good way to flow with wayfinder, it did a fantastic job creating wayfinder tasks that encompass what I want to accomplish, but the step after that is what I'm fuzzy on, do I /implement "resolved" wayfinder tasks? Do I /to-spec em then triage then implement?? It's not really clear to me. It's a beautiful planning tool, just not sure what to do with all the tasks it created that are simply design descriptions and not really plans of action.

[TimHoogervorst]

I think you need to iterate with /wayfinder over the map, till all the tasks are complete. They then get slowly added to the decisions, which then after you can /to-spec it go into an spec.

Which is quite an fine workflow, some epics require more research or prototyping, so epics that are outside of the scope of an grilling session.

I think there should be an way to bring this more into control of the user, maybe after the first wayfinder it will present all its findings, and then the user can decide which decisions are already fine, and which ones require more research, grilling or more prototyping. And i do believe this wayfinder expects you to run the agent in the background with some control, as all the wayfinder tasks can just be performed without the user.

[John-Ridgway]

After sleeping on it, this is kind of what I arrived at this morning. I'm letting wayfinder just resolve every task it made for itself, and then I'll make specs out of em.

[muse83]

I am now working with Wayfinder on my second project, and I have noticed a few things:

1. The scope of individual tickets is not defined precisely enough. Claude has repeatedly addressed aspects within a ticket that were actually intended to be handled in a later ticket.

2. Some of Claude’s summaries are difficult to follow, especially in the later stages of a project. Based on the context.md file and the project documentation, Claude gradually develops its own style of referencing previous work. Over time, these explanations become almost impossible to understand, for example: “Codex just asked me 200 questions #44 mentioned … because Grill-me skill improvement #12 showed …”

I added a note about this to the CLAUDE.md file, after which the analyses and explanations became understandable again. However, this might be something that could already be defined directly within the skill itself.

[TimHoogervorst]

Could you share what you’ve added in the Claude.md? Curious to see.

I’m still staying away from wayfinder, and exclusively use grill me, I do however see now more and more gaps with grill me, as this really is a one trick pony. Using it in any way outside its current scope introduces a lot of complexity. I think I will try wayfinder a bit after I automated the ai stuff a bit more with other tools.

[muse83]

Until now, I had handled this through a Markdown file in /memorys. I have since moved the instruction into my global CLAUDE.md file:

• Findings, ticket results and grilling sessions must be followable for me as
  the one steering the project: no code identifiers, formulas, statistical
  notation or bare ticket numbers. Name a ticket/issue by its subject, not its
  number; give every figure its consequence. Exact numbers and code paths go
  in the repo, the tracker and the commit.

  ...but this configuration with the global CLAUDE.md must be tested first. The results with the .md in /memorys was working fine.

[timtody]

Anyone with a tag reading "for real X" on their site should be ignored. Wayfinder adds no real context or proper form to skills so sure it might be fun but probably useless.

[ecc-parity-check]

Oh, in my opinion the wayfinder is really good. It splits complex topics into smaller pieces and you can grill each of them separately.
Please keep in mind that the context size is what we need to monitor.
If we want good results we need to "handle" larger tasks in smaller parts, each of them in a separate session.
And this is what the wayfinder does.

[John-Ridgway]

I've found it to be really good at catching the things you overlooked. "Oh I want this, should just be a couple files" wayfinder: "Have you considered this dependency you're gonna need? Here are three options we can explore.." type deal.