It looks like it's based on two main classes, which make sense in context of the physicality of board games. You have things you move around (`Piece`s), in your hand, from player (`Player`) to player and onto different spaces on the table itself (`Space`).
So for game you'd need your dice and your cards to be defined subclassing `Piece`, and give them to your players (which subclass `Player`) and maybe also to a Teller (also `Player` who manages the deck, before thinking about which instances of `Space` you'll need to set up on your board for your rules.
Your rules all in an instance of the `Game` class and it itself has this concept of actions, at their core instances of the `Action` class. Those take arguments that allow you to write the prompts for the user, define when the action is legal in play, and what effect it should have.
Beyond that the API then just kicks in and seems to have a lot of handy functions for finding pieces, making comparisons, all the stuff you expect. Beyond that just depends on your game logic.
There's also some handy functions to filter for different Spaces and Pieces so that you can build up the UI logic quite quickly, judging by the examples.