How to earn trust again with my skip manager?

So what you're running into is social capital: which in the broadest definition is the trust and expectations your colleagues will have in you. Social capital generally works the same way as normal capital (money): if your social captial is positive you can spend/use without issue, but if you're negative you'll compound debt (and likely can't get out of being in the "red").

What likely happened in this scenario is that you tried to spending first (which pushes you into debt) before checking if you had the capital. In this case, you should've made sure that your code had a stellar reputation and that your skip manager was clearly aware of this (akin to checking your balance first, and to spending that confirmed balance). Once you have the balance checked and confirmed, then you can spend it.

A lot of engineers earlier in their career often feel the pressure to voice their opinions as they get more proficient as an engineer to grow more senior. But what they often overlook is that opinions aren't meritocratic in a vaccum: who is behind the opinion and what is that person's background is weighed as well. Following through with an opinion takes time and effort and the opinion could potentially be wrong or not be an effective use of time, so we often find ourselves subconciously judging both the opinion and the person who says it.

For this specific scenario, you should take this as a learning opportunity. Look to resolve the gaps that your skip manager called out, and look to understand why your manager has these standards. Incoporate these learnings into your code, and get to the point where it's clear without a doubt that your code quality is the clearly around the best for the team/company.

For a broader lesson overall: don't spend what you don't have. Reputation always comes first before influence, so focus on building reputation if you want things done your way.

The obvious path forward here is to level up your own pull requests. Once you have become a top-notch code contributor, go further by inspiring others to level up their code (the easiest route here is to become a prolific reviewer of others' PRs leaving thorough but empathetic comments). Here's a course that dives into all that: [Course] Level Up Your Code Quality As A Software Engineer

As Jonathan mentioned, don't talk the talk if you can't walk the walk. Be careful voicing a strong opinion on something if you don't have the street cred to back it up. Classic senior engineer behavior is to become a proven thought leader on an area (like code quality) and then sharing that wisdom with the team. The good news is that you have already done the first step of acknowledging your own flaws (this is something that can be surprisingly difficult). Now you just have to follow through!

Here's a senior -> staff case study I gave that is a great example of everything I just talked about (i.e. cultivating a stellar reputation and then leveraging that to inspire massive change): [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project