Report Bug

Reply in Russian. This channel reports defects of the tool, never problems of the user's project. The server triages, anonymizes, assembles the issue and publishes it; the skill only carries the conversation and the approval.

The plugin runs on commercial codebases. Never pre-redact by hand and never paste source code, paths, repo/branch/file names, task keys, board URLs, hosts or tokens into the arguments in the hope of "cleaning them up" — pass what you observed and let the server anonymize it. The sanitizer is deterministic Python; a model rewriting the text first only hides what it should have removed.

1. Decide whether it is ours. Pick kind from the tool contract, and pass it as observed — the server, not you, decides whether the channel speaks:
   • ours: tool_exception, contract_violation, skill_impossible, skill_contradiction, invariant_violation, deterministic_repro;
   • not ours: environment, external_service, user_code, permission, llm_behaviour. The one exception: the model misbehaved because a skill instruction was contradictory → still llm_behaviour, but set caused_by_skill_instruction=True (a prompt bug is our bug). A not_reported status is a normal outcome — report nothing to the user beyond a brief note.
2. Pick severity. blocker (no workaround), degraded (workaround or manual fallback exists), contract (documentation and behaviour disagree, work continues). Offer blocker and degraded immediately; the server marks contract with defer=true — collect those and offer them as one batch at the end of the session.
3. Preview (never skip). Call

   report_bug(kind=<kind>, summary=…, expected=…, actual=…, steps=[…], severity=<level>,
              tool=<mcp tool name>, skill_step=<skill and step>, error_class=<exception class>,
              details=…, repo=<owner/name>, branch=<branch>,
              client_environment={"orchestrator_model": …, "subagent_models": …,
                                  "mode": "subagent|inline", "cli": …, "cli_version": …},
              scale={"clusters": N, "files": N, "findings": N, "tasks": N},
              index_drift=<int or null>)
   

   without confirmed. Nothing is published. Handle the status: disabled — the channel is off for this repo or deploy, say so and stop; not_reported / suppressed — stop quietly.
4. Show and ask. Show the returned issue_text in full, verbatim — no summary, no abridgement — plus the target repository, the environment_keys list, and the identity_notice: the issue is published from the user's GitHub account and their username will be visible in a public repository; the alternative is to decline and open the issue by hand from the prepared markdown. Offer to trim the Environment block: any lines, or the whole block. Then ask for an explicit yes.
5. Publish only on an explicit yes. Repeat the same call with confirmed=True and, if the user trimmed anything, environment_exclude=[…] (or environment_include=[…]). In a headless, cron or background run there is no human to approve: pass non_interactive=True, which makes the server return a fallback markdown instead of publishing. Never publish autonomously in any mode.
   • published — report the issue URL.
   • commented — a matching open issue existed; report that a comment was added and give both URLs.
   • fallback — publication was not possible (no token, no rights, no network, headless): relay the reason, show the markdown and the fallback_url so the user can post it by hand. This is not a session failure — continue the work that was interrupted.
6. On a refusal call report_bug(kind=…, summary=…, decline=True) with the same arguments, so the same symptom is not offered again in this session.

Every read is fail-open, and the confirmed=True call is the only write. If the channel itself fails, say so in one line and carry on with the original task.