You do it one at a time or a small cohesive group at a time, not all of them at once. And given that the list is already getting out of hand, you should NOT add any more without a good reason for each addition. In fact, you should look into what you can cut back.
If you can't keep all the characters in your head, guess what, the player probably can't neither. And a game that players would naturally lose track of and get confused with while playing is most likely not worth playing. The thickness of the design document has no binding on how well-designed a game is.
Depending on the type of game you're making, 130 monsters sounds like too many, unless you're working on something similar to Pokémon, in which case I guess it can't be avoided. In terms of movesets and abilities, look at the design of your monsters. You should be able to tell at a glance what they would do, how they would behave, whether they attack with brute force or try to keep their distance from the player. For (a very basic) example, if you have a giant stone golem, they would probably be able to absorb a lot of damage and do a lot of damage with just their fists. A squid-like creature may use its tentacles to bind opponents. Just take a look at your monsters and see what kind of associations and connections you come up with. Also keep in mind that each monster doesn't need entirely unique abilities: the same abilities in different combinations can create vastly different obstacles to overcome.
As for new characters, just focus on your story. As this develops, you'll find new characters kind of just occurring naturally. Think about what you have your main characters doing at any given moment. What kind of person would help them? What kind of person would ask them for help? Who would stand in their way? What kind of person would live in any given area? As long as you really know the story you're creating and the world it takes place in, these questions should become easier to answer.
Oh, and remember that NPCs in games don't see themselves as NPCs in games, or at least they shouldn't. If a character seems like they exist solely to give the player something to fight or something to click on once they've collected x amount of generic collectibles, they become instantly forgettable. If you treat them like they're the main character in their own story, they become much more memorable. That's a main part of the reason side quests in Witcher 3 were seen as such a big deal: the characters involved in them seemed like they had their own lives and weren't just waiting around to interact with the player.
Assuming you're making a monster collector or other type of RPG where only the gameplay bits matter:
Every character should feel unique, so try to make every monster have SOMETHING unique to them. Stat distribution, signature move, etc.
To get a large number of them, start with a central concept (e.g. "fire") and then make mutually exclusive spins on the formula. "Fire stronk", "Fire debuff", "Fire speed", "Fire and elements that don't meld together with fire").
Then make designs based on those concepts. Muscular Flamuscle, mysterious ninja Burninja, speedy racecar bird Powl Posignite, and boiling water flower Grasserole.
Given the designs, now pick movesets that make sense. Flamuscle punches and suplexes but has absolutely zero ranged attacks, Burninja throws knives laced with different poisons and needs to constantly manage ammunition, and so on.
I'm in the process of doing this too for my game. I haven't worked on it much, but my idea is to keep track of it all a spreadsheet. If what you're making is a decent-sized RPG then I don't think 130+ is too many at all. (Though for an RPG of that magnitude, you might also want to release a player's guide or something.)
Monsters - I'd say be creative on like half of them, and for the rest you can just reuse the same ideas but modify them a bit. Pokémon did this with evolutions. Final Fantasy did it with recolors. (Recolors are especially common in 8-bit games, since alternate palettes take up a lot less space on the cartridge than alternate sprites. Though I'm not really a fan of recolors, as they usually feel too generic/too repetitive.) Similar monsters can have similar movesets and similar stat proportions. Movesets should make sense and be fairly intuitive, unless you have good reason to surprise the player with something unexpected.
Moves - Same thing as with monsters. Be creative on some of them, and then reuse those same ideas to make the rest of the moves. (In Pokémon, Flamethrower is the same thing as Ember but more powerful and with a different animation.) Effects should make sense. Fire causes burns; water does not cause burns. Fire consumes a lot of MP but does high damage. etc.
One thing that is important is to make sure the monsters are balanced. Because it makes no sense for a Slime to be more powerful than a Firedrake, and it especially makes no sense for a level 1 Slime to be more powerful than a level 100 Firedrake. (Of course I'm exaggerating, but you get the picture.) So the monsters should have stats that make sense relative to other monsters. One way of doing this is to assign tier groups and base stats. (Higher tiers get more base stats than lower tiers.) Monster stats also have to be balanced against the Player's stats... you don't want to end up with monsters that are so powerful that they cannot be killed, but you also don't want to end up with a game that's too easy.
Create a system in which you categorize ALL the movesets and abilities you have thought of.
For example, attacks would include:
enemy movement methods:
move along a fixed path
follow the player
Further, projectile attacks would be categorized into:
Once you've got this down, just open a document and start creating profiles for each monster.
Monster 1 (Undead ghoul)
Attacks: shoot projectiles from afar + melee attacks in close range.
Projectile attack: Shoots 1 Fireball in the direction of player
Movement type: walks along path
Health: 20 HP
Monster 2 (Skeleton warrior)
Attacks: shoot projectiles + dashes.
Projectile attack: Shoots 3 Fireballs in 3 directions
Movement types: follows the player
Health: 25 HP
Monster 3 (Dark knight)
Attacks: melee attack only
Projectile attack: none
Movement types: follows the player + jumps at player
Health: 10 HP
Monster 4 (Slime blob)
Attacks: melee attack only
Projectile attack: none
Movement types: follows the player
Health: 5 HP
Then you can recycle enemies. Take an enemy that only shoots fireballs, and change the fireballs into ninja stars. Now you've got a new ninja enemy. You can also change sprite colors, and increase or decrease health, so you create a whole "family" of enemies. For example, blue bats cause -10 damage, red bats cause -20 damage and green bats cause -30 damage.
This way, by just mixing and matching things you can create as many enemy types as you want.
@pixeltroid -Yes, a system: A character or enemy has a place in an environment, and that environment is toxic, and there are lives in that environment that have adapted or become toxic. There is a utility that toxicity doesn't have in a game, and the player is trying to discern and determine how to accomplish goals by themselves or with others, to continue adapting to a toxic environment
A network of enemies that consort with each other and characters that take on those challenges with a player(s) who is/are the main character(s), has/have a developer(s) and writer(s)(or one person who does all the writing and development) oversee how all the resources in their situations and the terrain in the environment are distributed and designed, to control elements of a story and all the actions and events that equates to what goes on in that environment(a level or world).
The environment is a context for controlling and managing what goes on in a game in terms of the number of enemies and characters and determines what their strategies and tactics are vs. the player(s)(and this all has to be discerned by you or your team of developers and writers)
A player needs to discern their own logic to form a strategy, and the game's logic needs to be deciphered so that tactics can be understood
Changing the logical framework of the game(what rules are concerned with the game mechanics), changes the number of enemies that are needed, and the amount of time it takes to beat a level, or solve a puzzle, or complete a game.
Whether that is more or less content and time it takes to go through the content is up to you
Making a game is not so much about how a player is being rewarded, but why a player is being rewarded, because they are figuring out the logic they have discerned, and the game's logic that has been deciphered
Find the right multiplier for achievements and gauge the reward system to support the storyline and the content
Please also consider this: How a person goes up levels and achievements in a game. A player doesn't see the inner-workings of any logic at first and they understand the environment with their own logic. They start with a level of complexity they learn to simplify(and this changes their logic), and you as a programmer determine that complexity, and frame that logic for your game. In this way, you can determine how many enemies and characters you need, and things like, "where less is more". You can also change the complexity and increase the difficulty as the player graduates through levels or solves a puzzle so that solving a puzzle level or getting through an entire board has the impact that you expect with regard to the target audience you expect to play through your whole game((and I think it is always nice for a game to have a happy ending or a dark ending -at least have an ending IMHO)).