[Feature]: prefer lighter ZeroClaw

[ilteoood]

Summary

Remove from the codebase those tools that you can interact with using skills

Problem statement

At the moment ZeroClaw has some dedicated code for integrations like:

• gws-cli
• jira
• github (planned, according to the web ui)
• ...

But instead of creating ad-hoc code, wouldn't be better to keep ZeroClaw lean and suggest the users to use skills or mcp servers?
For example,

• gws-cli provides a set of skills based on the resource you want to interact with
• jira has the official atlassian mcp server
• github has the gh cli with the related skill

This allows us to make the codebase cleaner and focused on interacting with the models and giving them tools/skills to operate

Proposed solution

• Remove all the dedicated code
• Start suggesting external tools usage

Non-goals / out of scope

No response

Alternatives considered

No response

Acceptance criteria

No response

Architecture impact

No response

Risk and rollback

No response

Breaking change?

Yes

Data hygiene checks

• I removed personal/sensitive data from examples, payloads, and logs.
• I used neutral, project-focused wording and placeholders.

[Audacity88]

Triage Summary

Type: Enhancement / architecture proposal

Priority: Medium

Area: tool, skills, tool:mcp, domain:architecture

Risk: High

Summary: This lines up with the accepted microkernel direction in #5574: ZeroClaw should keep the runtime lean and move long-tail integrations out of the core where possible. I would not start with “remove all dedicated code” as the implementation plan, though. The useful next decision is the boundary between first-party built-in tools, optional/plugin tools, skills, MCP servers, and CLI-backed integrations.

Duplicates/Related: No exact duplicate found. Related to #5574 for the broader microkernel/plugin architecture and #5873 for binary-size pressure. #6065 is also nearby in the MCP direction, but it is about Xcode integration rather than removing bundled integrations.

Actionability: Needs design decision before implementation. A good next step would be an RFC/design pass that inventories current and planned built-ins, defines criteria for what belongs in core versus external integrations, and lays out a migration/deprecation path. After that, individual removals or feature-gating changes can be split into narrow PRs.

Repro quality: N/A for a feature request. The direction is clear, but acceptance criteria and migration details are not yet specific enough for direct implementation.