EGC[everything-gemini-code] A full Gemini CLI native port of ECC

[Jamkris]

Hello @affaan-m,

Thank you for building such a solid foundation with ECC. I was really inspired by your work and have created a full Gemini CLI native port based on it:

👉 Github
👉 Extension

What's included

Category	Count
Skills	182
Commands (TOML)	81
Agents	47
Workflows	51
Language rules	87 (15 categories)

Key changes from ECC

• All commands converted to Gemini CLI .toml format
• Agent tool names migrated to Gemini format (read_file, run_shell_command, etc.)
• model field removed from all agents (unsupported in Gemini CLI)
• Paths migrated: ~/.claude/ → ~/.gemini/, CLAUDE.md → GEMINI.md
• Full CI pipeline: lint, 122 tests, 4 validators, security audit — all passing
• Multilingual docs (English, Korean, Chinese)

Attribution

Full credit to you and the ECC contributors is prominently displayed at the top of the README. The original MIT license has been strictly preserved.

The project is still in its early stages, but I wanted to share it here in case anyone in the community uses the Gemini CLI and might find it helpful. Contributions and feedback are always welcome!

Related: #405

[affaan-m]

Thanks for preserving attribution and the MIT license. A Gemini-native port is exactly the kind of cross-harness experiment that is useful to see in the open.

The main thing I would watch is drift. Once commands, agent tool names, paths, and docs are translated into Gemini-specific formats, the port needs its own validation suite and a clear sync policy with upstream ECC. It sounds like you already have validators and tests, which is the right move.

From the ECC side, I would treat this as an ecosystem port rather than an official compatibility claim until the adapter surface is reviewed end to end. The reusable pieces are the skills/rules/workflow ideas; the harness-specific behavior has to be verified inside Gemini CLI itself.

If you keep the attribution clear and document what is changed versus copied, this is a helpful reference for future Gemini adapter work.

[Jamkris]

Thanks for taking the time to review it so carefully. Your feedback gave me a clear direction. Here are the three deliverables based on your three asks:

1. Documented sync policy → upstream/README.md. EGC syncs on a best-effort basis with no committed cadence; a solo maintainer can't reliably keep one, and a missed cadence is itself the kind of drift you flagged. Instead, drift is made mechanically visible — the last-synced ECC SHA is recorded in two places (in the README text + upstream/.upstream-sync.json), and a weekly GitHub Action (upstream-drift.yml) maintains a single rolling tracking issue when there is drift — live example: #60. A SHA mismatch between the README and the JSON is blocked at CI time by validate-upstream-sync.js. So the commitment is to surface drift, not to fix it on a schedule.

2. Ecosystem-port framing, not official compatibility → README disclaimer landed; upstream/README.md opens with the same framing. The doc explicitly says EGC's behavior is verified inside Gemini CLI itself, not by reference to ECC's Claude Code behavior. Also added a Conflict resolution clause: when an upstream change collides with Gemini-native surface area, Gemini CLI behavior stability wins over upstream alignment.

3. Changed vs. copied → category-level table in upstream/README.md covering Copied / Changed / Removed / Added. Category granularity (not per-file) so it stays maintainable — the repo itself is source of truth for the exhaustive list.

Korean and Simplified Chinese mirrors of upstream/README.md are included so non-English readers see the same framing.

The PRs that landed this:

• #56 — initial policy + framing + delta table
• #57 — folder restructure (upstream/) + badges + conflict-resolution + translations
• #58 — drift-tracker Action (Phase 1, log-only)
• #59 — Phase 2+3: rolling tracking issue + weekly cron + SHA validator + failure tracker
• #61 — post-smoke fix for an issue-body count display bug

Open to further feedback as the adapter surface evolves — your point about treating this as an ecosystem port rather than an official compatibility claim is exactly the framing the docs now use.

[affaan-m]

Thanks for the detailed follow-through. This addresses the review points I raised: drift is visible without pretending there is a guaranteed cadence, the docs frame EGC as an ecosystem port rather than official ECC compatibility, and the copied/changed/removed/added table gives readers the right mental model.

The weekly drift tracker plus SHA validation is a good practical boundary for a solo-maintained adapter. I will treat EGC as a useful reference point for future Gemini adapter work from the ECC side. Closing this thread as acknowledged and triaged; please open a new discussion or PR if the adapter surface changes in a way ECC should react to.