WILL NESS

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: github.com/will-ness-ai/skil…

In a world where everything is so easy to clone I think its going to be very important to ensure your docs + apis + sdks + frontend bundles do not leak implementation details.

I both love and hate the recent anti-subagent hype. Subagents are bad for a task that are PARALLEL to your main agent (this is likely if you are anthropomorphizing your agents). Your subagent context window will need a lot of the same stuff as your main window. Its just a waste of time and tokens. Subagents are great for tasks that are TANGENTIAL to your main agent. This is when your subagent context window will need very little of the same stuff as your main window (think Explore agents, research agents, side processes, etc..)

the consequence of making a wrong decision when building with agents is devastating and the current frontier models make it so easy to do this is the issue with the current corporate-slop being pumped out by models instead of actual human readable responses: 1. I get a response I *think* I understand but actually don't because of how sloppy the models text is and answer a question without actually understanding the intended consequences 2. The model holds on to that decision forever and makes bad decision after bad decision 3. slop This is my issue with the "forget the code" movement, the code is an indicator of bad decisions made that need to be corrected. If you aren't following the output, you'll never know when you're off track.

if your tool/library/docs cannot be used intuitively by agents, you've done something wrong

The optimal setup for agents: - one task directory per feature/effort - each task dir has its own AGENTS.md, scripts, and docs - repos are cloned within the task dir, each having their own AGENTS.md The task directory AGENTS.md helps align agents on what is being done, guidelines and guardrails, references to docs and tools available to them These resources act as ephemeral context and tools that the agents build for themselves as they work on a task. I have benefited from using this system because: 1. Most tasks now use many agents (and even more subagents). The common AGENTS.md, docs, and scripts saves sooo many tokens. For example, when prototyping and building out a recent feature each one of the implementation agents would have to re-learn how to deploy a test version of the product to qa test at the end of each ticket. With a task workspace, my agents were able to: - create a deployment script that deployed test instances of all 3 services involved in the feature - document the deployment script in the AGENTS.md so all future agents used that instead of learning ad-hoc every time - created a series of scripts that would load different datasets into the app to assist with QA (empty states, edge cases, golden path, stress tests) (+ document in AGENTS.md) - created some e2e tests for the feature that spanned across all the services being touched 2. It helps my agents be organized The file system is the best form of context persistence, and this allows me to utilize that without throwing a ton of junk in my git repo. These files are valuable only until your task is done. Right now your agent likely uses a scratchpad (temp folder) for a lot of these files so no future agents can read your agents valuable and relevant context!! (it also saves on tokens and you re-explaining) 3. When I want to give agents access to a risky tool (ex: aws cli), or give it guardrails of what not to do or what not to touch, the task/AGENTS.md is the best place to do this because it ONLY applies to this single effort, never anywhere else. For some tasks I want my agents to be innovative and risky, prototyping and trying out different solutions. For other tasks, I want my agents to follow instructions and complete a process or deliver on a spec. Task-based rules can allow me to optimize my context window without having to re-explain context. 4. Most of my tasks are cross-repo (still a great system for single repo work though)

Wanted to get a quick idea - where are you using your agents?? Right now I am transitioning from being majority CLI/IDE on Local to using Slack on Cloud.

You should not be steering your agents, you should be driving them. The difference to me: - steering is when you let the agent use its best judgement and you jump in to correct it where it goes wrong - driving is when you are planning out exactly what the agent needs to do to be successful in your original prompt and setting up tools to help you: skills, mcp servers, hooks, dynamic workflows, rules, custom scripts EXAMPLES Task: I want to create a product documentation section on my products website An example of steering: Prompt "I want to create a product documentation section on my products website" Interrupt "No, you need to find out our actual features first" Interrupt "No, that does not match our website theme, go look at how other components do it" Interrupt "Go test it using agent-browser" An example of driving: The context I know my agent needs to do this job: - layout of the frontend code, coding conventions - product feature-set - existing docs - how to test the changes - what the final output should be (a PR) So, my prompt would be something like: I want to build a product documentation section on our website. Before starting, please run 3 Explore agents to answer these questions: - what is the layout of the frontend code? What coding conventions should we adhere to? What files will we need to create? What components should we use to implement this feature to blend in to our current app? - What is the current product feature-set? Where can I source features from? Where are our APIs and are there typed contracts we can use for the docs? 1. plan and add the documentation to our website. 2. use our `browser-qa-testing` Skill to learn how to test the site via agent-browser. 3. run a code review subagent to review and fix issues 4. create a PR and `open <url>` for me to view

The quality of products being shipped by good engineers now is insane. Worth a watch if you have use-cases for building and tuning custom agents. This is the best tool I have seen for agent observability + control over your session.

Going to film a video demo on this skill soon, but I've been using this skill I made called /flashlight which plugs into @mattpocockuk's wayfinder. I call it flashlight because its a human tool that allows you to steer your course through the fog. The result should clear some of the fog and make it easier to get to the destination. I use it when I want to do some ad-hoc work in a wayfinder map, usually: 1. An on-demand ticket (ex: prototype this, grill on this, generate this deliverable for a coworker) 2. Re-chart the map (ex: adjusting strategies/path, switching destinations) github.com/will-ness-ai/skil…

