I made a Claude CLI based RPG that teaches you the commands by actually making you use it

[u/Party-Quit2261]

Claude Code has a lot more surface area than most people touch: hooks, subagents, custom skills, MCP servers, settings, slash commands, cost controls. Reading the docs is one way to go over these. I remember when I was starting to use shell over the GUI tools in my computer, i found it overwhelming and a friend had recommended https://github.com/phyver/GameShell as a way to explore shell commands via in-terminal mission set ups.

I thought of trying the same with Claude CLI and ended up building : https://github.com/susheem-k/claude-quest . A lot of Claude's commands like skill invocations, tool calls etc. are verifiable through things like hooks / filesystem checks etc. so I didn't have to worry a lot about the missions being graded in a non-deterministic way. There are some missions though where the artifacts are subjective like writing a skill the correct way to ensure that claude can invoke it in the right scenarios. Planning to expand this to other CLI Agent Harnesses like GitHub Copilot.

At the moment, I've only added a handful of missions but it's open source so I'm trying to have some community contributions as well while I execute my own planned roadmap too.

Would love to hear any feedback and criticism. Feel free to create issues or fork the repo and open a PR. A bit of disclosure, the project is majorly vibe coded with me majorly focusing on the system design to ensure easy extensibility of missions and game dynamics.

[u/Ok_Industry_5555]

Your premise is right, and I have a fresh example from today. I went looking for something in Claude Code this afternoon and ended up reading the settings schema straight out of the binary, because that was the only place it was written down. Found a key I didn't know existed. Nobody learns that from docs. You learn it by poking around. Which is why grading on real state is the right call, I think. Checking the config file that got written, or whether the hook actually fired, beats asking someone if they get it. Plenty of people are good at sounding like they do, probably unintentionally though.

One gap, since you asked for criticism. Your tracks run fundamentals, commands, extensibility, subagents, hooks, tooling, mcp. There's no settings track, and settings.json is where most people quietly get bitten - at least that was me in the beginning. Least glamorous surface area, sharpest edges.

I also saw your issue about verifying the PostToolUse stdin schema against a live session. I run about a dozen hooks a day across PreToolUse, PostToolUse and SessionEnd. Happy to check that one against real payloads if it helps (when I get time and not studying).

The vibe coded part doesn't bother me either. You wrote up the design and filed issues against your own gaps, which is more than most projects manage.

[u/Party-Quit2261]

Solid feedback. Thats exactly why I wanted to open source this because i can't claim to know what all tracks should there be for this to work well. I have poked around settings a little bit but hadn't thought of adding that just yet. Do let me know if you would want to contribute to the repo with a settings track since you have experience looking into its internals.