fix-issue
Fix a GitHub issue by number. Reads the issue, implements a fix, and prepares a commit.
- License 许可
- MIT
- 最近更新
- 2026-05-15
- Stars
- ★ 13
- Forks
- 1
01 前言 Front Matter
- name
- fix-issue
- title
- fix-issue
- description
- Fix a GitHub issue by number. Reads the issue, implements a fix, and prepares a commit.
- allowed-tools
- Bash(gh issue view *) Bash(gh issue list *) Read Grep Glob
- argument-hint
- [ "issue-number" ]
- disable-model-invocation
- true
02 资源文件 4
- 脚本_lib/browse-client.ts11.3 KB
- 参考文档fixtures/hn-2026-04-26.html5.0 KB
- 脚本script.test.ts3.8 KB
- 脚本script.ts4.6 KB
03 SKILL.md 正文
Fix GitHub issue
Step 1: Read the issue
Run:
gh issue view $ARGUMENTS
If the issue does not exist or the gh CLI is not authenticated, stop and report the error. Do not proceed.
Step 2: Understand the requirements
From the issue output, identify:
- The reported problem or requested feature
- Any reproduction steps or acceptance criteria mentioned in the issue body
- Labels that indicate the type of work (bug, enhancement, documentation, etc.)
- Any linked issues or pull requests that provide additional context
If the issue is unclear or underspecified, state the assumptions you are making before proceeding.
Step 3: Find the relevant code
Search for code related to the issue:
- Use
grep -rto find files referencing the relevant function, component, or error message - Read the most relevant files to understand the current implementation
- Identify where the change should be made and why
Step 4: Implement a minimal fix
Make the smallest change that correctly addresses the issue. Follow the existing code patterns in the affected file:
- Match the style, naming conventions, and error handling patterns already in use
- Do not refactor unrelated code
- Do not add features beyond what the issue describes
Step 5: Write or update tests
If the codebase has tests:
- Add a test that fails before the fix and passes after
- Update any existing tests that are affected by the change
- Run the existing tests to confirm nothing is broken (use the test runner you find in
package.jsonor the nearest test configuration file)
If you cannot determine the test runner, note that and ask the user.
Step 6: Prepare a commit message
Stage the changes and write a commit message in this format:
fix: <short description matching the issue title>
Fixes #$ARGUMENTS
Do not commit automatically. Present the staged diff and the proposed commit message, then wait for the user to confirm or adjust before committing.
04 同仓库更多 Skills
tag-version
Bump the package version and create an annotated git tag. Accepts a semantic version number (1.2.0) or a bump type (patch, minor, major). Does not push — use the publish skill to push. Use as part of a release workflow.
release
Run the complete release workflow: changelog entry, version bump, git tag, and GitHub release. Invokes changelog-entry, tag-version, and publish in sequence. Use when releasing a new version of the project.
publish
Push the current branch and all tags to origin, then create a GitHub release using the latest tag and its CHANGELOG.md entry. Use after tag-version to complete a release.
changelog-entry
Draft the changelog entry for all unreleased commits in Keep a Changelog format. Groups commits into Added, Changed, Fixed, Removed, and Security. Use before releasing a new version or when updating CHANGELOG.md.
auto-format-on-edit
Automatically format code files after every edit using Prettier and ESLint. Active in the background whenever Claude edits a file. Formatting is silent — no prompts, no output unless a formatter fails. Use when you want consistent formatting enforced automatically during a coding session.
code-quality-audit
Run a comprehensive code quality audit covering security, performance, and maintainability. Use for quarterly audits, pre-release reviews, or when onboarding to a large codebase.