AffableSpatula

Sync your Claude Design projects into your repos (list/pull/push) straight over the API; perfect for scripts and there's a skill for agents too.

`npx claude-design` `npx skills add mikekelly/claude-design`

You're absolutely right! I apologise — hopefully you can forgive me.

yep this is exactly how I use the main agent too, I explicitly instruct to only ever use background async subagents. Not enough people understand that the claude code harness is event driven now and will wake up whenever these subagent completion events happen.

Claude already had subagents. This is a new mode for the main agent to be in (bespoke context oriented to delegation), combined with a team-oriented task system and a mailbox system for subagents to communicate with each other. All integrated into the harness in a way that plugins can't achieve.

I don't know what you're referring to but I can say with confidence that I see more efficient token usage from a delegated approach, for the reasons I stated, provided that the tasks are correctly sized. ymmv of course :)

I think you've misunderstood what this is.

Task sizing is important. You can address this by including guidance in the CLAUDE.md around that ie. give it heuristics to use to figure out how to size tasks. Mine includes some heuristics and T shirt sizing methodology. Works great!

a similar question was asked elsewhere in the thread; the difference is that this is tightly integrated into the harness

I've seen more efficient use of tokens by using delegation. Unless you continually compact or summarise and clear a single main agent - you end up doing work on top of a large context; burning tokens. If the work is delegated to subagents they have a fresh context which avoids this whilst improving their reasoning, which both improve token efficiency.

it's my repo - it's a fork of cc-mirror which is an established project for parallel claude installs. I wanted to take the least disruptive approach for the sake of using working code and not spelunking through bugs. Having said that - if you look through the latest commits you'll see how the patch works, it's pretty straightforward - you could do it by hand if you wanted.

yeah I tend to agree. They're must be reaching the point where they can automate the analysis of claude code prompts to extract techniques and build them directly into the harness. Going up against that is brave!

Delegation patterns like swarm lead to less token usage because:

1. Subagents doing work have a fresh context (ie. focused and not working on the top of a larger monolithic context) 2. Subagents enjoying a more compact context leads to better reasoning, more effective problem solving, less tokens burned.

The feature is shipped in the latest builds of claude code, but it's turned off by a feature flag check that phones home to the backend to see if the user's account is meant to have it on. You can just patch out the function in the minified cli.js that does this backend check and you gain access to the feature.

ha! The default system prompt appears to give the main agent appropriate guidance about only using swarm mode when appropriate (same as entering itself into plan mode). You can further prompt it in your own CLAUDE.md to be even more resistant to using the mode if the task at hand isn't significant enough to warrant it.

The difference is that this is tightly integrated into the harness. There's a "delegation mode" (akin to plan mode) that appears to clear out the context for the team lead. The harness appears to be adding system-reminder breadcrumbs into the top of the context to keep the main team lead from drifting, which is much harder to achieve without modifying the harness.

"You can build your own thing using card emulation via apps, but you will take all the risks." right! This is exactly what I've developed. I've built a new NFC application, with its own PKI infrastructure, that's deployed onto users' mobile devices via an app install. It works over APDU, but it would be more efficient if A1 was made available by the two major mobile OS. It would likely shave off >10% of the total time to complete which makes a material difference to the failure rate (ie. customer's lifting away too early or other interference) and therefore improves the overall UX.

Hi there, author here! I think you've highlighted a couple of things worth clarifying in the doc:

1. Apple having just announced it is opening up NFC to developers means that both major mobile platforms can now act as responding devices; so widely distributing new NFC protocols to consumer devices has become very fast and inexpensive through an update to the OS or installing a third party app.

2. Mobile consumer hardware is sufficiently fast for the application operations (eg. Cryptographic operations) so that these roundtrip and metadata overheads of APDU do actually make a meaningful contribution to the total time it takes to complete a transaction. Experiencing this in my development efforts here was the motivation for designing this alternative.

3. A1 is interoperable with APDU infrastructure and can therefore be adopted by terminals immediately, since reader terminals can attempt an A1 initiation and any APDU response from a legacy device is considered a failure; at which point the terminal can fall back to its default APDU message exchange.

I will update the doc to clarify these points, what do you think?

Given your experience I'd be interested in your detailed feedback, maybe we could jump on a call soon if you have time?

The database is postgres under the hood which provides atomicity. We verify the signature of signed pieces (and signed deeds) and then commit the transaction to postgres with a digest of the content (which has a unique constraint on it) - this along with the atomic guarantee ensures there can be no double spend of signed messages.

Great question! :) Right now the UI for creating deeds is from author to owner. We will add the interface for owners to sign on ownership with further deeds in the future. This felt like a feature to leave out for early launch.

The application code that runs this isn't open source at the moment but there's no reason it couldn't be packaged up. Either way, the intention is to expose this as an API so that people can write their own open source clients for users who don't want to trust the web app.

Yeah that's a fair criticism. It is on the todo list to add some other auth factors.

It's applicable to the type of content you're seeing blockchain NFTs used for. It could be used for other types of digital signing/attestations too, even legal documents.

Yea, that's a decent way of framing it!

I nearly dropped all reference to NFTs altogether to avoid this reaction. This a genuine attempt to provide a service to people who want to exchange digitally signed content.

there is a type of reorg attack I proposed that's now been dubbed a "purge attack", that has the effect of destabalising the network by creating a window for all affected users to double spend their previously "finalised" transactions: https://medium.com/deribitofficial/destabilizing-bitcoin-con...

:)

UASF effectively became a negotiation between honest miners and fullnodes. Honest miners are incentivised to close off conflicts because it risks devaluing their future rewards. In this scenario the attacking miner is acting "non-economically" so it's nothing like UASF.

You're right, I totally misread what you said.

I think the answer to what you actually said is; miners don't control consensus on the network - it's not up to them, it's up to fullnodes/users who can change the ruleset whenever they want.

The attack scenario is an adversarial nation state who is not motivated economically and is intent on sabotage of the network.

The purpose of this project is to have people be specific about what ruleset they would fork to which could prevent this kind of attack.