gh-issue-fix-flow
Gh Issue Fix Flow
Overview
Resolve a GitHub issue from intake through fix, validation, and push using gh, local edits, XcodeBuildMCP, and git.
Workflow
1) Intake and issue context
- Use
gh issue view <id> --repo <owner/repo> --commentsto get the full issue context. - If the repo is unclear, run
gh repo view --json nameWithOwnerto confirm. - Capture reproduction steps, expected behavior, and any maintainer notes.
2) Locate the code path
- Use
rg -nto locate likely files and entry points. - Read the relevant code paths with
sed -norrg -ncontext. - Follow repo-specific conventions (AGENTS/CLAUDE instructions).
3) Implement the fix
- Edit the minimal set of files.
- Keep changes aligned with existing architecture and style.
- Add tests when behavior changes and test coverage is practical.
4) Build and test
- Use XcodeBuildMCP for required builds/tests:
- Set defaults once:
mcp__XcodeBuildMCP__session-set-defaults. - Build:
mcp__XcodeBuildMCP__build_macosormcp__XcodeBuildMCP__build_sim. - Tests: prefer targeted schemes (e.g.,
mcp__XcodeBuildMCP__test_sim).
- Set defaults once:
- If macOS tests fail due to deployment target mismatches, run the equivalent iOS simulator tests.
- Report warnings or failures; do not hide them.
5) Commit and push
- Check for unrelated changes with
git status --short. - Stage only the fix (exclude unrelated files).
- Commit with a closing message:
Fix … (closes #<issue>). - Push with
git push.
6) Report back
- Summarize what changed and where.
- Provide test results (including failures).
- Note any follow-ups or blocked items.
More from dagba/ios-mcp
swiftui-performance-audit
Audit and improve SwiftUI runtime performance from code review and architecture. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps, and to provide guidance for user-run Instruments profiling when code review alone is insufficient.
62swiftui-ui-patterns
Best practices and example-driven guidance for building SwiftUI views and components. Use when creating or refactoring SwiftUI UI, designing tab architecture with TabView, composing screens, or needing component-specific patterns and examples.
52swiftdata-coredata-persistence
Use when implementing data persistence in iOS apps with SwiftData or CoreData, encountering migration errors, performance issues with fetches, or choosing between persistence frameworks
41programmatic-uikit-layout
Use when building UIKit interfaces without storyboards, setting up Auto Layout constraints with anchors, creating reusable UI components, or encountering layout constraint errors and ambiguous layout warnings
37macos-spm-app-packaging
Scaffold, build, and package SwiftPM-based macOS apps without an Xcode project. Use when you need a from-scratch macOS app layout, SwiftPM targets/resources, a custom .app bundle assembly script, or signing/notarization/appcast steps outside Xcode.
23swiftui-view-refactor
Refactor and review SwiftUI view files for consistent structure, dependency injection, and Observation usage. Use when asked to clean up a SwiftUI view’s layout/ordering, handle view models safely (non-optional when possible), or standardize how dependencies and @Observable state are initialized and passed.
22