GitLab Solver

Implements fixes for GitLab issues with full verification, testing, and MR creation. Keeps the user in the loop.

Workflow

Step 1: Determine Project & Issue

Project path: - If the user mentions a project, use it. - Otherwise, check if the current workspace is a Git repository. If it is, derive the GitLab project path from git remote -v (e.g., owner/repo-name). Use this as the default project. - If the workspace is not a Git repository, ask the user which GitLab project to work on.

Issue: If the user specifies an issue IID, use it. Otherwise, ask which issue to fix.

Step 2: Get Issue Context

1. Call gitlab_get_issue to read the full issue and all comments.
2. Look for a research comment (from gitlab-researcher or otherwise).
3. Decide what to use from the comments:
4. If research exists and looks solid, use it as your starting point.
5. If research is partial, supplement with your own investigation.
6. If no useful research, do your own research:
   • Use Context7 to fetch current documentation for relevant libraries/frameworks. If Context7 is unavailable or returns no results, fall back to web search for the same documentation.
   • Search the web for similar issues, solutions, and best practices.
7. Read relevant code in the local workspace to understand the problem.
8. Read AGENTS.md if available for project conventions and gotchas.

Step 3: Plan Implementation

Present a plan to the user:

## Implementation Plan for Issue #{IID}

**What's broken:** [brief description]
**Root cause:** [explanation]
**Approach:** [how you'll fix it]

**Files to modify:**
- `src/file.py` — [what changes]
- `tests/test_file.py` — [what tests]

**Docs to update:**
- [README, AGENTS.md, CHANGELOG, etc.]

**Risks:** [what could go wrong]

Wait for user approval or modifications before proceeding.

Step 4: Prepare Branch

1. Get project access token: gitlab_get_project_access_token with the project path.
2. Create branch: gitlab_create_branch with branch: "fix/{iid}-{short-desc}", ref: "<default-branch>" (get from gitlab_get_project → default_branch).
3. Clone repo locally using the token's HTTP URL.
4. Sync with default branch — ensure branch is up to date.

Step 5: Implement Fix

Make changes following project conventions from AGENTS.md if available. Adhere to the project's coding style, naming conventions, and patterns.

Step 6: Test

1. Run existing tests to establish a baseline.
2. Add tests for the fix.
3. Run tests again to verify.
4. Run linter/formatter if available.
5. If integration tests are relevant, note them (they may require additional credentials).

If tests fail, fix and re-run until green.

Step 7: Update Documentation

Update any relevant documentation: - README.md — tool reference, configuration, quick start - AGENTS.md — gotchas, setup, structure - CHANGELOG.md — entry under appropriate section - Tool descriptions if behavior changed - pyproject.toml or equivalent if dependencies changed

Step 8: Handle Related Issues

• Update any issues affected by this change.
• Create new issues if the fix reveals other problems.
• Close duplicates if found.

Step 9: Commit & Push

git add -A
git commit -m "fix: {concise description}

- What changed and why
- References issue #{IID}"
git push origin fix/{iid}-{short-desc}

Step 10: Create MR

Use gitlab_create_merge_request with a detailed description:

## What Changed

[Clear description of the fix]

## Why

[Root cause and motivation. Reference issue #{IID}.]

## How to Test

1. [Step-by-step testing instructions]
2. [How to verify the fix works]
3. [What to check for regressions]

## Changed Files

- `src/file.py` — [brief description]
- `tests/test_file.py` — [brief description]

## Related Issues

- Fixes #{IID}
- [Any other related issues]

## Notes for Reviewer

[Any context the reviewer needs. Known limitations, trade-offs, things to
watch.]

Step 11: Final Summary

Show the user:

## Done! Issue #{IID}

**Branch:** `fix/{iid}-{short-desc}`
**MR:** [link to MR]
**Tests:** [passing/failing]

**Next steps:** Ready for review? Use the `gitlab-reviewer` skill to conduct
a thorough code review before merging.

Important

• Keep the user in the loop — show plan, wait for approval, show results.
• Always run tests before pushing — never push broken code.
• Check AGENTS.md before every change if available — many gotchas are documented there.
• Sync with default branch before starting — avoid merge conflicts.
• MR descriptions should be self-contained — a reviewer should understand everything from the MR alone.
• If the fix is more complex than expected, pause and consult the user before proceeding.
• Online research is required when no research comment exists — use Context7 (with web search fallback) and web search to ground your implementation in current best practices.

When NOT to Use

• When the user just wants to research without implementing.
• When the user wants to do a quick, trivial fix without the full workflow.
• When the issue is clearly invalid or a duplicate (suggest closing instead).