The standard workflow for sharing team conventions goes like this: someone writes a style guide, it's accurate for a few months, then the codebase evolves and the guide doesn't.
New developers follow outdated rules. Senior engineers catch it in review. The correction happens too late. Taste doesn't have this problem. It updates every session. The registry is how you share it.
taste push and pull
The commands are intentional:
1# Push your taste to the registry
2npx taste push --all
3
4# Pull someone's taste into your project
5npx taste pull ahmadawais/clipush reads your local .commandcode/taste/ directory, segments constraints by package, and uploads each package to commandcode.ai/username/taste.
pull fetches the specified profile, writes it to your local .commandcode/taste/, and registers it as a prior in the local taste-1 constraint solver. The pulled profile doesn't override your local signals. It biases them. Your behavior shapes the final result.
Two other commands worth knowing:
1npx taste list # list all available packages (project, global, remote)
2npx taste open cli # open a specific package in your editorWhat a taste profile actually is
A taste profile is a set of symbolic constraints with confidence scores, derived from the RL loop over your accept/reject/edit signals:
1## TypeScript
2- Use strict mode. Confidence: 0.80
3- Prefer explicit return types on exported functions. Confidence: 0.65
4- Use type imports for type-only imports. Confidence: 0.90
5
6## CLI Conventions
7- Use lowercase single-letter flags (-v, -h, -q). Confidence: 0.90
8- Version format: 0.0.1 starting point. Confidence: 0.90
9- Include ASCII art welcome banner. Confidence: 0.80
10
11## Error Handling
12- Use typed error classes. Confidence: 0.85
13- Always include error codes. Confidence: 0.90
14- Log to stderr, not stdout. Confidence: 0.75The confidence scores are the output of the RL loop, not metadata attached manually. A constraint at 0.90 has been observed consistently across many sessions. A constraint at 0.65 is still forming. taste-1 weights them accordingly during generation.
Three layers of taste
Taste lives in 3 places:
Project taste lives at .commandcode/taste/ inside your project. This is where the RL loop writes as you work.
1your-project/
2└── .commandcode/
3 └── taste/
4 ├── taste.md
5 ├── cli/
6 │ └── taste.md
7 ├── typescript/
8 │ └── taste.md
9 └── architecture/
10 └── taste.mdGlobal taste lives at ~/.commandcode/taste/. It follows you across all projects on a machine. Test runner preferences, error handling style, logging conventions: things that aren't codebase-specific go here.
Remote taste lives at commandcode.ai/username/taste. This is the registry. It's what enables sharing, backup, and sync across machines.
Packages for team efficiency
Taste is scoped into packages so teams can share only what's relevant. A frontend team doesn't need to pull backend API conventions. A new hire working on tests doesn't need the CLI package.
1npx taste push cli # push only the cli package to remote
2npx taste push cli -g # push cli package to global
3npx taste push typescript -g # push typescript package to globalPulling is explicit:
1npx taste pull ahmadawais/cli # CLI taste from Ahmad
2npx taste pull username/project-name # full project taste
3npx taste pull ACME/api # API patterns from ACME's team profile
4npx taste pull cli -g # pull your own cli package from globalEach developer pulls only the packages they need. Packages compose without interfering with each other.
Team workflow
Your Senior Engineer's Taste, One npx taste pull away
1npx taste pull {org-name}/{project-name}A new contributor pulls their senior engineer's taste before writing single line of code. Once the conventions are right, the senior engineer publishes the update so everyone else can sync it instantly:
Your conventions, One npx taste push away
1npx taste push --allThe agent generates code already shaped by the team's conventions. Local signals adapt the pulled profile over time. If the new developer consistently rejects a pulled constraint, it drops in confidence. They can decide if it's a real divergence or a mistake.
When the senior engineer pushes an update six months later, new joiners get it on next pull.
Open source
Open source maintainers can publish taste profiles for contributors. When you clone a repo, you can pull the maintainer's taste and start generating code that already matches the project's conventions before your first PR:
1npx taste pull maintainer/projectTry It
1npm i -g command-codeSign up for Command Code. Install it, run cmd, write some code, accept and reject a few suggestions. Check .commandcode/taste/taste.md after a day.
You'll see your own patterns reflected back at you. Patterns you never bothered to document because you didn't think they mattered.
They mattered. The AI just couldn't see them until now.

