Command Code

Command Code is the teammate that doesn't just follow a rules file — it watches accepts, rejects, and edits, then compounds that into project taste under .commandcode/. When I want a CLI agent that gets closer to how I actually ship, this is who I call.

#How Command Code helps me

Cursor owns the IDE. OpenCode owns open, provider-flexible TUI sessions. Command Code is the CLI agent that tries to learn how I write — not only what I paste into a system prompt.

Every accept, reject, and follow-up edit is a signal. Over time that becomes taste packages in .commandcode/taste/ that travel with the project. For a site like nzian.xyz — strict template conventions, "don't invent a second design system," PHP builders instead of a SPA — that kind of memory matters.

#Workflow

Typical session:

1. Install globally (npm i -g command-code), then in the repo run cmd (on Windows the alias is often cmdc).
2. Trust the folder once; log in if the session needs it.
3. Optionally /import cursor (or Claude / OpenCode) so existing rules aren't starting from zero.
4. Give a concrete task: "add a team member page matching github-copilot.md."
5. Accept / reject / edit deliberately — those choices feed taste for the next pass.
6. When a pattern stabilizes, taste push / taste pull so another machine or teammate gets the same conventions.

For scripts I use headless -p so Command Code does one prompt and exits, same idea as opencode run.

#Strengths

• Taste compounds. Rules files go stale; observed accepts stay closer to how I actually merge code.
• Terminal-first, hackable. Skills, slash commands, MCP, plugins — the harness is meant to be extended, not only chatted with.
• Import path. I can bootstrap from Cursor / Claude / OpenCode instead of retyping every convention.
• Shareable taste. Push/pull makes "how this repo likes PHP templates" a portable artifact, not tribal knowledge in my head.
• Model choice. Works across frontier and open models; useful when I want the harness tuned for tool-calling rather than a generic chat wrapper.

#Limits

• Younger on my bench than Cursor. Daily shipping still defaults to the IDE agent; Command Code is for terminal sessions and taste experiments.
• Windows naming. cmd conflicts with the shell — use cmdc or the full command-code binary and save yourself confusion.
• Taste needs honest signals. If I rubber-stamp bad diffs, it learns the wrong habits. Review still matters more than the marketing pitch.
• Node floor. Needs a current Node LTS; older environments won't start. Keep that in mind on older VPS images.
• Not a substitute for architecture. Big "should we rebuild this?" questions still go to Claude; Command Code executes with taste, it doesn't replace judgment.

#Tips

• Run /learn-taste or cmd learn-taste after a stretch of real edits so the profile reflects the repo you have, not a blank slate.
• Keep .commandcode/taste/ in review like any other config — it's code that shapes future agents.
• Import Cursor rules once, then let taste refine the gaps instead of maintaining two conflicting instruction piles forever.
• On Windows, standardize on cmdc in docs and muscle memory.
• Same agent hygiene as everywhere else: scoped prompts, validators after edits, no blind commits.