菜单
Fix a bug from a GitHub issue, following the reproduce-first workflow. Use when the user asks to fix a bug, investigate a GitHub issue, or debug a user-reported problem. Takes a GitHub issue URL or number as input.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | bugfix |
| description | Fix a bug from a GitHub issue, following the reproduce-first workflow. Use when the user asks to fix a bug, investigate a GitHub issue, or debug a user-reported problem. Takes a GitHub issue URL or number as input. |
Follow this workflow for GitHub issue bugfixes. Do not skip reproduction; fixing without first reproducing the bug tends to produce incomplete fixes and regressions.
A GitHub issue URL or number. Slash-command arguments are appended to this skill body by GLM Code.
Use .glm/issues/ in this repo. In the steps below, <issue-file> means the
selected issue markdown file.
Create the artifact directory if needed, then pipe the issue directly into a
markdown file using gh:
mkdir -p .glm/issues
gh issue view <number> \
--json number,title,body \
-t '# Issue #{{.number}}: {{.title}}
{{.body}}
---
## Reproduction report
_Pending - to be filled by the test engineer._
## Verification report
_Pending - to be filled by the test engineer._
' > .glm/issues/issue-<number>.md
Spawn the test-engineer agent and point it at <issue-file>. State only the
goal: reproduce the bug. Keep the prompt minimal; the test engineer owns the
reproduction strategy.
Wait for the test engineer to finish. Then read <issue-file> to get the
reproduction report. If the status is NOT_REPRODUCED, report that and stop.
Read the relevant code and make the fix. Use the reproduction report for context; it should contain observed behavior, expected behavior, and useful code paths.
If the bug is complex enough that the first attempt does not work, use the
structured-debugging skill and work through hypotheses systematically.
Build and bundle your changes:
npm run build && npm run bundle
Spawn the test-engineer agent again, pointing it at the same issue file. State
the goal: verify the fix using node dist/cli.js.
If the verification status is STILL_BROKEN, read the updated issue file, go
back to Step 3, and iterate. Do not proceed until verification returns
VERIFIED_FIXED.
Run unit tests for any packages you modified. If the test engineer wrote a failing test during reproduction, make sure it passes after the fix. Otherwise, add focused regression coverage for the failure scenario.
Skip this only for a plain one-line or trivial config fix. For anything else,
run /review with a review task listing all changed files. Triage each comment
with a verdict:
After fixing valid issues, re-run unit tests and a quick verification sanity check.
Answer any question about GLM Code usage, features, configuration, and troubleshooting by referencing the official user documentation. Also helps users view or modify their settings.json. Invoke with `/qc-helper` followed by a question, e.g. `/qc-helper how do I configure MCP servers?` or `/qc-helper change approval mode to yolo`.
Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, or `/review <pr-number> --comment` to post inline comments on the PR.
Review local code changes with git diff and update the official docs under docs/ to match. Use when the user asks to document current uncommitted work, sync docs with local changes, update docs after a feature or refactor, or when phrases like "git diff", "local changes", "update docs", or "official docs" appear.
Guide for running end-to-end tests of the GLM Code CLI, including headless mode, MCP server testing, and API traffic inspection. Use this skill whenever you need to verify CLI behavior with real model calls, reproduce user-reported bugs end-to-end, test MCP tool integrations, or inspect raw API request/response payloads. Trigger on mentions of E2E testing, headless testing, MCP tool testing, or reproducing issues.
Use GLM Code as a Code Agent for code understanding, project generation, features, bug fixes, refactoring, and various programming tasks
Automates terminal UI screenshot testing for CLI commands. Applies when reviewing PRs that affect CLI output, testing slash commands (/about, /context, /auth, /export), generating visual documentation, or when 'terminal screenshot', 'CLI test', 'visual test', or 'terminal-capture' is mentioned.