5 ms·

I can't recommend this post strongly enough. The way Jesse is using these tools is wildly more ambitious than most other people. Spend some time digging around

by simonw 1y ago

I can't recommend this post strongly enough. The way Jesse is using these tools is wildly more ambitious than most other people. Spend some time digging around in his https://github.com/obra/Superpowers https://github.com/obra/Superpowers repo. I wrote some notes on this last night: https://simonwillison.net/2025/Oct/10/superpowers/ https://simonwillison.net/2025/Oct/10/superpowers/

csar 1y ago
I’m curious how you think this compares to the Research -> Plan -> Implement method and prompts from the “Advanced Context Engineering from Agents” video when it comes to actual coding performance on large codebases. I think picking up skills is useful for broadening agents abilities, but I’m not sure I’d that’s the right thing for actual development. The packaged collection is very cool and so is the idea of automatically adding new abilities, but I’m not fully convinced that this concept of skills is that much better than having custom commands+sub-agents. I’ll have to play around with it these next few days and compare.
- ehsanu1 1y ago
  Using Research->Plan->Implement flow is orthogonal, though I notice parts of those do exist as skills too. But you sometimes need to do other things too, e.g. debugging in the course of implementing or specific techniquws to improve brainstorming/researching. Some of these skills are probably better as programmed workflows that the LLM is forced to go through to improve reliability/consistency, that's what I've found in my own agents, rather than using English to guide the LLM and trusting it to follow the prescribed set of steps needed. Some mix of LLMs (choosing skills, executing the fuzzy parts of them) and just plain code (orchestration of skills) seems like the best bet to me and what I'm pursuing.
  - drivebyhooting 1y ago
    Orthogonal means there should not be any overlap.
    - 0x696C6961 1y ago
      Yeah, but you knew what he meant.
troupo 1y ago
This looks like usage rules in Elixir, but for agent behaviors, and currently specifically for Claude: https://hexdocs.pm/usage_rules/readme.html https://hexdocs.pm/usage_rules/readme.html
smrtinsert 1y ago
Curious what you think of sub agents, don't they still consume a massive amount of tokens compared to simply running in main context? I'm skeptical of any process that starts massively delegating to sub agents. I'm on Pro and don't think its worth upgrading to 200 a month just to not pollute main context.
- redhale 1y ago
  In my opinion, subagents (or more generally, "agents as tools" as a pattern) are an order-of-magnitude level feature. Soon every CLI agent will have them as a first-class feature (you can get them via custom scripting right now with and CLI agent, albeit less ergonomically). The ability to isolate context-noisy subtasks (like agentically searching through a large codebase by grepping through dozens of irrelevant files to find the one you actually need) unlocks much longer-running loops, and therefore much more complex tasks. And you don't need a system this complicated to take advantage of it. Literally just a simple "codebase-searcher" agent (and Claude can vibe the agent definition for you) is enough to see the benefit first-hand. Once you see it, if you're like me, you will see opportunities for subagents everywhere.
  - simonw 1y ago
    This is a great answer IMO.
- simonw 1y ago
  I think they're worthwhile only as a token context management tool - to complete side quests without using up tokens in your main agent loop. Using them in a way that doesn't waste tokens is something I haven't fully figured out out yet!
  - gner75 1y ago
    I'm not sure I get this. If anything, they'll consume less tokens, because their context will possibly contain a subset of the original single agent prompt, and they only need to see a subset of the original single agent history. What am I missing?

by simonw 1y ago

csar 1y ago

I’m curious how you think this compares to the Research -> Plan -> Implement method and prompts from the “Advanced Context Engineering from Agents” video when it comes to actual coding performance on large codebases. I think picking up skills is useful for broadening agents abilities, but I’m not sure I’d that’s the right thing for actual development. The packaged collection is very cool and so is the idea of automatically adding new abilities, but I’m not fully convinced that this concept of skills is that much better than having custom commands+sub-agents. I’ll have to play around with it these next few days and compare.

ehsanu1 1y ago
Using Research->Plan->Implement flow is orthogonal, though I notice parts of those do exist as skills too. But you sometimes need to do other things too, e.g. debugging in the course of implementing or specific techniquws to improve brainstorming/researching. Some of these skills are probably better as programmed workflows that the LLM is forced to go through to improve reliability/consistency, that's what I've found in my own agents, rather than using English to guide the LLM and trusting it to follow the prescribed set of steps needed. Some mix of LLMs (choosing skills, executing the fuzzy parts of them) and just plain code (orchestration of skills) seems like the best bet to me and what I'm pursuing.
- drivebyhooting 1y ago
  Orthogonal means there should not be any overlap.
  - 0x696C6961 1y ago
    Yeah, but you knew what he meant.

troupo 1y ago

This looks like usage rules in Elixir, but for agent behaviors, and currently specifically for Claude: https://hexdocs.pm/usage_rules/readme.html https://hexdocs.pm/usage_rules/readme.html

smrtinsert 1y ago

Curious what you think of sub agents, don't they still consume a massive amount of tokens compared to simply running in main context? I'm skeptical of any process that starts massively delegating to sub agents. I'm on Pro and don't think its worth upgrading to 200 a month just to not pollute main context.

redhale 1y ago
In my opinion, subagents (or more generally, "agents as tools" as a pattern) are an order-of-magnitude level feature. Soon every CLI agent will have them as a first-class feature (you can get them via custom scripting right now with and CLI agent, albeit less ergonomically). The ability to isolate context-noisy subtasks (like agentically searching through a large codebase by grepping through dozens of irrelevant files to find the one you actually need) unlocks much longer-running loops, and therefore much more complex tasks. And you don't need a system this complicated to take advantage of it. Literally just a simple "codebase-searcher" agent (and Claude can vibe the agent definition for you) is enough to see the benefit first-hand. Once you see it, if you're like me, you will see opportunities for subagents everywhere.
- simonw 1y ago
  This is a great answer IMO.
simonw 1y ago
I think they're worthwhile only as a token context management tool - to complete side quests without using up tokens in your main agent loop. Using them in a way that doesn't waste tokens is something I haven't fully figured out out yet!
- gner75 1y ago
  I'm not sure I get this. If anything, they'll consume less tokens, because their context will possibly contain a subset of the original single agent prompt, and they only need to see a subset of the original single agent history. What am I missing?