🚀 v1.2.0 Released - Unified Commands & Skills + Python/Django Support

[affaan-m]

Everything Claude Code v1.2.0 is now available!

This release brings major improvements including unified commands/skills architecture and comprehensive Python ecosystem support.

✨ Highlights

• Unified Commands & Skills Architecture - Major refactor merging command and skill systems for a cleaner developer experience
• Python & Django Support - Full Python development patterns including:
  • Python code reviewer agent with PEP 8, type hints, and security checks
  • Django patterns, security, TDD, and verification skills
  • pytest integration and async testing patterns
• Comprehensive CI/CD Pipeline - Automated testing and validation workflows
• Golang Language Support - Full Go development patterns

📚 Documentation

• New Quick Start guides in all README versions
• Simplified & Traditional Chinese translations
• The Shortform & Longform Guides to Everything Claude Code

🔗 Links

• Full Release Notes
• Installation Guide

🙏 Contributors

Thanks to all our community contributors:

• @Freakz3z - Python/Django support
• @Hor1zonZzz, @jhsong-musinsa, @pangerlkr, @msyahidin, @lichengzhe, @roeiba

---

Upgrade today:

/plugin update everything-claude-code@everything-claude-code

Questions or feedback? Drop a comment below! 👇

[MawJPhysics]

Forgive a simple question but when you add extra processes for different languages i.e. Python and Go. Is it not costly to have all this support at once or is it very efficient at choosing the right tool given a chosen language? Is there minimal gain, removing say, python related command and hooks if you only plan to code in Go? It's just i imagine /plugin update would also install everything for every language supported.

[pangerlkr]

Great question! You're right to consider the efficiency trade-off. Currently, the plugin loads all language agents (Python, Go, JavaScript/TypeScript reviewers, etc.) simultaneously regardless of which languages you actually use. This does consume context window space.

Current Architecture:

• All 13 agents are loaded via plugin.json at startup
• While Claude intelligently selects the right tools based on your files, having unused language agents still occupies valuable context tokens upfront
• Most hooks in hooks.json are language-agnostic (TypeScript checking, console.log warnings)

Impact:
For single-language workflows, there is indeed unnecessary overhead. If you only code in Go, having Python and JS/TS agents loaded consumes context that could be used for deeper code analysis or longer conversations.

Potential Solutions:

1. Configuration-based filtering - Allow users to specify enabled languages in plugin settings
2. Auto-detection - Load agents dynamically based on detected file types in the project
3. Separate language-specific plugins - Modular plugins that users can mix and match

This would be a valuable enhancement. The /plugin update mechanism already handles file synchronization well, so adding language filtering would integrate smoothly. Would you be interested in opening a feature request issue for modular language support?

[borzov]

Thanks for the great release! I have a couple of questions.

First, when using the ⁠/plugin update command, will all necessary files be pulled correctly? Just want to make sure the update process handles everything properly without needing manual fixes.

Second, are there any plans to make language support more modular? It would be nice to have an option to configure which language ecosystems to include, so users could enable only the languages they actually work with.

[pangerlkr]

Thanks for the questions! Let me address both:

1. Plugin Update File Synchronization

Yes, /plugin update handles file synchronization properly! It correctly pulls:

• Agents (from ./agents/)
• Skills (from ./skills/)
• Commands (from ./commands/)
• Hooks (from hooks.json)
• Plugin metadata (plugin.json)

Important limitation: Rules cannot be distributed via plugins due to Claude Code platform constraints. Users must manually copy rules after installation:

cp -r everything-claude-code/rules/* ~/.claude/rules/

This is a platform limitation, not a bug. Rules directory isn't part of the plugin update mechanism.

2. Modular Language Support

Not currently implemented, but this would be a valuable feature! Here's what could work:

Option A: Configuration-based filtering

// ~/.claude/settings.json
{
  "pluginConfig": {
    "everything-claude-code@everything-claude-code": {
      "enabledLanguages": ["javascript", "typescript", "python"]
    }
  }
}

Option B: Separate modular plugins

• Core plugin with shared utilities
• Language-specific extensions (python-support, go-support, etc.)
• Users install only what they need

This ties into the efficiency concerns raised by @MawJPhysics - having all language agents loaded consumes context window space unnecessarily for single-language workflows.

Would you like to collaborate on a feature proposal for this? I think the configuration-based approach would integrate most smoothly with the existing architecture.

[borzov]

Thanks for the detailed response and for your work on the project.

About the manual rules copying after updates — it would be great to add this to the main README so people don't scratch their heads wondering why things don't work after /plugin update. Maybe a separate "Updating the Plugin" section with that command?

Regarding modular language support — I'd vote for Option A (configuration-based). Here's why:

1. Simpler for users, one settings file vs installing/uninstalling multiple plugins
2. Easier to switch, working on different projects? Just change the config, no need to reinstall anything
3. Less dependency headaches, all agents from one source, no risk of version conflicts between separate plugins
4. Faster to implement, no need to split the project into multiple repos and keep them in sync

Option B looks more "architecturally correct", but in practice it would create more complexity for both project maintainers and users. What do you think?

[affaan-m]

2026 maintainer update: the modularity concern in this thread was valid, and the current repo has moved toward selective loading rather than treating the full catalog as the right install for everyone.

Current guidance:

1. Use the plugin path when you want the packaged Claude Code surface.
2. Use the manual installer when you want finer-grained profiles/components.
3. For low-context use, start with ./install.sh --profile minimal --target claude.
4. For core workflow without hooks, use ./install.sh --profile core --without baseline:hooks --target claude.
5. Keep rules/language packs scoped to the languages you actually use.

The older answer that all language support gets loaded together should not be read as the desired end state. The direction now is smaller always-on context, on-demand skills, and manifest-driven install profiles. Plugin update covers plugin-managed assets, while rules still have platform-specific distribution limits.

[borzov]

Thx