Zulip session operator
Use this skill when the current Claude Code session is already bound to a Zulip topic
through zulipchat-mcp-hook and you want the rest of the work to respect that
control plane.
Required setup
- Read
ZULIPCHAT_SESSION_ID,ZULIPCHAT_SESSION_STREAM, andZULIPCHAT_SESSION_TOPICfrom the shell before using any ZulipChat MCP tools. - If
ZULIPCHAT_SESSION_IDis empty, stop and explain that the hook bridge has not initialized the session binding yet.
Operating rules
- Treat Zulip as the owner control plane for this session.
- Poll
poll_agent_events(session_id=..., limit=20)at the start of each work cycle, after each meaningful unit of work, and before going idle. - Interpret inbound events this way:
steer: treat the message as a high-priority owner instruction.command: support/status,/pause,/resume,/cancel, and/handoff.approval_response: only consume it when tied to a pendingrequest_user_inputapproval flow.
- Default notification policy is lifecycle-only. Use
agent_messageonly for:started,blocked,waiting,completed,failed, or a targeted owner message that materially changes execution. - If you need a decision from the owner, call
request_user_inputinstead of posting a freeform message. - Never spam the topic with token-by-token progress. One message per state transition is the expected behavior.
- If you are running inside Claude's native loop mode, keep the same poll-work-post discipline for every loop turn.
Command handling
/status: send one concise status update covering current goal, next step, and any blockers./pause: acknowledge, stop proactive work, and wait for a new owner message./resume: acknowledge and continue from the current plan./cancel: confirm the cancellation in the topic, stop work cleanly, and close the session if appropriate./handoff: summarize state, remaining work, and risks for whoever takes over next.- Any other slash command: reply once that it is not authorized or not supported by this session policy.