I built a variant of @mattpocockuk's grilling skill dedicated to frontend and it has improved how I build new apps and components.
The general idea:
1. Use /grilling and /prototype as a base
2. Tell Claude to build 5 WILDLY different prototypes
3. Tell Claude to include a picker that lets you switch between each variant live
4. Each round you select your favorite(s) + leave feedback, and Claude will walk down each branch of the design tree, helping you zoom in on your desired design
And THEN, I went and added it to /wayfinder, so whenever I make a new map and there's novel frontend work, a ticket is created specifically referencing that /grilling-frontend-prototyping needs to be invoked.
This will not be the last time I build a cool skill and add it to Wayfinder; this is a very powerful pattern for planning work.
You can find my skill here: https://t.co/4M4QPlfnp1
Hard to say. Maybe they keep it cheap for small volume users forever for the same reason that so many providers (Vercel, Mongo, etc..) keep their services cheap. But.. I think that an indie dev on a $200/mo plan costs Anthropic way more money than an indie dev on a free Mongo DB does.
Interesting theory!! The output could be an HTML artifact that implements the "If you answered A, don't do section D" logic.
For the 'during meeting' scenario, I constantly do grill sessions with my team on a call. I just screenshare my terminal. It is my favorite part of work - getting in a call with all the relevant people and just brainstorming a feature.
For async.. if we can make the assumption the other person is using coding agents you could build some really cool async grilling tooling using github issues as the context source to pull from (just like wayfinder).
@mattpocockuk I see. To be honest - I don't trust models to plan questions more than 2-3 in advance. Each question depends so much on the previous answer imo.
@bcherny@trq212 or even just tools with no paths? Like I can make an AWS CLI skill with the description of "you must invoke this whenever the AWS CLI is used" but there's still a chance the skill isn't invoked.
@bcherny@trq212
I love the idea of Claude Rules, but they are unusable for my team. Rules are too broadly applied, I care about two dimensions:
- Path (you already have)
- Tools (you don't have) (what the agent is going to do)
I want API_RULES.md (containing my coding standards) frontmatter to be:
---
paths:
- api/**/*.ts
tools:
- Edit
- Write
---
This means I wouldn't worry about the 'skill activation' problem, without muddying my context window for exploration tasks.
Day 1 of using @mattpocockuk's Wayfinder. I have a lot to say, but I think this sums it up:
1. Your agent can now be both a PM and a developer.
2. For the last year or so, every paradigm has been some form of Research -> Plan -> Implement. This is different, it's more like:
Set Goal -> Task -> Adjust -> Task -> Adjust -> Task -> Adjust -> ...
Where "Task" can be to research, to plan/grill, to implement, or to prototype.
In hindsight, this flexibility is obviously needed for real work.
3. The best solution I have used for 'sizing' tasks for a single agent session.
4. A lot of other frameworks are HUGE. This one is small.
I built a custom cli to distribute skills across my team. The main friction points i hit:
1. Every harness is slightly different (tool names, hooks, front matter, etc.. skills are easier to translate than subagents and hooks but there's still weird friction because of tools being named differently per harness)
2. People really want the ability to edit everything and add on to a skill without it getting overwritten
3. Updating things underneath people's feet often leads to lack of use of the tools
I think it depends on the size of the task (or 'length of the path').
- Changing text on a button --> No grill-me
- Updating app theme to match a different apps theme --> Maybe grill-me, depending on how complex the theme is
- Creating a small feature --> grill-me
- Creating a large feature --> wayfinder
It just depends. I wish I could give you solid rules but unfortunately given the stochasticity of LLMs a lot of it is just intuition (aka vibes) right now.
Maybe this would be a good rule to help you build your intuition: (also, your intuition partially resets every time a model changes or your harness has large updates)
1. Try to implement the task with no skills. Did you succeed? Great. Was it not headed for success? Try #2
2. Try to implement the task with /grill-me or /grill-with-docs. Did you succeed? Great. Was it not headed for success? Try #3
3. Try to implement the task with /wayfinder. Did you succeed? Great. Was it not headed for success? You'll need to find a way to split up your task even more.
Basically just default to the simplest method and you'll know pretty quickly whether your task fits or not. If it doesn't fit, move up one step.
@theDrewDag@mattpocockuk I definitely wouldn't pull out wayfinder for a really simple task.
I think its best meant for when there is "fog" (as Matt refers to it); aka: when you start the task you don't know the full path to get to the finish.
Anything grouped under a single "Map" in Wayfinder will definitely be adjusted as the project goes on. Claude is constantly commenting on multiple tickets whenever I resolve one (and creating new tickets as new work is discovered)
I don't know if parallel or sequential maps on the same project will impact each other.. AFAIK right now it won't. Maybe there's some use for a compounding step to improve the CLAUDE.md/skills when the goal is reached, maybe there isn't. Tbh, I wouldn't know yet, I haven't worked with it enough.