Command Code Taste: Preferences and Skills Explained

3 min read

,
Command Code taste setup with preferences vs skills

If you’re tired of asking a coding agent to make the same style choices in every project, Command Code Taste is meant to learn those preferences. Skills solve a different problem: they spell out the steps for a task you want done the same way each time. Taste remembers preferences; a Skill gives the agent a playbook.

What Taste saves

Taste builds a profile from patterns in your Command Code work. The result is stored as readable Markdown in taste.md files, organized by project or preference area. You can inspect and edit those notes instead of treating the profile like a hidden setting.

For example, a Taste note might record that you prefer small focused functions or a particular project structure. A Skill is better for a repeatable procedure, such as the checklist you want followed before preparing a release. Preferences are learned; a workflow is deliberately written down.

Build a Taste profile from a project

Open the repository in Command Code and run /learn-taste. The onboarding command can build a starting profile from an existing repository or sessions from other coding agents. Taste can also keep learning during normal work, so the first profile is a starting point rather than a final verdict.

Then open /taste to review the settings. Project learnings live under .commandcode/taste/. Personal preferences that should follow you between projects belong in ~/.commandcode/taste/. Keep project-specific conventions with the project, and put preferences that genuinely apply everywhere in your personal profile.

Review the profile before relying on it

Read the generated taste.md files. Remove anything that is too broad, based on a one-off decision, or no longer matches how you work. Taste is there to reduce repeated corrections, not to turn every past choice into a permanent rule.

Check the learning setting too. You can turn Taste off for the current project with cmd taste disable, or change the user-level setting across projects with cmd taste disable --user. A project setting can override your user preference, so check .commandcode/settings.local.json and the project settings if the behavior surprises you.

Use a Skill for a workflow

When the instruction is a sequence of steps, write a Skill. Command Code looks for Skills in .commandcode/skills/ and also supports the shared .agents/skills/ directory. Each Skill is a folder with a SKILL.md file containing its name, when to use it and the instructions to follow.

A simple test: “I prefer named exports” is a Taste preference. “Before opening a pull request, run these checks in this order and report failures” is a Skill. If a rule must be followed precisely every time, don’t rely on Taste to infer it from a handful of examples.

Lint before sharing

Before sharing or committing the profile, run npx taste lint --all. It checks the Taste Markdown structure and required fields, including confidence values. Fix errors first, then read the files once more yourself. Lint checks format, not whether a preference is accurate.

To upload the whole project profile to Command Code Studio, the documented command is npx taste push --all. That sends the project’s Taste packages to your remote profile. Review them first, especially if the project contains client-specific conventions or internal details. To bring a shared profile into a project, use npx taste pull username/project-name and inspect what it adds.

Which one should you set up first?

Start with Taste if you find yourself correcting the same code-style choices across sessions. Start with a Skill if you have a useful checklist or task procedure you want Command Code to follow on demand. You can use both without putting the same instructions in each.

Share this story

About the author