I have a similar workflow with jj.

jj will start recording all of your changes as a real commit that it constantly rewrites as you edit files. You can write the log message for it up front or later. Think of it as an index that every change automatically gets staged to, except it’s just a commit, so instead of two concepts that work differently, you just have one. And you get the benefits of real commits, so for instance you can’t accidentally lose anything you staged that isn’t committed.

When you would create a branch and then stage changes with Git, what you would do in jj is split. The changes you don’t pick end up as the next auto-updating commit, and the changes you do pick use the log message you already set when you were working on them. So if you’ve got a bunch of changes you want to record as a series of commits, you just split however many times you want.

You don’t have to think about branching while you are doing this. The HEAD of master doesn’t automatically move when you are making these changes, so the effect is that you’re working on an anonymous branch already without having to create one. You can give it a name whenever you want by setting a bookmark. Or if you decide that the changes you make need to go into two branches, then you can add two bookmarks.

For instance, if you have:

A (master) => [changes]

Then [changes] is already a commit. Suppose you realise that you have fixed a bug and added a feature, but you want these as separate pull requests. You’d split, giving the bug fix a log message:

A (master) => B (bug fix) => [changes]

Then you’d give the feature a log message:

A (master) => B (bug fix) => C (feature)

Even though we started on master and made a bunch of commits without even thinking about branches, we haven’t changed master at all. So in effect, it’s like B and C are on some anonymous branch that was transparently created for you.

Now you want to open the pull requests, so you add a bookmark for B and a bookmark for C, and push them to your remote. B and C show up as branches that you can open pull requests for.

So your workflow is basically the same as it is now, there’s just fewer moving parts for you to think about as you work, and fewer concepts for newbies to learn.