I just dropped a new skill made for devs working on enterprise codebases: About 12mo ago I was still on the "you must read all of the code" side of the pendulum. Starting about 3mo I have swung over to the other side of "i really dont need to read most of the code" However, I've realized that unfortunately the real answer is that... it depends (cop out answer, i know) For almost all of my internal tooling at work, I do not read the code ever. My agents: - prove to me the code works with testing/qa - run reviews (code, security, etc.) before every merge (btw, i think 40%+ of your time should be dedicated to internal tooling, even if you are on a product team. custom software has gotten insanely cheap lately...) For our key services and repos where the code really does matter because the consequences of getting it wrong are high, I do think its necessary to read *some* of the code. The important stuff. However, I struggle to do this for two reasons: 1. The pace of code is fast (and accelerating) 2. I am usually working in repos that I am not familiar with I review code at the PR step. Agent writes code, reviews it, pushes it and creates a PR. Then I view the diff. I've realized that PRs are a terrible way to introduce a code change to someone. So, introducing... /code-story Build a chaptered HTML page that teaches how and why a change works. See individual code diffs combined with explainers and diagrams. It helps me ramp up on every change and get a bit more comfortable in merging the code, allowing me to ask more questions and build better tests. SKILL: github.com/will-ness-ai/skil… EXAMPLE: claude.ai/code/artifact/6faa…

I forked @MikeGvozdev's claudish-to-english and combined with @mattpocockuk's CONTEXT.md + /wait-what. and this has completely solved my 'understanding claude' issue. Now every time my agent writes a message to me: 1. A hook triggers that gathers the message + previous conversation history + CONTEXT.md file 2. Calls a local model to re-write the assistant message using the gathered context using /wait-what's framing 3. Writes out the readable version for me inside Claude itself. This readable version is never added to the actual context window, its just for me to read!!! It's like an automated `/btw /wait-what` It is awesome I love /wait-what but I think it adds unnecessary bloat to the context window that the model doesn't need to continue doing its job, and it also takes mental energy for me to read claudes garbage and then decide to invoke /wait-what. "Anybody in the thread can run it. The gate is at the door, not per command." was changed to "Anyone in the thread can use the command." "/mute outside a ticket thread answers only to the caller, and does nothing. A channel is a ledger; there is no session to silence." was changed to "Using /mute in a regular channel does nothing." Definitely go check out Mike's version, here's my fork with the upgrades to fit into Matts agentic framework: github.com/will-ness-ai/clau…

The new grilling updates from Matt Pocock made this skill even more OP. Several questions in one round make iteration way more quick (and more fun!)

New problem of mine this week: My agents are constantly almost exposing my own PII into GitHub issues: - references to private repos and their contents on my machine - my name, my personal email address - my location The issue is im building so much personal software to solve my own problems (in private repos) and then I am building tools to help me build faster (in public repos) but my agents need to understand the use cases in the private repos to build the public tools. I have a decent fix in place for this but is anyone else encountering issues like this?

The context window should be a first class citizen of Claude Code. I want to be able to directly edit my context window with hooks/skills. This would allow me to be able to build custom compaction for different projects/agents. Custom agents could benefit SO MUCH from surgically editing the context window at certain times. Examples: - I have a long running agent that does many sequential tool calls and I want to automatically clear tool outputs in the context window older than 5 turns - When my coding agents finish implementation, I want to compact everything in the implementation phase (keeping the research phase intact) and then move on to qa and putting out a PR - Before inference I want to be able to use regex to remove PII from the context window (user messages, tool outputs, tool calls)

Stop putting agents in your product. No one wants to talk to your highly configured corporate-slop agents on your website or app. Instead, let agents use your product. I am using Claude Code all day to get stuff done, I don't want to have to switch to your website to click buttons and type things, I need to be able to do it from my claude code. If what you offer is valuable to people, it'll be valuable to agents. Here's a list of things that my usage has spiked probably 10x on and I very rarely use the ui: - project management (Linear, GitHub issues) - observability (Datadog, CloudWatch) - deployments/ops (GitHub CLI, Vercel CLI) - database (mongo compass)

I posted about this earlier today: When responding to agents, ramble your response as you read. Just dictate your full thoughts as you respond to an agents questions as you read it, not after. It's ok if it's ugly. It's ok if you change your mind mid ramble.

Pro-tip for my fellow dictators: dictate your response as you read, not after. (voice typist, not political leader) I used to read an entire assistant response from my agent (claude code) and then start dictating but its hard to address every point the agent has made in its response. Especially during grilling sessions agent responses can get really long and contain many possible things to correct or respond to. Dictating as I read ends up looking something like: "Yes I like point 3. No, I don't want to do strategy A because it'd break the current user experience. Yes, but we should do it this way instead of the way you suggested. Hmm, I like option 4. Okay, agreed." whereas without this I find that I read it all and just go: "okay lgtm" because I am lazy and don't want to go back and read individual points. This does lead to the case sometimes where you end up changing your mind for previous points, in which I use vim mode to surgically remove sentences, or just tell claude I changed my mind.