You can model your game as a (set of) finite state machine(s), where each state (vertex) has a number of valid transitions (directed graph) to progress the story depending on both the game's state and the player's input. Most adventure games have at least one FSM modelling the current player's location, but you can have more than one to handle things like puzzles, timers, NPCs and so on, depending on how complex your game will be.
Understanding the player's input is historically one of the hardest things to get right. There's no miracle solution, but generally you'll have to identify at least the verb (= action) and optionally one or more objects to act on. Tokenize the input and try to make sense of it. I recommend handling a fair amount of synonyms too, unless you want to frustrate users.
You can study some classic adventure games like battlestar (https://github.com/NetBSD/src/tree/trunk/games/battlestar
), though code quality has come a long way since the early 80s. I'd also recommend studying adventure (https://github.com/NetBSD/src/blob/trunk/games/adventure
) as an example on how NOT to write an adventure game.