Seems like a good start!

From my previous experiences with parser-based interactive fiction, I generally expect "inventory" or "inv" to list what I'm currently carrying. It's also fairly common to support abbreviations for directional movement: {n, s, e, w, u, d} for "north", "south", "east", "west", "up"  and "down" . It's very uncommon for navigation to use anything other than those directions, half-increments (northeast/ne, southwest/sw, etc), and very occasionally "enter PLACE" or "exit PLACE".

You can use the "in" or "like" primitives in Lil to check whether a string is one of several alternatives; "in" looks for inclusion in a list or dict keyset, while "like" looks for a glob pattern where "*" is a wildcard:

 verb:"north"
 
 verb in ("north","n")
1
 verb in ("east","e")
0
 verb like "n*"
1
 verb like "e*"
0

It's also a very important convention for room descriptions to clearly indicate the directions a player may exit, unless there's a reason to obscure it. So far as I can tell, the only way to discover the door in your room is to attempt (based on intuition) to go "down".

I was thrown off by having to use "take", since I'm more used to writing "get" for taking objects in these games. In general implementing the common synonyms may be handy (examine as well as look etc) as well as there's some common single letter abbreviations (like the directions IJ mentioned above but also like x for examine). I also noticed the mention of the door disappeared from the room description once I'd started doing things like using the hammer to break the window or the mirror - guessing this is an oversight?

Otherwise I'd second the feedback Internet Janitor mentioned. I'm guessing also there'll be some sort of "I don't know that word" messages for unknown commands in future?

I spent some time yesterday thinking about how we could reduce and untangle all the conditional logic in building parser-based IF in Decker, and I came up with a few thoughts. If we represent rooms within a game as cards, and objects within those rooms as widgets, we could use Decker's ordinary event-sending mechanisms to drastically reduce the amount of repeated logic, so that instead of having to write:

 # (imagine this surrounded by a huge pile of other semi-related repetitive logic)
 ...
 if (obj~"battery")&(verb~"lick")
  printf["tastes sparkly!"]
 end
 ...

It's only necessary to write an event handler on the "battery" widget:

on lick do
 println["tastes sparkly!"]
end

And everything is broken up into tidy logical pieces instead of one gigantic script.

Give this a spin and then poke around inside to see if it provides any useful ideas:

http://beyondloom.com/decker/goofs/ifparser.html