English | 中文

Bring web-login, CLI-first AI capabilities back into a Claude Code or LikeCode-centered workflow.

This repo is already useful as more than a loose idea dump.

Three concrete trust signals matter:

• it has runnable umbrella wrappers such as usecli-codex.sh and usecli-gemini.sh
• it ships a local smoke test in tests/test_wrappers.sh instead of leaving verification as a future promise
• it keeps the umbrella-vs-plugin split explicit, so provider quirks do not pollute the top-level control-plane story

If you only have three minutes, read this repo in this order:

1. skim this README for the control-plane model
2. run bash tests/test_wrappers.sh
3. open registry/plugins.md to see what belongs in the umbrella repo versus the *-plugin-cc family
4. open docs/repo-strategy.md if you want the split rule for umbrella repo vs provider repo
5. open examples/README.md if you want the shortest provider-ready demo matrix
6. open docs/workflows/multi-model-review.md if you want a concrete multi-model workflow

If you want the shortest proof that this repo is usable, not only conceptual:

1. run bash tests/test_wrappers.sh
2. run bash tests/test_plugin_family.sh if the sibling *-plugin-cc repos are present under the same projects/ root
3. read examples/README.md to pick one provider-ready wrapper path
4. then read docs/workflows/multi-model-review.md
5. if your local provider CLIs are already available, run bash examples/workflows/multi-model-review.sh examples/prompts/review.txt examples/outputs/manual-proof

The umbrella smoke test gives a no-login baseline. The family smoke matrix proves the umbrella repo is not recommending an unverified plugin story. The examples matrix gives the clearest provider-ready first run. The workflow script gives the clearest end-to-end demo path.

When this repo is used as the umbrella control tower, the next useful question is not only "does the umbrella wrapper run?" but also "does the current plugin family still hold together?"

Use:

bash tests/test_plugin_family.sh

By default it looks for sibling repos such as gemini-plugin-cc, qwen-plugin-cc, grok-plugin-cc, cursor-plugin-cc, qoder-plugin-cc, and trae-plugin-cc under the same projects/ root. Missing repos are reported as skips; present repos run their own smoke tests in sequence.

This repo is strongest when you read it in two complementary modes instead of only one.

If a reader only wants to know "can I use this now?", send them to the first row. If a reader wants to know "why is this repo structurally interesting?", send them to the second row.

A natural question is:

Why not just use Claude with an API?

Because that is not the real problem this project is solving.

Many useful AI products today do not expose their best value through a normal public API. The real pattern is often:

• you log in through a web flow
• your entitlement is attached to an official CLI
• you have free quota or a paid subscription
• but there is no matching public API for the same benefit

That means the capability exists, but it is trapped inside someone else's CLI.

This repository exists to break that isolation.

It is about turning:

• codex exec
• gemini
• grok
• qwen
• cursor
• copilot
• qoder
• trae

into callable workers inside a Claude Code or LikeCode workflow.

Most heavy users do not want seven terminals open at once.

If your real work already happens in Claude Code, then the problem is not "how do I get another API key?" The problem is:

• how do I reuse web-login-only model capability inside my main workflow?
• how do I use different models for different strengths in one task?
• how do I avoid switching tools every time I want a second opinion?

In practice, different models are good at different things:

• some are better at coding
• some are better at planning
• some are better at review
• some are cheaper for bulk work
• some are stronger for high-value final passes

Claude Code is powerful, but its native experience is still largely centered on a single provider/model path at a time. Even when subagents exist, they usually still inherit the same underlying model family. This project is about escaping that limitation.

Claude Code or LikeCode stays the control plane.

External CLIs become specialized workers.

Instead of treating every model as "one more chat tab", we treat each provider CLI as an executable agent.

Examples:

• usecli:gemini
• usecli:qwen
• usecli:codex
• usecli:grok

Under that umbrella, provider-specific repos can stay detailed:

• codex:review
• codex:generate-doc
• gemini:paper-review
• grok:critic

The umbrella repo stays simple and memorable:

• usecli:gemini
• usecli:codex
• usecli:qwen
• usecli:grok

One of the motivating workflows was paper review and coding review with multiple model CLIs in the same task.

The rough pattern looked like this:

1. Use one model to read and critique a paper.
2. Use another model to generate or refine API docs.
3. Use another model to challenge assumptions or review code.
4. Keep Claude Code as the main cockpit for context, files, edits, and orchestration.

