I can teach you the theory, but I don't think it's really usable in speedsolves or even in casual solves. (Maybe it is, maybe it's not? I'd love to be proven wrong here; at least it seems much easier to do this than OLL parity avoidance on big cubes.)
You can assign a number among {−1, 0, +1} to the orientation of each of the corner pieces (+1 if you need a cw turn to solve it, −1 if you need an acw turn), and you can also assign a number among {−1, 0, +1} to the permutation of the centre pieces (+1 if you need a cw turn to solve it, −1 if you need an acw turn, 0 if it's solved or a pair of 2-cycles). Let X be the sum of the corner orientations mod 3, and let Y be the centre permutation value. (These values should always be considered mod 3, so (+1) + (+1) = (−1), and so on.)
A clockwise non-wide move (i.e. turning one non-tip layer) changes X by −1 and does not affect Y. An anticlockwise non-wide move changes X by +1 and does not affect Y.
A clockwise wide move (i.e. turning two non-tip layers) changes both X and Y by −1. An anticlockwise wide move changes both X and Y by +1.
If X = Y and the edges are all paired, then you can solve it like a Jing's pyraminx (using only wide moves). In theory, you could determine the difference X−Y during inspection, do that many non-wide clockwise moves to start your solve, then restrict yourself to using commutators to do edge pairing (since comms will always have zero net effect on X and Y). This will force centres to be either solved or in a pair of 2-cycles (solved with triple sledge) once you have the corners and edges all solved.
