Fundamentally, you can't without some kind of reset of the old master. Unless the old master is shut down before the new master is promoted and you ensure all WAL is synced from old to new master, the old will usually be slightly "ahead" of the newly promoted replica at the point where the replica is promoted onto a new timeline.
It will refuse to start replaying from the new master because doing so would corrupt the old master. The old master might have assigned transaction ID 1234 already. So what should it do if the new master says "I'm starting transaction 1234". It already has 1234! There are similar issues all over, at the low level crash safety parts of the system.
That's why you usually re-sync the old master from the new master before starting it up. This can be made a lot faster with
rsync or one of the parallel variants.
However, you can instead use
pg_rewind to "wind back" the old master to the point where its history diverged from the new master, so it can start replaying from the new master. I don't use it myself, so I can't do much more than point you at it. But one of my colleagues wrote a couple of blog posts that could help you:
repmgr can use
repmgr standby switchover. As far as I know it does not do so with auto-failover, but you might want to ask the
repmgr team for clarification on that.
Personally I think auto-failover is a terrible idea unless you also trigger it randomly during your normal operations, so you always know it works. ChaosMonkey-style. Otherwise it's just a recipe for doubling your disasters. Prefer manually-triggered automated failover, with something like
repmgr standby switchover, and alerting to tell you when something's wrong.