That exposed a very concrete gap:

• Claude Code was the best main workspace
• but external model capacity often lived inside CLI tools with web login
• and those capabilities did not naturally flow back into the main coding loop

That gap is the birth of this repository.

everything-agent-cli-to-claude-code is not only an index of plugin repositories.

It is also meant to become a skill surface.

That means this repo has two jobs:

• collect and standardize provider integrations
• expose clean umbrella entrypoints that are pleasant to use inside Claude Code / LikeCode

So the design is intentionally split:

• detailed provider repos hold provider-specific wrappers and commands
• this umbrella repo holds clean top-level skills and workflows

flowchart LR
  A[Claude Code / LikeCode] --> B[umbrella skill: usecli:*]
  B --> C[provider wrapper]
  C --> D[official provider CLI]
  D --> E[web-login entitlement / subscription quota]
  E --> D
  D --> C
  C --> B
  B --> A

This is the central idea:

• keep the main workspace in Claude Code / LikeCode
• use official CLIs as execution surfaces
• recover otherwise isolated model capability through skills and workflows

This repository is the umbrella repo for the *-plugin-cc family.

It owns:

• positioning
• architecture
• specs
• workflow conventions
• umbrella-level usecli:* skills
• examples
• plugin registry

It is intentionally the control tower, not the permanent home of every provider-specific implementation detail.

The split is deliberate:

If a detail only makes sense for one provider, it should usually move down into that provider's own repo.
If a pattern should stay stable across providers, it belongs here.

• Umbrella repo: https://github.com/Harzva/everything-agent-cli-to-claude-code
• Gemini plugin: https://github.com/Harzva/gemini-plugin-cc
• Grok plugin: https://github.com/Harzva/grok-plugin-cc
• Qwen plugin: https://github.com/Harzva/qwen-plugin-cc
• Cursor plugin: https://github.com/Harzva/cursor-plugin-cc
• Copilot plugin: https://github.com/Harzva/copilot-plugin-cc
• Qoder plugin: https://github.com/Harzva/qoder-plugin-cc
• Trae plugin: https://github.com/Harzva/trae-plugin-cc

This repo is useful because it does not treat "CLI agent" as only a product ranking problem.

It treats Claude Code or LikeCode as the control plane, then asks a more operational question:

• how do we recover capability that is trapped inside official provider CLIs?
• how do we compose those CLIs into one review / planning / coding workflow?
• how do we turn isolated login-bound tools into reusable workers?

That makes it a strong companion repo for the site's CLI Agent topic:

• it connects Claude Code / Codex / Gemini / Qwen / Grok
• it also leaves room for Cursor / Copilot / Qoder / Trae plugin-style bridges
• it focuses on orchestration and workflow reuse instead of only comparing shell UX

• bin/: umbrella-level wrappers
• docs/: positioning, transport, architecture, workflow docs
• examples/: prompts and runnable workflow examples
• plans/: project plans and source ideas
• registry/: plugin registry and links
• skills/: umbrella-level usecli:* skill entrypoints
• specs/: naming and contract documents
• templates/: starter material for future plugin repos

The repository now includes a local wrapper smoke test:

• tests/test_wrappers.sh

What it verifies:

• each umbrella wrapper exposes help successfully
• usecli-codex.sh, usecli-gemini.sh, usecli-qwen.sh, and usecli-grok.sh build the expected command line
• examples/workflows/multi-model-review.sh writes the expected output files when provider CLIs are replaced by mocks

Run it with:

bash tests/test_wrappers.sh

For the next step after the smoke test, see:

• docs/workflows/multi-model-review.md

• docs/positioning.md
• docs/repo-strategy.md
• docs/transports.md
• docs/architecture.md
• docs/workflows/multi-model-review.md
• specs/skill-naming.md
• specs/command-skill-contract.md
• registry/plugins.md

The first practical goal is not to build a perfect universal protocol.

It is to make this feel natural:

• stay inside Claude Code / LikeCode
• call another model through its official CLI
• capture the result as part of the same task
• compose several model CLIs into one reusable workflow

If that works well, then multi-model coding and review becomes much more realistic for everyday use.

1. Keep verifying wrappers against real local CLIs.
2. Promote more scaffold providers into verified integrations.
3. Expand usecli:* umbrella skills.
4. Push multi-model review, planning, and doc-generation workflows.
5. Evolve from one-shot command wrappers toward structured local transports.