The list of opcodes is just a list for consulting. It's only about the opcodes, it says nothing about the expected arguments and so on. To understand how to invoke an opcode you'd have to read either the forbidding Intel manual or something terser like https://c9x.me/x86 as cited at the bottom of OP. The '/copy-to-ebx' after the slashes is just my way of helping the reader understand what the instruction does. I don't want the reader to have to consult the Intel manual for every instruction, even if I'm forcing the writer to do so.
So why am I forcing the writer to do so? Mu's goal is to build a computer where compound things can be understood in terms of their constituent parts. Most assemblers are implemented in C, and if you wanted to understand what a line of C does, in a specific context, you might imagine expanding the C into.. its generated Assembly. Now you're in a circular situation where you need to understand Assembly to understand Assembly.
So I started out with the goal of implementing an assembler in machine code. And Assembly is surprisingly complex. There's a reason nobody builds it in C anymore. So I ended up on my current trajectory, of making the code writer do more work just so the code reader doesn't have to deal with cycles.
With hindsight, it all feels quite inevitable and fore-ordained. You can read more in a 2-part blog post that starts at http://akkartik.name/post/mu-2019-1, and there's also an academic paper at http://akkartik.name/akkartik-convivial-20200607.pdf that goes into some of my sociopolitical goals (in a sentence: "everybody should spend some time auditing the software (and laws) that run their society". For a paragraph-length exposition see the top of https://github.com/akkartik/mu#readme.)