mcpField
F
fix-bug

fix-bug

github.com/bytebaseDevelopment3.8k80 installsUpdated 5d ago
Repository

About fix-bug

A structured skill for fixing DBHub bugs from GitHub issues, aimed at developers working in its codebase. It covers issue analysis through testing and pull request creation.

Key features

  1. 01Fetch and analyze GitHub issues
  2. 02Map bugs to DBHub code areas
  3. 03Reproduce issues with tests
  4. 04Implement focused fixes
  5. 05Run relevant verification
  6. 06Prepare and submit pull requests

Use cases

  1. 01Investigate a reported DBHub connection failure
  2. 02Add a regression test for a SQL execution bug
  3. 03Verify a database-specific fix
  4. 04Create a pull request linked to an issue

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/bytebase/dbhub --skill fix-bug

After installing, type/fix-bugin Claude Code to confirm it loaded.

Details

From the project README

Fix Bug from GitHub Issue

Systematic workflow for turning a GitHub issue into a working fix in the DBHub codebase.

Workflow

  1. Fetch → 2. Analyze → 3. Locate → 4. Reproduce → 5. Plan → 6. Implement → 7. Verify → 8. PR

Step 1: Fetch Issue

# From URL: https://github.com/owner/repo/issues/123
gh issue view 123 --json title,body,labels,comments,state

# From another repo
gh issue view 123 --repo owner/repo --json title,body,labels,comments,state
InputHow to fetch
https://github.com/owner/repo/issues/42gh issue view 42 --repo owner/repo
#42 or 42gh issue view 42 (current repo)
owner/repo#42gh issue view 42 --repo owner/repo

Step 2: Analyze Issue

Extract from the issue:

  • What's broken: Expected vs actual behavior
  • Reproduction steps: How to trigger the bug
  • Environment: Database type, connection method (DSN, SSH tunnel, TOML config), transport (stdio/HTTP)
  • Labels/comments: May reveal affected area or prior investigation
  • Linked PRs/issues: Check for related context

Step 3: Locate Relevant Code

Use the issue details to identify which part of the codebase is affected. DBHub has a clear modular structure — most bugs fall into one of these areas:

Bug CategoryWhere to LookKey Files
Connection failuresConnector implementationssrc/connectors/{db-type}/index.ts, src/connectors/manager.ts
SQL execution errorsTool handlerssrc/tools/execute-sql.ts, src/utils/allowed-keywords.ts
Schema/table listingSearch toolsrc/tools/search-objects.ts
DSN parsing issuesParser logicsrc/connectors/{db-type}/index.ts (DSNParser), src/utils/dsn-obfuscate.ts, src/utils/safe-url.ts
SSH tunnel problemsTunnel utilitiessrc/utils/ssh-tunnel.ts, src/utils/ssh-config-parser.ts
TOML config issuesConfig loadingsrc/config/toml-loader.ts, src/types/config.ts
Multi-database routingManager & toolssrc/connectors/manager.ts, src/utils/tool-handler-helpers.ts
Custom tool issuesCustom handlersrc/tools/custom-tool-handler.ts, src/tools/registry.ts
HTTP transportServer setupsrc/server.ts
Read-only violationsSQL validationsrc/utils/allowed-keywords.ts, src/utils/sql-parser.ts
Row limitingSQL rewritingsrc/utils/sql-row-limiter.ts
API endpoint issuesAPI handlerssrc/api/sources.ts, src/api/requests.ts
AWS IAM authToken signingsrc/utils/aws-rds-signer.ts

Search for error messages, function names, or file paths mentioned in the issue. Trace the code path from entry point to the failure.

Step 4: Reproduce

If integration tests exist for the area: Write a failing test that captures the bug. DBHub's test infrastructure makes this straightforward:

  • Database connector bugs → extend existing integration test in src/connectors/__tests__/
  • Utility bugs → add cases to existing unit tests in src/utils/__tests__/
  • Tool handler bugs → add to src/tools/__tests__/
  • Config bugs → add to src/config/__tests__/

Use the test fixtures in src/__fixtures__/ for multi-database or readonly/max_rows scenarios.

If no test infrastructure applies: Trace the code path and confirm the logic flaw by reading.

Step 5: Plan the Fix

For non-trivial fixes (multi-file, architectural impact): use EnterPlanMode.

For simple fixes (single function, clear root cause): proceed directly.

Step 6: Implement

  • Fix the root cause, not just the symptom
  • Keep changes minimal and focused
  • Follow existing code conventions (see CLAUDE.md for style guide)
  • Use parameterized queries for any database operations
  • Validate inputs with zod schemas where appropriate

Step 7: Verify

Run the relevant tests to confirm the fix:

pnpm test:unit                    # Quick check — no Docker needed
pnpm test src/path/to/test.ts     # Run the specific test file
pnpm test:integration             # Full integration suite if needed

Check that:

  • The failing test (if written) now passes
  • No existing tests regressed
  • The diff fully addresses the issue

Step 8: Create PR

  1. Create a branch:

    git checkout -b fix/issue-123
    
  2. Commit changes referencing the issue:

    git add <changed-files>
    git commit -m "$(cat <<'EOF'
    Fix: <short description>
    
    Closes #123
    EOF
    )"
    
  3. Push and create the PR:

    git push -u origin fix/issue-123
    gh pr create --title "Fix: <short description>" --body "$(cat <<'EOF'
    ## Summary
    <What was broken and how this fixes it>
    
    ## Changes
    <Bullet list of changes>
    
    Closes #123
    
    ## Test plan
    - [ ] Existing tests pass
    - [ ] New test covers the bug scenario (if applicable)
    EOF
    )"
    
  4. Return the PR URL to the user.

Common Mistakes

  • Fixing symptoms instead of root cause: Trace the full code path before patching
  • Skipping reproduction: A fix without a repro is a guess
  • Scope creep: Fix the reported issue, don't refactor surrounding code
  • Missing edge cases: Check if the fix handles related scenarios mentioned in comments
  • Not testing with the right database: If the bug is database-specific, test with that connector

Comments

Markdown supported