Recently I came across the /handoff skill, which I've been using a lot. I find it much better than /compact.
Basically:
- /handoff file creates a short document with the important context from your current session and maybe next steps as checklist.
- You can then start a fresh session with /continue file
- You can also hand the work from Claude to ChatGPT, or the other way around. Very useful at time of session limits.
- Plus your handoff files becomes a useful piece of project memory that you can reference later.
I find this much more useful than /compact or /clear because the context is saved in something portable instead of being tied to one session and i've seen better results doing this every 20 messages or so than running long sessions.
> Plus your handoff files becomes a useful piece of project memory that you can reference later.
I've been doing this since I started agentic development, and have a whole framework based on this; Simply put I define workflow s that output templated files for everytype of tasks that happens in development.
I started doing this and then a colleague of mine recommended me OpenSpec. It might be overkill for small projects but it’s pretty clean and if you have goldfish memory like me, it helps to track changes.
I now feel a bit silly but I reinvented the wheel during my last lil project and indeed found it very powerful. A variant of it is the "implementation (handover) prompt" when I conclude the planning session with plans and design documents, updated handoff, clean tree and a file for a new Opus implementing orchestrator (unusually do a single, highly specific implementer and a single, highly specific tester).
After implementation and task-level tests I end up with a long and very detailed implementation progress ledger and a summary findings from the orchestrator.
Then in the new session I do the whole branch tests.
Works really well, uses much less tokens than any other approach with more of Opus and very little repetitions/corrections.
Yeah, making it a skill is just much more convenient. It can be a very simple skill, a one liner asking the agent to gather the context and write a handoff for another agent. My skill is unnecessarily complex if that's the only requirement.
This is where I landed too. Basic skill for a Jira-like task board and another for keeping an orchestration ledger. Let’s me arbitrarily clear context without losing big picture knowledge.
I've been using my own variant docset driven development since late last year. It emerged organically for me by adapting to the limits of the agents.
- Prefix-numbered sets of documents, keeping them clustered visually and easily referenced by humans and agents. (124.5 = docset 125, phase 5)
- Each doc gets a suffix. Most of the time STRATEGY is the first doc. Sometimes NOTES, DISCUSSION, or HANDOFF though.
- Once the strategy doc is comprehensive, the multi-phase checklist PLAN doc can emerge.
- During execution, the agent drives the PLAN while purposefully expanding lightly scaffolded phases before entry.
- As the user, I drive a PROGRESS doc during the PLAN execution. This tracks the progression of my own questions and the important work summaries that I need for tracking the current work trajectory and for historic analysis over past decision-making.
- Any concern that exceed the scope of the active docset numbers calls for a new one.
- A "docs/archive" folder is kept where I sweep docsets into numbered eras.
I have aliases and templates too, but DDD is so simple that it's overkill.
Any modern reasoning agent can take the plain explanation above and understand you effortlessly when you say "open a new docset strategy" or "read docset 125 and proceed".
Ah I've been doing handoff manually by asking the model to do it. If Claude's handoff includes better context than its summaries, it's probably worth checking out.
I prefer to avoid its internal magic mechanisms. The LLM can read documents like a human (actually better since...no ADD) so I ask it to create documents. This also has the benefit that you can change to a different AI tool and the information is still usable.
I have been doing this a lot even without a skill, having Fable write a planning document, then spawning an Opus subagent with instructions to strictly follow the plan and report any deviance at the end. It also helps that then the plan is always saved in an md file so any future agent can look at it and see what happened.
Interestingly, this was tackled in this blog post[0] a month ago. They claim that plan files aren't token-efficient, because after reading the plan the workhorse model then reads all the relevant files anyways.
That link just says the planning stage should vet the idea concretely so that the plan focuses on a solution that won’t immediately have to pivot.
And I think plan files should focus on general ideas and invariants, not do “implementation as prose”. That way they perform as mini-ADRs that are useful historically, especially to mine why the system is the way it is.
My plan and implementation files are task specific (so specific workhorse reads only its own slice), and the workhorse itself is spawned from an orchestrator with a very specific small prompt.
I managed even the orchestrator to NOT read the plan whole, at once, but in sections.
The most useful thing is the task ledger the task agent leaves behind, which alongside its structured status message makes a very resilient handoff between all stages.
/handoff is the skill I use when I plainly are about to run out of token budget to give to a different harness system. Using this to avoid long sessions is something I will need to try, plus maybe "caveman" mode to cull the verbosity.
It might be even better if the harness were to automatically write a handoff note under some circumstances? If the user is away and the cache is going to expire, that would be a good time to do it.
I've been doing handoffs manually, but maybe the command is a better way. It's a great way to keep track of work, remove useless context, and more importantly, it's an enforced "what is the agent doing" line - you immediately notice if the handoff writing is missing something or confused. Commit each and every one (git is the unsung hero of AI).
One trick that makes me sleepy really fast: After I close my eyes, I imagine someone throwing black paint on them. The first coat is kinda gray and has lots of blob and not fully black. Then another coat. And another. Each one gets darker until it's just pure black and I'm usually asleep by then.
For some reason, my brain follows it, and I fall asleep much faster. It works way better for me than box breathing or most other sleep tricks I've seen. Sharing in case someone else finds this useful.
If noise keeps you awake (loud neighborhood) then a white noise blanket could work. I downloaded a 10 hour beachwaves sound and played it to cover the noise. Two small speakers left and right made it feel like I was there with the stereo. It took a little bit to get used to, but it did the trick.
I close my eyes and set out on a journey to explore an imaginary island. It almost always begins on a sun-drenched beach. Usually, I’ve already fallen asleep after just a few meters...
This is against the Show HN rules from what i can see:
> If your work isn't ready for users to try out, please don't do a Show HN. Once it's ready, come back and do it then. Don't post landing pages or fundraisers.
I didn’t know that! I really wanted to know if people are interested in that type of product or not, the app is almost ready, actually I’m in beta testing step
It's okay, we all miss these guidelines from time to time but if you wanted to know if people are interested in that type of product or not before launch, you can join the monthly discussion "Ask HN: What are you working on?" [1]. If the HN community is interested in your idea, you will get a lot of feedback/questions to validate your concept.
Everytime I read one of these it always boils down to the same thing..Don't solve solved problems. And the best code in this case is code you didn't write as PHP's session handler is battle-tested but every line you write to roll your own is a line you have to secure, maintain, and eventually patch at 2am when someone finds the bug.
Session handling, auth, crypto, password hashing etc - all these are the exact areas where you should be the most allergic to rolling your own. Not because you're not smart enough, but because a simple bug like sanitizing in the wrong place and the failure is catastrophic like in this instance.
Use boring, proven, widely-audited solutions. Save your creativity for the actual problem you're solving.
Oh you're right to push back. I just love saying this nowadays :P Anyway, I haven't used these languages in a long time but the code looked like php to me, though I did notice the .pm file extension and wondered where I've seen it before.
PHP has built in session handling and the ability to store them to local, in memory, RDBMS database, or you can implement SessionHandlerInterface, SessionIdInterface with your own custom class.
It's probably the most battle hardened session system ever.
I don't even know why you'd want to re-implement this stuff, too. It's not exciting or sexy work. It's like time parsing, time zone handling, leap years... Why would you want to inflict that on yourself? You will 100% not handle every edge case, and you will 100% get time and time zone handling bugs.
I tend to agree and I often strongly recommend to my clients to choose battle tested off-the-shelf solutions for these problems rather than roll their own, but...
Sometimes it makes sense to roll your own and the cost of a dependency isn't worth it. This can be especially true when you need to accommodate many bespoke environments and you end up needing to make little accomodations here and there. Can create a very unpleasant situation when you don't own the code.
I'm not a cryptographer but I've spent a significant portion of my career focusing on the security-side of things and I've rolled my own auth quite a few times on very public projects you can access today and I've never had any significant findings through repeated pentests.
But that's just the thing: I did it the right way, and there is a right way to roll your own stuff, to forge it in a way it comes out suitable. Is it bug free? Probably not, but I feel significantly better about it having thoroughly tested it by myself, my colleagues and paid professional penetration testers.
I couldn't easily find an answer but I'd like to know if this implementation has been validated by a professional or not.
Well, I tend to fall on your side of this, but doing this probably means you’re equally or more insecure and just won’t know it until you’re hacked. That said, I have written my own auth and session layers numerous times. My needs are generally simple, so getting it correct isn’t too hard.
When you pull in a generic auth or session library, you pull in a “can do everything” module rather than a “can do this one specific thing” module. So, your attack surface grows as do your odds of misconfiguration.
I doubt the mantra of "don't roll your own Auth/crypto" - especially if it lives on a server where the code can't be inspected.
Sure, there will be more bugs in my code, but the attackers will be putting far more scrutiny into a widely used library.
Some deliberately hilariously weak auth I built decades ago is only just now starting to get broken into by AI bots, whereas any vulnerable wordpress was broken into within days.
Thinking of use cases where services I build have reasonably low internal userbase. Maybe rolling out own is not worst choice always. After all it leads to manual or at least targeted work by attackers. Instead of very common spraying stuff randomly. So risks might in the end be lower.
Vice City was originally planned as an add-on to GTA III. Development time was 18 months. Incredible that they put out such a great game in so little time.
Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess?
I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack.
I interviewed frontend devs last year and was shocked how few knew about this stuff.
In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).
Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.
Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.
I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard.
This is unacceptable and the amount offered in general is low. It feels like we can agree on this.
No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.
No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies.
XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used.
JWT supports some encryption algorithms as an alternative to signatures but my experience is that most people like to keep it simple.
JWT is intended for authentication. Most of the time you're basically just signing a token containing an account ID and nothing else... Sometimes a list of groups but that only scales to a small number of groups.
Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.
Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.
Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account
The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.
The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.
I was once only given $1,000 for an exploit where I could put in npm usernames and get their email addresses. Big corps don't always pay what they should.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.
>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.
>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.
So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.
I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).
I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.
What 'arcwhite said (sorry, I got dragged into a call).
1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.
2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.
3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).
4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.
There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.
Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.
For a reflected XSS? Tell me who is paying that much for such a relatively common bug...
To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc
No real way to use this to compromise a large amount of users without more complex means
It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.
Yes, but this is not a particularly high access level bug.
Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)
I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss
Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.
In addition this is widespread. It's golden for any attacker.
Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.
I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).
If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).
Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.
Besides XSS, phishing has its own opportunity.
Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.
Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).
Still, purely with executing things under the user sessions there are interesting things to do.
> some people actually use web version of Discord to chat, or sign-in on the website for whatever reason
Beside this security blunder on Discord’s part, I can see only upsides to using a browser version rather than an Electron desktop app. Especially given how prone Discord are to data mining their users, it seems foolish to let them out of the web sandbox and into your system
Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!
There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.
What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.
Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.
Well, it used to be much more accessible before, now you have to do some hack to retrieve it, and by hack, I mean some "window.webpackChunkdiscord_app.push" kinda hack, no longer your usual retrieval. Basically you have to get the token from webpack. The localStorage one does not seem to work anymore. That is what I used, but now it does not work (or rather, not always). The webpack one seems to be reliably good.
So your code goes like:
// Try localStorage first
const token = getLocalStorageItem('token')
if (token) return token
// Try webpack if localStorage fails
const webpackToken = await getTokenFromWebpack()
if (webpackToken) return webpackToken
and localStorage does fail often now. I knew the reason for that (something about them removing it at some point when you load the website?) so you need the webpack way, which is consistently reliable.
I believe if you search for the snippet above, you can find the code for the webpack way.
Discord removes the token from localStorage when the web app is open and it's in app memory, and places it back when you close the tab using the "onbeforeunload" event.
Great job on this release! I've been waiting for something like it since my favorite browser, Kiwi, stopped getting updates.
Without updates, many sites will likely stop working with it soon.
Kiwi had some great features, like disabling AMP mode, rearranging the Chrome Store for mobile, and customizable tab layouts, etc. These features might interest others as well.
I still (unfortunately) am stuck with kiwi as well. I use it almost exclusively for a few webapps that use large amounts of indexeddb storage (>10gb) without a working export method[1]. With Firefox, I was able to export this data with devtools over ADB[2] to another Firefox install.
I really wish someone would create an indexeddb shim that interfaces with another system and only uses indexeddb for (very large) cache. Something I could drop in with a userscript would be lovely, even if it required running a local server with something like rsync or rclone responsible for the actual transfers.
[1]: dexie import export used to work, now it never returns. I have no way of verifying that it's doing nothing without putting it in background (thus suspending it...), but I've let it run 3 hours with no results.
[2]: Firefox doesn't allow backing up app data for some reason but devtools functions allow reading and writing the profile directory through the use of terminal commands (zip profile directory, unzip and restart browser).
I agree with this take, Product Hunt felt like it was chasing short term goals instead of building something sustainable They also allowed and sometimes encouraged behavior that undermined the quality of the site
The last time I used it one of the common hacks was adding 50 makers to a single app launch PH also openly condoned mass email blasts and tweets to drive votes which just rewarded whoever could push the hardest on promotion
In contrast Hacker News discourages asking people for upvotes and even treats it as a negative if you do That longterm focus on signal over hype is probably why HN still feels useful today while PH lost its way
Basically:
- /handoff file creates a short document with the important context from your current session and maybe next steps as checklist.
- You can then start a fresh session with /continue file
- You can also hand the work from Claude to ChatGPT, or the other way around. Very useful at time of session limits.
- Plus your handoff files becomes a useful piece of project memory that you can reference later.
I find this much more useful than /compact or /clear because the context is saved in something portable instead of being tied to one session and i've seen better results doing this every 20 messages or so than running long sessions.