Contributing to Zeroclaw

[abhinavmathur-atlan]

Hey folks ,
I have recently started fixing few issues in the zeroclaw repo , they were low hangers but I would still like to contribute more , how could I contribute more

[Audacity88]

Hi @abhinavmathur-atlan, thanks for the fixes you have already landed. That is exactly the kind of contribution path we want to encourage.

For the next step, I’d suggest picking one area you want to go deeper on rather than only taking one-off low-hanging fixes. Runtime, providers, tools, channels, gateway, and docs all have useful follow-up work. If you name the area you are most interested in, we can help point you at a good next slice.

Also, please join the Discord if you have not already: https://discord.gg/zeroclaw. The community call there is a good place to meet the team, hear what needs help this week, and ask for quick scope feedback before investing in a larger change. If that conversation turns into concrete work, we can move the outcome back to a GitHub issue so it is tracked.

A good path from here:

• pick one area or issue;
• comment before starting if the scope is not obvious;
• keep the PR small and focused;
• include what you tested in the PR body.

Happy to help route you toward a larger follow-up if you say what part of ZeroClaw you want to work on next.

[abhinavmathur-atlan]

Hey @Audacity88, thanks for the detailed response!

I've been thinking about where to go deeper and I think tools, channels, and providers are the areas that excite me most. My day job involves a lot of MCP, LangGraph and deep agent work, and I've also built AI bots for Teams and Slack, so I feel like I can contribute more meaningfully in these areas.

I'd love your guidance on what's most useful across these and where I should start.

Also, I've already joined the Discord and looking forward to joining the community call, excited to meet the team and hear what needs attention this week!

[Audacity88]

Great, that helps. Given your Slack/MCP/provider background, the cleanest next step is probably one focused channel slice rather than a broad tools/provider architecture issue.

Best starting point: #6055. It is a Slack thread-context hydration issue: on the first bot mention in an existing thread, backfill prior thread messages with conversations.replies so the agent can answer with the context users expect. It is accepted, medium-risk, and already names the likely helper/path to start from. If you want to take it, please comment on #6055 first with the narrow scope you plan to implement: first-mention only, bounded history, reuse the existing Slack fetch helper, and no rehydration on every message.

A good second option is #7113, also Slack/channel-focused: show sanitized lifecycle progress while the agent is working. That one may need a little more runtime/event-shape care, so I’d start with #6055 unless progress UX is the part you’re most interested in.

For providers, #8094 could use a current repro before code work. If you can reproduce the Anthropic/Quickstart provider-refresh behavior on current master and identify what kind of reset fixes it, that would be useful routing evidence.

I’d avoid grabbing the broader MCP/tool-policy items as a first larger PR unless you specifically want to do a design/RFC pass. Some of those are high-risk or already have active ownership, so the Slack hydration slice is a better place to build context.

[abhinavmathur-atlan]

Hey @Audacity88, update on the two Slack slices you routed me to.

#7113 → #8985 (merged). Six typed agent lifecycle states carried as ProgressEvent through the runtime and the channel draft boundary, resolved to display text only at the Slack rendering edge via Fluent keys for all five built-in locales. Legacy raw tool status stays on a separate compatibility path. Supersedes #8978, with commit-level co-author credit to @sbenedetto for the DM lazy-draft fallback.

#6055 → #8969 (merged, partial). Implemented the narrow scope I proposed: first-mention only, bounded history behind thread_context_max_messages (default 0, max 50, opt-in), a channel+thread scoped atomic reservation so concurrent events do not duplicate backfill, and a hard three-attempt budget on conversations.replies that 429 retries count against, honoring Retry-After.

I deliberately did not close #6055. conversations.replies paginates ascending with no reverse cursor, so guaranteeing newest-adjacent context on every thread under a three-attempt cap needs a maintainer call: relax the cap, or accept best-effort bounded history as the contract. Happy to implement either once you pick one.

That is the channel-side context you suggested I build up before taking anything larger. I would like a bigger slice next, still in channels/tools/providers. Two I would take:

1. The [Feature]: Slack: hydrate thread context from conversations.replies on first mention #6055 follow-up above, if you want that contract settled and finished.
2. A design/RFC pass on one of the MCP/tool-policy items — you flagged those as needing that before code, and it is the closest to my day job.

Beyond those two, I am happy to take on whatever else is actually useful rather than only what I find interesting. A few things I can help with if they are a bottleneck:

• Reproducing and triaging open channel/provider bug reports on current master, the way you asked for on [Bug]: Anthropic provider added in Quickstart is unavailable in chat until reset #8094. I can turn vague reports into concrete repros with logs so they are routable.
• Reviewing incoming Slack, MCP, or provider PRs — I have enough context in those paths now to give useful review rather than drive-by comments.
• Extending the lifecycle and hydration work to other channels (Telegram, Discord, Signal) if you want that behavior to be consistent across the channel layer.
• Docs or config reference gaps in the areas I have touched.

If none of that is the priority, just point me at what needs hands this week and I will pick it up.

[Audacity88]

@abhinavmathur-atlan, great -- this is exactly the progression I was hoping to see. You took both Slack slices through the ownership and boundary questions rather than treating them as isolated feature patches.

For #6055, let’s accept best-effort bounded history and keep the hard three-attempt budget. I do not want to trade an unbounded or substantially larger Slack API scan for a newest-adjacent guarantee that conversations.replies cannot provide directly. The supported contract should be: fetch chronological context within the configured message cap and request budget, make truncation visible, and do not claim that every very long thread yields the newest N messages. I’ll record that disposition on #6055 and close it as completed by #8969.

For what you take on next, here are some suggestions; live testing and review can be combined where that makes sense:

• Live Matrix test and review — feat(matrix): add single-message progress drafts #8443. This is the clearest immediate evidence gap. Run a controlled exact-head turn in a disposable Matrix room and verify one editable progress draft, a separate final message, draft deletion, status versus full reasoning disclosure, and visible delivery when typing or draft I/O stalls. Post the redacted setup and observations on the PR, and turn any defect into a concrete review finding.
• Telegram progress — feat(telegram): show tool-call progress during partial streaming #6663. This is the most direct cross-channel extension of your Slack lifecycle work: add tool-call progress to Telegram's existing partial draft path without introducing new config or widening other channels. Include a real Telegram smoke for edit throttling, long-running tools, and final delivery.
• Approval-wait lifecycle bug — [Bug]: the typing indicator keeps running for the whole approval wait, so a blocked turn looks like a working one #9656. Fix the shared typing lifecycle so Telegram stops claiming the bot is working while it is waiting for approval, then resumes only when an approved turn continues. The useful proof is a live approve, deny, and timeout pass.
• Discord thread mode — [Feature]: Discord mention-triggered thread mode #7849. If you want a larger channel slice, implement the accepted mention-triggered thread mode with current behavior preserved by default. Keep it separate from general progress rendering and test normal-channel mention, existing-thread continuation, missing permissions, and fallback behavior against Discord.
• Catalog architecture review — RFC: Define the unified package/capability/config/runtime-state catalog contract #9346. Review whether the package/capability/config/runtime-state model stays honest across MCP, channels, and providers. The most useful checks are multi-capability MCP packages, configured/enabled state versus per-agent authorization, unresolved implementation collisions outside channels/tools, and real aliases and runtime-health evidence.

Small docs or config-reference gaps found while doing any of these can be proposed as focused follow-ups.