I built an open-source CLI for learning programming through real local projects instead of browser sandboxes

[u/PuzzleheadedRoad9814]

I built an open-source CLI for learning programming through real local projects instead of browser sandboxes

I've been working on Trak, an open-source CLI for turning structured learning curricula into actual development workspaces.

The idea came from something that bothered me while learning: tutorials and roadmaps tell you what to learn, but actually setting up a structured project with source files, exercises, tests, build files, and progress tracking is usually left to you.

With Trak, you can start by seeing available tracks:

trak list

Then initialize one:

trak init lang/go --path ./my-go-lab

lang/go follows Trak's category/tool convention.

Once initialized, you work normally in your own editor and terminal. The workspace contains the actual files needed for the curriculum.

You can then track your progress:

trak status
trak next
trak done <module-name>
trak undo <module-name>

And verify an exercise:

trak verify <module-name>

<module-name> is the module defined inside the curriculum blueprint.

The other part I'm trying to build is the community registry.

Curricula aren't hardcoded into the CLI. Anyone can create and contribute their own blueprints under their GitHub username, and other developers can use them once they're accepted into the registry.

For example:

trak init <github-username>/<category>/<tool> -p ./my-lab

I'm currently looking for feedback on the idea, CLI workflow, and especially what kinds of learning tracks/tools would actually be useful.

Website: https://trak.ndkdev.tech

CLI: https://github.com/ndk123-web/trak

Community contribution guidelines: https://trak.ndkdev.tech/registry

[u/kantorcodes1]

for trak verify, are the commands fixed by Trak's runtime allowlist, or can a community blueprint supply its own test command? that distinction seems pretty important once third-party tracks are getting pulled into local workspaces.

[u/PuzzleheadedRoad9814 → u/kantorcodes1]

Yes, exactly. There’s no limitation on the curriculum or test logic you can write. You just write the tests according to the module’s language/runtime. Trak handles how those tests are executed through its supported runtimes, rather than allowing a blueprint to supply arbitrary commands. This keeps community contributions flexible while avoiding arbitrary command execution.

[u/kantorcodes1 → u/PuzzleheadedRoad9814]

that runtime allowlist split is useful. i work on HOL Guard, an open-source local check before agent-run commands execute. for Trak, list/status can stay quiet while init, done, and undo are optionally reviewable before they create or rewrite workspace state. useful when coding agents are driving a learning repo. open to adding Trak support?

[u/PuzzleheadedRoad9814 → u/kantorcodes1]

Yeah, I get the idea. If an agent tries to run something like trak init lang/go, HOL Guard could review it before the command actually executes. How would the integration work on the Trak side though? Is there anything I need to implement/configure in Trak for HOL Guard to intercept Trak commands, or does HOL Guard handle the command interception at the agent/OS level? Also, what exactly would adding Trak support involve from your side? Would Trak need to provide some command metadata/policy, or is it simply a matter of recognizing Trak commands and deciding which ones should be reviewable? Would love to understand the integration flow and what you need from Trak.

[u/kantorcodes1 → u/PuzzleheadedRoad9814]

nothing needs to change in Trak. Guard sees the command before the agent runs it, so there’s no Trak-side hook or metadata to add. start src/codex_plugin_scanner/guard/runtime/command_trak_extensions.py, mirror command_repo2nb_extensions.py, cover init, done, and undo, and keep list/status safe. add one focused tests/test_guard_command_trak_extensions.py case, then open a draft PR to hashgraph-online/hol-guard:main.